> From: Jim Baxter [mailto:jim_baxter@mentor.com]
> Sent: Monday, July 18, 2022 6:36 PM
> On 15/06/2022 10:27, Eugeniu Rosca wrote:
> > Hello Roberto,
> >
> > On Fr, Jun 10, 2022 at 03:38:24 +0000, Roberto Sassu wrote:
> >> I would be happy to address the remaining concerns, or take more
> >> suggestions, and then develop a new version of the patch set.
> > I face a number of conflicts when I try to rebase the latest openEuler
> > commits against vanilla master (v5.19-rc2). Do you think it is possible
> > to submit the rebased version to ML?
> >
> > In addition, I can also see some open/unresolved points from Mimi [*].
> > Did you by chance find some mutual agreement offline or do you think
> > they would still potentially need some attention?
> >
> > Maybe we can resume the discussion once you submit the rebased series?
> >
> > Many thanks and looking forward to it.
> >
> > [*] Potentially comments which deserve a reply/clarification/resolution
> >
> > https://lore.kernel.org/lkml/1561985652.4049.24.camel@linux.ibm.com/#t
> > https://lore.kernel.org/lkml/1561908456.3985.23.camel@linux.ibm.com/
> >
> > BR, Eugeniu.
> >
> 
> 
> 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.

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.

> So far I have set the xattr in the rootfs before creating the cpio file like this:
> $ setfattr -n user.comment -v "this is a comment" test.txt
> If I access the data here it works:
> $ getfattr test.txt
> # file: test.txt
> user.comment
> 
> 
> Then I package it and try to verify it with this command:
> $getfattr /test.txt

I assume you try to pack/unpack, right? If I remember correctly
I only implemented the pack part. Unpacking is done by the kernel
(but you are right, it should be done by user space too).

> Which returns to the command line without the data.
> 
> 
> 
> I believe the cpio is working because I see the file /METADATA\!\!\! in
> the target root filesystem, which shows the following when viewed with cat -e:
> 00000028^A^Auser.comment^@this is a comment
> 
> This matches the data I fed in at the start, so I believe the data is being
> transferred correctly but I am accessioning it with the wrong tools.

Yes, xattrs are marshalled in the METADATA!!! file, one per regular file
xattrs are applied to. Xattrs are applied to the previous regular file.
That file name was preferred to adding a suffix to the file, to avoid
reaching the filename size limit.

Roberto

On 7/18/22 11:49, Roberto Sassu 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.

It's initmpfs. You can argue about whether it should have two t's (I was
consistent naming it in the patch series adding it), but ramfs and tmpfs are two
different things and saying "initramtmpfs" is like saying "mount -t ext4btrfs".

> You are probably using ramfs, which does not have xattr support.

Do not specify root= in your kernel command line. If you specify root= you're
saying "switch off of initramfs to a different root filesystem", so it doesn't
make the overmounted filesystem tmpfs because you told it you wouldn't be using it.

(The decision of what to mount has to be made before it examines the cpio.gz
contents, so root= is used to signal "we are not keeping this initramfs" because
that's literally what root= means. Your root filesystem is not initramfs, it is
instead this thing to be mounted over initramfs.)

You can tell which you're using via /proc/mounts having a line:

rootfs / rootfs rw,size=121832k,nr_inodes=30458 0 0

If it's got the size= then it's tmpfs: ramfs basically doesn't have bounds
checking and "cat /dev/null > filename" on ramfs will lock your system solid due
to unpinnable memory exhaustion.

If you don't have a "rootfs" line at ALL then root= was used to overmount and
part of the gratuitously magic behavior of root= is it hides the rootfs line
from /proc/mounts even though the filesystem is actually still there, which is
not something it does for ANY OTHER OVERMOUNT:

  $ mkdir sub
  $ mount -t proc proc sub
  $ mount -t ramfs sub sub
  $ grep sub /proc/mounts
  proc /sub proc rw,relatime 0 0
  sub /sub ramfs rw,relatime 0 0

I've never understood why they added that gratuitous special case to hide how
the system actually works, but it's a land mine you have to be told about after
you've stepped on it in order to understand what's going on. Part of the reason
people think initramfs is so "magic" when PID 1 isn't, we don't HIDE the fact
that PID 1 is always there but we hide the fact initramfs is...

Rob

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 


I also found that root is always mounted as rootfs in my initramfs system
which I understood to be tmpfs, is that incorrect?

sh-3.2# mount
none on / type rootfs (rw)


>> So far I have set the xattr in the rootfs before creating the cpio file like this:
>> $ setfattr -n user.comment -v "this is a comment" test.txt
>> If I access the data here it works:
>> $ getfattr test.txt
>> # file: test.txt
>> user.comment
>>
>>
>> Then I package it and try to verify it with this command:
>> $getfattr /test.txt
> 
> I assume you try to pack/unpack, right? If I remember correctly
> I only implemented the pack part. Unpacking is done by the kernel
> (but you are right, it should be done by user space too).
> 


