Yes, your understanding is correct. I'm off at the moment, we will try and
open a PR sometime to explain it better.
By the way I'd also happily review your PR also if you think you could
explain it better.
At the moment it's a loopback mounted file from /boot, mounted as an erofs
with transient o
On Do, 14.12.23 02:17, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> On Wed, Dec 13, 2023 at 10:03 AM Lennart Poettering
> wrote:
> >
> > On Di, 12.12.23 23:01, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> >
> > > > sysexts are erofs or squashfs file systems with verity backing. Only
> > > >
On Wed, Dec 13, 2023 at 10:03 AM Lennart Poettering
wrote:
>
> On Di, 12.12.23 23:01, Nils Kattenbeck (nilskem...@gmail.com) wrote:
>
> > > sysexts are erofs or squashfs file systems with verity backing. Only
> > > the sectors you access are decompressed.
> >
> > Okay I forgot that they were erofs
On Di, 12.12.23 23:01, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> > sysexts are erofs or squashfs file systems with verity backing. Only
> > the sectors you access are decompressed.
>
> Okay I forgot that they were erofs based and mentioned cpio archives
> so I assumed they would be one.
> Do
On Tue, Dec 12, 2023 at 10:02 PM Lennart Poettering
wrote:
>
> If you have 7 cpio initrds then the kernel will allocate a tmpfs and
> unpack them all into it, one after the other, on top of each other,
> and then jumps into the result.
>
> if you have an erofs and 7 cpio initds, what are you going
On Di, 12.12.23 21:34, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> Hi, while I have been following this thread passively for now I also
> wanted to chime in.
>
> > (The main reason why sd-stub doesn't actually support erofs-initrds,
> > is that sd-stub also generates initrd cpios on the fly, t
On Tue, 12 Dec 2023 at 20:35, Nils Kattenbeck wrote:
>
> Hi, while I have been following this thread passively for now I also
> wanted to chime in.
>
> > (The main reason why sd-stub doesn't actually support erofs-initrds,
> > is that sd-stub also generates initrd cpios on the fly, to pass
> > cre
Hi, while I have been following this thread passively for now I also
wanted to chime in.
> (The main reason why sd-stub doesn't actually support erofs-initrds,
> is that sd-stub also generates initrd cpios on the fly, to pass
> credentials and system extension images to the kernel, and you can't
>
On Tue, Dec 12, 2023 at 06:40:32PM +0100, Lennart Poettering wrote:
> On Mo, 11.12.23 12:48, Eric Curtin (ecur...@redhat.com) wrote:
>
> > Although the nice thing about a storage-init like approach is there's
> > basically zero copies up front. What storage-init is trying to be, is
> > a tool to j
On Tue, 12 Dec 2023 at 12:38, Lennart Poettering
wrote:
> On Mo, 11.12.23 12:48, Eric Curtin (ecur...@redhat.com) wrote:
>
> > Sort of yes, but preferably using that __initramfs_start /
> > initrd_start buffer as is without copying any bytes anywhere else and
> > without teaching the bootloaders
On Mo, 11.12.23 17:03, Eric Curtin (ecur...@redhat.com) wrote:
> A generic approach is hard, I think it's worth discussing which type of boots
> you should actually care about milliseconds of performance for. It would be
> nice
> if we had an init system that contained the binary data to do the m
On Mo, 11.12.23 11:28, Demi Marie Obenour (d...@invisiblethingslab.com) wrote:
> I don't think this is "a pretty specific solution to one set of devices"
> _at all_. To the contrary, it is _exactly_ what I want to see desktop
> systems moving to in the future.
>
> It solves the problem of large f
On Mo, 11.12.23 12:48, Eric Curtin (ecur...@redhat.com) wrote:
> Although the nice thing about a storage-init like approach is there's
> basically zero copies up front. What storage-init is trying to be, is
> a tool to just call systemd storage things, without also inheriting
> all the systemd sta
On Mo, 11.12.23 12:48, Eric Curtin (ecur...@redhat.com) wrote:
> Sort of yes, but preferably using that __initramfs_start /
> initrd_start buffer as is without copying any bytes anywhere else and
> without teaching the bootloaders to do things.
>
> The "memmap=" approach you suggested sounds like
[Sorry for the spam to the people in Cc. Now the real address.]
Dear Luca,
Am 11.12.23 um 22:45 schrieb Luca Boccassi:
> On Mon, 11 Dec 2023 at 21:20, Demi Marie Obenour wrote:
>>
>> On Mon, Dec 11, 2023 at 08:58:58PM +, Luca Boccassi wrote:
>>> On Mon, 11 Dec 2023 at 20:43, Demi Marie Obeno
On Mon, 11 Dec 2023 at 21:20, Demi Marie Obenour
wrote:
>
> On Mon, Dec 11, 2023 at 08:58:58PM +, Luca Boccassi wrote:
> > On Mon, 11 Dec 2023 at 20:43, Demi Marie Obenour
> > wrote:
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > >
> > > On Mon, Dec 11, 2023 at 08:15:27
On Mon, 11 Dec 2023 at 20:59, Luca Boccassi wrote:
>
> On Mon, 11 Dec 2023 at 20:43, Demi Marie Obenour
> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On Mon, Dec 11, 2023 at 08:15:27PM +, Luca Boccassi wrote:
> > > On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenou
On Mon, Dec 11, 2023 at 08:58:58PM +, Luca Boccassi wrote:
> On Mon, 11 Dec 2023 at 20:43, Demi Marie Obenour
> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On Mon, Dec 11, 2023 at 08:15:27PM +, Luca Boccassi wrote:
> > > On Mon, 11 Dec 2023 at 17:30, Demi Mar
On Mon, 11 Dec 2023 at 20:43, Demi Marie Obenour
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Mon, Dec 11, 2023 at 08:15:27PM +, Luca Boccassi wrote:
> > On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenour
> > wrote:
> > >
> > > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Le
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, Dec 11, 2023 at 08:15:27PM +, Luca Boccassi wrote:
> On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenour
> wrote:
> >
> > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote:
> > > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@
On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenour
wrote:
>
> On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote:
> > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:
> >
> > > Here is the boot sequence with initoverlayfs integrated, the
> > > mini-initramfs contains ju
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, Dec 11, 2023 at 05:03:13PM +, Eric Curtin wrote:
> On Mon, 11 Dec 2023 at 16:36, Demi Marie Obenour
> wrote:
> >
> > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote:
> > > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@re
On Mon, Dec 11, 2023 at 12:30 PM Demi Marie Obenour
wrote:
>
> On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote:
> > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:
> >
> > > Here is the boot sequence with initoverlayfs integrated, the
> > > mini-initramfs contains
On Mon, 11 Dec 2023 at 16:36, Demi Marie Obenour
wrote:
>
> On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote:
> > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:
> >
> > > Here is the boot sequence with initoverlayfs integrated, the
> > > mini-initramfs contains ju
On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote:
> On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:
>
> > Here is the boot sequence with initoverlayfs integrated, the
> > mini-initramfs contains just enough to get storage drivers loaded and
> > storage devices init
On Mon, 11 Dec 2023 at 12:48, Eric Curtin wrote:
>
> On Mon, 11 Dec 2023 at 11:51, Lennart Poettering
> wrote:
> >
> > On Mo, 11.12.23 11:28, Eric Curtin (ecur...@redhat.com) wrote:
> >
> > > > > For the items listed above I think you can find different solutions
> > > > > which do not necessari
On Mon, 11 Dec 2023 at 11:51, Lennart Poettering wrote:
>
> On Mo, 11.12.23 11:28, Eric Curtin (ecur...@redhat.com) wrote:
>
> > > > For the items listed above I think you can find different solutions
> > > > which do not necessarily compromise security as much.
> > > >
> > > > So, in the list abo
On Mo, 11.12.23 11:42, Eric Curtin (ecur...@redhat.com) wrote:
> I am also thinking, what is the difference between "make the
> bootloader load the erofs into contiguous memory" part and doing
> something like storage-init.
Well, from my PoV there's value in reducing the stages of the boot
proces
On Mo, 11.12.23 11:28, Eric Curtin (ecur...@redhat.com) wrote:
> > > For the items listed above I think you can find different solutions
> > > which do not necessarily compromise security as much.
> > >
> > > So, in the list above you could address the latter three like this:
> > >
> > > 2. Use an
I am also thinking, what is the difference between "make the
bootloader load the erofs into contiguous memory" part and doing
something like storage-init.
They are similar approaches, introduce something in the middle to
handle the erofs.
Is mise le meas/Regards,
Eric Curtin
On Mon, 11 Dec 2023
On Mon, 11 Dec 2023 at 11:20, Eric Curtin wrote:
>
> On Mon, 11 Dec 2023 at 10:06, Lennart Poettering wrote:
> >
> > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:
> >
> > > Here is the boot sequence with initoverlayfs integrated, the
> > > mini-initramfs contains just enough to g
On Mon, 11 Dec 2023 at 10:06, Lennart Poettering wrote:
>
> On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:
>
> > Here is the boot sequence with initoverlayfs integrated, the
> > mini-initramfs contains just enough to get storage drivers loaded and
> > storage devices initialized. s
On Mo, 11.12.23 10:57, Lennart Poettering (mzerq...@0pointer.de) wrote:
> Which leaves item 1, which is a bit harder to address. We have been
> discussing this off an on internally too. A generic solution to this
> is hard. My current thinking for this could be something like this,
> covering the
On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:
> Here is the boot sequence with initoverlayfs integrated, the
> mini-initramfs contains just enough to get storage drivers loaded and
> storage devices initialized. storage-init is a process that is not
> designed to replace init, it
On Sat, 9 Dec 2023 at 18:12, Luca Boccassi wrote:
>
> On Sat, 9 Dec 2023 at 17:58, Eric Curtin wrote:
> >
> > On Sat, 9 Dec 2023 at 17:46, Luca Boccassi wrote:
> > >
> > > On Sat, 9 Dec 2023 at 17:25, Eric Curtin wrote:
> > > >
> > > > On Sat, 9 Dec 2023 at 17:19, Luca Boccassi wrote:
> > > >
On Sat, 9 Dec 2023 at 17:58, Eric Curtin wrote:
>
> On Sat, 9 Dec 2023 at 17:46, Luca Boccassi wrote:
> >
> > On Sat, 9 Dec 2023 at 17:25, Eric Curtin wrote:
> > >
> > > On Sat, 9 Dec 2023 at 17:19, Luca Boccassi wrote:
> > > >
> > > > On Sat, 9 Dec 2023 at 15:08, Eric Curtin wrote:
> > > > >
On Sat, 9 Dec 2023 at 17:46, Luca Boccassi wrote:
>
> On Sat, 9 Dec 2023 at 17:25, Eric Curtin wrote:
> >
> > On Sat, 9 Dec 2023 at 17:19, Luca Boccassi wrote:
> > >
> > > On Sat, 9 Dec 2023 at 15:08, Eric Curtin wrote:
> > > >
> > > > On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov
> > > > wro
On Sat, 9 Dec 2023 at 17:25, Eric Curtin wrote:
>
> On Sat, 9 Dec 2023 at 17:19, Luca Boccassi wrote:
> >
> > On Sat, 9 Dec 2023 at 15:08, Eric Curtin wrote:
> > >
> > > On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov wrote:
> > > >
> > > > On 09.12.2023 17:42, Eric Curtin wrote:
> > > > > On Sat
On Sat, 9 Dec 2023 at 17:19, Luca Boccassi wrote:
>
> On Sat, 9 Dec 2023 at 15:08, Eric Curtin wrote:
> >
> > On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov wrote:
> > >
> > > On 09.12.2023 17:42, Eric Curtin wrote:
> > > > On Sat, 9 Dec 2023 at 12:46, Luca Boccassi wrote:
> > > >>
> > > >> On F
On Sat, 9 Dec 2023 at 15:08, Eric Curtin wrote:
>
> On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov wrote:
> >
> > On 09.12.2023 17:42, Eric Curtin wrote:
> > > On Sat, 9 Dec 2023 at 12:46, Luca Boccassi wrote:
> > >>
> > >> On Fri, 8 Dec 2023 at 19:00, Eric Curtin wrote:
> > >>>
> > >>> We have
On Sat, 9 Dec 2023 at 15:23, Daan De Meyer 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 a
> 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
On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov wrote:
>
> On 09.12.2023 17:42, Eric Curtin wrote:
> > On Sat, 9 Dec 2023 at 12:46, Luca Boccassi wrote:
> >>
> >> On Fri, 8 Dec 2023 at 19:00, Eric Curtin wrote:
> >>>
> >>> We have been working on a new initial filesystem called initoverlayfs.
> >>
On 09.12.2023 17:42, Eric Curtin wrote:
On Sat, 9 Dec 2023 at 12:46, Luca Boccassi wrote:
On Fri, 8 Dec 2023 at 19:00, Eric Curtin 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 filesyste
On Sat, 9 Dec 2023 at 12:46, Luca Boccassi wrote:
>
> On Fri, 8 Dec 2023 at 19:00, Eric Curtin 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 usin
On Fri, 8 Dec 2023 at 19:00, Eric Curtin 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
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) bec
47 matches
Mail list logo