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

Standardizing file name structure for kernel images #100

Open
Conan-Kudo opened this issue Apr 11, 2024 · 25 comments
Open

Standardizing file name structure for kernel images #100

Conan-Kudo opened this issue Apr 11, 2024 · 25 comments

Comments

@Conan-Kudo
Copy link

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
Copy link
Member

lnussel commented Apr 11, 2024

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

keszybz commented Apr 15, 2024

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
Copy link
Member

keszybz commented Apr 15, 2024

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
Copy link
Member

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
Copy link
Author

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

@poettering
Copy link
Collaborator

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
Copy link
Member

mrc0mmand commented Apr 15, 2024

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
Copy link
Author

initimg then 😛

@keszybz
Copy link
Member

keszybz commented Apr 15, 2024

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

@Conan-Kudo
Copy link
Author

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

@behrmann
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Collaborator

(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
Copy link

bdrung commented Apr 15, 2024

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

@Conan-Kudo
Copy link
Author

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

@LaszloGombos
Copy link

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
Copy link

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
Copy link

bdrung commented May 6, 2024

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
Copy link

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
Copy link

bdrung commented May 6, 2024

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
Copy link
Collaborator

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
Copy link
Author

Yeah, I could try to write one.

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

No branches or pull requests