bug#70051: bug#70266: Failure to open LUKS devices from a Shepherd service

[aurtzy]

Hi Ludo',

On 4/7/24 19:43, Ludovic Courtès wrote:

Oops, sorry for not noticing it earlier!  (That was a hard-to-debug one
so kudos for the work you and others put in it.)

I pushed these two commits to address the problem:

   49f82fca41 mapped-devices: luks: Specify modules needed at the top-level.
   6062339156 mapped-devices:  can specify modules to 
import.

It works well in my tests but please let me know if something’s amiss.


Just pulled+reconfigured, and my machine boots just fine with the 
problem LUKS device being decrypted as expected again. Thanks!


Cheers,

aurtzy

bug#70266: Failure to open LUKS devices from a Shepherd service

[aurtzy]

Hi Ludo',

This bug has also been reported here: https://issues.guix.gnu.org/70051

I sent a patch that a few others have confirmed fixes the issue: 
https://issues.guix.gnu.org/70051#5


Cheers,

aurtzy

bug#70051: [PATCH] gnu: open-luks-device: Fix unbound variables.

[aurtzy]

It seems like `use-modules' never actually worked due to the way it is eval'd
by the Shepherd, and was only apparent after a change that prevented other
module imports from leaking into the namespace.  This is fixed by using direct
references instead.

* gnu/system/mapped-devices.scm (open-luks-device): Use direct references for
variables from other modules.

Fixes: https://issues.guix.gnu.org/70051

Change-Id: I993798e161c4b4fca6e8a4f14eea5042b184ebc9
---

Hi!

I encountered this issue as well, and think I've figured out what was
happening: `use-modules' appears to not work due to the way g-expressions are
evaluated by Shepherd, so after services became properly isolated in their own
modules, the variable references became no longer available.  There's a
comment further down in the file that seems to confirm this ("XXX: We're not
at the top level here...").

Can anyone confirm this patch works for them too?

Cheers,

aurtzy

 gnu/system/mapped-devices.scm | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/gnu/system/mapped-devices.scm b/gnu/system/mapped-devices.scm
index c19a818453..e46e2c7954 100644
--- a/gnu/system/mapped-devices.scm
+++ b/gnu/system/mapped-devices.scm
@@ -201,14 +201,12 @@ (define* (open-luks-device source targets #:key key-file)
#~(let ((source #$(if (uuid? source)
  (uuid-bytevector source)
  source))
-   (keyfile #$key-file))
-   ;; XXX: 'use-modules' should be at the top level.
-   (use-modules (rnrs bytevectors) ;bytevector?
-((gnu build file-systems)
- #:select (find-partition-by-luks-uuid
-   system*/tty))
-((guix build utils) #:select (mkdir-p)))
-
+   (keyfile #$key-file)
+   (bytevector? (@ (rnrs bytevectors) bytevector?))
+   (find-partition-by-luks-uuid (@ (gnu build file-systems)
+   find-partition-by-luks-uuid))
+   (system*/tty (@ (gnu build file-systems) system*/tty))
+   (mkdir-p (@ (guix build utils) mkdir-p)))
;; Create '/run/cryptsetup/' if it does not exist, as device locking
;; is mandatory for LUKS2.
(mkdir-p "/run/cryptsetup/")

base-commit: 6e2db85ca83528199a46b002d2592bd4bef017c8
-- 
2.41.0

bug#70021: Closing: Duplicate report

[aurtzy]

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.

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

[aurtzy]

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