Improvements on boot speed and rootfs size

[arnaldo2792]

Issue number:
N / A

Description of changes:
In #1689, we reverted the ZSTD compression for kernel modules due to problems with rpm and kube-proxy. The problem with rpm is gone, and the build doesn't hang anymore. As part of this pull request, the ipvs kernel modules are loaded early on the boot sequence to prevent kube-proxy from loading them.

kernel-5.15: enable ZSTD compression for kernel modules

kernel-5.10: enable ZSTD compression for kernel modules

kernel-5.4: enable ZSTD compression for kernel modules

kubelet: load ipvs modules for kube-proxy

The `insmod` binary that kube-proxy uses does not support compressed
modules, and hands the compressed file to the kernel to load. This
leads to warnings that unsigned modules are not allowed, if lockdown
is enabled, or errors about malformed modules otherwise.

kube-proxy does check whether the module is loaded, so we can avoid
these errors by loading the necessary modules before kubelet starts.

systemd: keep modprobe units running

This avoids repeated log entries and unnecessary modprobe invocations
when the default target changes.

Testing done:

• I built a variant for each kernel 10 times in a row, and the built didn't hang
• I confirmed that ipvs kernel modules won't be loaded when they are blocked by the new settings.kernel.modules API
• I confirmed that only a warning is shown by kube-proxy for the ipvs kernel modules, since it will try to load them without failing:

Failed to load kernel module ip_vs_wrr with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[bcressey]

Nice to see this finally land!

🐎

[foersleo]

Is there a reason why we keep the overall number of patches in the downstream patch series for systemd? I have seen this now on multiple PRs that we have to touch all of them to have that number reflect correctly ([90xx/9011]), without any other changes to the patch itself.

Can we take that second number away next time we touch this or is this necessary for some other reason?

[markusboehme]

Since d4bbe942098b ("kbuild: remove CONFIG_MODULE_COMPRESS") got merged in v5.13 CONFIG_MODULE_COMPRESS doesn't exist anymore. It'd be good to drop it for the kernel-5.15 config to avoid introducing a warning by merge_config.sh. We could also unset the CONFIG_MODULE_COMPRESS_NONE=y we pick up from Amazon Linux here.

[bcressey]

Can we take that second number away next time we touch this or is this necessary for some other reason?

I don't know that it's necessary, but I like the property that the patches are regenerated as a series so that they don't accumulate offsets and require fuzzy matching, which in my experience is something that tends to happen when they're maintained as independent changes.

[foersleo]

Can we take that second number away next time we touch this or is this necessary for some other reason?

I don't know that it's necessary, but I like the property that the patches are regenerated as a series so that they don't accumulate offsets and require fuzzy matching, which in my experience is something that tends to happen when they're maintained as independent changes.

But that would be much more of a process thing in two cases if I am not mistaken:

1. When we update the systemd base version we want to ensure that the patches apply cleanly and do not pick up extra offset -> regenerate them
2. When we add a new patch between two existing patches we want to ensure that following patches apply cleanly and do not pick up extra offset -> regenerate the patches following the newly introduced one

For the case where we just append an extra patch (like here) we are touching all the other downstream patches to adjust their subject line, which does not have impact on anything but the commit hash (which we do not adjust here), if I am not mistaken. The order of the patches is still governed by what the spec file defines and a later patch should not have an impact on previous patches applicability.

I am fine with how this is right now, my curiosity was just sparked when reviewing and I thought we might be able to cut some extra work.

[zmrow]

⚙️

[bcressey]

For the case where we just append an extra patch (like here) we are touching all the other downstream patches to adjust their subject line, which does not have impact on anything but the commit hash (which we do not adjust here), if I am not mistaken. The order of the patches is still governed by what the spec file defines and a later patch should not have an impact on previous patches applicability.

I am fine with how this is right now, my curiosity was just sparked when reviewing and I thought we might be able to cut some extra work.

My personal workflow is something like:

cd packages/systemd
tar xf systemd-stable-250.4.tar.gz
cd systemd-stable-250.4
git init .
git add .
git commit -m 'initial state'
git am ../*.patch
<make edits, add new patch>
git format-patch HEAD~11 --start-number=9001

I use different work trees pretty often and don't keep checkouts of the upstream projects around, so this is convenient. I haven't thought too much about the work on the reviewer side, so I'm open to the idea of changing something.

If it's just a matter of using this as the last command in the above sequence, I'm cool with that:

git format-patch HEAD~11 --start-number=9001 --no-numbered