subject:"\[Bug 1922342\] Re\: HIrsute live session takes ages to boot on BIOS systems"

Hi,

José Marinho wrote:
> I can't believe it... it boots fine again but once, twice, three
> times... and there is no MBR partition anywhere.

Let me make up a theory:

> - Burn on stick the iso that was builded with xorriso-1.5.5.
> - Boot it for the first time --> Success.

During this run of Ubuntu, casper did its "persistent partition creation",
as Steve Langasek puts it in bug 1899308.
This included a run of a GPT partition editor and then patching of MBR
partition slot 2 by the 16 bytes for the dummy partition with boot flag.

> - Boot it again --> Fails

The evil dummy partition does its work.

> sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdX conv=notrunc seek=462

Now it is gone again.

What is not gone is the persistent GPT partition number 3. It covers the
formerly free space on the USB stick. In case of my "128 GB" stick:
  GPT start and size :   3  5505024  240254913

The "$NEW" ISO from xorriso-1.5.5 with mbr_force_bootable=off has only
two GPT partitions. ("$ORIG" has three. Number 3 covers 300 KiB of padding.)

> - Boot it again --> Success

Up to this first success it is no surprise.

To my theory, casper sees no need to add a "persistent partition" and
thus does not run the partition editor and does not write to MBR partition
slot 2.

> - The following boot attempts went fine too and no MBR partition 2 is
added.

No new MBR partition 2 = no boot problems.

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-27 Thread Brian Murray

** Also affects: casper (Ubuntu Impish)
   Importance: High
   Status: Confirmed

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-27 Thread José Marinho

> What does happen if you zeroize it again ?
> dd if=/dev/zero bs=1 count=16 of=/dev/sdd conv=notrunc seek=462

I can't believe it... it boots fine again but once, twice, three
times... and there is no MBR partition anywhere.

And I repeated the steps again, just in case

- Burn on stick the iso that was builded with xorriso-1.5.5.
- Boot it for the first time --> Success.
- Boot it again --> Fails
- sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdX conv=notrunc seek=462 
- Boot it again --> Success
- The following boot attempts went fine too and no MBR partition 2 is added.
- All the successful boots finish when I reach full desktop environment after 
choosing "Try Ubuntu". Then I reboot.

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-27 Thread Matthieu Clemenceau

** Tags added: fr-1415

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Hi,

it comes to me that while no single ISO can serve all firmwares, it would
be possible that one casper can serve the original ISO and an ISO without
MBR partition 2 alike.

The trick would be to let casper memorize the 16 bytes 462 to 477 before
it runs the partition editor, and to let it write the memorized bytes
back to offset 462 afterwards.
So if a user did to the ISO image file or to the ISO on stick:

  dd if=/dev/zero bs=1 count=16 of="$ISO_OR_STICK" conv=notrunc seek=462

then this would survive casper's adjustment of the partition table.

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

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  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  5503775
  GPT:   N  Info
  ...
  GPT lba range  :  64  5503712  5503775
  ...
  GPT partition flags:   1  0x0005
  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  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee124575
  MBR partition  :   2   0x80  0x0001
  GPT:   N  Info
  ...
  GPT lba range  :  64  245759936  24575
  ...
  GPT partition flags:   1  0x0005
  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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-27 Thread Lucap

@ Thomas Schmitt

Thanks for explaining , it was just a thought as i noticed in the diff
text there was some numbers on there own such as the one at the top so i
wasn't sure if there was something else going on.

>21,22c21

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Hi,

Lucap wrote:
> https://gitlab.gnome.org/GNOME/gnome-disk-utility
> Would the code be worth you looking through for any insight for the
> legacy bios option?

Seems not necessary. Your diff in comment #44 shows the few changes which
gnome disks made for you.

José Marinho's boot1.txt shows that xorriso-1.5.5 with its new -boot_image
options was able to create the same partition table, except the size of
partition 0xee and the device size field in the GPT header block.
This device size depends on the actual USB stick on which the ISO is copied.
So it is futile to try predicting it when the ISO gets produced.

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-27 Thread Lucap

@ José Marinho

>>As I said yesterday, this changes only work at first boot but in the
following boots the >>behaviour is the same again.

If you look at post #16 i had the issue with hirsute where the USB stick
would no longer boot and i had to go to Gnome Disks and untick legacy
bios and then enable it again to get the stick to boot but it only
happened once and i've not had that issue again yet since i've been
using the Impish ISO but i'm guessing what ever gnome disks is doing is
a bit flakey or unorthodox is some way?

@ Thomas Schmitt

https://gitlab.gnome.org/GNOME/gnome-disk-utility

Would the code be worth you looking through for any insight for the
legacy bios option?

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-26 Thread José Marinho

It seems I only can attach a file per comment. Here you have the second
one file.

** Attachment added: "AfterFirstAttempt"
   
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/+attachment/5500539/+files/boot2.txt

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-26 Thread José Marinho

Hi Thomas,

As I said yesterday, this changes only work at first boot but in the
following boots the behaviour is the same again.

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.
On first boot, after dd the ISO file on the stick it boots fine reaching
logo on 25 seconds but after the first boot we have the regression
again.

