<div dir="ltr"><div dir="ltr">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.<br><br>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 <span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">systemd-remount-fs</span> so as to preserve the surrounding logic. Insert the overlay <i>after</i> the root volume is picked up from /etc/fstab, and <i>before</i> the special /{proc,dev,sys} are mounted.<div><br></div><div>At least that is my present guess.</div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 30, 2020 at 4:18 AM Simon McVittie <<a href="mailto:smcv@collabora.com">smcv@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 27 Mar 2020 at 10:17:37 -0700, Preston L. Bannister wrote:<br>
> Updates would be accomplished by booting from the original boot menu entry.<br>
> (This is slightly complicated by the fact the target systems' computers do not<br>
> have a console - but figure I can script altering the default boot.)<br>
<br>
I think you might be better off with something based on the idea of<br>
building an immutable "golden image" elsewhere, and deploying it to the<br>
stateless machines using a filesystem-image-based "A/B" update strategy<br>
(like casync and Android) or a filesystem-tree-based atomic update<br>
strategy (like libostree, as used in Fedora Silverblue and Endless).<br>
Either way, the big ideas are:<br>
<br>
- build the "golden image" in CI infrastructure somewhere else<br>
- have enough space for two complete OSs<br>
- whichever one you are booted into (let's say it's "A"), overwrite the<br>
  other one (let's say "B") with the new OS<br>
- reboot into "B", but just once (have a clever bootloader)<br>
- if "B" fails to boot, recover by going back to "A"<br>
  - you hope that a later upgrade will fix the regression and overwrite<br>
    "B" again, this time with a better version<br>
- if "B" boots OK, keep using it (tell the bootloader to boot it every<br>
  time from now on); next time you upgrade, swap the roles of "A" and "B"<br>
<br>
Most people who do that will be using an overlay-like arrangement to<br>
store whatever state they want to transfer between A and B, such as /etc<br>
and /home - but in your case you don't want to store any state at all.<br>
<br>
    smcv<br>
_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div></div>