Hi Thorsten, On 2024-01-29 17:04:12+0000, Thorsten Glaser wrote: > Background: https://github.com/grml/grml/issues/205 > > Using fdisk 2.36.1-8+deb11u1 from util-linux to create an extra > partition on a USB stick on which I had previously written an > ISO 9660 image does something to the data on the stick to make > klibc fstype not recognise it as ISO 9660 any more. Specifically, > it corrupts some data at some location within the first 4 MiB of > the stick but outside of the first 512 byte of it, as restoring > those first 4 MiB then re-restoring the MBR to the state fdisk > had written makes it work again. > > This is a data corruption bug. I expect fdisk to change precisely > the MBR and nothing else unless told so. When trying your reproduction steps with a newer version of fdisk I instantly get greeted like this: # fdisk /dev/loop0 Welcome to fdisk (util-linux 2.39.3). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details. Command (m for help): p Disk /dev/loop0: 492.25 MiB, 516161536 bytes, 1008128 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: 0x773b5e3b Device Boot Start End Sectors Size Id Type /dev/loop0p1 * 0 1007615 1007616 492M 0 Empty /dev/loop0p2 592 8783 8192 4M ef EFI (FAT-12/16/32) I guess your version does the same, but maybe is not printing the warning. So the disk gets converted to a normal MBR layout and the ISO signature get wiped. Which makes sense as the ISO image would need to be remastered. > Is there a way we can make it not corrupt such media? Did you look into grml2usb? This is what [0] recommends to achieve persistence. [0] https://wiki.grml.org/doku.php?id=persistency Thomas
