Hi,
> > > > Do we need this stuff configurable?
> > >
> > > No. But I think we should have a sanity check. To avoid getting
> > > stuck in the system-update.target: A service that is part of
> > > system-update.target and starts the rescue target. rc-once.service
> > > and your service should both be sorted 'Before' that service. If no
> > > other service starts a different target we automatically fall into
> the rescue target.
> > >
> > Is "FailureAction=reboot" or "FailureAction=rescue.target" in service
> > file sufficient here?
>
> Actually, I noticed that system-update-cleanup.service is supposed to
> handle this case. I'm currently unsure if 'remove the link and reboot'
> is ok, of if I want to drop into the rescue target.
>
I am unsure too. Because it depends on the system. On one hand, who knows why
the update fails and a reboot helps here? A reboot is simple, but does not
solve every problem. On the other hand, if you have e.g. an embedded system in
an industrial environment, you need a good rescue target that put the plant
into a safe mode :). I trend to rescue target (gut instinct).
> > I am not happy with my implementation today :-(. The main reason is,
> it does not cover my usecase where I want to do something:
> >* Once at first boot
> >* With UI on tty
> >* Without conflicting rc-once
> >
> > For this usecase it seems to be enough to add a service to
> > system-update.target.wants with "After=rc-once.service". This is not
> > flawless, because the system continues booting after rc-once is done
> e.g.
> > getty.target. It seems to be related to "systemctl daemon-reexec" in
> > systemd-rc-once I am not sure. The handling of bbinit beside systemd
> > and managing write protection in this scripts scares me. I am afraid
> > to break stuff when doing changes here.
>
> This stuff is a bit tricky. There are several things to consider:
> - The rootfs may or may not be mounted read-only. The remount stuff
> basically makes sure the rootfs is writable and returns to the
> previous
> state when we're done
I understand, and yesterday I thought that this (rw/ro) should be the job of
systemd update mode. But now I have a better understanding that you have to
consider bbinit, too.
> - The rc-once may modify the currently running executables and
> libraries.
> 'exec "$0" ...' and daemon-reexec try to make sure the new versions
> are
> used before the rootfs is mounted read-only. Otherwise this may fail.
Puhh, this is really tricky.
> - Deleting /system-update + daemon-reexec (or daemon-reload) results in
> a
> new 'default.target'. This is then activated by 'systemctl default'.
> - If mounting read-only fails, we reboot and run rc-once again. All
> scripts
> are done at this point so that's just some remounting. This is needed
> to
> make sure the journal is flushed and the filesystem is clean.
> - If any rc-once script fails, we want to drop into the rescue target.
> This
> is already used for other fatal errors during startup, so it's a
> central
> place to handle a broken rootfs.
>
Good explanation, I agree.
> I'm not sure what you want to do in your service. What should happen
> once it's done?
> We could split out the 'systemctl default' into a 'system-update-
> done.service'. Then you could sort your service between rc-once an this
> new service. Would that work for you?
>
Little background of what I am doing at the moment:
I use this stuff for a migration tool to transform older devices into new RAUC
based A+B system without losing user data. In my case the system boots from a
USB stick and I have a package 'system-migration-part1' that is part of the
userland of the USB stick (collections are cool!). This packages saves all user
data from the internal memory onto the USB-stick. Depending on the amount of
data the process takes up to 8 minutes. While this is running I want to show
the user a kind of UI, without kernel messages. Currently I am using
pipeviewer. In combination with dialog it looks ok for me. Next step is to
reorganize all internal storages (partition and filesystems) and put a cool
RAUC based image (recovery) into SLOT A installing another bootloader and do a
reboot into recovery starting migration-part-2 where the user data is restored
and the final firmware gets installed into SLOT B
I will try your idea with system-update-done.service.
> Do we need to check the link target of /system-update with your current
> requirements? Is there a use-case where your service should be started,
> but not rc-once? If not, then I'd say we leave this as is for now.
>
No, I currently do not need it for my requirements. The only thing left is the
Bugfix (/etc/rc.once.d -> etc/rc-once.d). And, because nobody really checks the
link target, we do not need this either. I suggest to leave things as is, until
a real requirement spawns?
Thank you both for detailed explanations and your help.
Regards Gavin
Eckelmann AG
Vorstand: Dipl.-Ing.
