Hi, José Marinho wrote: > changes only work at first boot [...] > This happened today with the new version of xorriso and yesterday with > "dd if=/dev/zero bs=1 count=16 of="$NEW" conv=notrunc seek=462" command. > [...] > the output of two xorriso commands BEFORE trying to boot from > the stick, just after dd the iso file on it. > https://launchpadlibrarian.net/540588248/boot1.txt
So xorriso is now able to at ISO production time do what gnome disks did for Lucap to make the stick bootable. The fact that "dd ... seek=462" did the trick too, indicates that the problem is associated with the MBR partition 2. (So probably the command -boot_image any mbr_force_bootable=off after -boot_image any replay would be sufficient, whereas -boot_image any gpt_iso_bootable=on -boot_image any gpt_iso_not_ro=on were not really needed with the xorriso-1.5.5 run. If you are curious, you could check this. Just to be sure.) > The second one (boot2.txt) > [https://launchpadlibrarian.net/540588529/boot2.txt] > is the same but AFTER the first successful boot. Surprisingly the MBR dummy partition is back again. (The "GPT partition flags:" of GPT partition are the same as in boot1.txt, namely 0x0...5, which indicates that not the "$ORIG" ISO sneaked in with flags value its 0x1...1.) What does happen if you zeroize it again ? dd if=/dev/zero bs=1 count=16 of=/dev/sdd conv=notrunc seek=462 Does it boot and then that partition gets installed again ? Does the stick stay bootable (i.e. without MBR partition 2) if you end the boot attempt at the first GRUB menu which shows up ? ------------------------------------------------------------------------ I have no idea how the MBR partition slot 2 gets back onto the stick. There is no backup of it which could be restored by any partition editor. Somehow the bootloader or the booted system install that partition. This partition is not an official GRUB feature, although it was originally invented as workaround of a boot problem with grub-mkrescue ISOs on old HP laptops. (One has to add xorrisofs option --mbr-force-bootable to the grub-mkrescue run in order to get that second partition.) Ubuntu intentionally brings the second MBR partition into the ISO. But i wonder which stage of a booting Ubuntu system copies the original MBR partition table over the table of the stick from where it booted. I am doubtful that a modern partition editor would be willing to create such an MBR partition on a device with proper "protective" MBR partition table and thus with valid GPT. So when it happens, it seems to be some raw binary operation, similar to our dd run which removes the partition. I will try to reproduce this strange behavior, but would still be clueless how to identify the particular culprit in the booting system. Any idea is welcome. ------------------------------------------------------------------------ Whatever exactly is happening here, the findings already indicate that there will be no Ubuntu ISO possible which fits all firmwares. (Without the problematic MBR partiton 2 there cannot be an MBR boot flag and without that flag, some old HP firmwares don't boot.) A possible solution would be a standard Ubuntu ISO without MBR partition 2 and thus a neat GPT. It has to refrain from re-installing that dummy partition, of course. For the old HPs there would be a BIOS-only ISO with no GPT and no EFI partition. (This would also address the old Macs, which Debian's "mac" netinst ISO addresses.) 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
