Re: [systemd-devel] Stateless system - Centos8 and overlayfs on root
To be clear, I am trying to introduce the minimal change possible to Centos
8 (due to outside constraints). Also past initial/lab development, the
embedded system goes on a trailer, and operates in (network) isolation for
months or years. Not so much a CI sort of setup. Did read the 0pointer
"stateless" post, before first post here.
Mucking through the systemd startup. switching root just Before local-fs
seems to cause trouble (allowing for possible other error on my part). To
my read, perhaps I need to hack systemd-remount-fs so as to preserve the
surrounding logic. Insert the overlay *after* the root volume is picked up
from /etc/fstab, and *before* the special /{proc,dev,sys} are mounted.
At least that is my present guess.
On Mon, Mar 30, 2020 at 4:18 AM Simon McVittie wrote:
> On Fri, 27 Mar 2020 at 10:17:37 -0700, Preston L. Bannister wrote:
> > Updates would be accomplished by booting from the original boot menu
> entry.
> > (This is slightly complicated by the fact the target systems' computers
> do not
> > have a console - but figure I can script altering the default boot.)
>
> I think you might be better off with something based on the idea of
> building an immutable "golden image" elsewhere, and deploying it to the
> stateless machines using a filesystem-image-based "A/B" update strategy
> (like casync and Android) or a filesystem-tree-based atomic update
> strategy (like libostree, as used in Fedora Silverblue and Endless).
> Either way, the big ideas are:
>
> - build the "golden image" in CI infrastructure somewhere else
> - have enough space for two complete OSs
> - whichever one you are booted into (let's say it's "A"), overwrite the
> other one (let's say "B") with the new OS
> - reboot into "B", but just once (have a clever bootloader)
> - if "B" fails to boot, recover by going back to "A"
> - you hope that a later upgrade will fix the regression and overwrite
> "B" again, this time with a better version
> - if "B" boots OK, keep using it (tell the bootloader to boot it every
> time from now on); next time you upgrade, swap the roles of "A" and "B"
>
> Most people who do that will be using an overlay-like arrangement to
> store whatever state they want to transfer between A and B, such as /etc
> and /home - but in your case you don't want to store any state at all.
>
> smcv
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Some Questions About Systemd and Dbus-daemon
Hi everyone, I have some questions and I'd like to know if you can help to answer them. 1. What is the relationship among systemd??dbus(libdbus,dbus-daemon) and dbus-broker? 2. Does systemd rely on dbus-broker(dbus-daemon) or vice versa? 3. Is org.freedesktop.DBus generated first or is dbus-broker started first? 4. Does org.freedesktop.DBus rely on dbus-broker or vice versa? 5. What is the usage of dbus.socket? 6. If I use systemd and dbus-broker only, does this mean that I can abandon dbus(libdbus,dbus-daemon) instead of rely on it? 7. I'd love to know the relationship of systemd and dbus, also the internals of systemd. Is there any materials you can share? Thank you in advance and looking forward to your early reply! Frank___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Stateless system - Centos8 and overlayfs on root
On Fri, 27 Mar 2020 at 10:17:37 -0700, Preston L. Bannister wrote: > Updates would be accomplished by booting from the original boot menu entry. > (This is slightly complicated by the fact the target systems' computers do not > have a console - but figure I can script altering the default boot.) I think you might be better off with something based on the idea of building an immutable "golden image" elsewhere, and deploying it to the stateless machines using a filesystem-image-based "A/B" update strategy (like casync and Android) or a filesystem-tree-based atomic update strategy (like libostree, as used in Fedora Silverblue and Endless). Either way, the big ideas are: - build the "golden image" in CI infrastructure somewhere else - have enough space for two complete OSs - whichever one you are booted into (let's say it's "A"), overwrite the other one (let's say "B") with the new OS - reboot into "B", but just once (have a clever bootloader) - if "B" fails to boot, recover by going back to "A" - you hope that a later upgrade will fix the regression and overwrite "B" again, this time with a better version - if "B" boots OK, keep using it (tell the bootloader to boot it every time from now on); next time you upgrade, swap the roles of "A" and "B" Most people who do that will be using an overlay-like arrangement to store whatever state they want to transfer between A and B, such as /etc and /home - but in your case you don't want to store any state at all. smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
