FS#75673 - [grub] long(er) start delays after upgrading from 2.06.r261 to 2.06.r297
Attached to Project:
Arch Linux
Opened by Marcel Langner (LanMarc77) - Monday, 22 August 2022, 18:14 GMT
Last edited by Christian Hesse (eworm) - Saturday, 03 September 2022, 21:39 GMT
Opened by Marcel Langner (LanMarc77) - Monday, 22 August 2022, 18:14 GMT
Last edited by Christian Hesse (eworm) - Saturday, 03 September 2022, 21:39 GMT
|
Details
Description:
After the upgrade of grub from 2.06.r261 to 2.06.r297 and regenerating the config, as well as updating the binaries using grub-install I noticed a much longer delay before the system starts. As I have an encrypted root and boot FS (without LVM, plain partitions), the delay happens after the message Slot 0 opens and after selecting the menu entry of which kernel to boot. I assume just before the initial ramdisk is loaded or while. I am uncertain. The additional delay is around 15s from around 1..2s before the upgrade. Someone else has the same issue and we already verified that downgrading seems to fix the issue. Also installing on a completely different computer seems to result in the additional delay when upgrading grub ( https://bbs.archlinux.org/viewtopic.php?id=279006 ). After reading the bug report guidelines I am unsure if this is upstream or not and already apologize beforehand. |
This task depends upon
Closed by Christian Hesse (eworm)
Saturday, 03 September 2022, 21:39 GMT
Reason for closing: Fixed
Additional comments about closing: grub 2:2.06.r322.gd9b4638c5-4
Saturday, 03 September 2022, 21:39 GMT
Reason for closing: Fixed
Additional comments about closing: grub 2:2.06.r322.gd9b4638c5-4
There was also a bunch of commits after Arch upgraded, so a build of git trunk might also be worth testing.
[1] https://wiki.archlinux.org/title/Bisecting_bugs_with_Git
What filesystem do you use?
I am using btrfs for the encrypted partition that contains root and /boot. /efi is normal fat32 partition.
Linux runs on a separated disk and the others are all bitlocker windows disks or unencrypted ntfs.
I run Linux from an NVME inside a USB case that is connected to a USB3.2 GEN2 port.
I also took a look at the commits but did not really understood a lot. There was a btrfs commit, but earlier I think and than a ptimer something but it looked it was only fir older i386 systems.
If the other person is not able to test I will starting next week. Then I could organize a test system that can break.
And Thank you!
I'm using ext4 on a LUKS encrypted /boot partition on a Thinkpad X1 Carbon Gen 10 (August 2022).
also removing fwsetup does not change anything
So I think we can go on testing the next bisecting step
Btw I also have an AMI bios
the other person I was talking about is using OpenZFS with the lts kernel and r322 also does not change his loading speed
Just updated another AMI system but takes less than two seconds in the same stage (as expected on both systems).
I have never done bisecting before, but (I think) understood the process. As I have build other AUR packages in the past I am confident I can lift that weight.
Well, I keep you posted.
The last fastloading version was r267.g887f98f0d
This was a commit that seems to be part of a bigger code change by Patrick Steinhardt. All individual commits I tried afterwards brought up other errors and did not even start the system.
The last of this commit series was r271.g1df293482 and with this the system started again and was slow loading. I could see some changes in how memory seems to be allocated and some changes in loop structures.
Picture of the problematic commit area attached.
I think this means it is upstream? Then how do we go from here?
Well... As I can not reproduce this myself - Are you willing to contact upstream? I think your best bet is via mailing list: https://lists.gnu.org/mailman/listinfo/grub-devel
If they fix it I report back here.
It is booting fast with the version you put in testing. The change I was referring to is the original one, that made it slow.