[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems
Thomas Schmitt
1922342 at bugs.launchpad.net
Sun May 23 07:56:17 UTC 2021
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
Foundations Bugs, which is subscribed to casper in Ubuntu.
https://bugs.launchpad.net/bugs/1922342
Title:
HIrsute live session takes ages to boot on BIOS systems
Status in casper package in Ubuntu:
Confirmed
Bug description:
First of all, I change the description of this bug because, thanks to
Chris Guiver comments, I could check that the live session effectively
works but it takes too long to complete. That's why I change the
description of the bug from live session does not boot to live session
takes ages to boot. I hope this is the best approach to this.
I think the problem is the same as described here:
https://discourse.ubuntubudgie.org/t/20-10-grub-error-can-t-find-
command-grub-platform/4292. I can see prior to grub menu, briefly, the
same error: Error can't find grub_platform. After the solution
described below, this error is not showed and the system is able to
boot.
I try making the live usb using startup disk creator and with gnome-
disks --> Restore disk image and get the same results.
The live-usb has a gpt partition table instead of mbr like 20.04 live-
usb has. That implies, I think, that the first one does not boot on
BIOS systems and the second does.
I try the same live-usb on an EFI laptop and it boots perfectly
(perhaps it takes long time, but more less than in this case.
If I try the solution described here:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1905491/comments/8
then it works.
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: casper 1.461
ProcVersionSignature: Ubuntu 5.11.0-13.14-generic 5.11.7
Uname: Linux 5.11.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu61
Architecture: amd64
CasperMD5CheckResult: pass
CasperVersion: 1.461
CurrentDesktop: ubuntu:GNOME
Date: Fri Apr 2 09:55:24 2021
LiveMediaBuild: Ubuntu 21.04 "Hirsute Hippo" - Beta amd64 (20210331.1)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=gl_ES.UTF-8
SHELL=/bin/bash
SourcePackage: casper
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/+subscriptions
More information about the foundations-bugs
mailing list