util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* fdisk not wiping sector 0 before writing new MBR
@ 2019-07-04 21:55 Mike Fleetwood
  2019-07-17 10:16 ` Karel Zak
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Fleetwood @ 2019-07-04 21:55 UTC (permalink / raw)
  To: util-linux

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-07-17 10:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-04 21:55 fdisk not wiping sector 0 before writing new MBR Mike Fleetwood
2019-07-17 10:16 ` Karel Zak
2019-07-17 10:26   ` Karel Zak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).