I'm going to to attach two files (boot1.txt and boot2.txt). The first
one are the output of two xorriso commands BEFORE trying to boot from
the stick, just after dd the iso file on it. The second one (boot2.txt)
is the same but AFTER the first successful boot. The changes on the
output could explain why boots fine only one time.

If it's necessary I append the same command outputs with the iso created
using the dd if=/dev/zero method. These files I append now are from the
iso created using the xorriso method just like you said today morning.

** Attachment added: "BeforeAnyAttepmt"

https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/+attachment/5500538/+files/boot1.txt

--
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-26 Thread antoha-mi

Why not create a BIOS boot partition and install grub on it?

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-26 Thread Sebastien Bacher

** Tags added: rls-ii-incoming

** Changed in: casper (Ubuntu)
   Importance: Undecided => High

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-25 Thread Thomas Schmitt

Hi,

i uploaded a new development snapshot of GNU xorriso which can create a
GPT similar to the result of Lucap's gnome disks run.

  cd "$HOME"/xorriso_dir
  wget http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz
  tar xzf xorriso-1.5.5.tar.gz
  cd xorriso-1.5.5
  ./configure --prefix=/usr
  make

Then

  xorriso/xorriso -version

should say

  GNU xorriso 1.5.5 : RockRidge filesystem manipulator, libburnia project.
  ...
  Version timestamp :  2021.05.25.195904
  ...

This program is able to repack "$ORIG" to gnome disks' idea of a GPT:

  "$HOME"/xorriso_dir/xorriso-1.5.5/xorriso/xorriso \
-indev "$ORIG" \
-outdev "$NEW" \
-changes_pending yes \
-boot_image any replay \
-boot_image any mbr_force_bootable=off \
-boot_image any gpt_iso_bootable=on \
-boot_image any gpt_iso_not_ro=on

Inspection of "$NEW" by xorriso should yield
  ...
  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  5503775
  GPT:   N  Info
  ...
  GPT partition flags:   1  0x0005
  ...

The partition tables of "$NEW" will differ from "$ORIG" by:
- No dummy MBR partition 2, because of mbr_force_bootable=off.
- bit 2 = "Legacy bootable" of the ISO 9660 partition is set, because of
  gpt_iso_bootable=on
- bit 60 = "Read-only" of that partition is not set, because of
  gpt_iso_not_ro=on

(The latter two -boot_image options are new in 1.5.5.)

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-25 Thread José Marinho

Well, that's strange: the first time I booted from the usb stick it
booted fine, reaching logo on 25 seconds but the second time and the
following it failed again (probably will boot after a long wait but I
did not check)

I'm going to try to reproduce this behavior and send you some logs. The
most curious thing is that this happened again with other tentative. I
think that it was the gnome-disks flag one (the veterinarian way as you
named it... XD). The first time worked fine but the following failed.
Give some time and tomorrow or the day after I'll send you more details.

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-25 Thread Thomas Schmitt

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   01   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  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-24 Thread José Marinho

Hi Thomas.

I corrected the steps I did wrong and I'm going to try to explain the
best I can for letting you know.

<>

I did it and check with xorriso and at least it showed the desired
output:

GPT partition flags:   1  0x0005

But, here begins the problems. When I dd the modified ISO (test-iso1)
into a USB stick the partition layout according with fdisk is again
different at the ISO one. I can assure that the method I used for
copying the ISO into the stick was dd. The partition layout according
with fdisk was:

GPT PMBR size mismatch (5505347 != 7907327) will be corrected by write.

Orden (m para obtener ayuda): p

Disco /dev/sdd: 3,79 GiB, 4048551936 bytes, 7907328 sectores
Disk model: Transcend 4GB   
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: dos
Identificador del disco: 0x

Dispositivo Inicio Comienzo   Final Sectores Tamaño Id Tipo
/dev/sdd1 1 7907327  7907327   3,8G ee GPT
/dev/sdd2   * 0   01   512B  0 Vacía


But, if I run xorriso -report_system_area I get:

GNU xorriso 1.5.4.pl02 : RockRidge filesystem manipulator, libburnia
project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 908 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and size: 1373661 * 2048 , 10040 * 512
xorriso : NOTE : Detected El-Torito boot information which currently is set to 
be discarded
Drive current: -indev 'stdio:/dev/sdd'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , MBR protective-msdos-label grub2-mbr cyl-align-off 
GPT
Media summary: 1 session, 1376337 data blocks, 2688m data, 1173m free
Volume id: 'Ubuntu 21.04 amd64'
GPT partition flags:   1  0x0005
GPT partition flags:   2  0x
GPT partition flags:   3  0x1001

Fdisk reports a GPT PMBR size mismatch and another strange fact is this:
Tipo de etiqueta de disco: dos (Disk label type: dos). But the first
partition is marked as GPT.

I have to say too that the ISO (test-iso1) layout was the following
according to fdisk:

jose@jose-pc:~$ sudo fdisk /home/jose/Impish_tests/ubuntu-21.04-test.iso

Bienvenido a fdisk (util-linux 2.34).
Los cambios solo permanecerán en la memoria, hasta que decida escribirlos.
Tenga cuidado antes de utilizar la orden de escritura.

