Re: [ptxdist] systemd: Using second offline update service beside rc-once in PTXDIST

["Schenk, Gavin" <G.Schenk@eckelmann.de>]

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. Peter Frankenbach (Sprecher) Dipl.-Wi.-Ing. Philipp Eckelmann
Dr.-Ing. Marco Münchhof Dr.-Ing. Frank Uhlemann
Vorsitzender des Aufsichtsrats: Hubertus G. Krossa
Stv. Vorsitzender des Aufsichtsrats: Dr.-Ing. Gerd Eckelmann
Sitz der Gesellschaft: Berliner Str. 161, 65205 Wiesbaden, Amtsgericht Wiesbaden HRB 12636
http://www.eckelmann.de 

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de