Re: [PATCH] mnt: add support for non-rootfs initramfs

[Arvind Sankar]

On Thu, Mar 05, 2020 at 01:09:10PM -0800, James Bottomley wrote:
> On Thu, 2020-03-05 at 19:35 +0000, Ignat Korchagin wrote:
> > The main need for this is to support container runtimes on stateless
> > Linux system (pivot_root system call from initramfs).
> > 
> > Normally, the task of initramfs is to mount and switch to a "real"
> > root filesystem. However, on stateless systems (booting over the
> > network) it is just convenient to have your "real" filesystem as
> > initramfs from the start.
> > 
> > This, however, breaks different container runtimes, because they
> > usually use pivot_root system call after creating their mount
> > namespace. But pivot_root does not work from initramfs, because
> > initramfs runs form rootfs, which is the root of the mount tree and
> > can't be unmounted.
> 
> Can you say more about why this is a problem?  We use pivot_root to
> pivot from the initramfs rootfs to the newly discovered and mounted
> real root ... the same mechanism should work for a container (mount
> namespace) running from initramfs ... why doesn't it?

Not sure how it interacts with mount namespaces, but we don't use
pivot_root to go from rootfs to the real root. We use switch_root, which
moves the new root onto the old / using mount with MS_MOVE and then
chroot to it.

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

> 
> The sequence usually looks like: create and enter a mount namespace,
> build a tmpfs for the container in some $root directory then do
> 
> 
>     cd $root
>     mkdir old-root
>     pivot_root . old-root
>     mount --
> make-rprivate /old-root
>     umount -l /old-root
>     rmdir /old-root
> 
> Once that's done you're disconnected from the initramfs root.  The
> sequence is really no accident because it's what the initramfs would
> have done to pivot to the new root anyway (that's where container
> people got it from).
> 
> 
> James
>