System can no longer be reconfigured

System can no longer be reconfigured

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

I can no longer reconfigure a system with any of these methods:

1. "guix deploy" which I use almost exclusively
2. "guix system reconfigure" after a recent pull
3. "./pre-inst-env guix system reconfigure" with a recent Git checkout.

Guix hangs during the system activation step.  Any ideas?

Kind regards
Felix

Re: System can no longer be reconfigured

[Ludovic Courtès]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> skribis:

> I can no longer reconfigure a system with any of these methods:
>
> 1. "guix deploy" which I use almost exclusively
> 2. "guix system reconfigure" after a recent pull
> 3. "./pre-inst-env guix system reconfigure" with a recent Git checkout.
>
> Guix hangs during the system activation step.  Any ideas?

Is it not hanging during Shepherd service upgrade?  (I think you
mentioned that elsewhere.)

If that is the case, (1) that is not preventing upgrade from happening
since that’s the very last step (it just means you’ll have to reboot),
and (2) it’s a shepherd-related bug for which perhaps there are clues in
/var/log/messages?

HTH!

Ludo’.

Re: System can no longer be reconfigured

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Ludo'

On Fri, Apr 19 2024, Ludovic Courtès wrote:

> Is it not hanging during Shepherd service upgrade?

Yes, thank you!  It was hanging during the Shepherd system upgrade due
to an invalid calendar-event specification.  In a service that uses both
#:days-of-month as well as #:days-of-week, I got confused because the
count starts with one in one, and with zero in the other. [1]

Thank you for your kind pointer in another forum! The issue is now
solved.

On this occasion, please allow me to mention for everyone's benefit that
your support level for the Shepherd is very generous---especially when
the complaints involve repeated user errors by the people bothering you.

> If that is the case, (1) that is not preventing upgrade from happening
> since that’s the very last step (it just means you’ll have to reboot),

Yes, but 'reboot' and 'halt' also stop working, which meant that I
issued 'sync' a few times and then, crossing my fingers, pressed the
reset button a few hundreds of a second later.  I wish there were a way
to force a reboot.

> (2) it’s a shepherd-related bug for which perhaps there are clues in
> /var/log/messages?

Thank you for that pointer, too.  I'm still learning about where to look
for error messages, whose destination is not always obvious to me.

Kind regards
Felix

[1] https://codeberg.org/lechner/system-config/commit/8639339dbd3ad4c51ceba239bf4aadc56223fb4a

Re: System can no longer be reconfigured

[John Kehayias]

Dear Felix et al,

On Sun, Apr 21, 2024 at 08:54 AM, Felix Lechner via \"Development of GNU Guix and the GNU System distribution.\" wrote:

> Hi Ludo'
>
> On Fri, Apr 19 2024, Ludovic Courtès wrote:
>
>> Is it not hanging during Shepherd service upgrade?
>
> Yes, thank you!  It was hanging during the Shepherd system upgrade due
> to an invalid calendar-event specification.  In a service that uses both
> #:days-of-month as well as #:days-of-week, I got confused because the
> count starts with one in one, and with zero in the other. [1]
>
> Thank you for your kind pointer in another forum! The issue is now
> solved.
>
> On this occasion, please allow me to mention for everyone's benefit that
> your support level for the Shepherd is very generous---especially when
> the complaints involve repeated user errors by the people bothering you.
>
>> If that is the case, (1) that is not preventing upgrade from happening
>> since that’s the very last step (it just means you’ll have to reboot),
>
> Yes, but 'reboot' and 'halt' also stop working, which meant that I
> issued 'sync' a few times and then, crossing my fingers, pressed the
> reset button a few hundreds of a second later.  I wish there were a way
> to force a reboot.
>

Not sure if this is what you did, but for anyone else that didn't know
this (like me, for many years!) there is the Magic SysRq Key to talk
directly to the kernel:
<https://en.wikipedia.org/wiki/Magic_SysRq_key>

I always remember "BUSIER" backwards as the sequence to push to safely
stop everything, sync disks, and reboot, without needing to use the
power button. Or the mnemonics: "raising elephants is so utterly
boring" or "reboot even if system utterly broken." Hopefully rarely
needed, but really handy when it is.

(I wrote a whole basic guide to killing things and these last keys:
<https://boilingsteam.com/kill-magic/>)

>> (2) it’s a shepherd-related bug for which perhaps there are clues in
>> /var/log/messages?
>
> Thank you for that pointer, too.  I'm still learning about where to look
> for error messages, whose destination is not always obvious to me.
>
> Kind regards
> Felix
>
> [1]
> <https://codeberg.org/lechner/system-config/commit/8639339dbd3ad4c51ceba239bf4aadc56223fb4a>