System | Switch from initramfs-tools to tiny-initramfs?

MichaIng commented 5 years ago

A lightweight alternative to the fully fledged initramfs implementation. Much smaller, boots faster, less features that are not required for default setups. Can be easily replaced if required.

Have it up on my testing VMs for a while now, no issues observed. Only issue is that is has a different update command: update-tirfs So we would need to check which command is available, before calling it.

It does not support PARTUUID for rootfs in cmdline, however we ship RPi without any initramfs implementation and all other SBCs allow UUIDs? But requires testing on each SBC anyway, at first should be only added to x86_64 devices without custom kernel+bootloader.

So if someone is in mood, for testing:

apt purge initramfs-tools
apt autoremove --purge
apt install tiny-initramfs

Just it. It's updated with kernel upgrades automatically, just as initramfs-tools does.
Note that in case of an SBC, it might make it unbootable, if kernel/bootloader requires some extended feature. So have a backup of the old initrd.img (either in root or /boot) available to restore, or at best an SDcard or /boot partition clone.

Vansinnet commented 5 years ago

@MichaIng Is it a problem that it was last updates 3 years ago?

MichaIng commented 5 years ago

Yeah recognised this. However it works well at least on my VMs and has boot time benefits.

Also Debian is still maintaining it regularly: https://deb.debian.org/debian/pool/main/t/tiny-initramfs

We could also experiment with Dracut, with by default should be faster as well with its modular system and is actively developed within Linux itself.

Vansinnet commented 5 years ago

As long as the intent is to switch to something faster and still being able to function to DietPis needs I’m all for switching to it!

I’m just a bit concerned about switching to something which barely is supported itself anymore. Maybe it has not been updated because it doesn’t need to? In that case, I’d say do the switch! :)

MichaIng commented 5 years ago

tiny-initramfs

root@VM-Buster:~# l /boot/initrd.img-5.2.0-0.bpo.2-amd64
-rw------- 1 root root 816K Oct 10 20:08 /boot/initrd.img-5.2.0-0.bpo.2-amd64
root@VM-Buster:~# systemd-analyze
Startup finished in 2.238s (kernel) + 4.290s (userspace) = 6.528s
graphical.target reached after 4.263s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 2.249s (kernel) + 3.325s (userspace) = 5.574s
graphical.target reached after 3.299s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 2.255s (kernel) + 3.235s (userspace) = 5.490s
graphical.target reached after 3.209s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 2.236s (kernel) + 3.196s (userspace) = 5.433s
graphical.target reached after 3.170s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 2.241s (kernel) + 3.205s (userspace) = 5.446s
graphical.target reached after 3.180s in userspace

initramfs-tools (Debian default)

root@VM-Buster:~# l /boot/initrd.img-5.2.0-0.bpo.2-amd64
-rw-r--r-- 1 root root 27M Oct 10 17:02 /boot/initrd.img-5.2.0-0.bpo.2-amd64
root@VM-Buster:~# systemd-analyze
Startup finished in 4.237s (kernel) + 3.168s (userspace) = 7.405s
graphical.target reached after 3.143s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 3.680s (kernel) + 3.097s (userspace) = 6.777s
graphical.target reached after 3.072s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 3.644s (kernel) + 3.177s (userspace) = 6.822s
graphical.target reached after 3.151s in userspace

dracut

root@VM-Buster:~# l /boot/initrd.img-5.2.0-0.bpo.2-amd64
-rw-r--r-- 1 root root 13M Oct 10 18:41 /boot/initrd.img-5.2.0-0.bpo.2-amd64
root@VM-Buster:~# systemd-analyze
Startup finished in 2.371s (kernel) + 2.403s (initrd) + 5.024s (userspace) = 9.800s
graphical.target reached after 4.993s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 2.372s (kernel) + 2.016s (initrd) + 4.161s (userspace) = 8.550s
graphical.target reached after 4.132s in userspace
Startup finished in 2.222s (kernel) + 1.933s (initrd) + 3.309s (userspace) = 7.465s
graphical.target reached after 3.283s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 2.211s (kernel) + 1.901s (initrd) + 3.207s (userspace) = 7.320s
graphical.target reached after 3.183s in userspace
root@VM-Buster:~# systemd-analyze
Startup finished in 2.242s (kernel) + 1.913s (initrd) + 3.175s (userspace) = 7.331s
graphical.target reached after 3.150s in userspace

Interesting, compared to the other ones there is an additional (initrd) time and as well some additional systemd units:

Oct 10 19:57:59 VM-Buster dracut-cmdline[149]: dracut-10 (buster) dracut-048+80-1-1-3-gebb7dd39
Oct 10 19:57:59 VM-Buster dracut-cmdline[149]: Using kernel command line parameters: root=UUID=b254104d-395d-4e4d-b1bc-0474230d116a rootfstype=ext4 rootflags=rw,noatime BOOT_IMAGE=/boot/vmlinuz-5.2.0-0.bpo.2-amd64 root=UUID=b254104d-395d
-4e4d-b1bc-0474230d116a ro net.ifnames=0 consoleblank=0 logo.nologo quiet loglevel=0 vt.global_cursor_default=0
Oct 10 19:58:00 VM-Buster systemd[1]: Started dracut cmdline hook.
Oct 10 19:58:00 VM-Buster systemd[1]: Starting dracut pre-udev hook...
Oct 10 19:58:00 VM-Buster systemd[1]: Started dracut pre-udev hook.

Probably one can enhance it by changing some settings, however the I measure the default only here since custom settings/tinkering is out of scope for now.

Result

Not sure why the VM (VirtualBox) boots faster on subsequent reboots, probably some caching thing. To be sure I redid some tiny-initramfs install+reboots again after testing the other two, with same result:

tiny-initramfs not only IS very tiny (816K vs 27M vs 13M), but also boots fastest, quite significantly.
initramfs-tools by far is the largest initrd but boot time is in the middle. It seems that its own boot time is counted within the kernel time as systemd-analyze shows a significant increase there, compared to boot with tiny-initramfs.
dracut boots slowest but its size is in the middle. It adds some systemd units for boot and shutdown. Looks like it adds many features in a modular way. AND it is developed as part of the Linux project itself. However it it's just about a regular boot on x86_64 via grub, this seems to be a large overhead. Its additional boot time is shown separately by systemd-analyze, since the kernel time again matches the one of tiny-initramfs moreless.

So we have a quite clear winner here. At least for VMs we can ship tiny-initramfs safely as default.

MichaIng commented 4 years ago

Done:

Probably native PCs can follow, but requires more testing.

MichaIng / DietPi