I modified the file before packing. To pack I use the following commands:

$ ./usr/gen_initramfs.sh -l initramfs.list -e xattr ../rootfs > initramfs.cpio
$ gzip initramfs.cpio
$ mkimage -A arm64 -O linux -T ramdisk -d initramfs.cpio.gz uRamdisk

The kernel is loaded using:
booti ${kernaddr} ${initramaddr} ${dtbaddr}




>> Which returns to the command line without the data.
>>
>>
>>
>> I believe the cpio is working because I see the file /METADATA\!\!\! in
>> the target root filesystem, which shows the following when viewed with cat -e:
>> 00000028^A^Auser.comment^@this is a comment
>>
>> This matches the data I fed in at the start, so I believe the data is being
>> transferred correctly but I am accessioning it with the wrong tools.
> 
> Yes, xattrs are marshalled in the METADATA!!! file, one per regular file
> xattrs are applied to. Xattrs are applied to the previous regular file.
> That file name was preferred to adding a suffix to the file, to avoid
> reaching the filename size limit.
> 
> Roberto

Best regards,
Jim

> 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

On 7/18/22 13:08, Jim Baxter wrote:
> 
> 
> 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 

/dev/ram0 is a block device. Trying to provide it to tmpfs is like trying to say:

  mount -t proc /dev/sda1 /proc

There's nowhere for the block device to GO because it's not a block backed
filesystem.

There's four types of filesystem: block back, pipe backed, ram backed, and
synthetic.

- Only block backed filesystems take a block device argument. Block backed
filesystems require two drivers: one to handle I/O to the block device and one
to interpret the filesystem format with the block device. You do not "format"
any other kind of filesystem. (There's no mkfs.nfs or mkfs.proc: it doesn't work
that way.)

- Pipe backed ones include network filesystems (nfs, samba), FUSE filesystems,
or hybrid weirdness like https://wiki.qemu.org/Documentation/9psetup . These
drivers talk a protocol over a pipe (or network socket, or char device, or...)
to a server at the far end that serves up the filesystem contents. Usually their
source argument is a server address plus filesystem identification plus login
credentials. Often they have a wrapper program that assembles this argument for you.

- Ram backed filesystems (ramfs, tmpfs) treat the "source" argument to mount(2)
as basically a comment, and ignore it. When you're adding things like size
limitations, it goes in the "data" argument (I.E. mount -o thingy).

- synthetic filesystems are just interfaces to the kernel that make up their
contents programmatically (proc, sys, cgroup...) and no two are alike, although
they generally ignore their "source" argument and look at "data" too.

I wrote up documention about this many years ago...

  https://landley.net/toybox/doc/mount.html

> I also found that root is always mounted as rootfs in my initramfs system
> which I understood to be tmpfs, is that incorrect?

Yes, although the kernel tries to hide this by lying in /proc/mounts for bad
reasons.
> I modified the file before packing. To pack I use the following commands:
> 
> $ ./usr/gen_initramfs.sh -l initramfs.list -e xattr ../rootfs > initramfs.cpio
> $ gzip initramfs.cpio
> $ mkimage -A arm64 -O linux -T ramdisk -d initramfs.cpio.gz uRamdisk
> 
> The kernel is loaded using:
> booti ${kernaddr} ${initramaddr} ${dtbaddr}

Remove the root= argument from your kernel command line. It is explicitly
telling the kernel "we will not be staying in rootfs" and thus it doesn't use
tmpfs for it. In your case, you're saying "we're going to overmount the initial
ramfs with a ram disk block device", which is nonsensical because nothing can
have populated it so it will be all zeroes (unformatted) and thus the filesystem
type detection staircase in
https://github.com/torvalds/linux/blob/v5.18/init/do_mounts_rd.c#L38 won't be
able to find a filesystem type to mount on it and it's guaranteed to fail.

Note: initramfs was introduced in the early 2000s, and back in the 1990s there
was an older "initrd" mechanism that DID use ramdisks (which are a chunk of ram
used as a block device). I wrote documention about THAT too:

  https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Basically the mechanism you're feeding init.cpio.gz in through was originally
written to populate a ramdisk, and you'd make an ext2 image or something and
gzip that. These days, the kernel decompresses the first few bytes of the file
and if the result is a cpio signature it calls the initramfs plumbing
(extracting the archive into the ram backed filesystem) and if not it extracts
it into the /dev/ram0 block device and treats it as an initial ram disk. In
NEITHER case do you need root= because that's used AFTER initramfs and initrd
have both failed to find an /init program. (Well initrd looks for /linuxrc
instead of /init because historical cruft, and then there was pivot_root...
Don't go there.)

Rob