Shrink /boot by removing duplicate and unused grub binaries/modules #1955
Conversation
build_library/grub_install.sh
Outdated
| @@ -183,6 +183,12 @@ sudo grub-mkimage \ | |||
| --output "${ESP_DIR}/${GRUB_DIR}/${CORE_NAME}" \ | |||
| "${CORE_MODULES[@]}" | |||
|
|
|||
| if [[ "${FLAGS_target}" != i386-pc ]]; then | |||
There was a problem hiding this comment.
Since they become part of the core.img it should be possible to remove this, or? I think we can try this out and either BIOS will boot or not.
There was a problem hiding this comment.
I will also try this out and see if BIOS works or not.
There was a problem hiding this comment.
With @pothos suggestion to remove also the i386-pc parts:
used 61681
free 67358
versus before:
used 61782
free 67258
The image boots correctly as a Hyper-V gen 1 VM.
|
Build action triggered: https://github.com/flatcar/scripts/actions/runs/9614448176 |
|
This is the current difference on AMD64: The flatcar image was tested and booted correctly on both Gen1 and Gen2 Hyper-V (BIOS and UEFI). |
|
Hello @jepio, I have verified that the image boots on both Gen 1/Gen 2 for Hyper-V AMD64. |
|
Verified on ARM64 and the free space looks good too: |
We currently carry multiple copies of the same grub core.elf or core.efi on the boot partition. Save some space by removing duplicates that are never used at runtime. CPIO build needed to be adapted because it publishes grub efi files. Signed-off-by: Jeremi Piotrowski <[email protected]>
Since we build them into the grub executable, they are not needed on disk. The only case I am unsure of is legacy BIOS boot, so left those on disk. Signed-off-by: Jeremi Piotrowski <[email protected]> Signed-off-by: Adrian Vladu <[email protected]>
The image also boots on Hyper-V Generation 1 VM (BIOS) if the modules are removed. Signed-off-by: Adrian Vladu <[email protected]>
Signed-off-by: Adrian Vladu <[email protected]>
ader1990
changed the title
|
@ader1990 keep in mind that existing nodes will still have these files so this PR is just a cleanup, and doesn't let us ship a larger kernel. |
Definitely, this PR will help a little to not go beyond the 50% logical threshold in the near future with things like natural size increase of the Linux kernel / other portage stable minor versions. |
|
@jepio I get what you mean, so we need to be careful not to go beyond a certain threshold with the vmlinuz kernel file. I will post the numbers for both amd64 / arm64 on the main issue so that we remember the sizes. |
Shrink /boot
Remove grub modules from disk that are assembled into the grub executable.
Remove grub executables that are copies that are not used in the boot path.
This should have no user visible impact.
How to use
[ describe what reviewers need to do in order to validate this PR ]
Testing done
[Describe the testing you have done before submitting this PR. Please include both the commands you issued as well as the output you got.]
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.