Hi, > Thinking it through, I am happy for us to make this change from MBR to > GPT.
Me not so much. GPT has that backup at the end of the device. But when an image is made, the size of the storage device is not known. So after putting (cloning) the image onto the USB stick, the backup GPT is misplaced. So we'd actually need an adjustment step after cloning, although the boot firmwares don't care for that flaw. But partition editors do. (Modern versions of program sfdisk fix the problem silently when any manipulation of GPT is done. E.g.: echo 'name=DATA' | sudo sfdisk -a /dev/sdc ) But if more machines boot by GPT than by MBR partition table, i can hardly be against it. Let's see what problems this causes ... > I do see that the GPT has an extra partition at the end; is this required > for alignment? It's the padding against the TAO CD Read-Ahead Bug. This bug is caused by an ambiguity in SCSI MMC specs about command READ CAPACITY when the last track ends by two TAO Run-out blocks. About 80 percent of CD capable drives count them as readable, which they are not for data read command READ(10). By a cargo cult theory of last century, ISO 9660 producers and most burn programs add 300 KiB of padding to keep legitimate read operations away from the dangerous end of the device. Actually it would have to be the buffer size of Linux when reading ahead of the block range that is requested by the ISO 9660 filesystem driver. (If i had a better standing at linux-scsi it would already be fixed for single session by testing the last two blocks for readability and adjusting the device size perception of the kernel if they are not readable by READ(10). I have made me a kernel which does this.) With ISO images which never end up on a CD you can safely suppress this padding by xorriso -as mkisofs option -no-pad Even then most CD burn programs will add their own padding by default or use write type SAO which produces no Run-out blocks. > I haven't seen such partition entries when using MBR. With MBR partition table the padding is either counted as part of partition 1 (old Fedora/Debian/Ubuntu layout) or not marked as partition (with appended partition). The reason for that GPT partition is probably in my discussions with Vladimir Serbinenko when i made xorriso ready for serving under grub-mkrescue. If we find compelling reasons not to create it, i could try to suppress this. (The boot preparation code in libisofs is quite entangled by the many variations and little stunts which it accumulated over time.) Have a nice day :) Thomas -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1886148 Title: failure to boot groovy daily To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1886148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs