On Fri, Sep 11, 2020 at 06:00:25PM +0200, Emmanuel Kasper wrote: > truncate --size 64M fs.img > mkfs.fat -A fs.img # -A for Atari variant > blkid fs.img # nothing > > (a real disk image with partitions can also be downloaded here > https://subsole.org/st_mint ) > > However fsck, and kernel can check and mount this partition. > The kernel detects properly the fat when mounting a block device, > without having to force the filesystem on the command line. > > From this doc about the Atari fat format, > info-coach.fr/atari/documents/_mydoc/Atari_HD_File_Sytem_Reference_Guide.pdf > > I see on page 9 > that the main differences between MS DOS and Atari FAT, is about the fat > logical sector size, > which can goes over 512 bytes in the Atari FAT, whereas in MSDOS FAT it > is always 512 bytes. This is not the issue. The problem is that Atari FAT does not contain any magic string. There is also missing MBR signature (0x55 0xAA) which is used for old FAT floppies without magic strings. So, libblkid completely ignores stuff on the device ... If I add the first bytes from the device as magic string to libblkid and disable MBR signature check than the rest of the verification pass. Note that "`.mkdosf" from the begin of the device is mkfs specific stuff it's probably bad idea use it as a regular magic string. It's also pretty fragile to avoid magic strings at all in this case, because something-like-FAT is pretty common used by many random media. Frankly, it seems better to force Atari users to use "vfat" in the fstab :-) BTW, the old good file(1) returns nothing for the Atari FAT too. Karel See Atari FAT (mkfs.fat -A): $ hexdump -C fs.img 00000000 60 1c 6d 6b 64 6f 73 66 a1 0c 36 00 08 02 01 00 |`.mkdosf..6.....| 00000010 02 00 02 00 80 f8 10 00 20 00 40 00 00 00 00 00 |........ .@.....| 00000020 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00008800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00008810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 04000000 and now regular FAT16 (mkfs.vfat -F 16): hexdump -C fs.img 00000000 eb 3c 90 6d 6b 66 73 2e 66 61 74 00 02 04 04 00 |.<.mkfs.fat.....| 00000010 02 00 02 00 00 f8 80 00 20 00 40 00 00 00 00 00 |........ .@.....| 00000020 00 00 02 00 80 00 29 1b d0 9c a3 4e 4f 20 4e 41 |......)....NO NA| 00000030 4d 45 20 20 20 20 46 41 54 31 36 20 20 20 0e 1f |ME FAT16 ..| 00000040 be 5b 7c ac 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 |.[|.".t.V.......| 00000050 5e eb f0 32 e4 cd 16 cd 19 eb fe 54 68 69 73 20 |^..2.......This | 00000060 69 73 20 6e 6f 74 20 61 20 62 6f 6f 74 61 62 6c |is not a bootabl| 00000070 65 20 64 69 73 6b 2e 20 20 50 6c 65 61 73 65 20 |e disk. Please | 00000080 69 6e 73 65 72 74 20 61 20 62 6f 6f 74 61 62 6c |insert a bootabl| 00000090 65 20 66 6c 6f 70 70 79 20 61 6e 64 0d 0a 70 72 |e floppy and..pr| 000000a0 65 73 73 20 61 6e 79 20 6b 65 79 20 74 6f 20 74 |ess any key to t| 000000b0 72 79 20 61 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 |ry again ... ...| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00010800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00010810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 04000000 > > fsck.vfat -v fs.img > fsck.fat 4.1 (2017-01-24) > Checking we can access the last sector of the filesystem > Boot sector contents: > System ID "kdosf" > Media byte 0xf8 (hard disk) > 2048 bytes per logical sector <---- more than 512 bytes > > > However after a quick glance on the code in fat_valid_superblock() > at > https://github.com/karelzak/util-linux/blob/master/libblkid/src/superblocks/vfat.c#L218 > > it seems to me that libblk should would work with sectors up to 4096 > bytes, so I am bit puzzled. > Any pointers on what could be missing here ? > > Manu > > > -- > You know an upstream is nice when they even accept m68k patches. > - John Paul Adrian Glaubitz, Debian OpenJDK maintainer > -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com
