You are not logged in.
I'm attempting to fix a ThinkPad t420 which is unable to boot after installing intel-ucode, possibly due to a broken bootloader (efistub) configuration.
Summary
The system is up to date and has been booting successfully with efistub previously. I'm using LVM on LUKS with an unencrypted boot volume as described in https://wiki.archlinux.org/index.php/Dm … VM_on_LUKS
After installing intel-ucode and creating a new boot entry with efibootmgr, the system boots to a black screen.
Ordinarily I would boot archiso from a usb drive and chroot in to fix the bootloader, but due to an error that I made in specifying boot order (see below), I don't seem to be able to boot via usb. I'm hoping that someone can offer some advice so I can get efistub working again, and hopefully get intel-ucode working as well.
Steps Taken
pacman -S intel-ucode
efibootmgr --device /dev/sda --part 1 --create --label "arch-ucode" --unicode 'cryptdevice=UUID=<UUID-of-/dev/sda1>:cryptlvm root=/dev/vg/root resume=/dev/vg/swap rw initrd=\intel-ucode.img initrd=\initramfs-linux.img'(Yes, I did use the actual UUID -- since I don't have access to the system as I'm writing this, the above is transcribed from memory.)
efibootmgr --verboseVerified that the only difference between the previous boot entry and the new one is "initrd=\intel-ucode.dmg".
The new boot entry has index 001A; the old one is 0019. here's where I believe I made a mistake:
efibootmgr --bootorder 001A,0019 --verboseThe error was obviously in thinking that this would simply move 001A before 0019 instead of removing all the other entries as well.
sudo rebootSystem shows thinkpad bios splash screen, then hangs on a black screen.
(boot into bios)Boot menu shows only the new "arch-ucode" entry and the one i was using previously (label "arch").
(select "arch")System boots to black screen again.
(power off, insert archiso usb drive, and power on again)System boots to black screen.
(power off and boot to bios with usb drive connected)Boot menu still shows only "arch-ucode" and "arch", as it did when no drive was connected.
My assumption is that there are two problems here. First, either an issue with intel-ucode or the boot entry that I created for it. Second, the removal of the boot entry which would have made it possible to boot from a usb drive. I'm hoping that someone can tell me whether I understand this correctly and what options (if any) I have for repairing the bootloader and getting this machine booting again. Thanks in advance.
Last edited by catniptwinz (2020-11-17 19:07:36)
Offline
Have you tried hitting [F1] while the Lenovo splash screen is up? This may kick you into a Lenovo menu which would allow you to select a temporary hardware device (i.e., your USB drive) from which to boot.
Please see pages 177, 179 and 180 of the T420 Manual.
Regards,
Offline
Have you tried hitting [F1] while the Lenovo splash screen is up?
Thanks for the suggestion; this was the first thing I thought to do. Unfortunately because I accidentally removed all of my other boot entries, the only options available in the "Boot Priority Order" menu are the boot entry that I was using previously (which worked until I installed intel-ucode) and the one that I created for intel-ucode. Booting either of these hangs on a black screen. These are the same options that I see when I power on holding F12, even with a known good archiso usb connected.
Offline
Okay, pleased to say that I've resolved the issue with the efi boot entries. Regardless of the boot order displayed in "bios", the system would not boot if the "arch-ucode" entry was present. Once I deleted it, I was able to boot using my old (non-ucode boot entry) and repair the boot order with efibootmgr.
However, I'm still unable to boot with microcode. Here's the actual command that I used to create the boot entry:
sudo efibootmgr --create --label "arch-ucode" --loader \vmlinuz-linux --unicode 'cryptdevice=UUID=6c70f63d-dce3-4a70-baed-3f7cc7de2622:cryptlvm root=/dev/vg/root resume=/dev/vg/swap rw initrd=\intel-ucode.img initrd=\initramfs-linux.img' --verboseintel-ucode is version 20200616-1 and vmlinuz-linux, intel-ucode.img, and initramfs-linux.img are all directly under my EFI partition, which is /dev/sda1, mounted at /boot
Offline
Just a quick update: this issue persists with intel-ucode version 20201112-1. Any advice on how I might troubleshoot this would be appreciated.
Offline
Does /boot/intel-ucode.img exist? Is it possible that you installed intel-ucode while /boot was not mounted? Is it possible that your EFI implementation dislikes multiple initrd entries, such that you'll need to concatenate the two?
Regards,
Offline
If you add the parameter dis_ucode_ldr to the entry with microcode which will disable the kernels microcode loader [1] can you then use the entry?
Offline
Thanks both of you for your suggestions.
Does /boot/intel-ucode.img exist? Is it possible that you installed intel-ucode while /boot was not mounted?
Yes, /boot/intel-ucode.img is present and its mtime corresponds to the time at which I installed the last update.
If you add the parameter dis_ucode_ldr to the entry with microcode which will disable the kernels microcode loader [1] can you then use the entry?
No, adding `dis_ucode_ldr` to the kernel params in my boot entry does not seem to make any difference.
Is it possible that your EFI implementation dislikes multiple initrd entries, such that you'll need to concatenate the two?
Indeed, that seems to be the issue. If I do:
cat /boot/intel_ucode.img /boot/initramfs-linux.img > /boot/initramfs-linux-ucode.img && chmod +x /boot/initramfs-linux-ucode.img
efibootmgr --create --label "arch-ucode" --loader \vmlinuz-linux --unicode 'cryptdevice=UUID=6c70f63d-dce3-4a70-baed-3f7cc7de2622:cryptlvm root=/dev/vg/root resume=/dev/vg/swap rw initrd=\initramfs-linux-ucode.img'...then reboot, the system boots as expected and
dmesg | grep microcodeprints:
[ 0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17
[ 0.707004] microcode: sig=0x206a7, pf=0x10, revision=0x2f
[ 0.707043] microcode: Microcode Update Driver: v2.2.So it looks like I just need to figure out how to automate this process for kernel updates. Thanks again!
Offline
Marked solved. One (hopefully quick) followup question, though. Assuming that I want to:
keep my efistub entries as they currently are (separate entries for Arch with and without intel-ucode)
ensure that the `initramfs-linux-ucode.img` file that I'm generating stays in sync with any updates to the kernel and the intel-ucode package
...would adding the following hook to /etc/pacman.d/hooks be an appropriate approach?
/etc/pacman.d/ucode-ramdisk.hook
...
[Trigger]
Operation = Upgrade
Type = Package
Target = linux
[Trigger]
Operation = Upgrade
Type = Package
Target = intel-ucode
[Action]
Description = Concatenating intel-ucode with initial ramdisk...
When = PostTransaction
Depends = linux
Depends = intel-ucode
Exec = /bin/sh -c 'cat /boot/intel-ucode.img /boot/initramfs-linux.img > /boot/initramfs-linux-ucode.img && chmod +x /boot/initramfs-linux-ucode.img'Offline