On 12/31/23 10:03, Stefan Berger wrote: >> Let me see if I understand your problem: it sounds like debian's initramfs-tools >> overloads the root= and rootfstype= arguments parsed by the kernel to have a >> second meaning (the kernel uses them for one thing, you want to use them for >> something else, and there's currently a semantic gap between the two.) > > My intention is to be able to pass rootfstype= to the kernel and have it > interpreted correctly in the presence of root=, which currently does not > work. User space tools that interpret the value of rootfstype= as if > this option belonged to user space is not helpful, though it should be > easy to teach the user space scripts to strip a leading 'tmpfs,' or > 'ramfs,' from the rootfstype value and let them interpret the rest. Does your initramfs plumbing need to pass a rootfstype equivalent on to the userspace mount at all? In what cases does it not autodetect the type correctly? (Even NFS and SMB mounts are generally detectable because of the leading \\ or blah: although I suppose there are other network filesystem types that wouldn't be. Or if you wanted to micromanage the fat variant you were using...) "rootfstype=" is the argument that tells the _kernel_ how to mount / and by the time init runs the kernel's already mounted what it's going to mount. The kernel only exposes one visible / mount to userspace, you don't return back into it and get another init launched running in a different root filesystem. >> You want to add a new capability requiring a new build dependency in the >> initramfs-tools package because it's doing new stuff, but there cannot be any >> OTHER changes made to initramfs-tools, so the kernel should change its existing >> semantics instead. > > I haven't even thought of what would need to be added to Debian's > initramfs-tools package since my primary goal was to enable tmpfs for > the initramfs on OpenBMC where we then read the xattr values from a file > and write them into the filesystem because cpio format doesn't carry > them. Me, I'd have a simple initramfs extract/decrypt a tarball with the filesystem that needs xattr values into a new tmpfs mount and switch_root to that. But I tend to statically link an initramfs into the kernel image when I want to be sure what it's running, and have never quite been clear on the benefit of _additionally_ verifying data that originates from within the kernel image. (If they can change that, they can change ring 0 code.) Still, adding xattr support to cpio comes up a lot. It seems like a couple days work tops, maybe the interested parties should do a video conference thingy, hammer out the details, and come up with a patch to add support? The userspace side sounds easy enough, I added xattr support to toybox tar in 2021 in a weekend, and have sent "would you like to keep up with toybox" patches at the busybox guys semi-regularly. I even poked coreutils about feature parity once (the Android guys asked me to), which they said they would like to add, but which but still isn't in years later: https://lists.gnu.org/archive/html/coreutils/2023-08/msg00009.html https://lists.gnu.org/archive/html/coreutils/2023-08/msg00100.html But eh, I'm used to that with 30 year old projects licensed under copyleft... > Also, I didn't expect that any user space tools would try to > handle a kernel command line option as if it was theirs. Debian predates the 1.0 kernel release, so has some historical design baggage. That's why it's I tend to check them for snags in this area. >> You can't NOT provide root=, and you can't provide initramfstype=tmpfs... > > I only know about rootfstype= ( > https://github.com/torvalds/linux/blob/master/init/do_mounts.c#L128 ). > If currently handling of rootfstype= in presence of root= is not > considered a bug and we should introduce initramfstype= instead, we > could do that. But doesn't this become a bit confusing if rootfstype= > can be passed when root= is absent but then initramfstype= must be used > when root= is present? I personally think having two would be confusing, and changing the existing API without adding new capabilities is pointless. > This is 'our' patch describing the issue: > https://github.com/torvalds/linux/blob/master/init/do_mounts.c#L128 > >> either, and those are the two existing ways to tell rootfs to be tmpfs instead >> of ramfs. You'd like to add a third way to specify the same thing. > > Do you have a link to initramfstype= handling in kernel code? No, it's never done that. There was a suggestion to do that earlier in this thread: https://lkml.iu.edu/hypermail/linux/kernel/2312.2/07060.html And I thought it was a bad idea. The submitter agreed it was a bad idea. (Over the holidays I've haven't been paying close attention and threads tend to bleed together, sorry. :) The answer to my "do I have this right" question was, apparently, "no". I mixed together what two different people wanted... Rob
