From: Adriana Kobylak <anoo@linux.ibm.com>
To: "Alexander A. Filippov" <a.filippov@yadro.com>
Cc: openbmc <openbmc-bounces+anoo=linux.ibm.com@lists.ozlabs.org>,
openbmc@lists.ozlabs.org, Anton Kachalov <rnouse@google.com>
Subject: Re: Headsup: Alternative to the filesystem overlay
Date: Mon, 21 Sep 2020 14:42:49 -0500 [thread overview]
Message-ID: <3f491d1ca08a5480af9d4555121da090@linux.vnet.ibm.com> (raw)
In-Reply-To: <20200921143331.GA20273@bbwork.lan>
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
WARNING: multiple messages have this Message-ID (diff)
From: Adriana Kobylak <anoo@linux.ibm.com>
To: "Alexander A. Filippov" <a.filippov@yadro.com>
Cc: openbmc@lists.ozlabs.org, Anton Kachalov <rnouse@google.com>,
openbmc <openbmc-bounces+anoo=linux.ibm.com@lists.ozlabs.org>
Subject: Re: Headsup: Alternative to the filesystem overlay
Date: Mon, 21 Sep 2020 14:42:49 -0500 [thread overview]
Message-ID: <3f491d1ca08a5480af9d4555121da090@linux.vnet.ibm.com> (raw)
Message-ID: <20200921194249.qzS6wpmSZiUlzN6idgj8RjRqm05VlKXfP03ElCq33tY@z> (raw)
In-Reply-To: <20200921143331.GA20273@bbwork.lan>
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
next prev parent reply other threads:[~2020-09-21 19:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 9:52 Headsup: Alternative to the filesystem overlay Anton Kachalov
2020-09-21 14:33 ` Alexander A. Filippov
2020-09-21 19:42 ` Adriana Kobylak [this message]
2020-09-21 19:42 ` Adriana Kobylak
2020-09-22 8:06 ` Alexander A. Filippov
-- strict thread matches above, loose matches on Subject: below --
2020-09-21 9:49 Anton Kachalov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f491d1ca08a5480af9d4555121da090@linux.vnet.ibm.com \
--to=anoo@linux.ibm.com \
--cc=a.filippov@yadro.com \
--cc=openbmc-bounces+anoo=linux.ibm.com@lists.ozlabs.org \
--cc=openbmc@lists.ozlabs.org \
--cc=rnouse@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.