La tabla GPT primaria está dañada, pero la de respaldo parece que está
bien, así que esa será la que se utilice.

Orden (m para obtener ayuda): p

Disco /home/jose/Impish_tests/ubuntu-21.04-test.iso: 2,64 GiB, 2818738176 
bytes, 5505348 sectores
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: gpt
Identificador del disco: AF8737A9-1E23-4373-B87A-C8B16199D461

DispositivoComienzo   Final Sectores Tamaño 
Tipo
/home/jose/Impish_tests/ubuntu-21.04-test.iso1   64 5494643  5494580   2,6G 
Datos básicos de Micros
/home/jose/Impish_tests/ubuntu-21.04-test.iso2  5494644 550468310040   4,9M 
Sistema EFI
/home/jose/Impish_tests/ubuntu-21.04-test.iso3  5504684 5505283  600   300K 
Datos básicos de Micros

Orden (m para obtener ayuda):


Later I copied two ISO's for manipulate in the following way:

First I copy the original Ubuntu ISO and:

echo $'\005' | dd bs=1 count=1 conv=notrunc seek=1072 of="$NEW"

And then:

echo $'\005' | dd bs=1 count=1 conv=notrunc seek=2818705968 of="$NEW"

And the partition layout of this ISO (test-iso2) is different:

jose@jose-pc:~$ sudo fdisk
/home/jose/Impish_tests/ubuntu-21.04-test2.iso

Bienvenido a fdisk (util-linux 2.34).
Los cambios solo permanecerán en la memoria, hasta que decida escribirlos.
Tenga cuidado antes de utilizar la orden de escritura.


Orden (m para obtener ayuda): p
Disco /home/jose/Impish_tests/ubuntu-21.04-test2.iso: 2,64 GiB, 2818738176 
bytes, 5505348 sectores
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: dos
Identificador del disco: 0x

Dispositivo Inicio Comienzo   Final 
Sectores Tamaño Id Tipo
/home/jose/Impish_tests/ubuntu-21.04-test2.iso1   1 5505347  
5505347   2,6G ee GPT
/home/jose/Impish_tests/ubuntu-21.04-test2.iso2 * 0   0
1   512B  0 Vacía

Las entradas de la tabla de particiones no están en el orden del disco.

Here we have no complains about damage GPT partition table but as the
first ISO burned on the stick disklabel is dos but the first partition
is type GPT.

The xorriso output:

 sudo Impish_tests/xorriso_dir/xorriso-1.5.4/xorriso/xorriso -indev

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-24 Thread Thomas Schmitt

Hi,

José Marinho wrote:
> 4- [...] I assume that the usb drive shoud have an original ubuntu
> 21.04 ISO burned.

The "$STICK" in the setting of Lucap at comment #44 was additionally
treaded with gnome disks: "edit partition and tick the box that says
Legacy BIOS bootable".
This yielded GPT flags 0x0...05.

> 8- Verify that these 8 bytes into $NEW are now like in "$STICK".
> GPT partition flags:   1  0x1001  --> But you said it must be
> GPT partition flags: 1 0x0005

0x10...01 is the original setting of Ubuntu ISOs.

> Did I something wrong or that is OK but this solution will not work?

Your dd transplantation did not change the flags of GPT partition 1,
because the "$STICK" did not get the gnome disks treatment before
the flags bytes were copied out of it.

-

> Oh wait! I'm just to see this:
> echo $'\005' | dd bs=1 count=1 conv=notrunc seek=1072 of="$NEW"
> [yields]
> GPT partition flags:   1  0x1005

Now you are back on the proposed test track.

> It does not work.
> I mount the resulting ISO ($NEW) as a loop device and inspect the
> partition layout with fdisk.

(fdisk does not need mounting. Actually the device should not be mounted
if you change partitions, in order not to confuse the system drivers.
Whatever if loop34 is connected to "$NEW" then the result should be the
ame as with fdisk examining the plain file "$NEW".)

But fdisk is picky with the GPT checksum, which we spoil by inserting the
new flags value. Mine reports
  The primary GPT table is corrupt, but the backup appears OK,
  so that will be used.
and my very restricted spanish skills tell me that yours raises protest,
too:
> La tabla GPT primaria está dañada, pero la de respaldo parece que está
> bien, así que esa será la que se utilice.

All firmwares which i know do not react on checksum mismatches.
But well, we are in unchartered territory.

So fdisk shows you the unchanged content of the GPT backup at the end of
the ISO image:

> Tipo de etiqueta de disco: gpt
> [...]
> /dev/loop34p1   64 5494643  5494580   2,6G Datos básicos de Microsoft
> /dev/loop34p2  5494644 550468310040   4,9M Sistema EFI
> /dev/loop34p3  5504684 5505283  600   300K Datos básicos de Microsoft

This looks like what i expect after echo | dd to the original ISO.

> But the layout is different from the usb stick burned with that ISO file
> jose@jose-pc:~/Impish_tests$ sudo fdisk /dev/sdd
> [...]
> Tipo de etiqueta de disco: dos
> [...]
> /dev/sdd1 1 7907327  7907327   3,8G ee GPT
> /dev/sdd2   * 0   01   512B  0 Vacía

