Re: Intercepting/Delaying the boot process

[Andreas Hartmann <hartan@xxxxx>]

On Fri, 2022-04-08 at 15:14 +0200, Lennart Poettering wrote:
> On Fr, 08.04.22 09:01, Andreas Hartmann (hartan@xxxxx) wrote:
> > To this end I was wondering whether it would be feasible to "hook" into the
> > boot
> > process, somewhere before the disks are decrypted, to only have it charge (or
> > continue to boot when I press some magic button maybe).
> 
> The way I'd implement this would be via a generator. See
> https://www.freedesktop.org/software/systemd/man/systemd.generator.html
> for details on that.
> 
> Generators are in a way "plugins" to systemd's unit graph logic. They
> can insert units and dependencies into the tree from external
> sources. They can also override the regular tree. So here's what I
> would specifically do: write a tiny generator that figures out if it
> is in this charging mode. And if so, it overrides the "default.target"
> symlink so that it points to a new target "charge-mode.target" or
> so. Note that "default.target" is the default target the system will
> boot into. Thus with this generator you made sure that if this charge
> mode is selected only a tiny subset of units can be activated. Now,
> add in a service into "charge-mode.target" that brings some nice
> graphics to screen, and then just waits. If eventually something
> happens so that the system shall power up fully, you can do the
> equivalent of "systemctl isolate graphical.target" so that you boot up
> into the regular system again.

Great, that indeed sounds much better than delaying the boot process!

> 
> > - After which stage in the boot process is the sysfs available?
> 
> sysfs is mounted by very early PID 1 code. It's basically always there.
> 
> > - Can I delay the boot for an indefinite amount of time, or will this cause
> > some
> > services later on in the process to timeout and fail?
> 
> You can, but as mentioned I'd rather redirect boot to a separate
> target, see above.
> 
> > - Is it possible for a service during early boot to command a system shutdown
> > instead of continuing to boot?
> 
> Sure.
> 
> > - May I simply take control of the TTY and clear/rewrite it as I like, or
> > does
> > systemd use some magic for this?
> 
> Use StandardInput=tty and your program will be started once there is
> noone else who is the controller of the TTY.
> 
> This reminds of an RFE we have had for a while, and which I think
> would make sense to add directly to systemd: a generator that detects
> whether the battery is nearly empty at boot, and if so redirects boot
> to some special target showing a nice message for a bit and then
> powering off.
> 
> How do you intend to discern "power-up due to charger plugged in" from
> "power-up due to power button pressed" btw? Is there generic infra for
> discerning that? Or just something pinephone specific thing? Ideally
> we had some generic infra for that in the kernel.
> 
> (On PCs there's a field for that in DMI called "Wake-up Type". I
> wonder how well that works these days.)

Right now: I have no idea how I'll do that. The pinephones PMIC at least is able
to discern these two power-on reasons and they can be read out from internal
registers. I had a quick glance at the kernel driver for the IC and the registers
are at least mentioned there, but that's all I know so far. I don't know whether
this is exposed to sysfs somewhere related to the PMIC, or whether the kernel has
its own way of collecting such information and (not) telling me... I get a
feeling this project will keep me busy for quite some time.

Don't take this as a real commitment, but maybe I'll start with the "battery low,
turning off" thingy to get a feeling for the generators *before* I start adding
such hardware specifics as power-on reasons. I'm curious where this will lead...

Thank you for all the hints!


hartan

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin