-
Notifications
You must be signed in to change notification settings - Fork 113
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
Comments
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. |
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. |
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. |
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. |
Refiled as https://bugzilla.suse.com/1172909 which is publicly accessible. |
Isn't this a dup of #111? |
Can you check if pull request #153 fixes this issue? |
#153 was merged |
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
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? |
(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:
and the installation will report an error.
Curiously enough, 'mkfs.vfat -F 32 -S 2 /dev/nvme0n1p1' works:
Why do I have to specify these parameters?
The text was updated successfully, but these errors were encountered: