Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is given

[Stefan Berger <stefanb@linux.ibm.com>]

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