Danny Milosavljevic <dan...@scratchpost.org> skribis:
>> If you run this on an “old” GuixSD, ‘find-long-options’ is undefined.
> How can it be that (gnu services base) with find-long-options call is present
> but the (gnu build linux-boot)'s find-long options isn't present?
The service-upgrade code loads new service definitions in PID 1.
However, it does not force a reload of already-loaded modules.
What happens here is that (gnu build linux-boot), the one without
‘find-long-options’, is already available in PID 1. Thus, when end up
using that one, which lacks ‘find-long-options’.
We could call ‘reload-module’, but that’s probably not a great idea as
it could cause breakage in previously-loaded code in PID 1. So I think
the current approach is the safest, and breakage of this sort should be
quite rare; we should pay attention to such issues, though, and try hard
to avoid them.
(Note that there’s no problem once you reboot, of course.)
>> 1. ‘guix system reconfigure’ should probably register services one by
>> one so that if one of the service expressions is erroneous, we
>> don’t bork everything. See ‘upgrade-shepherd-services’.
> Yes please.
>> 2. IWBN to delay execution of this whole default-tty thing to the
>> #:start method. Ideas, Danny?
> The idea was that if you specify a serial console at boot that you can
> actually log in at that console.
> So it's trying to find out whether, at the time of service start,
> there is a serial console specified (in the Linux command line), and if
> so, start an agetty. Otherwise do not start that agetty.
> We could also do that without a guix service - but I thought it would be
> nice to have a guix service for it as well.
I agree. I think what you did in
c32e3ddedd103318ca3f0a4bf0c91c91e2517806 is good. The effect here is
just that agetty would fail to start upon reconfigure, but that’s an
acceptable limitation IMO.