-
Notifications
You must be signed in to change notification settings - Fork 25
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
Comments
FWIW with BLS and snapshot support, dracut alone cannot produce a useful initrd. It needs external tooling like Because of that I've asked for an option to actually turn off guessing of the output filename dracutdevs/dracut#2448 |
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 |
In Arguably calling them |
Yeah, this is the case. Actually Fedora used to call it |
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
I think we should do the same here, and use "initrd". |
NIH successfully failed :)
|
|
My personal opinion would be to use |
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 |
|
It's not an img. Ramdisk was an image. Now it's an archive. 😛😛 |
(Sidebar: maybe it should be an image, squashfs or similar...) |
That might actually not be the worst name. I don't care which one wins, as long as we agree on one thing. |
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 ;-).) |
(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) |
Going the initcpio direction, it could be named init.cpio (despite normally being multiple concatenated cpio archives followed by an compressed cpio). |
Thinking slightly more broadly... |
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. |
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. |
My impression is that this discussion have a slight preference to name it |
On the ostree side, we expect the initrd to live in I don't have a really strong opinion here though, if there's some consensus for 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. |
For the transitional period, the tools look for |
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: 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. |
Yeah, I could try to write one. |
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 useinitrd.img-$KVER
, openSUSE patches this toinitrd-$KVER
, and Mageia patches it toinitrd-$KVER.img
.The text was updated successfully, but these errors were encountered: