-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce vmlinuz size #688
Comments
First small size reduction in flatcar-archive/coreos-overlay#1750 |
Current situation: |
This may be a blocker for Clevis integration for LUKS setup from Ignition with TPM unlocking |
When |
By moving Ignition and afterburn/coreos-metadata out and use it from the /usr partition I was able to reduce the /boot size from 58 MiB to 52 MiB for arm64 (from 55 MiB to 49 MiB for amd64). Am still testing the changes but this will likely "solve" the growth issue for the next years and once we hit the limit again we can search for more binaries or even kernel modules to move out to the /usr partition. |
PR in flatcar/bootengine#52 We can leave this open to use |
Now with the 6.1 update the amd64 kernel is quite large, even larger than the arm64 kernel. Some configs got changed unexpectedly, this could have caused it, too. |
|
Description
The boot partition has to fit both kernels on update. If both are > 60 MiB they won't fit. Therefore, we always have to ensure that the vmlinuz file is < 60 MiB. On arm64 we are closely approaching the limit (new Alpha has a ~57 MiB vmlinuz).
Impact
To avoid hitting the size limit we may have to block a security update.
And of course updates will break for users if we release with a too large vmlinuz file.
Environment and steps to reproduce
See end of the console output of the image-matrix job
Expected behavior
Have some MiBs wiggle room, on amd64 we have a ~54 MiB vmlinuz - while not perfect it's still double the margin
Additional information
Compression was adjusted last time, and we couldn't enable it more at that time. This time it's worth to check if we can throw binaries/kernel modules out of the initramfs (planned is torcx for example, but I don't think the impact on the initramfs will be that large?).
The text was updated successfully, but these errors were encountered: