Message-ID: <97078f1e-0267-5ddf-15c0-51423e738487@gmail.com>
Date:   Tue, 8 Jun 2021 14:49:12 -0500
From:   "Harry G. Coin" <hgcoin@...il.com>
To:     Vivek Goyal <vgoyal@...hat.com>
Cc:     linux-fsdevel@...r.kernel.org, virtio-fs@...hat.com,
        linux kernel mailing list <linux-kernel@...r.kernel.org>,
        Miklos Szeredi <miklos@...redi.hu>,
        Richard Weinberger <richard.weinberger@...il.com>,
        Dominique Martinet <asmadeus@...ewreck.org>,
        David Howells <dhowells@...hat.com>, viro@...iv.linux.org.uk,
        v9fs-developer@...ts.sourceforge.net
Subject: Re: [Virtio-fs] [PATCH] init/do_mounts.c: Add root="fstag:<tag>"
 syntax for root device


On 6/8/21 2:26 PM, Vivek Goyal wrote:
> On Tue, Jun 08, 2021 at 01:38:56PM -0500, Harry G. Coin wrote:
>> On 6/8/21 10:35 AM, Vivek Goyal wrote:
>>> We want to be able to mount virtiofs as rootfs and pass appropriate
>>> kernel command line. Right now there does not seem to be a good way
>>> to do that. If I specify "root=myfs rootfstype=virtiofs", system
>>> panics.
>>>
>>> virtio-fs: tag </dev/root> not found
>>> ..
>>> ..
>>> [ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]
>> Whatever the best direction forward might be for kernel patches
>> regarding 'not block device as root', it would ease learning curves if
>> 'the patterns that set config issue X' were the same across root 'not
>> block device options' whether cephfs, nfs, 9p, virtiofs.
> I think achieveing same pattern for all non-block options is pretty
> hard. There are too many varieits, mtd, ubifs, nfs, cifs, and you
> just mentioned cephfs.
>
> It would be nice if somebody can achieve it. But that should not be
> a blocker for this patch. Goal of this patch is to take care of virtiofs
> and 9p. And any other filesystem which can work with this pattern.
>
> I think ubi and mtd should be able to work with "root=fstag:<tag>"
> as well. Something like "root=fstag:ubi:foo". And then ubi:foo
> will should be passed to ubifs. I think only thing missing is
> that current code assumes there is one filesystem passed in
> rootfstype. If we want to try mounting device with multiple
> filesystems then one can modify the code to call do_mount_root()
> in a loop from a filesystem list.
>
> Right now I did not need it, so I did not add it.
>
>> All of them
>> will have to handle the selinux xattr/issue, posix and flock issues,
>> caching etc.
> Filesystem specific flags will be passed by rootflags=.
>
>> While by definition virtiofs has to exist only in a vm
>> guest, the others could be baremetal or vm guest roots.  (How much 9p's
>> other-than-guest transports are used I don't know).
>>
>> FYI (though patching the kernel may be the best option)  there is a case
>> that does not have those kernel panics for virtiofs-root and 9p root
>> using stock fc34.  As 9p, the virtiofs method uses the initrd creation
>> mechanisms provided by 'dracut' or 'initramfs' to provide the 'sysroot
>> pivot glue'.
>>
>> On the fc34 guest a successful 'direct kernel boot' today looks like:
>>
>> kernel path: /vmsystems/fedora_generic/boot/vmlinuz
>>
>> initrd path: /vmsystems/fedora_generic/boot/initrd.img
>>
>> Kernel args: root=virtiofs:myfs rd.shell rd.fstab
> Does it work with upstream dracut or you have modified dracut to
> parse "root=virtiofs:myfs" option.

It works with dracut and stock fs34 kernel right now by exactly the
three files 9p upstream works with dracut to root fs boot, except
'virtiofs' instead of '9p' in the dracut.conf.d files.  Note it requires
the virtiofs: in the root= line, but not in the fstab and qemu configs.

re: cephfs Here's a cephfs approach to the problem: 
https://github.com/jurashka/dracut-ceph-module

Powered by blists - more mailing lists