Standardizing file name structure for kernel images

[Conan-Kudo]

In the Dracut-NG project, we got a pull request about making the initramfs file name configurable (dracut-ng/dracut-ng#146), which I pushed back on because as a developer of image build tools, I've experienced a lot of issues dealing with trying to detect and handle initramfs images correctly because not knowing what the expected filename formula is leads to inadvertently broken system images.

It was suggested that I ask the UAPI group to consider standardizing the naming formula for kernel image files (vmlinu(x|z), initramfs, etc.) so that this could be made easier for everyone.

For reference, Dracut uses initramfs-$KVER.img, while Debian patches this to use initrd.img-$KVER, openSUSE patches this to initrd-$KVER, and Mageia patches it to initrd-$KVER.img.

[lnussel]

FWIW with BLS and snapshot support, dracut alone cannot produce a useful initrd. It needs external tooling like kernel-install to tell dracut where to put the initrd and how to name it in order to make sure there's an actual boot loader entry that uses the initrd. The way it's currently done in openSUSE is initrd-$checksum, see https://github.com/openSUSE/sdbootutil/blob/main/ARCHITECTURE.md

Because of that I've asked for an option to actually turn off guessing of the output filename dracutdevs/dracut#2448

[behrmann]

Having an agreed-upon naming scheme for the kernel image and the initrd seems sensible to me, since this would make life easier for all consumers of them, including kernel-install. We already document a naming scheme for distribution-built UKIs in the UKI spec. The possible problem is that for UKIs we were on a green field and these names will have a lot of inertia in their respective distributions.

[Foxboron]

For reference, Dracut uses initramfs-$KVER.img, while Debian patches this to use initrd.img-$KVER, openSUSE patches this to initrd-$KVER, and Mageia patches it to initrd-$KVER.img.

In mkinitcpio we use initramfs-$presetname.img.

Arguably calling them initrd is wrong as this is the old format, and they are doing this because it's how it was before initramfs became a thing?

[Conan-Kudo]

Yeah, this is the case. Actually Fedora used to call it initrd in the pre-Dracut days too, they gave up their old naming convention as part of switching to Dracut.

[keszybz]

Arguably calling them initrd is wrong as this is the old format, and they are doing this because it's how it was before initramfs became a thing?

In systemd, we tried to be "correct" and say "initramfs" in various places, but in the end we ripped all that out and say "initrd" everywhere. There is just one note that says

Nowadays this is implemented as an "initramfs" — a compressed CPIO archive that the kernel extracts into a tmpfs. In the past normal file systems using an in-memory block device (ramdisk) were used, and the name "initrd" is still used to describe both concepts.

I think we should do the same here, and use "initrd".

[keszybz]

Dracut uses initramfs-$KVER.img, while Debian patches this to use initrd.img-$KVER, openSUSE patches this to initrd-$KVER, and Mageia patches it to initrd-$KVER.img.

NIH successfully failed :)

---

initrd-$KVER.img seems the most sensible. I think we should say that "initrd-$KVER.img should be used" and call it a day.

[Foxboron]

initrd-$KVER.img seems the most sensible. I think we should say that "initrd-$KVER.img should be used" and call it a day.

mkinitcpio will be sticking with initramfs :)

[Conan-Kudo]

My personal opinion would be to use initramfs and I'd prefer to keep that for Dracut...

[poettering]

initramfs is not really "correct" btw. It has been a long time since the ramfs that the initrd was unpacked into stopped being a ramfs, and became a tmpfs. So in a way you'd have to call the thing inittmpfs now, if you wanted to be fully correct...

I'd just stick to the moniker "initrd", even if it's a bit wrong. Of the two wrong names "initrd" and "initramfs" I sense the former is more widely adopted than the latter, even though the latter is kinda widely used too.

[mrc0mmand]

