Le 14/09/2020 à 13:26, Karel Zak a écrit : > 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. indeed but disktype, available in the Debian archive, recognizes an Atari bootable sector :) $ curl http://www.subsole.org/static/retrocomputing/st_mint-1.2.img.zip | funzip > ahdi.img $ dd if=ahdi.img of=boot.sector skip=1024 count=512 bs=1 $ disktype boot.sector --- boot.sector Regular file, size 512 bytes FAT16 file system (hints score 3 of 5, ATARI ST bootable) Unusual sector size 4096 bytes Volume size 63.95 MiB (67051520 bytes, 8185 clusters of 8 KiB) I had a look at how disktype does this internally and disktype computes the Atari m68k specific checksum described in https://en.wikipedia.or/wiki/Design_of_the_FAT_file_system. see https://sources.debian.org/src/disktype/9-10/dos.c/#L477 Now for my use case I am not actually using an Atari Computer with Linux, but I am using removable media between an Atari and a PC. The lack of support for the Atari FAT prevents udisks and friends to mount the partition as an unpriviledged user via `udisksctl mount` Also people using emulators have to do loops around to access the content of a disk image (https://hatari.tuxfamily.org/doc/manual.html#Moving_files_to_from_hard_disk_images) Is that something we could consider ? Manu
