Is initramfs compression supposed to work?

Hi. I’ve tried pushing down on initramfs sizes in one of the last gifts of time I’m gonna bestow upon my Tumbleweed install before I switch to OpenMandriva (if all goes well).

So, I’ve modified /etc/dracut.conf.d/_.conf (very creative name, I know), also deleting all the other conf files (after checking what they’re doing). This is what it has now:

persistent_policy="by-partuuid"
hostonly="yes"
hostonly_mode="strict"
aggressive_strip="yes"
filesystems="btrfs"
compress="zstd"
omit_dracutmodules=" suse-xfs pcr-signature "

Well, well, well. Turns out it’s still not compressing the file; size is about the same and file gives it as CPIO archive. (Zstd has been installed, so it’s not that.)

Dracut has been invoked via sdbootutil. (sdbootutil -v --no-reuse-initrd add-all-kernels)

I’ve taken note of the Dracut cmdline that lsinitrd tells me has been used to create the initramfs, it had --reproducible in it. I’ve tracked that down to sdbootutil, and from lack of a better option, I’ve directly altered the script and commented that parameter out (it’s somewhat in the middle of the file).

lsinitrd on the new initramfs confirms that --reproducible hasn’t been added that time around, but it wasn’t the culprit (not sure whether it could have been).

Now I wonder, is initramfs compression even supposed to work on openSUSE? I thought it to be a rather basic feature, and I’ve used it well on Void Linux.

By the way, the new forum is weird (but I’m not sure I’ll care anymore) and for whatever reason, I’ve found the i10n dracut module to be hardcoded to include the eurlatgr font, which, however, I’ve confirmed, is upstream weirdness: dracut/modules.d/10i18n/module-setup.sh at 5d2bda46f4e75e85445ee4d3bd3f68bf966287b9 · dracutdevs/dracut · GitHub .

Initrd start with early cpio which is not compressed.

Oh, thanks for the pointer, I’ve totally missed out on that. On Void, I’ve set up early microcode loading on my own, which was a couple of years ago, so I completely forgot about that part.

I have to say, I’m vindicated to have failed, though, since on searching how to unpack this file, many of the apparent sources have claimed to uncompress first, as I tried to do. Has early microcode loading only recently become popular?
(All of these are incomplete:

So, I’ve found another explanation, which says to use dd. I don’t know why he does it in such a complicated way (Seems like he’s searching for the magic bytes?), yet with a simpler invocation that just jumps over the first 672 blocks (as cpio gave it for me) got file to confirm that it’s compressed by Zstd.
> dd if=/boot/efi/opensuse-tumbleweed/6.12.10-1-default/initrd-55b0ffe8178a0a29a1294a25c81ab12d4ddbeeec bs=512 skip=672|file - /dev/stdin: Zstandard compressed data (v0.8+), Dictionary ID: None

With that, I’ve tried specifying “cat” for the compressor (which, in hindsight, I should have done first, though it seems I’ve stumbled past that) and indeed, I’ve got a much bigger file, a whopping 44MiB.

So, I stand at 19MiB Zstd-compressed now, which isn’t great. I don’t have current numbers, but on Void, I think I got it down to 8MiB or so? (Without Systemd, of course.)—Hrm.

I think I could skip it completely, as I don’t want anything fancy at all from it, only mounting my Btrfs rootfs and stuff, which the kernel should be able to do on its own.

Judging by lsinitrd -s, most of the remaining bulk is some useless crypto stuff that I remember (from Void) being hard to get rid of, Systemd, a couple useless tools (cdrom_id on a system without optical drives) and some troubleshooting tools (well, presumably that’s what they’re there for) (like, the btrfs executable or udevadm) (To be clear, I’m aware that’s likely upstream’s doing.), and … yeah (forgot what I’ve wanted to add, I’m making dinner right now).

Guess I’m gonna suck it up for now.

andrei@tumbleweed:~> rpm -ql dracut | grep skipcpio
/usr/lib/dracut/skipcpio
andrei@tumbleweed:~>

Indeed, albeit not indexed by cnf.

I’ve pondered refraining from refreshing this topic once again, but I have three further bits of information that came from this, which I purport might be useful for others :

  1. The tuned Void initramfs is actually in the five to six megabytes range (the decimals escape me), with Booster and (I think) Busybox-based; it’s for an F2FS root. Void’s kernel is smaller by roughly two megabytes and doesn’t have either F2FS or BtrFS built-in, so those are not the reason for the difference.
  2. The biggest files that remain after the limited tuning I’ve been able to apply are: libcrypto, libsystemd, glibc, two others, the btrfs executable and only then the btrfs kernel module. (Which is big itself, at 1.2MiB precompressed (.ko.zst).)
  3. Since BtrFS support is built as a module, I actually do need an initramfs. I hadn’t expected to, but that’s what the configs say. Sure, 18MiB are not huge, yet I still would have liked to push it down. Much more useful would be finally tracking down the bug that sometimes makes initramfs generation after kernel updates skip deleting the previous, obsoleted files.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.