But this cannot be the original ISO treated by the echo | dd pipeline.
The size of /dev/sdd1 already reflects the size of the stick, which the
original ISO cannot have known in advance. So some software must have
manipulated the table before or after copying to the stick.

---

Please check again by

  xorriso -indev stdio:"$NEW" -report_system_area plain

that "$NEW" still contains
  ...
  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  5505347
  MBR partition  :   2   0x80  0x0001
  ...
  GPT partition flags:   1  0x1005
  GPT start and size :   1  64  5494580
  ...
  GPT start and size :   2  5494644  10040
  ...
  GPT start and size :   3  5504684  600
  ...

Then, without letting partition editors or other smart programs interfere,
use dd to put "$NEW" onto /dev/sdc.
If you want to check the tables on stick, use instead of fdisk:

  xorriso -indev stdio:/dev/sdc -report_system_area plain

Then try booting.

---

It might be that the firmware ignores the main GPT because of the checksum
mismatch and rather uses the backup GPT. In that case our experimental
flags setting would not get into effect.

So if the boot problem persists, the next try is to change the flags of
partition 1 in the backup GPT, too:

  echo $'\005' | dd bs=1 count=1 conv=notrunc seek=2818705968 of="$NEW"

(The number computation for this is somewhat complicated:
  GPT entry array:  2  248  separated
  GPT lba range  :  64  5505284  5505347
tell that the backup header block is 5505347 (512 bytes per block) and that
there are 248 partition slots (of 128 bytes each). I.e. they occupy 62
blocks. So the backup partition slot number 1 is at block 5505347 - 62 =
block 5505285 = byte offset 2818705920.
The flags begin 48 bytes after the slot start = byte offset 2818705968.)

After this echo | dd, the backup GPT has the desired flags value.
Its checksum is now as broken as with the main GPT.
(My fdisk does not complain or announce the use of the backup GPT any more.)

Put this "$NEW" onto USB stick and try booting.

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Bad luck!

It does not work.

I mount the resulting ISO ($NEW) as a loop device and inspect the
partition layout with fdisk. Here is the output:


jose@jose-pc:~/Impish_tests$ sudo fdisk /dev/loop34

Bienvenido a fdisk (util-linux 2.34).
Los cambios solo permanecerán en la memoria, hasta que decida escribirlos.
Tenga cuidado antes de utilizar la orden de escritura.

La tabla GPT primaria está dañada, pero la de respaldo parece que está
bien, así que esa será la que se utilice.

Orden (m para obtener ayuda): p

Disco /dev/loop34: 2,64 GiB, 2818738176 bytes, 5505348 sectores
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: gpt
Identificador del disco: AF8737A9-1E23-4373-B87A-C8B16199D461

Dispositivo   Comienzo   Final Sectores Tamaño Tipo
/dev/loop34p1   64 5494643  5494580   2,6G Datos básicos de Microsoft
/dev/loop34p2  5494644 550468310040   4,9M Sistema EFI
/dev/loop34p3  5504684 5505283  600   300K Datos básicos de Microsoft

Orden (m para obtener ayuda):


But the layout is different from the usb stick burned with that ISO file

jose@jose-pc:~/Impish_tests$ sudo fdisk /dev/sdd

Bienvenido a fdisk (util-linux 2.34).
Los cambios solo permanecerán en la memoria, hasta que decida escribirlos.
Tenga cuidado antes de utilizar la orden de escritura.

GPT PMBR size mismatch (5505347 != 7907327) will be corrected by write.

Orden (m para obtener ayuda): p

Disco /dev/sdd: 3,79 GiB, 4048551936 bytes, 7907328 sectores
Disk model: Transcend 4GB   
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: dos
Identificador del disco: 0x

Dispositivo Inicio Comienzo   Final Sectores Tamaño Id Tipo
/dev/sdd1 1 7907327  7907327   3,8G ee GPT
/dev/sdd2   * 0   01   512B  0 Vacía

Las entradas de la tabla de particiones no están en el orden del disco.

Orden (m para obtener ayuda):

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Oh wait! I'm just to see this:

In bash there is a special form of quoting:

  echo $'\005' | dd bs=1 count=1 conv=notrunc seek=1072 of="$NEW"

And now the output:

.

Media summary: 1 session, 1376337 data blocks, 2688m data, 19.1g free
Volume id: 'Ubuntu 21.04 amd64'
GPT partition flags:   1  0x1005
GPT partition flags:   2  0x
GPT partition flags:   3  0x1001

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Hi Thomas,

I try the solution from comment #39 erasing the five lines referring to
grub_platform and it did not work.

Now I'm trying to do what you proposed on comment #45 being aware of
comment #46 and, like it happened this morning when I first tried it,
the output of -report_system_area is different to what you said. At
morning, before your post realizing that the Ubuntu version of xorriso
can't create an ISO with a GPT partition table, I was trying that and
got the same output. I continued burning the iso to the usb drive but
the boot delayed again. Then you mentioned the xorriso affair and I
stopped the test.

I return to the test now and I have the same output of the
report_system_area command. In this case I stopped here because I think
that is anything wrong and it is going to be unsuccessful again.

I sumarize what I did (my working directory is $HOME/Impish_tests). I
use absolute paths for avoiding possible errors.

