Messages in this thread | | | Date | Tue, 2 Jan 2024 08:03:00 -0500 | Subject | Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is given | From | Stefan Berger <> |
| |
On 1/1/24 13:50, Rob Landley wrote: > 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?
The only change I needed was to have tmpfs used for the initramfs to enable xattrs. No other changes were needed in my case (OpenBMC/Yocto).
> > (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
Let's see where we can take this next now that we will have xattr support via tmpfs for the initramfs.
Stefan
> 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
| |