Unable to boot after removing package intel-ucode

mb720 · 2021-12-18 13:05:45

I temporarily broke my Arch installation for the first time: After uninstalling package intel-ucode and rebooting some time later, I got this message:

error: file '/boot/intel-ucode.img' not found

For anybody encountering the same issue: You can fix this by reinstalling intel-ucode using an Arch Linux live USB:

Boot from the live USB stick
Mount the root partition, for example: mount /dev/sda3 /mnt
Reinstall intel-ucode which will create the file /boot/intel-ucode.img: pacman --root /mnt -S intel-ucode

I was wondering if removing intel-ucode could be made safer by either:

Warning the user that they need to reconfigure their bootloader after removing intel-ucode.
Automatically reconfiguring the bootloader after removing intel-ucode.
Not removing /boot/intel-ucode.img and telling the user to delete the file themselves and then reconfigure their bootloader if they don't want to use the updated microcode anymore.

Last edited by mb720 (2021-12-18 13:22:45)

V1del · 2021-12-18 16:03:44

2. and 3. are unfeasible 2 because it makes impossible assumptions about the user's setup that the user should be aware of themselves, 3 because the package would not actually contain a file anymore or rather you'd uninstall a package that then leaves a file lying around, this wouldn't be very intuitive to anyone that knows how packages work.

1. could be done, but what is/was your reasoning for doing this in the first place? New microcodes generally fix bugs and unless you did that to try and check whether you can avoid a certain bug I don't see why you'd generally do that in the first place.

Last edited by V1del (2021-12-18 16:04:40)

mb720 · 2021-12-19 17:46:39

The reasons I updated the microcode were:

Hoping to fix a bug but I didn't verify whether the microcode update made a difference.
Generally assuming that keeping microcode up to date is good practice.

I guess adding the microcode updates to initramfs would side-step the issue of users having different bootloaders but might load the updated microcode too late in case bugs in the original microcode would prohibit booting.

Last edited by mb720 (2021-12-19 17:47:13)

seth · 2021-12-19 21:58:10

mb720 wrote:

The reasons I updated the microcode were:

mb720 before wrote:

After uninstalling package intel-ucode

?

mb720 wrote:

You can fix this by

… editing the kernel command line in the bootloader.

mb720 · 2021-12-20 05:47:47

V1del asked me why I installed the package. I didn't intend to make this thread about my motives.

Rather, I wanted to discuss whether there's interest in making that package a bit safer. So that uninstalling it does not prevent booting.

Head_on_a_Stick · 2021-12-20 06:46:56

mb720 wrote:

I wanted to discuss whether there's interest in making that package a bit safer. So that uninstalling it does not prevent booting.

Perhaps file a bug report against the packages then. I don't think it's needed though because there's no real reason to uninstall the µcode, as V1del noted.

seth · 2021-12-20 06:53:40

… and also why he asked.

Even if you didn't want to discuss your motives to remove the package, despite them being at the very heart of the question "do we need to somehow secure the uninstallation despite nobody ever will reasonably do that?" (answer implied) - please don't try to diffuse that by making confusingly contradicting statements about the base of your inquiry.

V1del · 2021-12-20 09:03:21

To clarify, I wondered why you'd want to uninstall it when it's already installed and set up.

schard · 2021-12-20 09:08:23

Indeed this auto-update of the bootloader would be unfeasible, because there are a bunch of boot loaders and managers available.
Only you know which one you are using. So why not create your own ALPM hook to safe yourself from yourself uninstalling intel-ucode for no reason.

covid19 · 2022-11-03 09:16:12

Not to state the bleeding obvious, did OP even know/mention that the bootloader config needed a tiny tweak? Just get rid of the "/boot/intel-ucode.img" on the initrd line once the intel-ucode package is removed... clearly that's what it's trying to find from that package?
Assuming for the sake of performance and want absolutely nothing to do with the spectre/meltdown vulns? If so, also add the mitigations=off to the linux line aswel.
I usually do this immediately post-installation

		echo	'Loading Linux linux ...'
		linux	/boot/vmlinuz-linux root=UUID=(removed) rw  loglevel=3 mitigations=off 
		echo	'Loading initial ramdisk ...'
		initrd	/boot/intel-ucode.img /boot/initramfs-linux-fallback.img

Last line should probably be initrd /boot/initramfs-linux-fallback.img

Last edited by covid19 (2022-11-03 09:16:56)

ewaller · 2022-11-03 13:59:21

Covid19, your answer is correct, but I think the thread was not about how to fix it, but rather whether the package and its removal process should be hardened so as the problem would not have occurred in the first place.

Using this opportunity to close this old thread.

Arch Linux

#1 2021-12-18 13:05:45

Unable to boot after removing package intel-ucode

#2 2021-12-18 16:03:44

Re: Unable to boot after removing package intel-ucode

#3 2021-12-19 17:46:39

Re: Unable to boot after removing package intel-ucode

#4 2021-12-19 21:58:10

Re: Unable to boot after removing package intel-ucode

#5 2021-12-20 05:47:47

Re: Unable to boot after removing package intel-ucode

#6 2021-12-20 06:46:56

Re: Unable to boot after removing package intel-ucode

#7 2021-12-20 06:53:40

Re: Unable to boot after removing package intel-ucode

#8 2021-12-20 09:03:21

Re: Unable to boot after removing package intel-ucode

#9 2021-12-20 09:08:23

Re: Unable to boot after removing package intel-ucode

#10 2022-11-03 09:16:12

Re: Unable to boot after removing package intel-ucode

#11 2022-11-03 13:59:21

Re: Unable to boot after removing package intel-ucode

Board footer