1- Set the ORIG variable to $HOME/Impish_tests/ubuntu-21.04-desktop-
amd64.iso

ORIG=/home/jose/Impish_tests/ubuntu-21.04-desktop-amd64.iso

2- Set the NEW variable to $HOME/Impish_tests/ubuntu-21.04-test.iso

NEW=/home/jose/Impish_tests/ubuntu-21.04-test.iso

3- Make a copy of the original iso (cp "$ORIG" "$NEW")

4- Set the STICK variable to /dev/sdd. My system assign this letter to
the usb drive. I assume that the usb drive shoud have an original ubuntu
21.04 ISO burned.

STICK=/dev/sdd

5- Set the FLAGSFILE variable to the file
$HOME/Impish_tests/gnome_disk_flags.img

FLAGSFILE=gnome_disk_flags.img

6- Extract 8 bytes of the working USB stick after the 1072 one and
create the file referenced by $FLAGSFILE (this command shoud be issued
with sudo).

sudo dd if="$STICK" bs=1 skip=1072 count=8 of="$FLAGSFILE"
8+0 records in
8+0 records out
8 bytes copied, 0,00128856 s, 6,2 kB/s

7- Implant this 8 bytes after the first 1072 of the $NEW ISO file.

dd if="$FLAGSFILE" conv=notrunc bs=1 seek=1072 count=8 of="$NEW"
8+0 records in
8+0 records out
8 bytes copied, 0,000311537 s, 25,7 kB/

8- Verify that these 8 bytes into $NEW are now like in "$STICK". Here is
the problem. The output is the following:

~/Impish_tests$ xorriso_dir/xorriso-1.5.4/xorriso/xorriso -indev stdio:"$NEW" 
-report_system_area plain | grep 'GPT partition flags:'
GNU xorriso 1.5.4.pl02 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 908 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and size: 1373661 * 2048 , 10040 * 512
xorriso : NOTE : Detected El-Torito boot information which currently is set to 
be discarded
Drive current: -indev 'stdio:/home/jose/Impish_tests/ubuntu-21.04-test.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , MBR protective-msdos-label grub2-mbr cyl-align-off 
GPT
Media summary: 1 session, 1376337 data blocks, 2688m data, 19.1g free
Volume id: 'Ubuntu 21.04 amd64'
GPT partition flags:   1  0x1001  --> But you said it must be GPT 
partition flags: 1 0x0005
GPT partition flags:   2  0x
GPT partition flags:   3  0x1001

But like you said on the comment <>
So if I run the command with $STICK:

~/Impish_tests$ sudo xorriso_dir/xorriso-1.5.4/xorriso/xorriso -indev 
stdio:"$STICK" -report_system_area plain | grep 'GPT partition flags:'
GNU xorriso 1.5.4.pl02 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 908 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and size: 1373661 * 2048 , 10040 * 512
xorriso : NOTE : Detected El-Torito boot information which currently is set to 
be discarded
Drive current: -indev 'stdio:/dev/sdd'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , MBR protective-msdos-label grub2-mbr cyl-align-off 
GPT
Media summary: 1 session, 1376337 data blocks, 2688m data, 1173m free
Volume id: 'Ubuntu 21.04 amd64'
GPT partition flags:   1  0x1001--> It is the same as $NEW, but 
ending in 1 instead of 5, like you said.
GPT partition flags:   2  0x
GPT partition flags:   3  0x1001

At morning like I said before I did this test and, ignoring that the output of 
the last command did not match with yours, burn the $NEW ISO on the USB stick 
and it did not work.
Now I get the same output and, before burning the $NEW ISO again, I ask you. 
Did I something wrong or that is OK but this solution will not work?

-- 
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:

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Hi,

José Marinho:
> Well, I try the first method (compiling xorriso) and removing the if
> condition from grub.cfg keeping grub_platform command. The usb drive now has
> a GPT partition table but unfortunately, the issue persists so, it seems
> that the grub_platform thing is not the cause.

Remove the grub_platform command and try again.

Initially we thought that removing all five lines had helped. But that
test has to be repeated, now that we have to expect that this success was
due to the partition table changes.

If the repeated test with no command grub_platform shows that the problem is
gone, then the test result with just no "if"-lines would tell us that indeed
the command is to blame for the long delay.

If removing all five lines does not help, then the error message about
grub_platform is just an unrelated complaint.

-

> If any other test is needed don't hesitate on ask me, but for today I have
> enough, so perhaps I'll take a while on doing it.

Please try what i proposed to Lucap in comment #45
  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/45
