On Sat, 9 Dec 2023 at 15:08, Eric Curtin <ecurtin@xxxxxxxxxx> wrote: > > On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote: > > > > On 09.12.2023 17:42, Eric Curtin wrote: > > > On Sat, 9 Dec 2023 at 12:46, Luca Boccassi <bluca@xxxxxxxxxx> wrote: > > >> > > >> On Fri, 8 Dec 2023 at 19:00, Eric Curtin <ecurtin@xxxxxxxxxx> 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?
