Re: [systemd-devel] stacked extension not working

2021-10-20 Thread Luca Boccassi
No, it's only supported for images at the moment, as the documentation says: --extension=PATH Add an additional image PATH as an overlay on top of IMAGE when attaching/detaching. This argument can be specified multiple times, in which case the order in which images

Re: [systemd-devel] stacked extension not working

2021-10-20 Thread Umut Tezduyar Lindskog
It indeed worked as squashfs image. Thanks for that. It is not working as a folder though (portablectl --runtime attach --extension=./stackupper ./base stackupper) This stuff should work on folders too right? Should I open a ticket? Also, when it works, the upper stack shows as detached. Isn't

Re: [systemd-devel] [External] : Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification

2021-10-20 Thread Alec Brown
On Tue, Sep 21, 2021 at 03:40:20PM +, Peter Stuge wrote: > Alec Brown wrote: > > Below is how the layout of these logs would store their data. > > > > bf_log_header: > >+---+ > > u32| version | > > u32| size | >

Re: [systemd-devel] [SPECIFICATION RFC v3] The firmware and bootloader log specification

2021-10-20 Thread Alec Brown
On Sun, Sep 19, 2021 at 12:53:35AM +0200, Heinrich Schuchardt wrote: > > > Am 18. September 2021 18:04:13 MESZ schrieb Alec Brown > : > >Hi everyone, > > > >I've been working on improving the specification for the firmware and > >bootloader > >log that Daniel Kiper has proposed and take into

[systemd-devel] [SPECIFICATION RFC v3] The firmware and bootloader log specification

2021-10-20 Thread Alec Brown
Hi everyone, I've been working on improving the specification for the firmware and bootloader log that Daniel Kiper has proposed and take into account most of the suggestions that were made in these threads [1], [2]. The goal is to allow various boot components to pass logs to the running OS and

Re: [systemd-devel] [SPECIFICATION RFC v3] The firmware and bootloader log specification

2021-10-20 Thread Peter Stuge
Alec Brown wrote: > Below is how the layout of these logs would store their data. > > bf_log_header: >+---+ > u32| version | > u32| size | > u8[64] | producer | > u8[64] | log_format| >