[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
I can confirm that "removing MBR partition 2" indeed WORKS. I've tested the "second" step as I've already had booted from the stick a couple of times (and always had experienced the daunting delay). Thus I've patched the partition on the stick directly as you've advised. As expected the insanely long pause after hitting enter on the GRUB menu is gone. Thank you for your investigation! Incidentally, I'm assembling a new desktop system for me right now, it's a modern platform obviously... so I'm expecting all this to not be needed for 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, i opened a separate bug with my wish for not needing a second zeroizing dd run when the ISO is already on the USB stick: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1977644 "Please preserve MBR partition entries 2 to 4 when creating persistent partition" 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, tlk wrote: > which post details the "removing MBR partition 2"? #112 by me, confirmed by #114 by Chris Guiver: If the USB stick with the the slowly booting ISO is overwritten meanwhile: # Patch the ISO already as image on hard disk ISO=ubuntu-22.04-desktop-amd64.iso dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462 # Put it onto the USB stick as you usually do. E.g. sudo dd bs=4M oflag=sync status=progress of=/dev/sdX if="$ISO" In any case after the USB stick has already booted once, you have to apply the change again directly to it, because casper installed MBR partition 2 again after creating its persistent partition: # Take care not to name any of your valuable disks as USB_STICK USB_STICK=/dev/sdX sudo dd if=/dev/zero bs=1 count=16 of="$USB_STICK" conv=notrunc seek=462 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
which post details the "removing MBR partition 2"? I'll try when I come around to 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, Chris Guiver wrote: > This confirms what I believe you wanted. Yes. The stick needs the remedy once again after casper created the persistent partition. sudodus wrote: > This is like development of physics ;-) Like a unification of relativity theory and quantum mechanics ? My apologies again for not remembering the results from one year ago and wasting everybody's time with my first questions of this year. Between #94 and #103 i was off track. I'll wait a few days whether Steve Langasek shows up at this bug report. If not, i plan to file a new wishlist bug for casper which describes our findings and proposes the code change as of #115. I re-re-read this report to list the affected machines: - a tablet computer "motion computing j3400" of Chris Guiver, - a Gigabyte H61M-D2H-USB3 mainboard of José Marinho (see also https://launchpadlibrarian.net/531427797/lshw.txt), - (a Gigabyte GA-970A-DS3, BIOS F7a 01/24/2013 of tlk in #91, of which we have no confirmation that removing MBR partition 2 really helps). 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Congratulations Thomas (for theory) and Chris (for experiments). This is like development of physics ;-) -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
> If you now apply the remedy to the stick > dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462 >then i expect it to be permanently booting in reasonable time. > .. Please confirm. Inserted thumb-drive(2) [Ubuntu-MATE jammy] into box and -- start paste guiverc@d960-ubu2:/de2900/ubuntu_mate_64$ sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462 [sudo] password for guiverc: 16+0 records in 16+0 records out 16 bytes copied, 0.0107609 s, 1.5 kB/s -- end paste booted it on j3400 - motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series) on boot (noting when at grub) it had reached maybe-ubiquity in ~3 mins using room clock (no seconds as digital). I made an error in typing SysRq-REO (intended REISUB) so as no sync.. ignoring this bot. turned box back on & booted again; again at maybe-ubiquity in ~3 mins by room clock. Correctly used SysRq-REISUB to restart another boot & again ~3 mins by room clock. SysRq-REISUO now NOTE: I didn't wait for clock to change minute & press enter this time, thus the extra seconds (making 2+ mins ~3 mins) is just ME not starting hitting the timing at ~:01 secs or hitting ENTER just after minute changes.. Either way ~3 mins is NOT TEN minutes as the slow boot takes to reach maybe-ubiquity. This confirms what I believe you wanted. -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi,
Chris Guiver wrote:
> On j3400; pressed ENTER (at grub) at 13:10 (room clock).. I didn't note
> time of plymouth but I had maybe-ubiquity @ 13:13 (room clock) for
> altered version of 2022-04-19 ISO
> [...]
> so I'll now boot twice
> [...]
> alas should have noted clock.. it 'feels' slow... nah it's slow :(
> [...]
> another boot on j3400, hit ENTER (at grub) at 13:31, maybe-ubiquity jingle
> waking me from sleep at 13:41
> [...]
> MBR partition : 2 0x80 0x0001
Looks like casper is still re-installing MBR partition 2 on the first
run of the Live system, although it was not there before this run.
If you now apply the remedy to the stick
dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462
then i expect it to be permanently booting in reasonable time.
(Not because it was applied to the stick, but because casper will not
manipulate the partition table any more.)
Please confirm.
--
I had hoped that capser would save the partition entry and re-install it after
the creation of the persistent overwrote the MBR partition table. But it
seems to just write a pre-recorded partition entry with the boot flag.
So we'd need a change in casper if the description of the workaround
shall be reasonably safe.
I don't consider dd of=/dev/sdb safe considered that the Ubuntu tutorial
advises to use Balena Etcher for the copy-to-USB-stick step.
Casper would have to save before the additon of the persisten partition
at least 16 bytes beginning at offset 462, or 48 bytes to cover all three
unused MBR partitions. After creation of the partition the saved bytes
would be written back to the MBR of the USB stick.
In
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/66
i read:
casper (1.455) groovy; urgency=medium
[...]
* Limit our dd to only change 16 bytes in the MBR regardless of input,
[...]
-- Steve Langasek Fri, 16 Oct 2020 09:51:20 -0700
But this is not what Chris Guiver observes.
In
https://git.launchpad.net/ubuntu/+source/casper/commit/?id=5c3637a224e7eca4c8998d72ac1711cd8b58b335
i see unconditional insertion of the boot flag partition:
+ echo $escape_arg -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 count=16
The current state in
https://git.launchpad.net/ubuntu/+source/casper/tree/scripts/casper-helpers
still has this gesture:
find_or_create_persistent_partition () {
[...]
echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
[...]
if sfdisk -d $DEVICE | grep -q 'label: gpt'; then
[...]
echo $escape_arg -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 count=16
fi
[...]
I would propose to do something like:
+MBR_STASH=/tmp/mbr_stash_$$
+dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH"
echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
[...]
-echo $escape_arg -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 count=16
+dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48
fi
+rm "$MBR_STASH"
@Steve Langasek: Are you watching ? Do we need to open a new bug ?
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:
Impish live session takes ages to boot on BIOS systems
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
-- reply to @Thomas #112 (start paste) So if we want to propose a workaround for the current layout, it would be a good base if you could confirm that j3400 boots after the plain procedure with no other experiments inbetween: # Patch the ISO already as image on hard disk ISO=ubuntu-22.04-desktop-amd64.iso dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462 # Put it onto the USB stick as you usually do. E.g. sudo dd bs=4M oflag=sync status=progress of=/dev/sdb if="$ISO" Then you would check if it boots twice on the j3400. If the second boot succeeds and shows a writable big partition as last one, then we could be sure that this procedure is a valid workaround. A run of sudo xorriso -indev stdio:/dev/sdb -report_system_area plain would (hopefully) confirm that there is no second MBR partition with boot flag. Of course it would be enough if you can confirm that you did this already during the experiments, with no intermediate manipulations. But given the curvy way of this bug report, we need to be sure. -- (end paste) I grabbed my thumb-drive 2; Ubuntu-MATE jammy (2022-04-19) - plugged into j3400; enter pressed [just] @12:28 using room clock, plymouth seen at 12:36, maybe-ubiquity appeared at 12:38 This wasn't required/requested; but I omitted `sudo` for last; so added here --- (start paste) guiverc@d960-ubu2:~/uwn/issues/735$ sudo xorriso -indev stdio:/dev/sdb -report_system_area plain [sudo] password for guiverc: xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Loading ISO image tree from LBA 0 xorriso : UPDATE : 774 nodes read in 1 seconds libisofs: NOTE : Found hidden El-Torito image for EFI. libisofs: NOTE : EFI image start and size: 1422522 * 2048 , 8496 * 512 xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev 'stdio:/dev/sdb' 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, 1424812 data blocks, 2783m data, 4849m free Volume id: 'Ubuntu-MATE 22.04 LTS amd64' System area options: 0x4201 System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT ISO image size/512 : 5699248 Partition offset : 16 MBR heads per cyl : 0 MBR secs per head : 0 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xee1 15630335 MBR partition : 2 0x80 0x0001 GPT: N Info GPT disk GUID : 92da1293cf19e54b80558e26d983bc85 GPT entry array: 2 248 separated GPT lba range : 64 15630272 15630335 GPT partition name : 1 490053004f003900360036003000 GPT partname local : 1 ISO9660 GPT partition GUID : 1 92da1293cf19e54b80548e26d983bc85 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 64 5690024 GPT partition name : 2 41007000700065006e006400650064003200 GPT partname local : 2 Appended2 GPT partition GUID : 2 92da1293cf19e54b80578e26d983bc85 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x GPT start and size : 2 5690088 8496 GPT partition name : 3 4700610070003100 GPT partname local : 3 Gap1 GPT partition GUID : 3 92da1293cf19e54b80568e26d983bc85 GPT type GUID : 3 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 3 0x1001 GPT start and size : 3 5698584 600 GPT partition name : 4 GPT partition GUID : 4 a77519baa6474c698e9d5848797c7dc5 GPT type GUID : 4 af3dc60f838472478e793d69d8477de4 GPT partition flags: 4 0x GPT start and size : 4 5701632 9928641 guiverc@d960-ubu2:~/uwn/issues/735$ --- (end paste) guiverc@d960-ubu2:/de2900/ubuntu_mate_64$ cp -pv jammy-desktop-amd64.iso jammy-desktop-amd64.iso.scdbackup 'jammy-desktop-amd64.iso' -> 'jammy-desktop-amd64.iso.scdbackup' guiverc@d960-ubu2:/de2900/ubuntu_mate_64$ dd if=/dev/zero bs=1 count=16 of=jammy-desktop-amd64.iso.scdbackup conv=notrunc seek=462 16+0 records in 16+0 records out 16 bytes copied, 0.205961 s, 0.1 kB/s guiverc@d960-ubu2:/de2900/ubuntu_mate_64$ sudo dd bs=4M oflag=sync status=progress of=/dev/sdb if=jammy-desktop-amd64.iso.scdbackup [sudo] password for guiverc: 2918014976 bytes (2.9 GB, 2.7 GiB) copied, 786 s, 3.7 MB/s 695+1 records in 695+1 records out 2918014976 bytes (2.9 GB, 2.7 GiB) copied, 785.505 s, 3.7 MB/s Ejected thumb-drive (2) & booted on plugged into hp.dc7700; it failed to boot :( On j3400; pressed ENTER (at grub) at 13:10 (room clock).. I didn't note time of plymouth but I had maybe-ubiquity @ 13:13 (room clock) for altered version of 2022-04-19 ISO I used SysRq-REISUO to shutdown there.. (I'm reading your instructions as I do it) so I'll now boot twice
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, i wrote towards Chris Guiver: > it would > be a good base if you could confirm that j3400 boots after the plain > procedure with no other experiments inbetween I should have written: it would be a good base if you could confirm that j3400 boots without the extra delay of ~6 minutes after the plain procedure with no other experiments inbetween Reading my text proposal for the tutorial, i now think it should give less info. Like On some very old and meanwhile rare machines it can last 10 minutes or longer until you see this welcome screen. If you really have to wait that long, consider to read the article [link] about a possible cause and a workaround. The article would explain that - the Ubuntu ISOs contain a boot flag as inavoidable workaround for booting some old and not so rare machines, - which causes the long boot delay with some other old and rarer machines, - and can be disabled by the dd procedure. 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, Chris Guiver wrote: > libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied Oops. No read permission for normal users on USB sticks. (I should really operate my workstation with a more conventional setup so that i better anticipate other's adventures.) > My thumb-drive K does not boot on > - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) > - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915) > as it stands now. Obviously the addicted HPs don't see a boot flag. > echo $'\x80' | dd of=/dev/sdb bs=1 count=1 conv=notrunc seek=446 > it NOW BOOTS ON > - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) > - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915) Another confirmation that the flag was not set before. The only small chance for a red herring would be a prolonged history of experiments with the ISO on the stick, which would have caused casper to not do what it normally does. We had that in the #50s comments. -- So if we want to propose a workaround for the current layout, it would be a good base if you could confirm that j3400 boots after the plain procedure with no other experiments inbetween: # Patch the ISO already as image on hard disk ISO=ubuntu-22.04-desktop-amd64.iso dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462 # Put it onto the USB stick as you usually do. E.g. sudo dd bs=4M oflag=sync status=progress of=/dev/sdb if="$ISO" Then you would check if it boots twice on the j3400. If the second boot succeeds and shows a writable big partition as last one, then we could be sure that this procedure is a valid workaround. A run of sudo xorriso -indev stdio:/dev/sdb -report_system_area plain would (hopefully) confirm that there is no second MBR partition with boot flag. Of course it would be enough if you can confirm that you did this already during the experiments, with no intermediate manipulations. But given the curvy way of this bug report, we need to be sure. -- Assumed that dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462 is really a reliable way to make the Ubuntu ISOs boot on the few old BIOS machines, which slow down GRUB when encountering the combination of GPT and MBR dummy partition, we would need a way to inform the downloaders of Ubuntu ISOs about this trick. To whom would we have to talk to get this proposal onto sites like https://ubuntu.com/tutorials/install-ubuntu-desktop which gets pointed to by a link on https://ubuntu.com/download/desktop I think it should be mentioned in https://ubuntu.com/tutorials/install-ubuntu-desktop#4-boot-from-usb-flash-drive like "On some very old and meanwhile rare machines it can last 8 minutes or longer until you see this welcome screen. If you plan just a single installation then simply wait until the screen appears. But if you plan to repeatedly use the "Try Ubuntu" offer on such an old machine, then see [link to new page tutorials/remove-boot-flag-from-iso] for a way to substantially shorten this time span." The new page would briefly explain the problem and propose the manipulation before putting the ISO onto the USB stick. It would warn not to do this unless a first boot attempt really lasted unreasonably long. 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
My thumb-drive K does not boot on - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915) as it stands now.. (No big news as dc7700 & dc7900 usually react the same; but confirmed it won't boot on dc7900) Likely not required; but again -- guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev stdio:/dev/sdb -report_system_area plain xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied xorriso : FAILURE : Cannot acquire drive 'stdio:/dev/sdb' xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' -- Executed -- [sudo] password for guiverc: root@d960-ubu2:~# echo $'\x80' | dd of=/dev/sdb bs=1 count=1 conv=notrunc seek=446 1+0 records in 1+0 records out 1 byte copied, 0.000132766 s, 7.5 kB/s root@d960-ubu2:~# -- Safely ejected thumb-drive; tested and it NOW BOOTS ON - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915) I only booted to maybe-ubiquity|try/install then used sysrq-REISUO. If you needed me to complete boot & shutdown like a user, you'll have to ask me to do that. I tested boot again on - dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550) - dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350) and sysrq-REISUO when it reached maybe-ubiquity|try/install The following would NOT BOOT thumb-drive K now - sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT) (I didn't get it to boot on samsung 700t1c-p10aat either, but I can't rule out me; as I find that device a pain booting external media) Inserting thumb-drive K into my primary box -- guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev stdio:/dev/sdb -report_system_area plain xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied xorriso : FAILURE : Cannot acquire drive 'stdio:/dev/sdb' xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev stdio:/dev/sdb -report_system_area plain xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied xorriso : FAILURE : Cannot acquire drive 'stdio:/dev/sdb' xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' guiverc@d960-ubu2:~/uwn/issues/735$ sudo xorriso -indev stdio:/dev/sdb -report_system_area plain [sudo] password for guiverc: xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Loading ISO image tree from LBA 0 xorriso : UPDATE : 940 nodes read in 1 seconds libisofs: NOTE : Found hidden El-Torito image for EFI. libisofs: NOTE : EFI image start and size: 1782345 * 2048 , 8496 * 512 xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev 'stdio:/dev/sdb' 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, 1784635 data blocks, 3486m data, 4146m free Volume id: 'Ubuntu 22.04 LTS amd64' System area options: 0x4201 System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT ISO image size/512 : 7138540 Partition offset : 16 MBR heads per cyl : 0 MBR secs per head : 0 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0xee1 15630335 GPT: N Info GPT disk GUID : cfe88ff9575b6a418e0fa695d43fc159 GPT entry array: 2 248 separated GPT lba range : 64 15630272 15630335 GPT partition name : 1 490053004f003900360036003000 GPT partname local : 1 ISO9660 GPT partition GUID : 1 cfe88ff9575b6a418e0ea695d43fc159 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 64 7129316 GPT partition name : 2 41007000700065006e006400650064003200 GPT partname local : 2 Appended2 GPT partition GUID : 2 cfe88ff9575b6a418e0da695d43fc159 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x GPT start and size : 2 7129380 8496 GPT partition name : 3 4700610070003100 GPT partname local : 3 Gap1 GPT partition GUID : 3 cfe88ff9575b6a418e0ca695d43fc159 GPT type GUID : 3 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 3 0x1001 GPT start and size : 3 7137876 600 GPT partition name : 4 GPT partition GUID : 4 8e2bdedd63554344a8fad7869da92b5a GPT type GUID : 4 af3dc60f838472478e793d69d8477de4 GPT partition flags: 4 0x GPT start and size : 4 7139328 8490945 -- BUT PLEASE DO NOTE I didn't complete a single boot; using
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, Chris Guiver wrote: > └─sdb4 8:20 1 4G 0 part /media/guiverc/writable So it seems that casper added its persistent partition without creating a dummy MBR partition with boot flag. This simplifies the task of making current Ununtu ISOs digestible for the j3400. One run of dd if=/dev/zero bs=1 count=16 of="$STICK" conv=notrunc seek=462 suffices. Chris Guiver wrote: > guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev /dev/sdb > -report_system_area plain > xorriso : FAILURE : Drive address '/dev/sdb' rejected because: not MMC and > -drive_class 'caution' '/dev' My mistake. The program is right. The command proposal should have been xorriso -indev stdio:/dev/sdb -report_system_area plain Please run this to verify that the dummy partition is really not there after the first successful booting of the USB stick. (The demand for the "stdio:" prefix is a safety precaution to protect system disks from dangerous superuser activities. I forgot about it because i have a file /etc/opt/xorriso/rc which declares -drive_class harmless '/dev/sd[c-e]*' so that i don't have to use "stdio:" with my USB sticks. Whatever, -indev without -outdev to the same device prevents writing and -report_system_area "plain" does not want to write to the device. So it would be safe even for the system disks.) 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
My thumb-drive K (what was used in #107 & #101) which contains Ubuntu 22.04 LTS (20220416) resulted in PLEASE NOTE: I just noted the ISO date shows it wasn't the released image.. It'll be the last daily/final/RC i actually used in testing... I'd expect 20220419 for the released ISO. I don't expect it'll impair these results though. (parts of lsblk & blkid are included... I'm not sure the provided command xorriso contains I expected) sdb 8:16 1 7.5G 0 disk ├─sdb1 8:17 1 3.4G 0 part /media/guiverc/Ubuntu 22.04 LTS amd64 ├─sdb2 8:18 1 4.1M 0 part ├─sdb3 8:19 1 300K 0 part └─sdb4 8:20 1 4G 0 part /media/guiverc/writable sr0 11:01 1024M 0 rom guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev /dev/sdb -report_system_area plain xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. xorriso : FAILURE : Drive address '/dev/sdb' rejected because: not MMC and -drive_class 'caution' '/dev' xorriso : HINT : If the address is a legitimate target, prepend "stdio:" xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' guiverc@d960-ubu2:~/uwn/issues/735$ lsblk^Crriso -index /dev/sdb -report_system_area plain guiverc@d960-ubu2:~/uwn/issues/735$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS .. redacting loop devices & my sda disk sdb 8:16 1 7.5G 0 disk ├─sdb1 8:17 1 3.4G 0 part /media/guiverc/Ubuntu 22.04 LTS amd64 ├─sdb2 8:18 1 4.1M 0 part ├─sdb3 8:19 1 300K 0 part └─sdb4 8:20 1 4G 0 part /media/guiverc/writable -- I stopped at this point & haven't performed > This is obviously one of the machines which demand a boot flag in MBR. Does > it boot after you (rawly and naughtily) set the boot flag to MBR Please advise if I should continue, or other (the xorriso output didn't appear right to me) -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, Chris Guiver wrote: > I performed the command > `sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462` > to Ubuntu Desktop 22.04 LTS thumb-drive (K) > Booted on j3400 > BOOT1: > it was fully-operational at 2 min 45 secs So it looks like the dd run brought about the best boot-up speed we can expect from this hardware. (Please contradict me if i'm wrong.) > system just rebooted (alt-sysreq+reisub) > 03:11 system fully-operational So casper did not re-install the dummy partition 2 when creating a persistent partition. Well, did it create a new partition at all ? What do you get from xorriso -indev /dev/sdb -report_system_area plain Expectation: The report about the MBR partition table should list only one partition MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xee1 5090363 with possibly the Blocks number adjusted to the size of your USB stick. (The original ISO would show a MBR partition 2 MBR partition : 2 0x80 0x0001 which obviously makes the trouble with j3400.) The GPT part of the report would list a fourth GPT partition, if casper created one. > BUT FAILED TO BOOT on > - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) This is obviously one of the machines which demand a boot flag in MBR. Does it boot after you (rawly and naughtily) set the boot flag to MBR partition 1: echo $'\x80' | dd of=/dev/sdX bs=1 count=1 conv=notrunc seek=446 (If Ubuntu decides to leave these machines behind, this run could be the remedy for hp dc7700 and others. It is simpler than a dd run which installs partition 2. On the other hand it is clearly violating the specs.) What does the j3400 do with this state of the USB stick ? (If it boots slowly: Above dd run can be revoked by "cat /dev/zero" instead of "echo $'\x80'".) --- It looks like a fundamental decision by Ubuntu is needed: Since GPT specs forbid the boot flag with the MBR partition of type 0xee and since some EFI implementations indeed take offense if it is there, the MBR partition with its boot flag was the best compromise ... until j3400 and José Marinho's machine of which i could not find a model name. But now seems that Ubuntu needs to decide with its ISOs whether to leave behind either j3400 or hp dc7700. A good reason for keeping j3400 bootable is that this partition layout is fully specs compliant and tasty to all EFI implementations (... so far). The only partition layout for hp dc7700 which complies to UEFI and its GPT specs would be a MBR partition table marking the EFI partition by type 0xEF and no GPT. But although this is covered by the specs, there are EFI implementations known which don't boot from a device without GPT. (Really annoying to me is the fact that the old ISOLINUX/GRUB jackalope works for all machines with its MBR partition table and a dead GPT strapped on its back. Somehow i hope for a widely used EFI which hates it and forces it out of the world.) I guess that it is not an option to provide full ISO sets for both, the mainstream and some old exotic firmwares. I hope that the old jackalope is not an option either. So we should find easy-to-apply remedies for those old machines which need to be left behind. To do so, we need to know which group of them will be abandoned by the unmodified ISOs. 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Thomas Schmitt in #104 >...> motion computing j3400 > This one is possibly allowed to be somewhat slow. From me (comment #76) > ((or 3 mins 30 secs for `hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)` The time for lubuntu kinetic actually beat a comparison time of one of an old hp.dc7700 I use heaps in QA-testing. > This prompts another test request @ Chris Guiver: > Does it help to remove MBR partition 2 similarly to what i proposed a year > ago to José Marinho and what helped to boot: I performed the command `sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462` to Ubuntu Desktop 22.04 LTS thumb-drive (K) Booted on j3400 (note: times for BOOT1 will be ~3-8 secs slower than reported due my- error operating phone-stopwatch) BOOT1: (I won't give times as I can't be sure which are which) 00:18, 00:27, 01:57, 02:18, 02:45 HOWEVER either way it was fully-operational at 2 min 45 secs (or 3-8 secs after that anyway) system just rebooted (alt-sysreq+reisub) BOOT2: 00:25 screen clears & message(s) 00:28 plymouth seen 02:17 maybe-ubiquity; try/install selection (I may have been a tad slow here in selecting try) 02:41 (i forget sorry) 03:11 system fully-operational Maybe my [estimated] 3-8 secs is inaccurate; but I'd suggest it was similar. FYI: If you need more testing; just ask (or I miss anything I was asked).. I'll boot the thumb-drive on a few boxes to confirm no issues with the I'll go & boot the thumb-drive on some boxes to ensure it's usable elsewhere.. I'll edit this and add boxes it was tested on (I'm not expecting any issues) It booted successfully on - hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600) BUT FAILED TO BOOT on - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, i have to correct a statement of mine in #104: > Last year this worked only once, because casper added the partition again > during "persistent partition creation". This could be fixed now: > https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/60 It's probably not fixed. The comment by Steve Langasek rather announces the problem which José Marinho experienced: casper was probably adjusted to create the boot flag when creating the persistent partition. Originally it did not preserve it. We will see what the j3400 does on first and second boot attempt. 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
I agree with Thomas about the problems to boot some old computers. I'm continuing to develop/tweak dus-iso2usb, added an extra (optional) parameter 'boot-flag' that can be added when mkusb partition table is selected. It helps HP computers, but may spoil booting some other computers. So I think we probably need ways to get boot drive versions with and without a boot flag. One way would be two different iso files, another way is to use some special tool (like dus-iso2usb) for the corner cases that need a boot flag. -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, Chris Guiver wrote: > BOOT2: LIVE > 00:25 secs & screen blanks & messages > 00:35 plymouth visible > 01:11 message(s) again & plymouth gone > 02:23 system fully-operational The overall boot time is still very long. But no particular stage stands out as the big time waster. >...> motion computing j3400 This one is possibly allowed to be somewhat slow. > Ubuntu Desktop 22.04 LTS > 08:01 screen blanked I really wonder which side, GRUB or vmlinuz, causes this delay. After wasting time with clueless experiments i re-read what we have and what i vastly forgot. -- This prompts another test request @ Chris Guiver: Does it help to remove MBR partition 2 similarly to what i proposed a year ago to José Marinho and what helped to boot: # (When replacing the "X", take care not to zap your system disk) STICK=/dev/sdX dd if=/dev/zero bs=1 count=16 of="$STICK" conv=notrunc seek=462 Last year this worked only once, because casper added the partition again during "persistent partition creation". This could be fixed now: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/60 If not fixed: A second dd treatment after the first boot was not overridden by casper in the next Live system run. -- Summary of my re-reading: José Marinho wrote in https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/35 > With the iso without any change: > - Plymouth --> 7 minutes > - Desktop environment --> 7 minutes 50 seconds > Marking the first partition as bootable legacy BIOS: > - Plymouth --> 54 seconds. > - Desktop environment --> 1 minute 45 seconds > Without marking any partition as bootable but changing the partition table > from GPT to MBR: > - Plymouth --> 25 seconds. > - Desktop environment --> 1 minute 20 seconds. So we had already a good suspect for a delay of about 6 minutes. Then we had the red herring of these lines in grub.cfg which for a while seemed to be the culprit. I proposed a change in #39. But in #55, José Marinho finally reported that the intermediate success was rather due to inadverted partition table changes during the experients. In #60 i propose to remove partition 2 from the MBR. (This partition exists to lure in some HP laptops which want to see a boot flag. This flag is forbidden for the GPT-announcing partition slot.) José Marinho reports in #61 that this helps for one time booting, but not for further attempts to boot. In #70 i demonstrated that the software in the ISO manipulates the MBR partition table of the stick. In #73 i point to "casper" and its "persistent partition creation". Chris Guiver introduced the j3400 tablet to us in #76. Chris Guiver and Brian Murray let GRUB be verbose in #82 and #83. It prints: > "Booting a command list" Screenshots are at #84 and #85. Since the messages do not look to me like from a Linux kernel, it appears that the delay is in GRUB. We could ask at grub-devel for help. But it happens only to a few (old ?) machines and it is about the boot flag, which at least Vladimir Serbinko rejected firmly when the HP laptops showed up which don't boot without it. So the conclusion of "tlk (sarcasticskull)" in #91 is noteworthy: > kinda frustrating that the fixes/kludges for both "advanced" EFI and > legacy crap "proprietary" systems suddenly make booting an Ubuntu LTS > live ISO impossible I thought i had read the proposal to have two flavors of Live ISOs but cannot find currently it in this giant bug report. So without the claim to have invented it myself: Have an EFI+BIOS flavor without the problematic boot flag in the MBR, and an Odd-Old-BIOS flavor without GPT and with boot flag. Most machines, including those which are affected by this bug would boot by the EFI+BIOS ISOs. Only a few would need Odd-Old-BIOS. - A peek over the fence: Fedora considers to adopt for its ISOs the GPT partition layout without boot flag in MBR: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/2G3DQ5SGCV5DSD7NPVXU3KAKQ57BOXVU/ They found a Dell XPS 15 L502X laptop which does not boot from this but also does not boot if a boot flag MBR partition is added. Nevertheless it looks like Fedora is willing to leave it behind together with the HP laptops which want the boot flag. 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
I grabbed my phone (stopwatch app) & lubuntu (kinetic; what was used last time) thumb-drive & timed a boot of Lubuntu kinetic (no new write of ISO) Purpose: > (#102) Are those times stable or do they vary by minutes ? I hoped it would be a re-creation of #92 (but didn't read was there so it wouldn't influence result), alas I didn't use stopwatch then & didn't note which option I used > (#92) I didn't set up stopwatch to time correctly; but room clock said 13:16 at start of boot, and system was fully functional just as it hit 13:22 ie. system operation in ~5 mins (<5 I believe as clock had just flipped 13:22 as it appeared), but I didn't say if persistent OR live was used. OPTION USED THIS TIME = LIVE only (not persistent) BOOT 1: LIVE started stopwatch as I pressed ENTER at grub by 2 mins 43 secs the system appeared functional BOOT2: LIVE 00:25 secs & screen blanks & messages 00:35 plymouth visible 01:11 message(s) again & plymouth gone 02:23 system fully-operational BOOT3: LIVE 00:29 secs & screen blanks & messages 00:35 plymouth visible 01:10 message(s) again & plymouth gone 02:25 system fully-operational BOOT4: PERSISTENCE 00:27 secs & screen blanks & messages 00:34 plymount visible 01:41 message(s) again & plymouth gone 03:06 system fully-operational (boot 4 and there was a longer delay between wallpaper being drawn & the menu responding to wacom-pen or SUPER key being pressed & menu appearing which is what I use to detect 'fully-operational) Boot 2 & 3 are identical; any differences will be me needing to press the screen on the phone more than once to get it to register 'lap' time. Re-creating test #101 using Ubuntu Desktop 22.04 LTS (comment #101) > - 00:09 enter pressed at GRUB > - 08:06 screen blacked > - 08:20 ubuntu plymouth first appeared > - 09:52 plymouth is gone, system text message appears > - 10:10 maybe-ubiquity TRY INSTALL prompt > - 10:37 system fully operational (I started time at ENTER PRESSED at GRUB, so 9 secs difference expected) 08:01 screen blanked 08:08 ubuntu plymouth first appeared 09:41 plymouth is gone, system text message(s) appear 10:08 maybe-ubiquity; TRY/INSTALL prompt 10:55 system fully operational Times here start out consistent (9 secs difference expected as I started time with right hand as I hit enter at grub with left, last time it was when I saw 'grub' prior to grub.menu appearing), however at MAYBE- UBIQUITY times differed a bit.. and final-operational differs well beyond any user/me error(s) Picking when a system is 'fully operational' is subjective, so a few secs difference can be just me using wacom-pen touching screen OR hitting SUPER at the right sec, versus a short delay (as I'm not hitting key/pen rapidly), but we have ~30 secs difference (10mins37secs-9sec 10m55s?) > (#102) Are those times stable or do they vary by minutes ? To me as a user they feel ~stable; but BOOT 1 of Lubuntu LIVE was slower than BOOTS 2 & 3 (which were consistent; boot 4 was different mode).. and some some times of Ubuntu Desktop were identical; but by end they differed beyond I believe could be me. They don't vary by minutes though in my opinion; secs like this is all I've generally noted (and some of those secs are likely me/dog; hitting my phone with the wacom pen for the device instead of my finger as I did on last test; I can't see that adding 20 secs though! etc) -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, Chris Guiver wrote: > lubuntu (jammy) plymouth seen at 7:27 (#90) > ubuntu (jammy) plymouth seen at 8:20 (#101) So it is not about the "huge amounts of time" which ubuntu.seed wants to avoid. Are those times stable or do they vary by minutes ? We know that the firmware executes GRUB without much delay. I am pondering how we could find out when GRUB hands over execution to vmlinuz. Any ideas anybody ? 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Booting the released image of Ubuntu Desktop 22.04 LTS - 00:00 word 'GRUB' appeared on screen (where I started stopwatch, so these results will be ~10 secs slower sorry) - 00:09 enter pressed at GRUB - 08:06 screen blacked - 08:20 ubuntu plymouth first appeared - 09:52 plymouth is gone, system text message appears - 10:10 maybe-ubiquity TRY INSTALL prompt - 10:37 system fully operational quick comparison with comment #90 (https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/90) shows ~minute longer to be fully functional; given a 1-5 secs gets lost as touch 'try ubuntu' it's still longer lubuntu (jammy) plymouth seen at 7:27 (#90) ubuntu (jammy) plymouth seen at 8:20 (#101) -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
@ guiverc, I think you have suitable hardware and the best experience of us to answer the question in comment # 99. -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, sudodus wrote: > http://cdimage.ubuntu.com/lubuntu/releases/22.04/release/ The "Try or Install" menu item of grub.cfg in lubuntu-22.04-desktop-amd64.iso differs from the one of ubuntu-22.04-desktop-amd64.iso mainly by kernel parameter file=/cdrom/preseed/lubuntu.seed instead of ubuntu.seed. The .seed files differ by: --- ubuntu.seed 2022-05-15 19:02:13.187611554 +0200 +++ lubuntu.seed 2022-05-15 19:01:54.003611482 +0200 @@ -1,9 +1,8 @@ +# The Lubuntu seeds assume that installation of Recommends is disabled. +d-ibase-installer/install-recommends boolean true # Enable extras.ubuntu.com. d-iapt-setup/extrasboolean true -# Install the Ubuntu desktop. -taskseltasksel/first multiselect ubuntu-desktop -# On live DVDs, don't spend huge amounts of time removing substantial -# application packages pulled in by language packs. Given that we clearly -# have the space to include them on the DVD, they're useful and we might as -# well keep them installed. -ubiquity ubiquity/keep-installed string icedtea6-plugin openoffice.org +# Install the Lubuntu desktop. +taskseltasksel/first multiselect standard, lubuntu-desktop +# No LXDE translation packages yet. +d-ipkgsel/language-pack-patterns string It is noteworthy that ubuntu.seed talks of avoiding "huge amounts of time", whereas lubuntu.seed does not. Does ubuntu-22.04-desktop-amd64.iso boot faster than the lubuntu ISO ? 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
At https://releases.ubuntu.com/22.04/ you find the amd64 iso file and its sha256sum, and at http://cdimage.ubuntu.com/lubuntu/releases/22.04/release/ you find the corresponding Lubuntu files. -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, sudodus wrote: > The grub comes from a compressed tarball, Well, then the hope to find a simple explanation from tweak 3 was an illusion. I am staring at the /boot/grub/grub.cfg of ubuntu-22.04-desktop-amd64.iso and compare it with Chris Guiver's comment #90: >...> "00:10 secs enter pressed at grub >...> BLINKING CURSOR without change until >...> 7:19 (7 mins 19 secs) first boot message So i assume that /boot/grub/grub.cfg was executed. But then would last very long to get from linux /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- initrd /casper/initrd to a usable system. Do i look at the wrong ISO ? (I could not find Ubuntu "live" ISOs in the web.) 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi again Thomas, The grub comes from a compressed tarball, that is extracted onto the target drive. This makes it independent of the current operating system and its version of grub. So in order to look at it, use dus-iso2usb, or if you want only the basics, extract only the tarball, in this case if you installed mkusb 22.0.1 /usr/share/mkusb/dd_grub-boot-template-for-uefi-n- bios_msdos_grub-2.0.2-n-2.0.4.img.xz If you don't want to install mkusb into your main system, you can install it into a persistent live system in a USB pendrive or into a system in a virtual machine. -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, sudodus wrote: > # tweak 3: search by UUID > sed -i '/set isofile/'a" search --set=root --fs-uuid $uid3" > "$targ1"/boot/grub/grub.cfg > sed -i 's/(hd0,3)/($root)/' "$targ1"/boot/grub/grub.cfg Where does the grub.cfg come from, in which you find "set isofile" and "(hd0,3)" ? I looked into /boot/grub/grub.cfg of ubuntu-22.04-desktop-amd64.iso and of ubuntu-20.04.1-live-server-amd64.iso . Nothing to see of above search texts. 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi Thomas Schmitt,
> I wonder what is meant by "add some tweaks".
1. Made grub use UUID instead of device name to identify partition where
to find the grub files
---
# create grub.cfg to match iso file's name
echo -e "$inversvid tweak grub ...$resetvid"
# tweak 3: search by UUID
sleep 2
partprobe
sleep 2
targ1=$(mktemp -d --tmpdir dus.XX)
uid2=$(lsblk -o uuid,label "$target" |grep -i 'usbboot'|sed "s% *usbboot%%")
uid3=$(lsblk -o uuid,label "$target" |grep 'isodevice'|sed "s% *isodevice%%")
echo "uid2=$uid2"
echo "uid3=$uid3"
mount -U "$uid2" "$targ1"
sleep 2
if [ "$uid3" != "" ]
then
sed -i '/set isofile/'a" search --set=root --fs-uuid $uid3"
"$targ1"/boot/grub/grub.cfg
sed -i 's/(hd0,3)/($root)/' "$targ1"/boot/grub/grub.cfg
if [ $? -ne 0 ]
then
error="$error - sed: tweak 3 grub.cfg"
result="target drive might work, but setting 'search by UUID' failed :-("
echo "$result"
fi
fi
umount "$targ1"
rmdir "$targ1"
sleep 2
partprobe
sleep 1
}
---
# tweak 1: maybe modify label of partition for persistence
mntpt=$(mktemp -d --tmpdir dus.XX)
mount -o loop "$source" "$mntpt"
syslbl=$(lsblk -o label,mountpoint | grep "$mntpt"|sed "s% *$mntpt%%")
umount "$mntpt"
sleep 2
isover=$(<<< "$syslbl" grep -o ' [0-9]*\.'|grep -o '[0-9]*')
pptarg=$(lsblk -lo name,label "$target" |grep writable|sed -e 's/ .*//' -e
's#^#/dev/#')
if [ $isover -lt 20 ]
then
tune2fs -L casper-rw "$pptarg"
sleep 1
fi
# tweak 2:
# To make Firefox work in Jammy & newer:
# apparmor.service.d/30_live_mode.conf: ConditionPathExists=
if [ $isover -ge 22 ]
then
targ1=$(mktemp -d --tmpdir dus.XX)
/bin/echo -e "$inversvid To make Firefox work in Jammy & newer $resetvid
apparmor.service.d/30_live_mode.conf: ConditionPathExists="
umount "$targ1" 2>&1
targ0=$(mktemp -d --tmpdir dus.XX)
mount -o loop "$source" "$targ0" 2>&1
echo '$pptarg $targ1'": $pptarg $targ1"
mount "$pptarg" "$targ1" 2>&1
tghme=$(find "$targ0" -name '*ubuntu*.seed')
# echo "$tghme"
tghme=${tghme##*/}
tghme=${tghme%.seed}
if [ "$tghme" == "ubuntustudio" ]
then
tghme='ubuntu-studio'
elif [ "$tghme" == "" ]
then
tghme=$(grep -om1 'ubuntu-kylin' "$targ0"/casper/filesystem.manifest)
fi
echo "target's home directory: /home/$tghme"
mkdir -p "$targ1"/upper/home/"$tghme"/.config/autostart
mkdir -p "$targ1"/upper/usr/local/sbin
cp /usr/share/mkusb/fixfox.desktop
"$targ1"/upper/home/"$tghme"/.config/autostart
cp /usr/share/mkusb/fixfox "$targ1"/upper/usr/local/sbin
umount "$targ1" "$targ0" 2>&1
rm -r "$targ1" "$targ0"
# read -p "press Enter to continue"
fi
---
I think tweak 3 is most relevant in this case (of this bug report).
I have also noticed that it is difficult to 'make all computers happy
with the same configuration' even within the group that want an MSDOS
partition table.
The bug of this report seems to be somewhat worked around by the version
in dus-iso2usb version 22.0.1, but I think old HP computers with
core2duo processors want a bootable flag on the partition where grub is
located. However, adding that boot flag seems to stop booting in UEFI
mode. I am trying to make a configuration work for all these test cases
...
--
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:
Impish live session takes ages to boot on BIOS systems
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hi, Chris Guiver wrote: > The ISO wasn't cloned to thumb-drive; but written using > `sudo -H dus-iso2usb kinetic-desktop-amd64.iso /dev/sdb msdos grub-2.0.4 > persistent` Ahum. Congrats to sudodus then. :)) I read in https://help.ubuntu.com/community/mkusb#Installation "The main function of dus-iso2usb is to 1. extract the first partitions and the grub structure from compressed image files 2. create new partitions, one for an iso file labeled 'isodevice', and one optional for persistence labeled 'writable' (or in older systems labeled 'casper-rw'). 3. copy iso file to 'isodevice' and add some tweaks. " So this indicates that GRUB alone is not to blame for the slow booting. Something in the ISO's partitioning or GRUB configuration is needed for the problem. What do you get reported about the USB stick partitions by fdisk -l ? I wonder what is meant by "add some tweaks". 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
I just booted Lubuntu kinetic daily on - motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series) I didn't set up stopwatch to time correctly; but room clock said 13:16 at start of boot, and system was fully functional just as it hit 13:22, which is way faster than comment #90 on same box with jammy ISO. The ISO wasn't cloned to thumb-drive; but written using `sudo -H dus-iso2usb kinetic-desktop-amd64.iso /dev/sdb msdos grub-2.0.4 persistent` guiverc@d960-ubu2:/de2900/lubuntu_64$ apt-cache policy mkusb mkusb: Installed: 22.0.1-1ubuntu2 Candidate: 22.0.1-1ubuntu2 Version table: *** 22.0.1-1ubuntu2 500 500 http://ppa.launchpad.net/mkusb/unstable/ubuntu kinetic/main amd64 Packages This comparison isn't complete; as different ISOs used (jammy vs kinetic) & different writes (clone/dd vs mkusb-altered), but noted here. -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Hitting this rn with Ubuntu MATE 22.04 dd'ed onto a USB stick Spotted the grub_platform thingy, then had to wait (after reading this bug) like ~20 min after the GRUB menu for it to start booting. Run of the mill legacy (I guess) platform: Gigabyte GA-970A-DS3/GA-970A-DS3, BIOS F7a 01/24/2013 AMD FX-6100 8GB Kinda frustrating that the fixes/kludges for both "advanced" EFI and legacy crap "proprietary" systems suddenly make booting an Ubuntu live ISO impossible (or at least having some hint on what's going on). -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
** Also affects: casper (Ubuntu Kinetic) 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Lubuntu 22.04 LTS (jammy) ISO booting on - motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series) 00:10 secs enter pressed at grub (I could reduce 10secs from following times, but have opted not to) BLINKING CURSOR without change until 7:19 (7 mins 19 secs) first boot message 7:27 lubuntu plymouth is seen 8:04 system messages replace plymouth 8:31 Xorg mouse pointer is seen 9:12 lubuntu wallpaper is drawn by 9:20 the system is fully functional ** Tags added: jammy -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
** Also affects: ubuntu-release-notes Importance: Undecided Status: New ** Changed in: ubuntu-release-notes Status: New => Fix Committed -- 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: Impish live session takes ages to boot on BIOS systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems
Booting Ubuntu Desktop (groovy RC 2020-10-16.4) - - motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series) and plymouth takes ~8 mins to appear on screen the maybe-ubiquity (try or install) screen took >10 mins I did mention groovy in comment #17, but I don't believe I filed bugs, just noted on iso.qa.ubuntu.com QA-test reports. I didn't use stop-watch, but looked at room clock in room (digital without seconds so my times are approx only).. My ISO may also not have been released groovy; just last I zsync'd prior to release for QA. -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
I can write a 20.10 ISO to a thumb-drive & re-test it on - motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series) to confirm/deny @juliank's #86 comment on that box. That device is not a common box used for QA by me so it's possible I may not have used it late in the groovy cycle... I won't do it tonight though; it'll have to be tomorrow if helpful. -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
qemu kvm data, with the iso specified as -hda - 23s to splash on 20.04 BIOS (isolinux), vs 22s on UEFI - 30s to splash on 21.04 BIOS, vs 19s on UEFI I have resized the image using fallocate to be 16G, but that did not increase boot time. Optimized VM (kvm, virtio HD): - 3s to splash on 20.04 BIOS, 4s to splash on UEFI - 9s to splash on 21.04 BIOS, 3s to splash on UEFI These times are on very fast Samsung NVMe SSD. All times from starting the boot item in the grub menu to splash appearing. -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
Are we sure this issue does not happen on 20.10 as well? It seems to spend the same time in 20.10, 21.04, 21.10, and jammy daily when booted in a qemu vm. I don't know for sure what's going on, I assume it's trying to read the entire partition into memory to verify it, but not 100% sure. Certainly it seems to be trying to verify the initrd, loading it takes longer than the kernel. -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
There was also a much shorter pause in the boot process at: "commands/verifiers.c:88: file: /casper/vmlinuz type: 3" The attached picture shows what happens after that. ** Attachment added: "IMG_20220112_115522.jpg" https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/+attachment/5553628/+files/IMG_20220112_115522.jpg -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
Reading the grub manual I found a "pager" option which causes the output to pause after each screenful. By setting that I was able to capture what happens after "lib/relocator.c:1410:". ** Attachment added: "IMG_20220112_120411.jpg" https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/+attachment/5553622/+files/IMG_20220112_120411.jpg -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
I modified the grub arguments, using grub shell, so that "set debug=all" was used. Having done that and watching the boot process the last message I saw before a very long pause was: "lib/relocator.c:1410: chunks = 0xb9fd5c00" The context before the pause can be found in the attached screenshot. ** Attachment added: "IMG_20220112_082453.jpg" https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/+attachment/5553603/+files/IMG_20220112_082453.jpg -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
I just noted Brian's comment so booted a somewhat recent jammy (2021-12-29) Lubuntu ISO on - motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series) with 'quiet splash' removed I had ~similar response to Brian... " Booting a command list \n\n" & blinking cursor for a long time before eventual boot. -- 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: Impish 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: Impish live session takes ages to boot on BIOS systems
If I remove "quiet splash" from the grub command prompt, which I reach quickly on the above system, I see "Booting a command list" and then nothing else until the system is booted. -- 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: Impish 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