(beware of swallowed blanks, see #46)

Somehow the quite marginal changes of gnome disk prevent the problem.
The proposed dd runs manipulate the GPT, veterinarian style.

If all we need to do is to set the flags of GPT partition 1 to
  0x1005
then i could quite directly provide a remedy in GNU xorriso-1.5.5.

Further there would be a veterinary solution for the time being.
The biggest obstacle would be to get byte value 5 by shell means.
In bash there is a special form of quoting:

  echo $'\005' | dd bs=1 count=1 conv=notrunc seek=1072 of="$NEW"

In dash the built-in echo command interprets backslashes on its own:

  echo '\005' | dd bs=1 count=1 conv=notrunc seek=1072 of="$NEW"

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Well, I try the first method (compiling xorriso) and removing the if condition 
from grub.cfg keeping grub_platform command. The usb drive now has a GPT 
partition table but unfortunately, the issue persists so, it seems that the 
grub_platform thing is not the cause.
If any other test is needed don't hesitate on ask me, but for today I have 
enough, so perhaps I'll take a while on doing it.
Have a nice day

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Hi,

Lucap wrote:
> gnome disks no longer says it's a GPT layout and
> says the first partition is Linux (Bootable)(0x83)

José Marinho wrote:
> in this last experiment I see with Gnome disks that the usb drive with
> the modified iso has a MBR partition table instead the GPT partition table
> of the original ISO.

Aargh. My fault. I forgot that the original GPT layout of modern Ubuntu
ISOs needs a newer xorriso for automatic boot equipment replay.
I now repeated my proposal in comment #39 with xorriso-1.5.2 and indeed
you are right. The -boot_image replay command did not correctly recognize
the new Ubuntu ISO layout.

So we have to retract the diagnosis that grub_platform in grub.cfg is
to blame, until one of you can repack an ISO to GPT.

In my tests with current upstream release xorriso-1.5.4 it worked fine.
But the packaging for xorriso-1.5.4 is sitting in Debian's salsa git and
waits for the end of Debian 11 release freeze.

There are two ways to work around:

--
1st way:

Build the current GNU xorriso from source. Do not install it, but rather
use it from where it was built. This keeps it from confusing Ubuntu's
package management.

You need the compiler equipment of meta-package "build-essential".

Download the tarball to a new directory:

  cd "$HOME"
  mkdir xorriso_dir
  cd xorriso_dir
  wget https://ftp.gnu.org/gnu/xorriso/xorriso-1.5.4.pl02.tar.gz

(Mistrusting people also download xorriso-1.5.4.pl02.tar.gz.sig and let
gpg --verify that both match.)

Build it according to its README file:

  tar xzf xorriso-1.5.4.pl02.tar.gz
  cd xorriso-1.5.4
  ./configure --prefix=/usr
  make

Expect a storm of messages from ./configure and "make".
Success is when "make" ends and a run of

  ./xorriso/xorriso

can say
  GNU xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

  usage : xorriso-1.5.4 [commands]
  More is told by command -help

Use this resulting xorriso binary by its absolute path

  "$HOME"/xorriso_dir/xorriso-1.5.4/xorriso/xorriso \
  -indev "$ORIG" \
  -outdev "$NEW" \
  -map ./grub.cfg /boot/grub/grub.cfg \
  -boot_image any replay

You may later safely remove the tree "$HOME"/xorriso_dir to get rid of
the GNU xorriso construction site.

--
2nd way:

xorriso-1.5.2 is well able to repack the ISO to GPT. (After all it did
pack up the original ISO.)
It just needs the correct list of boot related commands, as analyzed by
xorriso-1.5.4 and told by its command -report_system_area "cmd".

The bad news is that this command list is long and that i need to see
the exact "$ORIG" ISO in order to let xorriso-1.5.4 tell the exact
arguments.

With "$ORIG" = ubuntu-21.04-desktop-amd64.iso which has
MD5 736a9acaf195063600a6e1876d48a263 it would be:

  xorriso \
-indev "$ORIG" \
-outdev "$NEW" \
-map ./grub.cfg /boot/grub/grub.cfg \
\
-volid 'Ubuntu 21.04 amd64' \
-volume_date uuid '2021042011161600' \
-boot_image grub 
grub2_mbr=--interval:imported_iso:0s-15s:zero_mbrpt,zero_gpt:'ubuntu-21.04-desktop-amd64.iso'
 \
-boot_image any partition_table=on \
-boot_image any partition_cyl_align=off \
-boot_image any partition_offset=16 \
-boot_image any mbr_force_bootable=on \
-append_partition 2 28732ac11ff8d211ba4b00a0c93ec93b 
--interval:imported_iso:5494644d-5504683d::'ubuntu-21.04-desktop-amd64.iso' \
-boot_image any appended_part_as=gpt \
-boot_image any iso_mbr_part_type=a2a0d0ebe5b9334487c068b6b72699c7 \
-boot_image any cat_path='/boot.catalog' \
-boot_image grub bin_path='/boot/grub/i386-pc/eltorito.img' \
-boot_image any platform_id=0x00 \
-boot_image any emul_type=no_emulation \
-boot_image any load_size=2048 \
-boot_image any boot_info_table=on \
-boot_image grub grub2_boot_info=on \
-boot_image any next \
-boot_image any 
efi_path='--interval:appended_partition_2_start_1373661s_size_10040d:all::' \
-boot_image any platform_id=0xef \
-boot_image any emul_type=no_emulation \
-boot_image any load_size=5140480

This yields with xorriso-1.5.2 what xorriso-1.5.4 can replay on its own.

--

In both cases, xorriso -report_system_area "plain" should report this
layout of MBR and GPT.

  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  5503967
  MBR partition  :   2   0x80  0x0001
  GPT:   N  Info
  GPT disk GUID  :  3000c6ade0e5ab4c8f79bd4e1e7794e7
  GPT entry array:  2  248  separated
  GPT lba range  :  64  5503712  5503775
  GPT partition name :   1  490053004f003900360036003000
  GPT partname local :   1  ISO9660
  GPT partition GUID :   1  3000c6ade0e5ab4c8f78bd4e1e7794e7
  GPT type GUID  :

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Thanks José for confirming that and trying Thomas instructions on GPT.

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

@ Lucap

I've just test the iso modified keeping grub_platform command and removing the 
part that evaluates the variable and I get the same results as when I removed 
both: 32 seconds to togo and 1 minute 22 seconds to language selector.
I wasn't noticed what was changing on partitions layout with all this tweaks 
but in this last experiment I see with Gnome disks that the usb drive with the 
modified iso has a MBR partition table instead the GPT partition table of the 
original ISO. In fact, before all of this experiments on the first post of this 
report I link a post where give instructions for changing the partition table 
from GPT to MBR. 
According to fdisk the partition table resulting from the modified ISO is:

Orden (m para obtener ayuda): p
Disco /dev/sdd: 3,79 GiB, 4048551936 bytes, 7907328 sectores
Disk model: Transcend 4GB   
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: dos
Identificador del disco: 0x

Dispositivo Inicio Comienzo   Final Sectores Tamaño Id Tipo
/dev/sdd1   *64 5496567  5496504   2,6G 83 Linux
/dev/sdd2   5496568 550660710040   4,9M ef EFI (FAT-12/16/32)
/dev/sdd3   5509120 7907327  2398208   1,1G 83 Linux

The last one is a writable partition and was preceding of a empty space of 1.3 
MB according with gnome-disks
Furthermore, the first partition is marked as bootable
So I confirm your results.
I'm going to trying the last instructions of Thomas. I don't have too much 
technical skills either but I'm going to try my luck.

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

>>Thomas Schmitt , Let's try to find out which of the two suspects does
the trick:

Sorry Thomas i tried to read through the instructions but i just simply
don't have any type of command or development skills and i find it
confusing. :(

I'm just a point and click Ubuntu user...

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

I've just built a new ISO with xorriso but this time i never removed
grub_platform and left it all untouched and now the USB stick boots
without any grub_platform error and after 20 to 30 seconds of a black
screen it boots as normal so it's the way the new ISO is being written
to the USB stick as Linux (Bootable)(0x83) instead of GPT.


José Marinho can confirm this if you don't mind building another ISO but this 
time don't remove 
grub_platform from grub.cfg just leave it all original and build a new ISO and 
see if it boots?

Thanks

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

You might need to hold my hand through this as my technical skills are
limited.

Before i attempt what you ask i've just built a new ISO with
grub_platform removed and it now boots  up in the same manner as the
Gnome disk option , after the grub menu it gives a black screen for
about 20 to 30 seconds and then boots as normal so removing
grub_platform works.

I don't know if this is of any significance but the new ISO is written
to USB differently as gnome disks no longer says it's a GPT layout and
says the first partition is Linux (Bootable)(0x83)

So i'm not sure if it's the removal of grub_platform or the way the new
ISO has been written as Linux bootable?

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Hi,

regrettably the display of launchpad's website eats blanks.
This mutilates my proposed grep 'GPT partition flags:   1' by condensing
three blanks before "1" to a single blank.

So i change the inspection proposal to

  xorriso -indev stdio:"$NEW" -report_system_area plain | \
grep 'GPT partition flags:'

which should yield something like

  GPT partition flags:   1  0x1005
  GPT partition flags:   2  0x
  GPT partition flags:   3  0x1001

Interesting for our problem is only the first of these lines.

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

Hi,

Lucap wrote:
> < MBR partition  :   1   0x00  0xee1  5508391
> < MBR partition  :   2   0x80  0x0001
> ---
> > MBR partition  :   1   0x00  0xee1 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  0x1001
> ---
> > GPT partition flags:   1  0x0005

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  0x0005

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  0x1005

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  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  5505347
  MBR partition  :   2   0x80  0x0001
  GPT:   N  Info

to "$NEW" lines:

  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  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:

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

@Thomas Schmitt

run1.txt = Standard ISO unmodified
run2.txt = Gnome disks - first partition legacy bios enable.

I'll post the difference between the logs , if you want the full logs
posted let me know and i will paste them up.

diff run1.txt run2.txt
21,22c21
< MBR partition  :   1   0x00  0xee1  5508391
< MBR partition  :   2   0x80  0x0001
---
> MBR partition  :   1   0x00  0xee1 15649199
26c25
< GPT lba range  :  64  5508328  5508391
---
> GPT lba range  :  64  15649136  15649199
31c30
< GPT partition flags:   1  0x1001
---
> GPT partition flags:   1  0x0005

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

My bad , I've got it working with /dev/sdc instead of $/dev/sdc.

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

@José Marinho

I don't mean to put this on you but as the Gnome disks options also
worked for you i might be better if you run the report_system_area scan
between the normal ISO and the Gnome disk edited version so it gets done
correctly as i'm getting out of my depth here as a point and click user
, for example.

xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.

libburn : SORRY : Neither stdio-path nor its directory exist
xorriso : FAILURE : Cannot acquire drive 'stdio:$/dev/sdc'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'

My USB stick is /dev/sdc and i also tried sdc1 but it's still the same
error.

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-22 Thread Thomas Schmitt

Hi,

José Marinho wrote:
> I made the experiment you proposed modifying grub.cfg file.
> [...]
> So it seems that you find the cause of the problem. 

By luck and 14 years of xorriso development. :))

