Headsup: Alternative to the filesystem overlay

Headsup: Alternative to the filesystem overlay

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

There was a topic year ago:

https://lists.ozlabs.org/pipermail/openbmc/2019-August/017611.html

Is anyone currently working in this direction? Any thoughts on possible
approaches?

We're going to revisit this and discuss possible solutions.

One point to mention is: introduce an image feature flag that would enable
rootfs overlay, i.e. for development purposes.

[-- Attachment #2: Type: text/html, Size: 572 bytes --]

Headsup: Alternative to the filesystem overlay

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

There was a topic year ago:

https://lists.ozlabs.org/pipermail/openbmc/2019-August/017611.html

Is anyone currently working in this direction? Any thoughts on possible
approaches?

We're going to revisit this and discuss possible solutions.

One point to mention is: introduce an image feature flag that would enable
rootfs overlay, i.e. for development purposes.

[-- Attachment #2: Type: text/html, Size: 572 bytes --]

Re: Headsup: Alternative to the filesystem overlay

[Alexander A. Filippov]

On Mon, Sep 21, 2020 at 02:42:49PM -0500, Adriana Kobylak wrote:
> On 2020-09-21 09:33, Alexander A. Filippov wrote:
> > I solved the problem with a difference of the user groups set during
> > firmware
> > upgrade by installing a systemd service which starts on the first BMC
> > boot after
> > upgrade and merges groups from RWFS and new ROFS.
> > 
> > This recipe is stored in our internal repo only, but I can share it if
> > it is
> > interesting to someone.
> 
> I'd be interested, if you would share it. Thanks!
> 

Here is it.
  https://gerrit.openbmc-project.xyz/c/openbmc/meta-yadro/+/36650

But it looks I was wrong. In fact, the script just adds missing groups from a 
predefined list instead of the merging files from RWFS and new ROFS.

--
Regards,
Alexander

Re: Headsup: Alternative to the filesystem overlay

[Adriana Kobylak]

On 2020-09-21 09:33, Alexander A. Filippov wrote:
> On Mon, Sep 21, 2020 at 11:52:54AM +0200, Anton Kachalov wrote:
>> There was a topic year ago:
>> 
>> https://lists.ozlabs.org/pipermail/openbmc/2019-August/017611.html
>> 
>> Is anyone currently working in this direction? Any thoughts on 
>> possible
>> approaches?
> 
> As I can see there is no any actions in this direction.

I want to pick up this topic in the next coming months.

> 
> I solved the problem with a difference of the user groups set during 
> firmware
> upgrade by installing a systemd service which starts on the first BMC 
> boot after
> upgrade and merges groups from RWFS and new ROFS.
> 
> This recipe is stored in our internal repo only, but I can share it if 
> it is
> interesting to someone.

I'd be interested, if you would share it. Thanks!

> 
> The problems with other files is not met yet.
> 
>> 
>> We're going to revisit this and discuss possible solutions.

Another alternative I want to explore that is not listed in the original 
email is systemd's stateless implementation, where there's no need to 
have /etc/ populated to boot. The advantage of that approach is that you 
could mount /etc/ to a writable volume like /var/ and have applications 
write data to that directory without it being an overlay.

>> 
>> One point to mention is: introduce an image feature flag that would 
>> enable
>> rootfs overlay, i.e. for development purposes.
> 
> We still use a static flash layout on our hardware which already uses 
> overlayfs.
> It works fine for us.
> 
> --
> Regards,
> Alexander

Re: Headsup: Alternative to the filesystem overlay

[Adriana Kobylak]

On 2020-09-21 09:33, Alexander A. Filippov wrote:
> On Mon, Sep 21, 2020 at 11:52:54AM +0200, Anton Kachalov wrote:
>> There was a topic year ago:
>> 
>> https://lists.ozlabs.org/pipermail/openbmc/2019-August/017611.html
>> 
>> Is anyone currently working in this direction? Any thoughts on 
>> possible
>> approaches?
> 
> As I can see there is no any actions in this direction.

I want to pick up this topic in the next coming months.

> 
> I solved the problem with a difference of the user groups set during 
> firmware
> upgrade by installing a systemd service which starts on the first BMC 
> boot after
> upgrade and merges groups from RWFS and new ROFS.
> 
> This recipe is stored in our internal repo only, but I can share it if 
> it is
> interesting to someone.

I'd be interested, if you would share it. Thanks!

> 
> The problems with other files is not met yet.
> 
>> 
>> We're going to revisit this and discuss possible solutions.

Another alternative I want to explore that is not listed in the original 
email is systemd's stateless implementation, where there's no need to 
have /etc/ populated to boot. The advantage of that approach is that you 
could mount /etc/ to a writable volume like /var/ and have applications 
write data to that directory without it being an overlay.

>> 
>> One point to mention is: introduce an image feature flag that would 
>> enable
>> rootfs overlay, i.e. for development purposes.
> 
> We still use a static flash layout on our hardware which already uses 
> overlayfs.
> It works fine for us.
> 
> --
> Regards,
> Alexander

Re: Headsup: Alternative to the filesystem overlay

[Alexander A. Filippov]

On Mon, Sep 21, 2020 at 11:52:54AM +0200, Anton Kachalov wrote:
> There was a topic year ago:
> 
> https://lists.ozlabs.org/pipermail/openbmc/2019-August/017611.html
> 
> Is anyone currently working in this direction? Any thoughts on possible
> approaches?

As I can see there is no any actions in this direction.

I solved the problem with a difference of the user groups set during firmware
upgrade by installing a systemd service which starts on the first BMC boot after
upgrade and merges groups from RWFS and new ROFS.

This recipe is stored in our internal repo only, but I can share it if it is
interesting to someone.

The problems with other files is not met yet.

> 
> We're going to revisit this and discuss possible solutions.
> 
> One point to mention is: introduce an image feature flag that would enable
> rootfs overlay, i.e. for development purposes.

We still use a static flash layout on our hardware which already uses overlayfs.
It works fine for us.

--
Regards,
Alexander

Re: Headsup: Alternative to the filesystem overlay

[Alexander A. Filippov]

On Mon, Sep 21, 2020 at 11:52:54AM +0200, Anton Kachalov wrote:
> There was a topic year ago:
> 
> https://lists.ozlabs.org/pipermail/openbmc/2019-August/017611.html
> 
> Is anyone currently working in this direction? Any thoughts on possible
> approaches?

As I can see there is no any actions in this direction.

I solved the problem with a difference of the user groups set during firmware
upgrade by installing a systemd service which starts on the first BMC boot after
upgrade and merges groups from RWFS and new ROFS.

This recipe is stored in our internal repo only, but I can share it if it is
interesting to someone.

The problems with other files is not met yet.

> 
> We're going to revisit this and discuss possible solutions.
> 
> One point to mention is: introduce an image feature flag that would enable
> rootfs overlay, i.e. for development purposes.

We still use a static flash layout on our hardware which already uses overlayfs.
It works fine for us.

--
Regards,
Alexander

Headsup: Alternative to the filesystem overlay

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

There was a topic year ago:

https://lists.ozlabs.org/pipermail/openbmc/2019-August/017611.html

Is anyone currently working in this direction? Any thoughts on possible
approaches?

We're going to revisit this and discuss possible solutions.

One point to mention is: introduce an image feature flag that would enable
rootfs overlay, i.e. for development purposes.

[-- Attachment #2: Type: text/html, Size: 588 bytes --]