Upgrade Dracut to 106, use its sysroot feature, fix CPU microcode #2837
Conversation
...c/third_party/coreos-overlay/coreos/user-patches/sys-kernel/dracut/001-dracut-post-106.patch
Show resolved
Hide resolved
Apply our patch using user-patches instead. Signed-off-by: James Le Cuirot <[email protected]>
Flatcar can't benefit from this performance boost for several reasons, the main one being the use of binary packages. Signed-off-by: James Le Cuirot <[email protected]>
This is code I have submitted upstream that has not yet been merged. This also includes a small "catch up" patch from 106 to current main for both a clean base and because these changes actually look important. Signed-off-by: James Le Cuirot <[email protected]>
Dracut includes native binaries that are executed during the creation of the initrd, so it always needs to be installed to /. For now, it expects to find its modules in the sysroot, so it needs to be installed there too, though that may change. bootengine only needs to be installed to sysroot for its Dracut modules. The update-bootengine tool is a Bash script, so it doesn't really need to be installed to /. Signed-off-by: James Le Cuirot <[email protected]>
systemd-journal's Forward Secure Sealing feature requires gcrypt, but Flatcar doesn't need it. Signed-off-by: James Le Cuirot <[email protected]>
The microcode was accidentally dropped from Flatcar a while back because Gentoo started telling Dracut to not include it when USE=-initramfs. Flatcar disabled that flag because the microcode is installed to /boot. This is only done under the board root though, not in the final image, so there's no harm in enabling it. That Dracut setting also affected the AMD microcode, which is part of coreos-firmware, so this fixes that too. Signed-off-by: James Le Cuirot <[email protected]>
This is only needed for direct loading by the kernel, which is dangerous, and we include all the microcode in the initrd anyway. Signed-off-by: James Le Cuirot <[email protected]>
|
Hello @chewi, if you can please update the documentation as well regarding the bootengine, as now the documentation steps are not working anymore: https://www.flatcar.org/docs/latest/reference/developer-guides/sdk-modifying-flatcar/#build-the-os-image-packages |
|
Build action triggered: https://github.com/flatcar/scripts/actions/runs/18367579617 |
|
The step to delete bootengine.cpio simply isn't needed any more. See flatcar/flatcar-website#420. |
dongsupark
moved this to Implemented
in Flatcar tactical, release planning, and roadmap
|
|
||
| # Only needed for direct loading by the kernel, which is dangerous, and we | ||
| # include all the microcode in the initrd anyway. | ||
| sys-firmware/intel-microcode -split-ucode |
There was a problem hiding this comment.
Seems this is the reason we still have AMD ucode in the kernel but not Intel anymore.
Why is direct loading dangerous? I didn't see any difference documented compared to the inclusion in the initrd.
There was a problem hiding this comment.
I meant "late loading" after booting. See the kernel docs for why it is dangerous. intel-uc.img contains all the microcode we should need.
|
Seems that the embedded cpio build logic in the kernel doesn't handle the early cpio so that the microcode gets applied. I've filed this issue for it: flatcar/Flatcar#1909 and noticed that the |
Upgrade Dracut, use its sysroot feature, fix CPU microcode
This must be reviewed in tandem with flatcar/bootengine#105.
Flatcar has lagged behind on Dracut 053 for quite a while. The latest version is currently 106, although it did jump from 060 to 100 when it changed hands.
As well as upgrading, this moves the sys-kernel/dracut package from coreos-overlay to portage-stable. Patches are now applied as user patches.
The patches included here are large because we are relying on my new Dracut improvements, which allow it to parse the ELF
.note.dlopendependency metadata used by JSON and reliably determine dependencies across foreign architectures. These are not yet merged but upstream seem willing. They will not be merged for version 107, but the hope is to get them in for 108.We now run Dracut with its
--sysrootargument, removing the need to chroot and jump through hoops to avoid the Portage sandbox in the coreos-kernel ebuild. The sandbox still needs a little taming due to ldconfig calling chroot internally, but this is a lot saner than it was before.For now, Dracut still needs to be installed in both the SDK and the board root. dracut-install is a native binary, but the modules are expected to be found within the sysroot. This may change later. bootengine has no native binaries, so it only needs to be installed in the board root.
The CPU microcode was accidentally dropped from Flatcar a while back (don't know when) because Gentoo started telling Dracut to not include it when
USE=-initramfs. Flatcar disabled that flag because the microcode is installed to /boot. This is only done under the board root though, not in the final image, so there's no harm in enabling it. That Dracut setting also affected the AMD microcode, which is part of coreos-firmware, so this fixes that too.How to use
You will need the latest SDK due to changes in my earlier PR. You should be able to update dracut in the SDK, plus dracut and bootengine in the board root, before building coreos-kernel.
Testing done
I have done a lot of manual testing and CI testing, as well as a close inspection of the initrd changes. Everything is looking good.
The size of the initrd was a concern. Upgrading Dracut initially increased the size massively, but I took measures here and in bootengine to trim it back down. Changing the compression from zstd to xz in my other PR was needed to bring the size back to around what it was previously though.
Dropping a Flatcar-specific patch to drop most of the keymaps was one reason for the size increase, but I deliberately chose to keep them as only supporting US English is unfair to bare metal users.
Adding the CPU microcode should have increased the size yet further. The raw intel-mc.img file is 9MB. Compressing it manually with xz only brings it down to 8MB. However, it made a minimal difference to the final vmlinuz, and I haven't been able to figure out why. The microcode definitely wasn't there before, and it definitely is there now. I have extracted the vmlinuz to make sure. The amd64 nightly report says the raw initrd is 19MB larger, and yet the final vmlinuz is 132KB smaller. Perhaps it compresses very well alongside the rest? 🤷♂️
changelog/directory (user-facing change, bug fix, security fix, update)/bootand/usrsize, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.