Skip to content
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

Discussion about the files in the /boot and initrd #1731

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

ader1990
Copy link
Contributor

@ader1990 ader1990 commented Mar 6, 2024

This PR was opened to have a place where to discuss line by line on the files that we can or cannot remove from the /boot partition and initrd. Or maybe move them into the /usr.

This is a follow up on @pothos suggestion to cut things we do not need: flatcar/Flatcar#1381 (comment)

How the data was compiled:

# Content of the /boot partition for AMD64 built from
# flatcar/scripts commit a842366ed9a2c2b1204a87f8563ef09e2950e5e3
tree -sifF  /boot | sort -k2 -rn
# Main data
$: df | grep '/boot'
/dev/vda1          129039      64135      64905  50% /boot

$: file flatcar_production_image.vmlinuz
flatcar_production_image.vmlinuz: Linux kernel x86 boot executable bzImage, version 6.6.17-flatcar (build@pony-truck.infra.kinvolk.io) #1 SMP PREEMPT_DYNAMIC Mon Mar  4 18:50:2A

$: du flatcar_production_image.vmlinuz
56124   flatcar_production_image.vmlinuz

Added another commit with the initrd contents.

How the data was compiled:

bash extract-initramfs-from-vmlinuz.sh flatcar_production_image.vmlinuz vmlinuz
cd vmlinuz/
tree -sifF . | sort -k2 -rn

@pothos
Copy link
Member

pothos commented Mar 6, 2024

Copy link

github-actions bot commented Mar 6, 2024

Comment on lines +4 to +6
[ 783864] ./flatcar/grub/x86_64-efi/core.efi.signed*
[ 783864] ./EFI/boot/grubx64.efi*
[ 782336] ./flatcar/grub/x86_64-efi/core.efi*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are all the same file and i want to say that we only need EFI/boot/grubx64.efi, but this needs testing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless we would also remove them in the update postinst hook these would still occupy space to prevent an update - but even then for some old clients the postinst hook might be too late because the kernel can't even be extracted to /boot.

[ 2058480] ./rootfs-1/usr/lib/systemd/libsystemd-core-252.so*
[ 1933576] ./rootfs-1/usr/lib64/libc.so.6*
[ 1845305] ./rootfs-1/usr/lib/firmware/phanfw.bin
[ 1649076] ./rootfs-1/usr/lib/firmware/mellanox/mlxsw_spectrum-13.2010.1006.mfa2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory we could the network firmware and kernel modules from /sysusr/usr but it needs some wrangling to have them available at the right time…

Comment on lines +7 to +8
[ 470624] ./xen/pvboot-x86_64.elf*
[ 470624] ./flatcar/grub/x86_64-xen/core.elf*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same file, and i'm not convinced pvboot elf works. Hasn't been tested in years/ever.

@@ -0,0 +1,1397 @@
[ 12539904] ./rootfs-0/kernel/x86/microcode/GenuineIntel.bin
Copy link
Member

@pothos pothos Mar 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The microcode updates can be delayed by defining a service that does echo 1 > /sys/devices/system/cpu/microcode/reload (see https://www.kernel.org/doc/Documentation/x86/microcode.txt) once we would symlink/copy them to /lib/firmware/{intel-ucode,amd-ucode} in the initrd from /sysusr.

[ 1167440] ./rootfs-1/usr/sbin/nvme*
[ 1145040] ./rootfs-1/usr/lib64/libgcrypt.so.20.4.3*
[ 1127648] ./rootfs-1/usr/lib/firmware/mellanox/mlxsw_spectrum3-30.2010.1006.mfa2
[ 1038064] ./rootfs-1/usr/sbin/btrfs*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That binary could be symlinked to /sysusr/, same for xfs* and mkfs.* stuff and even ip and mdadm

[ 267160] ./rootfs-1/usr/lib64/libtinfo.so.6.4*
[ 266400] ./rootfs-1/usr/lib64/libsmartcols.so.1.1.0*
[ 265300] ./rootfs-1/usr/lib/firmware/ql2400_fw.bin
[ 254499] ./rootfs-1/usr/share/ca-certificates/ca-certificates.crt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small win, but that file could be symlinked.

@pothos
Copy link
Member

pothos commented Mar 6, 2024

My impression is that we should start with the big stuff: find a way to load network firmware and kernel modules, and CPU microcode update from /sysusr/usr/.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you also check how well individual files compress? this might make a big difference

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this means if the files we d like to move/remove have a great compression rate, it does not make too much sense to remove them?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the initrd is compressed with some algorithm (zstd i think), and so we would want to focus on files that are big when compressed so that removing them actually has the desired impact. Otherwise we might remove a file that looks big but doesn't give much benefit because it compresses to something really small.

initrd.txt Show resolved Hide resolved
[ 814776] ./rootfs-1/usr/lib64/libsepol.so.2*
[ 812616] ./rootfs-1/usr/sbin/xfs_db*
[ 785272] ./rootfs-1/usr/lib64/libzstd.so.1.5.5*
[ 745872] ./rootfs-1/usr/sbin/xfs_repair*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i dont think we have anything that would call xfs_repair from the initrd

…rrent/flatcar_production_image_kernel_config.txt
@ader1990
Copy link
Contributor Author

ader1990 commented Mar 6, 2024

Thanks, we can also discuss the kernel config: https://alpha.release.flatcar-linux.net/amd64-usr/current/flatcar_production_image_kernel_config.txt

Added this file for discussion.

@ader1990
Copy link
Contributor Author

ader1990 commented Mar 25, 2024

I will keep in this updated comment a log of the AMD64 /boot partition size history, to have a clear picture on the size increase over time:

# 2024-03-12, Flatcar HEAD https://github.com/flatcar/scripts/commit/89cca15171f0b2424a4c132bb0c2138159b7eb6e
/dev/sda1         129039       59962      69078  47% /boot
# 2024-03-18, Flatcar ALPHA 3913.0.0 https://alpha.release.flatcar-linux.net/amd64-usr/3913.0.0/
/dev/sda1         129039       61753     67287  48% /boot
# 2024-03-25, Flatcar HEAD https://github.com/flatcar/scripts/commit/6ebffa7a4fde3a1b2c8d362b065b35b4ce3a43e4
/dev/sda1         129039       62503     66536  49% /boot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants