> From: Jim Baxter [mailto:jim_baxter@mentor.com] > Sent: Monday, July 18, 2022 8:08 PM > > > > Best regards, > > *Jim Baxter* > > Siemens Digital Industries Software > Automotive Business Unit > DI SW STS ABU > UK > Tel.: +44 (161) 926-1656 > mailto:jim.baxter@siemens.com <mailto:jim.baxter@siemens.com> > sw.siemens.com <https://sw.siemens.com/> > > On 18/07/2022 17:49, Roberto Sassu wrote: > >> From: Jim Baxter [mailto:jim_baxter@mentor.com] > >> Sent: Monday, July 18, 2022 6:36 PM > >> > >> > >> Hello, > >> > >> I have been testing these patches and do not see the xattr information when > >> trying to retrieve it within the initramfs, do you have an example of how > >> you tested this originally? > > > > Hi Jim, all > > > > apologies, I didn't find yet the time to look at this. > > Hello Roberto, > > Thank you for your response, I can wait until you have looked at the patches, > I asked the question to make sure it was not something wrong in my > configuration. > > > > > Uhm, I guess this could be solved with: > > > > https://github.com/openeuler- > mirror/kernel/commit/18a502f7e3b1de7b9ba0c70896ce08ee13d052da > > > > and adding initramtmpfs to the kernel command line. You are > > probably using ramfs, which does not have xattr support. > > > > > Thank you, I have tested that patch but the problem remained. Here is my > command line, I wonder if there is something wrong. > > Kernel command line: rw rootfstype=initramtmpfs root=/dev/ram0 > initrd=0x500000000 rootwait It is just initramtmpfs, without rootfstype=. Roberto
On 19/07/2022 07:55, Roberto Sassu wrote: >> From: Jim Baxter [mailto:jim_baxter@mentor.com] >> Sent: Monday, July 18, 2022 8:08 PM >> >> >> >> Best regards, >> >> *Jim Baxter* >> >> Siemens Digital Industries Software >> Automotive Business Unit >> DI SW STS ABU >> UK >> Tel.: +44 (161) 926-1656 >> mailto:jim.baxter@siemens.com <mailto:jim.baxter@siemens.com> >> sw.siemens.com <https://sw.siemens.com/> >> >> On 18/07/2022 17:49, Roberto Sassu wrote: >>>> From: Jim Baxter [mailto:jim_baxter@mentor.com] >>>> Sent: Monday, July 18, 2022 6:36 PM >>>> >>>> >>>> Hello, >>>> >>>> I have been testing these patches and do not see the xattr information when >>>> trying to retrieve it within the initramfs, do you have an example of how >>>> you tested this originally? >>> >>> Hi Jim, all >>> >>> apologies, I didn't find yet the time to look at this. >> >> Hello Roberto, >> >> Thank you for your response, I can wait until you have looked at the patches, >> I asked the question to make sure it was not something wrong in my >> configuration. >> >>> >>> Uhm, I guess this could be solved with: >>> >>> https://github.com/openeuler- >> mirror/kernel/commit/18a502f7e3b1de7b9ba0c70896ce08ee13d052da >>> >>> and adding initramtmpfs to the kernel command line. You are >>> probably using ramfs, which does not have xattr support. >>> Can I clarify which filesystem type is supported with this patch series? Is it tmpfs or perhaps a ramdisk? >> >> >> Thank you, I have tested that patch but the problem remained. Here is my >> command line, I wonder if there is something wrong. >> >> Kernel command line: rw rootfstype=initramtmpfs root=/dev/ram0 >> initrd=0x500000000 rootwait > > It is just initramtmpfs, without rootfstype=. > > Roberto Best regards, Jim
On 7/29/22 05:37, Jim Baxter wrote:
>>>> Uhm, I guess this could be solved with:
>>>>
>>>> https://github.com/openeuler-
>>> mirror/kernel/commit/18a502f7e3b1de7b9ba0c70896ce08ee13d052da
>>>>
>>>> and adding initramtmpfs to the kernel command line. You are
>>>> probably using ramfs, which does not have xattr support.
>>>>
Oh, here's the actual tested version of the patch wiring up rootfstype=tmpfs to
force rootfs to be tmpfs even when you specify root=
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7058e14ad5f7..dedf27fe9044 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {
void __init init_rootfs(void)
{
- if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
- (!root_fs_names || strstr(root_fs_names, "tmpfs")))
+ if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? !saved_root_name[0] :
+ !!strstr(root_fs_names, "tmpfs")))
is_tmpfs = true;
}
Signed-in-triplicate-by: Rob Landley <rob@landley.net>
No idea why nobody else has fixed that bug in the past 9 years, seems obvious?
Anyway, here's the testing I did using mkroot (ala
https://landley.net/toybox/faq.html#mkroot):
$ (cd root/x86_64; KARGS='quiet root=potato HANDOFF="/bin/head -n 1
/proc/mounts"' ./run-qemu.sh) | tail -n 3
rootfs / rootfs rw 0 0
reboot: Restarting system
$ (cd root/x86_64; KARGS='quiet HANDOFF="/bin/head -n 1 /proc/mounts"'
./run-qemu.sh) | tail -n 3
rootfs / rootfs rw,size=121828k,nr_inodes=30457 0 0
reboot: Restarting system
$ (cd root/x86_64; KARGS='quiet rootfstype=tmpfs root=potato HANDOFF="/bin/head
-n 1 /proc/mounts"' ./run-qemu.sh) | tail -n 3
rootfs / rootfs rw,size=121828k,nr_inodes=30457 0 0
reboot: Restarting system
I.E. rootfstype=tmpfs neutralized the root= so it was still tmpfs despite the
kernel being explicitly told you weren't going to stay on initramfs (which is
still what root= means). With just root= it's still ramfs, with all the "my log
file got too big and the system livelocked" and "querying available space always
returns zero" that entails.
> Can I clarify which filesystem type is supported with this patch series?
> Is it tmpfs or perhaps a ramdisk?
I believe both tmpfs and ramfs support xattrs? (I know tmpfs does, and
fs/ramfs/file-mmu.c plugs simple_getattr() into ramfs_file_operations.setattr so
it looks like that would too? Haven't tried it.)
This isn't a modification to the filesystem code (ramfs/tmpfs), this is a
modification to the boot-time loader (initramfs) that extracts a cpio.gz file
into the filesystem.
Ramdisks have supported xattrs for years: they fake up a block device out of a
chunk of memory and them format it and mount some other filesystem on it,
meaning the driver for the other filesystem handles the xattr support.
But ramdisks don't use initramfs, they load an image of the preformatted
filesystem into the ramdisk block device. Completely separate mechanism, sharing
no code with initramfs, depending on the block layer, etc.
>>> Thank you, I have tested that patch but the problem remained. Here is my
>>> command line, I wonder if there is something wrong.
>>>
>>> Kernel command line: rw rootfstype=initramtmpfs root=/dev/ram0
>>> initrd=0x500000000 rootwait
>>
>> It is just initramtmpfs, without rootfstype=.
The above patch does not go on top of that patch, it's instead of.
Rob
On 7/19/22 01:55, Roberto Sassu wrote: >> Thank you, I have tested that patch but the problem remained. Here is my >> command line, I wonder if there is something wrong. >> >> Kernel command line: rw rootfstype=initramtmpfs root=/dev/ram0 >> initrd=0x500000000 rootwait > > It is just initramtmpfs, without rootfstype=. Whoever wrote that patch really doesn't understand how this stuff works. I can tell from the name. Technically, initramfs is the loader, I.E. "init ramfs". The filesystem instance is called "rootfs" (hence the name in /proc/mounts when the insane special case the kernel added doesn't hide information from people, making all this harder to understand for no obvious reason). ramfs and tmpfs are two different filesystems that COULD be used to implement rootfs. (Last I checked they were the only ram backed filesystems in Linux.) If a system administrator says they're going to install your server's root partition using the "reiserxfs" filesystem, I would not be reassured. > Roberto Rob P.S. Note: there IS another boot option, you can have a pipe backed root filesystem! CONFIG_ROOT_NFS for NFS or CONFIG_CIFS_ROOT for Samba. No, I don't know why the order isn't consistent. P.P.S. If you want to run a command other than /init out of initramfs or initrd, use the rdinit=/run/this option. Note the root= overmount mechanism is completely different code and uses the init=/run/this argument instead, which means nothing to initramfs. Again, specifying root= says we are NOT staying in initramfs.
> From: Rob Landley [mailto:rob@landley.net] > Sent: Tuesday, July 19, 2022 1:51 PM > On 7/19/22 01:55, Roberto Sassu wrote: > >> Thank you, I have tested that patch but the problem remained. Here is my > >> command line, I wonder if there is something wrong. > >> > >> Kernel command line: rw rootfstype=initramtmpfs root=/dev/ram0 > >> initrd=0x500000000 rootwait > > > > It is just initramtmpfs, without rootfstype=. > > Whoever wrote that patch really doesn't understand how this stuff works. I can > tell from the name. Hi Rob surely, I should have been more careful in choosing the name of the option. > Technically, initramfs is the loader, I.E. "init ramfs". The filesystem instance > is called "rootfs" (hence the name in /proc/mounts when the insane special case > the kernel added doesn't hide information from people, making all this harder to > understand for no obvious reason). Ok, thanks for the explanation. > ramfs and tmpfs are two different filesystems that COULD be used to implement > rootfs. (Last I checked they were the only ram backed filesystems in Linux.) Yes, that part I got it. > If a system administrator says they're going to install your server's root > partition using the "reiserxfs" filesystem, I would not be reassured. Definitely. [...] > P.P.S. If you want to run a command other than /init out of initramfs or initrd, > use the rdinit=/run/this option. Note the root= overmount mechanism is > completely different code and uses the init=/run/this argument instead, which > means nothing to initramfs. Again, specifying root= says we are NOT staying in > initramfs. Sorry, it was some time ago. I have to go back and see why we needed a separate option. Maybe omitting root= was impacting on mounting the real root filesystem. Will get that information. Intuitively, given that root= is consumed for example by dracut, it seems a safer choice to have an option to explicitly choose the desired filesystem. Roberto
On 7/19/22 07:26, Roberto Sassu wrote:
>> P.P.S. If you want to run a command other than /init out of initramfs or initrd,
>> use the rdinit=/run/this option. Note the root= overmount mechanism is
>> completely different code and uses the init=/run/this argument instead, which
>> means nothing to initramfs. Again, specifying root= says we are NOT staying in
>> initramfs.
>
> Sorry, it was some time ago. I have to go back and see why we needed
> a separate option.
Did I mention that init/do_mounts.c already has:
__setup("rootfstype=", fs_names_setup);
static char * __initdata root_fs_names;
static int __init fs_names_setup(char *str)
{
root_fs_names = str;
return 1;
}
void __init init_rootfs(void)
{
if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
(!root_fs_names || strstr(root_fs_names, "tmpfs")))
is_tmpfs = true;
}
I thought I'd dealt with this back in commit 6e19eded3684? Hmmm, looks like it
might need something like:
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7058e14ad5f7..4b4e1ffa20e1 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {
void __init init_rootfs(void)
{
- if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
- (!root_fs_names || strstr(root_fs_names, "tmpfs")))
+ if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? !saved_root_name[0] :
+ strstr(root_fs_names, "tmpfs"))
is_tmpfs = true;
}
> Maybe omitting root= was impacting on mounting
> the real root filesystem. Will get that information.
I know some old bootloaders hardwire in the command line so people can't
_remove_ the root=.
The reason I didn't just make rootfs always be tmpfs when CONFIG_TMPFS is
enabled is:
A) It uses very slightly more resources, and the common case is overmounting an
empty rootfs. (And then hiding it from /proc/mounts so people don't ask too many
questions.)
B) Some embedded systems use more than 50% of the system's memory for initramfs
contents, which the tmpfs defaults won't allow (fills up at 50%), and I'm not
sure I ever hooked up I don't think I ever hooked up rootflags= ala
root_mount_data to the initramfs mount? (If so, setting size= through that
should work...)
> Intuitively, given that root= is consumed for example by dracut, it seems
> a safer choice to have an option to explicitly choose the desired filesystem.
Sounds like a dracut issue. Have you used dracut in a system running from initramfs?
Lots of systems running from initramfs already DON'T have a root=, so you're
saying dracut being broken when there is no root= is something to work around
rather than fix in dracut, even though it's been easy to create a system without
a root= for a decade and a half already...
> Roberto
Rob
> From: Rob Landley [mailto:rob@landley.net]
> Sent: Tuesday, July 19, 2022 4:15 PM
> On 7/19/22 07:26, Roberto Sassu wrote:
> >> P.P.S. If you want to run a command other than /init out of initramfs or initrd,
> >> use the rdinit=/run/this option. Note the root= overmount mechanism is
> >> completely different code and uses the init=/run/this argument instead,
> which
> >> means nothing to initramfs. Again, specifying root= says we are NOT staying
> in
> >> initramfs.
> >
> > Sorry, it was some time ago. I have to go back and see why we needed
> > a separate option.
>
> Did I mention that init/do_mounts.c already has:
>
> __setup("rootfstype=", fs_names_setup);
It is consumed by dracut too, for the real root filesystem.
[...]
> Lots of systems running from initramfs already DON'T have a root=, so you're
> saying dracut being broken when there is no root= is something to work around
> rather than fix in dracut, even though it's been easy to create a system without
> a root= for a decade and a half already...
If there is a possibility that root= or rootfstype= are used by
someone else, I would not count on those to make a selection
of the filesystem for rootfs.
On the other hand, what can go wrong in having a dedicated,
not used by anyone option to do this job?
Thanks
Roberto
© 2016 - 2026 Red Hat, Inc.