Hi, the Ubuntu system really manipulates the installation stick's partition table if i choose to try out Ubuntu.
It looks like i was involved as adviser when the addition of MBR partition 2 was introduced to "casper's persistent partition creation". See https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308 beginning at comment #60 up to https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/63 (Sorry for my dim memory. It's just half a year ago.) Can we assume that Steve Langasek is already subscribed to this bug report ? Else we should notify him. I repeat my opinion that under these circumstances no single ISO can serve all firmwares. ------------------------------------------------------------------------- Details: I tested the result of xorriso-1.5.5 repacking gnome-disks-style, i.e. with only one MBR partition and no MBR boot flag: MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 5503775 GPT : N Info ... GPT lba range : 64 5503712 5503775 ... GPT partition flags: 1 0x0000000000000005 GPT start and size : 1 64 5493608 The stick stays that way if i reset the computer when it shows the first white-on-black GRUB menu. (Stick afterwards inspected by the Debian on the SSD of that machine.) If i instead choose "Ubuntu" and the try-out option in the subsequent menu, i get to the drawing of a stubbly hippo and cannot find any way to start a shell terminal. (Is it Gnome or is it Ubuntu, which is to blame ? The user impression for me is abysmal. I was unix-ly socialized in 1985.) At least i find the logout button to the upper right. Afterwards, xorriso on Debian reports about the stick MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 245759999 MBR partition : 2 0x80 0x00 0 1 GPT : N Info ... GPT lba range : 64 245759936 245759999 ... GPT partition flags: 1 0x0000000000000005 GPT start and size : 1 64 5493608 The difference affects the MBR partition table, where the protective partition was expanded to the size of the USB stick (nominally "128 GB"). Further the MBR partition of type 0x00 with boot flag was added. Also affected is the GPT header block, were the partitionable size was adapted to the real stick size. The backup GPT was moved to the end of the stick's block range. Contrary to my expectation this looks like the work of a partition editor, which can deal with GPT. On the other hand it - or some other program - is willing to add MBR partition 2 to a GPT. At this point i began to remember that Steve Langasek, sudodus, and i discussed the same effect back last year: The HP machine, which needed the MBR boot flag, booted the new ISO once because casper's partition editing then removed MBR partition 2. Now casper probably does after the partition editor run: echo -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' | \ dd of="$DEVICE" bs=1 seek=462 conv=notrunc 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/1922342 Title: HIrsute live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
