Hi, This is a bit more of a speculative than my other recent one, but I saw this quote in aix.c: "All fdisk-like programs has to properly wipe the first sector. Everything other is a bug." Using fdisk to create an MBR over the top of a whole disk FAT32 (and probably FAT16) file system doesn't clear any of the FAT32 boot record (aka super block). Blkid and wipefs report this as just an MBR, but because the boot record is intact, GNU parted reports this still as a whole disk FAT32 file system. This is from a GParted issue report where a user had an SD card that must have originally come with a whole disk FAT32 file system and then the user partitioned it over the top with fdisk. GitLab GParted issue 64 - Add support for Nobbs-partitioned SD cards https://gitlab.gnome.org/GNOME/gparted/issues/64 Test case: Create a whole disk FAT32 file system. # dd if=/dev/zero bs=1M of=/dev/sdb # mkfs.fat -F32 -I /dev/sdb # ./blkid /dev/sdb /dev/sdb: UUID="1EF0-1723" TYPE="vfat" # ./wipefs /dev/sdb DEVICE OFFSET TYPE UUID LABEL sdb 0x52 vfat 1EF0-1723 sdb 0x0 vfat 1EF0-1723 sdb 0x1fe vfat 1EF0-1723 Create a single primary partition covering the whole disk. # ./fdisk --version lt-fdisk from util-linux 2.34.24-e3bb9 # ./fdisk /dev/sdb n p [Return] (defaults to 1) [Return] (defaults to 2048) [Return] (defaults to 16777215) w # ./fdisk -l /dev/sdb Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors Disk model: VBOX HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 16777215 16775168 8G 83 Linux util-linux tools now report this as only containing an MBR. # ./blkid /dev/sdb /dev/sdb: PTTYPE="dos" # ./wipefs /dev/sdb DEVICE OFFSET TYPE UUID LABEL sdb 0x1fe dos But GNU parted still sees this as a whole disk FAT32 file system. # parted --version parted (GNU parted) 3.2 ... # parted /dev/sdb unit s print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdb: 16777216s Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End 1 0s I used hexdump -C to look at sector 0 after writing the FAT32 and after writing the MBR. The only bytes which changed were those 16 bytes storing partition 1 in the MBR. None of the other bytes in sector 0 changed, hence why parted was able to misidentify this as a FAT32 file system. Then just remove that partition and blkid and wipefs again detect it as a whole disk FAT32 file system. # ./fdisk /dev/sdb d w # ./blkid /dev/sdb /dev/sdb: UUID="1EF0-1723" TYPE="vfat" # ./wipefs /dev/sdb DEVICE OFFSET TYPE UUID LABEL sdb 0x52 vfat 1EF0-1723 sdb 0x0 vfat 1EF0-1723 sdb 0x1fe vfat 1EF0-1723 I don't think a user can have any expectation that if a whole disk FAT32 file system "superfloppy" was bootable, that after using fdisk to write an MBR over the top, that it can still be bootable, without writing new boot code to the disk. Thank you for your consideration, Mike