* Headsup: Alternative to the filesystem overlay
@ 2020-09-21 9:52 Anton Kachalov
2020-09-21 14:33 ` Alexander A. Filippov
0 siblings, 1 reply; 8+ messages in thread
From: Anton Kachalov @ 2020-09-21 9:52 UTC (permalink / raw)
To: OpenBMC Maillist
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Headsup: Alternative to the filesystem overlay
2020-09-21 9:52 Headsup: Alternative to the filesystem overlay Anton Kachalov
@ 2020-09-21 14:33 ` Alexander A. Filippov
2020-09-21 14:33 ` Alexander A. Filippov
2020-09-21 19:42 ` Adriana Kobylak
0 siblings, 2 replies; 8+ messages in thread
From: Alexander A. Filippov @ 2020-09-21 14:33 UTC (permalink / raw)
To: openbmc; +Cc: Anton Kachalov
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Headsup: Alternative to the filesystem overlay
2020-09-21 14:33 ` Alexander A. Filippov
@ 2020-09-21 14:33 ` Alexander A. Filippov
2020-09-21 19:42 ` Adriana Kobylak
1 sibling, 0 replies; 8+ messages in thread
From: Alexander A. Filippov @ 2020-09-21 14:33 UTC (permalink / raw)
To: openbmc; +Cc: Anton Kachalov
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Headsup: Alternative to the filesystem overlay
2020-09-21 14:33 ` Alexander A. Filippov
2020-09-21 14:33 ` Alexander A. Filippov
@ 2020-09-21 19:42 ` Adriana Kobylak
2020-09-21 19:42 ` Adriana Kobylak
2020-09-22 8:06 ` Alexander A. Filippov
1 sibling, 2 replies; 8+ messages in thread
From: Adriana Kobylak @ 2020-09-21 19:42 UTC (permalink / raw)
To: Alexander A. Filippov; +Cc: openbmc, openbmc, Anton Kachalov
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Headsup: Alternative to the filesystem overlay
2020-09-21 19:42 ` Adriana Kobylak
@ 2020-09-21 19:42 ` Adriana Kobylak
2020-09-22 8:06 ` Alexander A. Filippov
1 sibling, 0 replies; 8+ messages in thread
From: Adriana Kobylak @ 2020-09-21 19:42 UTC (permalink / raw)
To: Alexander A. Filippov; +Cc: openbmc, Anton Kachalov, openbmc
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Headsup: Alternative to the filesystem overlay
2020-09-21 19:42 ` Adriana Kobylak
2020-09-21 19:42 ` Adriana Kobylak
@ 2020-09-22 8:06 ` Alexander A. Filippov
1 sibling, 0 replies; 8+ messages in thread
From: Alexander A. Filippov @ 2020-09-22 8:06 UTC (permalink / raw)
To: Adriana Kobylak; +Cc: openbmc, openbmc, Anton Kachalov, 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Headsup: Alternative to the filesystem overlay
@ 2020-09-21 9:49 Anton Kachalov
2020-09-21 9:49 ` Anton Kachalov
0 siblings, 1 reply; 8+ messages in thread
From: Anton Kachalov @ 2020-09-21 9:49 UTC (permalink / raw)
To: OpenBMC Maillist
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-09-22 8:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-21 9:52 Headsup: Alternative to the filesystem overlay Anton Kachalov
2020-09-21 14:33 ` Alexander A. Filippov
2020-09-21 14:33 ` Alexander A. Filippov
2020-09-21 19:42 ` Adriana Kobylak
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
2020-09-21 9:49 ` Anton Kachalov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).