Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mkfs.fat fails to format 2G NVMe partition #139

Closed
mcepl opened this issue Jun 12, 2020 · 11 comments
Closed

mkfs.fat fails to format 2G NVMe partition #139

mcepl opened this issue Jun 12, 2020 · 11 comments

Comments

@mcepl
Copy link

mcepl commented Jun 12, 2020

(Originally filed on openSUSE bugzilla as https://bugzilla.suse.com/1172863)

Trying to run mkfs.vfat to create the EFI partition on an NVMe-over-Fabrics device results in:

# mkfs.fat /dev/nvme0n1p1
mkfs.fat 4.1 (2017-01-24)
WARNING: Not enough clusters for a 32 bit FAT!
mkfs.fat: Attempting to create a too large filesystem
# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 931.5G  0 disk 
├─sda1        8:1    0   500M  0 part /boot/efi
├─sda2        8:2    0    40G  0 part 
├─sda3        8:3    0    40G  0 part /
├─sda4        8:4    0  31.2G  0 part [SWAP]
├─sda5        8:5    0    40G  0 part 
└─sda6        8:6    0  31.2G  0 part 
nvme0n1     259:1    0    32G  0 disk 
├─nvme0n1p1 259:2    0   1.9G  0 part 
├─nvme0n1p2 259:3    0   1.9G  0 part 
└─nvme0n1p3 259:4    0  28.3G  0 part /mnt

and the installation will report an error.

Curiously enough, 'mkfs.vfat -F 32 -S 2 /dev/nvme0n1p1' works:

# mkfs.vfat -F 32 -s 2 /dev/nvme0n1p1
mkfs.fat 4.1 (2017-01-24)
# blkid /dev/nvme0n1p1
/dev/nvme0n1p1: UUID="077B-E051" TYPE="vfat" PARTLABEL="boot" PARTUUID="7f8c144a-15b5-49ae-93f7-b5665c4c178a"

Why do I have to specify these parameters?

@pali
Copy link
Member

pali commented Jun 12, 2020

Could you try to use version from git?

I know that cluster parameter calculation in mkfs.fat is incorrect and I have fixes for it, but they depends on my already open pull requests. Therefore I can create a pull request with calculation fixes after my all open pull requests are reviewed and merged.

@pali
Copy link
Member

pali commented Jun 12, 2020

Note that external bug link is not accessible.

@mcepl
Copy link
Author

mcepl commented Jun 12, 2020

Note that external bug link is not accessible.

Give me your email address on openSUSE Bugzilla and I will add you to the CC list.

@pali
Copy link
Member

pali commented Jun 12, 2020

It would be better to have all details available publically, so other people who watch this github issue could read all information and could either provide patch/fix/comment. I'm probably not the only person here.

But I can understand that external bug link/report is not open to everybody and in some situation cannot be (e.g. it may contain sensitive information, etc.).

@mcepl
Copy link
Author

mcepl commented Jun 12, 2020

It would be better to have all details available publically, so other people who watch this github issue could read all information and could either provide patch/fix/comment. I'm probably not the only person here.

But I can understand that external bug link/report is not open to everybody and in some situation cannot be (e.g. it may contain sensitive information, etc.).

There is not anything really secret about the bug, but the bug has been reported against the enterprise SLE distribution, and these bugs are kept secret as matter of policy. Getting you on CC, it would be easier to communicate with the original bug reporter, but I can pass the messages in between you if you prefer that.

@pali
Copy link
Member

pali commented Jun 12, 2020

Well, currently I do not have time to look deeply at this issue. I can look at it later, after all my other patches for dosfstools project are reviewed and merged. Just I do not want to prepare and open another set (conflicting to my existing) changes to dosfstools.

This is why I said that probably other people could be interested in details about this issue more then me.

@mcepl
Copy link
Author

mcepl commented Jun 15, 2020

Refiled as https://bugzilla.suse.com/1172909 which is publicly accessible.

@tomty89
Copy link

tomty89 commented Nov 26, 2020

Isn't this a dup of #111?

@pali
Copy link
Member

pali commented Jan 8, 2021

Can you check if pull request #153 fixes this issue?

@pali
Copy link
Member

pali commented Jan 14, 2021

#153 was merged

@pali pali closed this as completed Jan 14, 2021
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Mar 4, 2021
dosfstools 4.2 - released 2021-01-31
====================================

fatlabel now accepts two new options. When given the -i or --volume-id option,
fatlabel changes to an alternate mode where it displays or changes the volume
serial number instead of the volume label. With the -r or --reset option, it
will remove the label or (in the alternate mode) generate a new volume serial
number.

The user prompting for interactive fsck has been overhauled. Now it will
directly react to a pressed key without the user having to additionally press
enter. The changed prompting is also consistently repeating the prompt when
invalid input is given.

The legacy check whether it is running on Atari hardware when compiled for 68k
in order to automatically switch to Atari mode is now disabled by default. It
can be compiled in with the new configure switch --enable-atari-check.

Both mkfs and fsck now have a new option --variant=TYPE where TYPE can be
'standard' or 'atari' to explicitly select one of those variants rather than
having to toggle between them with -A.

fsck, mkfs and fatlabel were fixed to process volume label correctly. Previously
there were many issues during processing labels. Fixes issues are: leading byte
0xE5 of root label needs to be handled in special way, label cannot contain some
special characters, label itself is stored according to the current DOS codepage
which may be specified by a new --codepage option. fatlabel now reads volume
label only from the root directory to be compatible with existing systems like
MS-DOS 5.00, MS-DOS 6.22, MS-DOS 7.10, Windows 98, Windows XP, Windows 7, 8, 10
and also with the Linux mlabel from mtools project. fsck was extended to fix
incorrect volume labels and ensure that volume label from the root directory is
same as the volume label stored in boot sector. Old versions of dosfslabel read
label only from the boot sector. So with all these changes fsck now ensures
compatibility with both MS-DOS/Windows and old Linux/dosfslabel world.

fsck now allows spaces in the middle of SFNs. Previous behavior (when spaces
are disallowed) can be achieved by a new option -S.

Both mkfs and fsck now have fixed Year 2038 Bug. mkfs may still set filesystem
timestamp to 1980-01-01 00:00:00 (beginning of the FAT era) in case operating
system has Year 2038 Bug and cannot provide current time in time_t variable.

Some memory leaks were fixed in fatlabel and fsck to make valgrind happy.

Processing of command line arguments in all tools were fixed to ensure that
invalid options are not accepted anymore and proper error message is thrown
instead of trying to continue with uninitialized or undefined value.

In fsck and fatlabel were fixed issues that faulty filesystems were able to
trigger integer overflows during reading them.

mkfs now has a new option --offset for specifying offset at which filesystem
would start. This is useful when formatting FAT filesystem on disk image with
MBR table without need to use loopback kernel driver with partx to access only
specific partition.

All tools now can be compiled without iconv library and in this case they
support only CP850 codepage which is integrated into tools. This internal
CP850 codepage can be used also when tools were compiled with iconv library
which do not support CP850 (e.g. iconv from GNU libc without installed gconv
shared libraries).

Manual pages were updated to clarify some ambiguous options and descriptions.
fatlabel has a new section with details about volume label and codepage issues.

mkfs now has a new option --mbr which fills (fake) MBR table with one partition
which spans whole disk device. This (fake) MBR table is needed only for
non-removable disks used on Microsoft Windows systems and only when formatting
whole unpartitioned disk.

mkfs now calculates CHS geometry according to the SD Card Part 2 File System
Specification. For SD cards with more than 256MB capacity is this new CHS
calculation same as CHS calculation defined for hard disks via LBA-Assist
Translation. So CHS geometry calculation in mkfs is now compatible with both
SD Card specification and also LBA-Assist Translation. Moreover mkfs now has
also a new option -g for specifying CHS geometry manually if it is needed for
compatibility with some SD card readers. CHS geometry is part of FAT boot
sector which mkfs.fat must fill.

fsck now checks for DOS Clean Shutdown bit and marks filesystem as clean after
successful run. This is for compatibility with Microsft Windows 98 and also with
Windows NT-based variants.

Dependency on systemd/udev was completely removed from mkfs tool. But there is
no lost or removed functionality. Existing systemd/udev code was rewritten to
directly access sysfs and new implementation has less lines of code as previous
implementation which used systemd/udev libraries.

mkfs was fixed to setup FAT32 backup boot sector correctly.

mkfs's -D option (BIOS drive number) was relaxed to support also higher level
hard disk and floppy devices (second, third, ...).

fsck now preserve reserved fields in info sector. They are used by other systems
(e.g. FSIBOOT stage of lDOS boot32.asm), hence why are reserved.

fsck was extended to check and fix that first two entires in directory
structures are . and ..

mkfs now aligns total number of sectors to be multiple of the value of sectors
per track which is stored in FAT boot sector. This requirement is needed by DOS
systems and also by Linux FAT tools from mtools project. Alignment can be turned
off by -a option.

mkfs is now able to calculate FAT32 cluster size also for disks which have
sector size different than 512 bytes. Note that this calculation is not optimal.
It is just first step which ensures that mkfs does not fail during formatting
Native 4K disks.

mkfs cluster calculation was fixed to correctly handle differences between
FAT12 and FAT16 variants. mkfs now explicitly disallow to create FAT filesystem
with 4085 or 4086 clusters because Windows fastfat.sys detects such filesystem
as FAT12 but Linux msdos.ko/vfat.ko detects it as FAT16. mkfs now avoids this
situation to happen by fully automatic increasing or decreasing cluster size.

fsck now has a new option -F which can be used to specify FAT table used for
reading whole FAT filesystem. It can be useful in situation when user wants
to do recovery and filesystem repairing from second FAT table independently
of what fsck thinks that is the best.

fsck was extended to try fixing first FAT cluster but only when -F option is
specified. Previously when first FAT cluster was broken, fsck just printed
error: "Both FATs appear to be corrupt. Giving up." and failed.

fatlabel was fixed to not call parts of fsck procedure and to not print
warning or log messages on stdout as it conflicts with expected label
output on stdout.

A test suite was heavily extended and now it also checks that fsck repairs
broken filesystem into the expected state.

List of fixed issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803391
dosfstools/dosfstools#13
dosfstools/dosfstools#18
dosfstools/dosfstools#22
dosfstools/dosfstools#29
dosfstools/dosfstools#32
dosfstools/dosfstools#38
dosfstools/dosfstools#39
dosfstools/dosfstools#43
dosfstools/dosfstools#45
dosfstools/dosfstools#52
dosfstools/dosfstools#53
dosfstools/dosfstools#54
dosfstools/dosfstools#64
dosfstools/dosfstools#66
dosfstools/dosfstools#69
dosfstools/dosfstools#70
dosfstools/dosfstools#74
dosfstools/dosfstools#88
dosfstools/dosfstools#99
dosfstools/dosfstools#111
dosfstools/dosfstools#139
dosfstools/dosfstools#151
@dm17
Copy link

dm17 commented Mar 10, 2021

I have a similar scenario with 1GB, nvme, but no error at end - just the warning. No warning if I use 'mkfs.vfat -F 32 -S 2 /dev/nvme0n1p1'... Either way there seemed to be no issue until I mounted it and see the 'df -h' reports 491K instead of 1024MB. I'm not sure how to debug this - any ideas?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants