libblk / blkid not recognizing Atari FAT16 variation

libblk / blkid not recognizing Atari FAT16 variation

[Emmanuel Kasper]

Hi List

As said in $subject,

  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.

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

Re: libblk / blkid not recognizing Atari FAT16 variation

[Karel Zak]

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@redhat.com>
 http://karelzak.blogspot.com

Re: libblk / blkid not recognizing Atari FAT16 variation

[Emmanuel Kasper]

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

libblk / blkid not recognizing Atari FAT16 variation

[Emmanuel Kasper]

Hi List

As said in $subject,

  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 )

fsck.vfat, and the kernel can check and mount such a 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.

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