[RFC] initoverlayfs - a scalable initial filesystem

[Luca Boccassi]

On Sat, 9 Dec 2023 at 15:08, Eric Curtin <ecurtin at redhat.com> wrote:
>
> On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> >
> > On 09.12.2023 17:42, Eric Curtin wrote:
> > > On Sat, 9 Dec 2023 at 12:46, Luca Boccassi <bluca at debian.org> wrote:
> > >>
> > >> On Fri, 8 Dec 2023 at 19:00, Eric Curtin <ecurtin at redhat.com> wrote:
> > >>>
> > >>> We have been working on a new initial filesystem called initoverlayfs.
> > >>> It is a new filesystem that provides a more scalable approach to
> > >>> initial filesystems as opposed to just using initrds. We are writing
> > >>> this RFC to the systemd and dracut mailing lists (feel free to forward
> > >>> to UAPI group also) because although this solution works without
> > >>> changing the code in these projects, it operates in the same area as
> > >>> systemd, udev, dracut, etc. and uses these tools.
> > >>
> > >> It seems to me everything you described already exists? If you want to
> > >> avoid having an initrd -> rootfs transition, you can already do that -
> > >
> > > You need a initrd -> rootfs transition for generic linux operating
> > > systems right?
> >
> > No, you do not. Nothing stops you from running off initramfs (today you
> > do not really have init*RAM Disk* - the content of initrd is unpacked
> > into initramfs.
>
> Apologies if I am misinterpreting this response, I use terms initrd
> and initramfs
> interchangeably (not technically correct, but it's common to do this). The
> point is to avoid unpacking as much as possible, because in many initrds
> the majority of the software need not be unpacked, but is designed to work
> with throwaway initial filesystems.

sd-stub already supports having a small initrd shipped in the UKI,
that is extended via sysexts, and systemd already supports running
from it, without any transition to a final rootfs. What else do you
need? What problem is this attempting to solve?