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
