The latest update of intel-microcode
package on Ubuntu broke some systems (mine in particular), and was the occasion to learn a bit more about initrd
images and Ubuntu boot procedure.
So, here are some notes of things that may be useful for future problems.
The initrd
image is mini-filesystem used to boot the OS. It’s a kind of trampoline root fileystem used by the kernel to initialize/activate/configure some hardware and/or features (e.g. full disk encryption, etc.)
Thus, this initrd
contains binaries that might need to be updated. This process is automatically performed by Ubuntu when you install your package updates, with some packages triggering a rebuild of this initrd
to incorporate the new and updated binaries.
So, when you install an update of intel-microcode
, the initrd
image is rebuilt to incorporate the new microcode files.
Ubuntu’s initrd
seems a bit different from what I used to tinker with in my earlier days in the sense that they are not a CPIO archive, but a kind of aggregate incorporating the microcode binaries (that are applied first-most) and a « classical » initrd
archive in CPIO format.
So, to introspect an initrd
you’ll have to use something like binwalk
to get the offset of the initrd
archive, extract it, then you’ll have a « classical » CPIO image.
In the case of this microcode update, the initrd
filesystem image was not the culprit, but rather theses microcode firmware/files.
I managed to recover my system by booting from a bootable USB live OS, mounting and chrooting into the broken system, reverting the intel-microcode
to the previous version which in turn triggered a rebuild of the initrd
image incorporating this previous microcode.
From issues/tickets I learned that I also could have disabled the loading of the microcode by appending the dis_ucode_ldr
flag to the kernel from Grub.
Finally, here is the issue on GitHub: microcode-20200609 Release, at least 06-4e-03, hangs user’s system