You are not logged in.
I use refind to boot and have used it without issue for the life of my laptop. Today after update to the kernel to 5.7.2-arch1-1 the laptop failed to boot and I had the message on the screen:
EFI stub: ERROR: failed to open file /boot/intel-ucode.img
Error: Not Found returned from vmlinuz-linux
I fortunately have an option in refind to boot via grub using the refind stanza in refind.conf:
menuentry "Arch Linux and grub" {
icon EFI/refind/icons/os_arch.png
volume 850c708f-e49d-4644-b2a5-2e7f2e4f179a
loader /boot/vmlinuz-linux
initrd /boot/initramfs-linux.img
options "rw root=UUID=7ca56a4d-53d8-4b15-9d31-b303b2e50061 PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a initrd=/boot/intel-ucod
e.img quiet"
ostype Linux
submenuentry "boot via Grub" {
loader /boot/grub/grubx64_standalone.efi
initrd
options
}
}
and the refind_linux.conf is:
## This file should be present in the same directory as the EFISTUB kernel and initramfs files
## More info at http://www.rodsbooks.com/refind/linux.html , http://www.rodsbooks.com/efi-bootloaders/efistub.html
"Boot with defaults" "root=PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a rw initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img rootfstype=ext4 systemd.unit=graphical.target"
"Boot to console" "root=PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a rw initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img rootfstype=ext4 systemd.unit=multi-user.target"
"Boot Fallback to console" "root=PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a rw initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-fallback.img rootfstype=ext4 systemd.unit=multi-user.target"
Choosing the boot via grub option does allow the laptop to boot to the new kernel.
However I am puzzled as to why for the first time my laptop has failed to boot with refind directly and wondered if anyone else has had a similar problem with the 5.7 kernel using refind?
Edit: I have just found a possible answer in the thread: https://bbs.archlinux.org/viewtopic.php?id=256273
Edit 2: The comment about the use of backslashes in initrd files in options for the refind config files was the problem. Changing the forward slash to backslash both in the refind.conf menuentry stanza and in refind_linux.conf for the initrd definitions allowed the new kernel to boot normally via the efistub. i.e. initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img was changed to initrd=boot\intel-ucode.img initrd=boot\initramfs-linux.img and corresponding for the other lines in refind_linux.conf and in the options line in refind.conf
If anyone uses refind, it would be worth checking this in the refind configs before updating to kernel 5.7.2
Last edited by mcloaked (2020-06-11 17:44:47)
Mike C
Offline
I got the same error with:
initrd=/amd-ucode.img
Removing the leading '/' allowed it to boot as suggested in the link you provided.
Offline
I got the same error with:
initrd=/amd-ucode.img
Removing the leading '/' allowed it to boot as suggested in the link you provided.
Yes, and if the path had been in a subdir then any / would need to be changed to \ which was the case for my config files.
Mike C
Offline
Had the same Problem and changed / to \ and it worked, but I must say I find it quite confusing since it worked the other way. Also in the english wiki it says there should be a backslash
https://wiki.archlinux.org/index.php/EFISTUB
# efibootmgr --disk /dev/sdX --part Y --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw initrd=\initramfs-linux.img' --verbose
In the german wiki it says there should be a slash
https://wiki.archlinux.de/title/UEFI_In … on#EFISTUB
efibootmgr -c -d /dev/sda -p 1 -l \vmlinuz-linux -L "Arch Linux efistub" -u "initrd=/initramfs-linux.img root=LABEL=p_arch rw"
Most likely before 5.7.2 both worked and now only a backslash worked is this correct? And should that be the correct syntax?
Offline
It would certainly seem to be the case. Also somewhat of concern is the commit at https://github.com/torvalds/linux/commi … 0bd047f0f5 where it says: "Loading an initrd passed via the kernel command line is deprecated: it
is limited to files that reside in the same volume as the one the kernel itself was loaded from, and we have more flexible ways to achieve the same. So make it configurable so new architectures can decide not to enable it." So if anyone has the initrd file on a different volume to where the kernel is then booting presumably will become impossible.
So the question then is will there come a time when loading from an initrd kernel parameter in the arch linux kernel will not be switched on, and if so, how would arch refind users be able to boot the kernel at all? Will this impact other bootloaders also? I don't know if this has already been though of but it would be very re-assuring to know what is being planned so that our machines will continue to boot.
I understand that arch users who use dracut instead of mkiniticpio can avoid this issue, in contrast to me where I have to have two initrd parameters with one for the microcode file, because in dracut the microcode file is is part of the boot initrd.
Last edited by mcloaked (2020-06-12 09:25:27)
Mike C
Offline