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.
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.)
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
initrd image is rebuilt to incorporate the new microcode files.
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