Can i talk you into a second test ?
This time only disable the part in grub.cfg which evaluates the variable:

if [ "$grub_platform" = "efi" ]; then
menuentry 'Boot from next volume' {
exit
}

but leave the command in effect:

grub_platform

The resulting behavior will be of interest when asking GRUB experts for an
explanation.

-

We still could need to know what wonder exactly gnome disks does for
Lucap.
Somehow the partition table of the ISO influences the ability of
command and/or variable evaluation to do its job in reasonable time.

The proposed xorriso runs will hopefully show what exactly lets
grub_platform or the evaluation of $grub_platform block boot progress.

-

When both open questions are answered, it will be time that Ubuntu ISO
production takes this case to one of the mailing lists about misbehaving
GRUB. Let's have a look into the archives.

Not much replies:
  https://lists.gnu.org/mailman/listinfo/bug-grub

Probably not the right audience:
  https://lists.gnu.org/mailman/listinfo/help-grub

Quite oriented to "[PATCH]"-work. But at least they discuss what is posted:
  https://lists.gnu.org/mailman/listinfo/grub-devel/
I am subscribed to grub-devel, because of grub-mkrescue. So i could serve
as curious bystander who wonders where command grub_platform is
implemented.

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-22 Thread José Marinho

Hi Thomas,

