> 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