GNU bug report logs - #70021
6f9d844 causes system hang right before GDM supposed to start

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: aurtzy <aurtzy <at> gmail.com>
Subject: bug#70021: closed (Closing: Duplicate report)
Date: Mon, 01 Apr 2024 08:32:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#70021: 6f9d844 causes system hang right before GDM supposed to start

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 70021 <at> debbugs.gnu.org.

-- 
70021: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70021
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: aurtzy <aurtzy <at> gmail.com>
To: 70021-done <at> debbugs.gnu.org
Subject: Closing: Duplicate report
Date: Mon, 1 Apr 2024 04:31:44 -0400

Another report which looks to be the same issue was also submitted here: 
https://issues.guix.gnu.org/70051

That one is more active, so I'll close this one and move my discussion 
there.

[Message part 3 (message/rfc822, inline)]

From: aurtzy <aurtzy <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: 6f9d844 causes system hang right before GDM supposed to start
Date: Tue, 26 Mar 2024 18:38:33 -0400

Hi!

I recently encountered an issue with my system hanging during the 
startup process, where it halts just before GDM is supposed to start.

Bisect has led to commit 6f9d844 (related issue: 
https://issues.guix.gnu.org/67649 ) being the culprit.

Context/workaround:

This appears to be an issue with code relating to mapped drives. Further 
inspection reveals my `device-mapping-cryptstorage` service fails to 
start, which is supposed to map my secondary encrypted drive. I 
currently work around this by commenting out the `file-system` entry 
that depends on this mapping before mounting it.

I managed to find the following line in /var/log/messages, which - if I 
understand the change correctly - points to `bytevector?` being now 
unavailable, causing the device mapping service to fail (and take the 
system with it?):

Mar 26 17:50:27 localhost vmunix: [   24.680761] shepherd[1]: Exception 
caught while starting device-mapping-cryptstorage: (unbound-variable #f 
"Unbound variable: ~S" (bytevector?) #f)

Best,

aurtzy

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.