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