Hi,
Lucap wrote:
> < MBR partition : 1 0x00 0xee 1 5508391
> < MBR partition : 2 0x80 0x00 0 1
> ---
> > MBR partition : 1 0x00 0xee 1 15649199
So gnome disks expanded the range of the protective MBR partition to
nearly 8 GB, which i assume is the size of the USB stick.
I do not believe that this change is significant.
It also removed the data in the dummy partition 2 which carries the
bootable flag to please some old HP machines with old BIOS.
This removal of could be a significant change.
> < GPT lba range : 64 5508328 5508391
> ---
> > GPT lba range : 64 15649136 15649199
Accordingly the range of the GPT now offers space for new partitions.
> < GPT partition flags: 1 0x1000000000000001
> ---
> > GPT partition flags: 1 0x0000000000000005
Original flags mean: bit60=read-only, bit0=System partition.
gnome disks flags mean: bit2=Legacy BIOS bootable, bit0=System partition.
Having set bit2 could be a significant change.
-------------------------------------------------------------------------
Let's try to find out which of the two suspects does the trick:
The flag field of partition 1 in ubuntu-21.04-desktop-amd64.iso is at
byte address 1024+48 = 1072 and 8 bytes long.
Please verify that xorriso says about your original ISO
GPT entry array : 2 248 separated
where the value 2 tells the start block of the partition slot array
meaning byte offset 2 * 512 = 1024.
(The meaning of the reported lines is roughly explained by
xorriso -report_system_area help
)
Assuming that you see the expected value 2, you can begin byte surgery:
Make a copy of your original ISO:
ORIG=ubuntu-21.04-desktop-amd64.iso
NEW=ubuntu-21.04-test.iso
cp "$ORIG" "$NEW"
Extract the flag bytes from the working USB stick:
STICK=/dev/sdc
FLAGSFILE=gnome_disk_flags.img
dd if="$STICK" bs=1 skip=1072 count=8 of="$FLAGSFILE"
This should yield a "$FLAGSFILE" with 8 bytes.
Implant these 8 bytes into the "$NEW" copy of the original ISO:
dd if="$FLAGSFILE" conv=notrunc bs=1 seek=1072 count=8 of="$NEW"
Verify by xorriso -report_system_area of "$NEW" that the flags of
partition 1 are now like in "$STICK":
xorriso -indev stdio:"$NEW" -report_system_area plain | \
grep 'GPT partition flags: 1'
should say:
GPT partition flags: 1 0x0000000000000005
Copy "$NEW" onto the stick and check whether it boots in reasonable
time.
------------------------------------------------------------------------
If it works nicely despite the fact that "$NEW" has MBR partition 2 with
MBR boot flag, then it might be possible to fix this issue by a change in
xorriso (namely setting the GPT partition flags to a different value).
For that we would need to verify that the read-only flag does not hamper
success.
Copy byte 1072+7 = 1079 from "$ORIG" to byte 7 of "$FLAGSFILE":
dd if="$ORIG" bs=1 skip=1079 count=1 of="$FLAGSFILE" conv=notrunc
seek=7
Implant into "$NEW":
dd if="$FLAGSFILE" conv=notrunc bs=1 seek=1072 count=8 of="$NEW"
Verify correctness by:
xorriso -indev stdio:"$NEW" -report_system_area plain | \
grep 'GPT partition flags: 1'
which should now say:
GPT partition flags: 1 0x1000000000000005
Copy "$NEW" onto "$STICK" and try booting.
(Alternatively you may implant and check directly on "$STICK" instead of
file "$NEW". This would save you the time to copy the whole image to
"$STICK". But being superuser with dd is always a risk.)
------------------------------------------------------------------------
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:
dd if=/dev/zero bs=1 count=16 of="$NEW" conv=notrunc seek=462
This should change in xorriso -report_system_area the "$ORIG" lines:
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0xee 1 5505347
MBR partition : 2 0x80 0x00 0 1
GPT : N Info
to "$NEW" lines:
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0xee 1 5505347
GPT : N Info
("Blocks" value of partition 1 depends on the size of "$ORIG".)
Try whether "$NEW" now boots swiftly.
(If it does not, i'd be quite puzzled.)
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