initramfs is not really "correct" btw. It has been a long time since the ramfs that the initrd was unpacked into stopped being a ramfs, and became a tmpfs. So in a way you'd have to call the thing inittmpfs now, if you wanted to be fully correct...

I'd just stick to the moniker "initrd", even if it's a bit wrong. Of the two wrong names "initrd" and "initramfs" I sense the former is more widely adopted than the latter, even though the latter is kinda widely used too.

Let's just do initmayberamfs. Everybody else keep introducing new names for it, so why not us as well ;) ^(/s)

[Conan-Kudo]

initimg then 😛

[keszybz]

It's not an img. Ramdisk was an image. Now it's an archive. 😛😛

[Conan-Kudo]

(Sidebar: maybe it should be an image, squashfs or similar...)

[behrmann]

initimg then 😛

That might actually not be the worst name.

I don't care which one wins, as long as we agree on one thing.

[poettering]

i think "initcpio" would actually be the best name. describes what it actually is, and decouples it from the choice of fs it is ultimately unpacked into. I mean, we don't call tarballs "btrfsballs" just because we tend to unpack them into btrfs file systems these days.

("btrfsballs" has a really nice alliterating feel to it though ;-).)

[poettering]

(but sure, i am actually of the opinion too that it should be an erofs one day again backed by memory. Which interestingly puts us back at square 1, i.e "initrd" is kinda an appropriate name after all then)

[bdrung]

Going the initcpio direction, it could be named init.cpio (despite normally being multiple concatenated cpio archives followed by an compressed cpio).

[Conan-Kudo]

Thinking slightly more broadly... initroot-$KERNEL_VERSION.(cpio|img) depending on whether it's CPIO or EROFS/SquashFS...

[LaszloGombos]

This file is an input to the Linux kernel and the Linux kernel documentation calls it initrd. One could argue that if we really want to suggest a better name than initrd than we should engage the Linux Kernel as well.

[berrange]

While it may have originally reflected a specific impl, I think that these days people broadly treat/interpret "initrd" to be an generic umbrella term that applies to any subsequent conceptually equivalent impl, whether initramfs or even something non-cpio based. IOW, I'd suggest 'initrd' is fine as a term to use regardless of what today's most commonly used impl is.

[bdrung]

My impression is that this discussion have a slight preference to name it initrd for the file. Taking the comments into account, I suggest to not add a suffix (to cover all cases like cpio, erofs, squashfs). So use initrd and initrd-$KVER.

[cgwalters]

On the ostree side, we expect the initrd to live in /usr/lib/modules/$kver/initramfs.img in the OS image. This location is distinct from what happens when an image is deployed where the kernel/initrd may be installed in /boot.

I don't have a really strong opinion here though, if there's some consensus for initrd we can also support that too.

I suspect the reality is e.g. documentation or tools that wants to be cross-OS/cross-distribution for use cases like inspect the initramfs on a given system is just going to need to deal with both names.

[bdrung]

For the transitional period, the tools look for initrd first (or what we end up deciding in the end) and then fallback to their previous name. So look for /boot/initrd, /boot/initrd-$KVER, /usr/lib/modules/$kver/initrd first.

[poettering]

so, under the assumption that people prefer "initrd" as name for this, @Conan-Kudo any chance you can write a brief spec for this?

maybe make it slightly more broader though, and also document where non-UKI kernel images should be placed.

Or in other words, we have this in the UKI spec:

https://github.com/uapi-group/specifications/blob/main/specs/unified_kernel_image.md#distribution-built-ukis-installed-by-package-managers

So, it might make sense to have a spec that mirrors this for non-UKI kernel + initrd case, that says where to put the kernel image itself, and where the initrd (both below /usr/lib/modules/$kver/ of course).

Spec'ing this out would actually really useful, so that systemd's "kernel-install" tool's add-all logic actually operates on path that we can rightfully claim are spec'ed somewhere.

[Conan-Kudo]

Yeah, I could try to write one.