syslinux creating unexpected partitions on disk image
I’m encountering some odd behavior while trying to install a bootloader on a disk image. Here’s the process I followed:
$ dd if=/dev/zero of=test.img status=progress bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 0.190117 s, 1.1 GB/s
$ mkfs.ext2 test.img
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 204800 1k blocks and 51200 inodes
Filesystem UUID: f6442813-7b8c-4636-b69e-334696e0840b
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
$ sudo mount test.img mount-point/ -o loop
$ fdisk -l test.img
Disk test.img: 200 MiB, 209715200 bytes, 409600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
$ sudo extlinux -i mount-point/
mount-point/ is device /dev/loop0
Warning: unable to obtain device geometry (defaulting to 64 heads, 32 sectors)
(on hard disks, this is usually harmless.)
$ fdisk -l test.img
Disk test.img: 200 MiB, 209715200 bytes, 409600 sectors
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: 0x20ac7dda
Device Boot Start End Sectors Size Id Type
test.img1 3224498923 3657370039 432871117 206.4G 7 HPFS/NTFS/exFAT
test.img2 3272020941 5225480974 1953460034 931.5G 16 Hidden FAT16
test.img3 0 0 0 0B 6f unknown
test.img4 50200576 974536369 924335794 440.8G 0 Empty
Partition table entries are not in disk order.
I can’t understand why the extlinux -i command would create new partitions on the disk image. I suspect it might be modifying some filesystem metadata, but I’d appreciate some clarification on the details. Additionally, is it possible to install Syslinux on an unpartitioned disk image?
The MBR partition table is a very simple structure at the end of the very first 512-byte block of the disk. It contains no checksums, hashes or other error-protection features.
By running fdisk -l against the filesystem/partition image you’ve created, you are effectively forcing it to misinterpret its first block (the Partition Boot Record, or PBR for short) as a MBR. This results in nonsensical output, as you demonstrated.
If I recall correctly, the PBR created by extlinux would contain boot code in the locations occupied by the actual partition table in a MBR. So fdiskwould be reading parts of extlinux PBR boot code and trying to display it as MBR contents. It is no wonder the output makes no sense!