Hi, José Marinho wrote: > GPT PMBR size mismatch (5505347 != 7907327) will be corrected by write. > ... > /dev/sdd1 1 7907327 7907327 3,8G ee GPT > /dev/sdd2 * 0 0 1 512B 0 Vacía
Looks like fdisk reports to you what would be the result if you let it write what it thinks would be correct. > another strange fact is this: > Tipo de etiqueta de disco: dos (Disk label type: dos). (It would help if you do export LANG=C before running fdisk, in the hope that it will then talk english. Revoke this later by unset LANG ) Probably fdisk does not accept the partition table as GPT because of the second MBR partition of type 0x00 which carries the boot flag. > Disco /home/jose/Impish_tests/ubuntu-21.04-test.iso: 2,64 GiB, 2818738176 > Tipo de etiqueta de disco: gpt For some reason it believes in GPT as long as the ISO image is not on the stick. Not very consistent. We should not give fdisk too much attention here. It has its own ideas which it does not communicate transparently. > the first ISO burned on the stick disklabel is dos but the first partition > is type GPT. It is of MBR partition type 0xee which the EFI specs call "GPT Protective". (EFI is where GPT is specified.) This partition is supposed to cover the whole block range of the storage device. It is also supposed to be the only MBR partition to indicate the presence of a valid GPT. The latter expectation is not fulfilled by the Ubuntu ISO because of the boot flag and non-zero bytes in MBR partition slot 2. But the EFI specs also say: A [MBR] Partition Record that contains an OSType value of zero or a SizeInLBA value of zero may be ignored. The MBR partition 2 of the Ubuntu ISO has OSType zero (0x00). So EFI firmwares normally ignore it and accept the MBR as "protective" indicating the presence of a valid GPT. -------------------------------------------------------------------------- So the manipulations about setting the "Legacy BIOS bootable" flag in the GPT EFI partition did not help. (We can revisit this attempt when xorriso-1.5.5 can set this flag while producing a GPT with correct checksums. I began to implement this yesterday but will also have to offer the opportunity to suppress the "read-only" flag, which gnome disks did not set.) For now our experiments exhausted the first alternatives of https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/45 This leaves us with the last alternative: "If the transplated flags field does not fix the problem, then it must be about the MBR partition 2 with its boot flag. In this case it would not be possible to create an ISO that pleases all. So if "$NEW" does not boot swiftly after the first transplantation, try whether it helps to overwrite MBR partition slot 2 by zeros" So try this now: cp "$ORIG" "$NEW" dd if=/dev/zero bs=1 count=16 of="$NEW" conv=notrunc seek=462 Afterwards xorriso -indev "$NEW" -report_system_area plain should then report only a single MBR partition MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 5505347 Now the "protective MBR" is flawless (but also some old BIOS machines will not boot this from USB stick, because of no MBR boot flag). Copy "$NEW" onto USB stick and see whether it boots better. At least fdisk should be less confused. :)) This does still not do exactly what gnome disks did to yield success for Lucap. For a better approximation to that state, we will need the new xorriso-1.5.5 which will be able to achieve the same. 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