I made the experiment you proposed modifying grub.cfg file. In this case I use 
a regular Ubuntu (Main edition with Gnome) Impish iso file.
After Grub I get a blank screen with the cursor blinking and after only 32 
seconds I reach Ubuntu logo and after 1 minute and 22 seconds the window where 
you select language settings and if you want to try Ubuntu first or begin 
installation process now without trying Ubuntu.
So it seems that you find the cause of the problem. 
Hope that helps.

Have a nice weekend.

-- 
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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-22 Thread Thomas Schmitt

Hi,

just in case somebody wants to make experiments with changed grub.cfg,
here are instructions how to create a modified ISO from an Ubuntu amd64
original (but not from a "powerpc" ISO):

Set paths to the original ISO image and for the emerging ISO image:

  ORIG=ubuntu-21.04-desktop-amd64.iso
  NEW=ubuntu-21.04-test.iso

Extract grub.cfg from the original ISO to the current working directory:

  xorriso -indev "$ORIG" -osirrox on -extract /boot/grub/grub.cfg
./grub.cfg

Make the extracted file writable:

  chmod u+w ./grub.cfg

Now edit the file.
My proposal is to remove the 5 lines about grub_platform.

Make sure that a file with path "$NEW" does not yet exist.
Then create the new modified ISO:

  xorriso -indev "$ORIG" \
  -outdev "$NEW" \
  -map ./grub.cfg /boot/grub/grub.cfg \
  -boot_image any replay

This run of xorriso will issue some righteous warnings
  xorriso : WARNING : -volid text problematic as automatic mount point name
  xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
because of the blanks and lower case characters in
  Volume id: 'Ubuntu 21.04 amd64'
It will analyze "$ORIG" for boot equipment and boot entry points in order to
create the same in "$NEW"
  xorriso : NOTE : Replayed 22 boot related commands
  xorriso : NOTE : Copying to System Area: 32768 bytes from file 
'--interval:imported_iso:0s-15s:zero_mbrpt,zero_gpt:ubuntu-21.04-desktop-amd64.iso'

Then it begins to write to "$NEW" an ISO image of roughly the same size as
the size of "$ORIG". Enjoy the progress messages. :))

When done, put "$NEW" onto the USB stick and try what happens.
(Maybe mount "$NEW" and check whether your changes really did get into
 effect in /boot/grub/grub.cfg, before the lengthy dd to USB stick.)

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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

2021-05-22 Thread Thomas Schmitt

Hi,

Lucap wrote:
> If i look at the USB sticks first partition with gnome disks , edit
> partition and tick the box that says Legacy BIOS bootable then the USB
> stick no longer shows "cannot find grub_platform" and goes straight to
> the grub menu , then it boots to a black screen with a blinking cursor
> for about 20 seconds and then it boots as normal just like any previous
> Ubuntu release?

Is this a question or a report of an observed fact ?

If it is an observation, then i would be strongly interested in seeing the
results of two runs of

  STICK=/dev/sdc
  xorriso -indev stdio:"$STICK" -report_system_area plain 

with STICK holding the device address which you used with dd.

Each run will emit about 50 lines of text.
You may catch them in a /tmp file by

  xorriso -indev stdio:"$STICK" -report_system_area plain 2>&1 | \
tee -i -a /tmp/report_system_area.txt

Please make one run after freshly writing the unmodified ISO to the stick
before you use gnome disks. Afterwards make a second run to show the result
of gnome disk's activities.


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

[Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems