« BackMkfs.fat on Linux vs. OS/2 2.1uninformativ.deSubmitted by zdw a year ago
  • PreInternet01 a year ago

    > The rest of the "Extended BIOS Parameter Block" looks like it isn't relevant data, like the volume label or the volume's serial number

    No, that's the exact reason why OS/2 checks the OEM ID. The volume label was initially used to detect disk swaps (so that if an application has open files on disk 1, it does not destroy data on disk 2 by writes after the user replaces the floppy in the drive, which could not be detected in hardware until much later, and even then not unless you were using a Mac, basically).

    Of course, the volume label is user-set (so duplicates are possible), and more often not set than meaningful in any case. So, DOS 3.3 added the (unique-at-format-time) volume serial number. Which was always all-zeroes (or garbage) on pre-3.3 disks, hence the need for the OEM ID check.

    • rwmj a year ago

      Doesn't mention what hypervisor is used (qemu? bochs?) but if it speaks NBD then you can do:

        $ nbdkit floppy /path/to/some/directory
      which will serve the data in that directory as a floppy disk over NBD on port 10809. In qemu you can attach this with -drive nbd:localhost:10809.

      It doesn't use mkfs.fat, instead a custom FAT generator, and I think people have used it with ancient guests (however I'd have to check to be sure, either way should be easy to patch).

      • blueflow a year ago

        maximum control over your DOS filesystems: Create the boot sector with nasm and have mformat -B (from mtools) fill in the disk geometry.

        For devices with CHS addressing, information in the BPB is crucial for getting the CHS geometry. It has to match how the medium was formatted.

        • anthk a year ago

          mkfs.vfat -F 16. Also a FreeDOS boot disk could work too, with Qemu.