Failure to open LUKS devices from a Shepherd service

  • Done
  • quality assurance status badge
Details
2 participants
  • aurtzy
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
Merged with
L
L
Ludovic Courtès wrote on 7 Apr 23:30 +0200
(address . bug-guix@gnu.org)
87h6gcoo85.fsf@inria.fr
Hello,

Commit 6f9d844d2ece7b369d17bbe678978462425f869c led to a regression:
when a ‘luks-device-mapping’ mapped device is opened from a Shepherd
service (for instance a ‘device-mapping-XXX’ service created by
‘device-mapping-service-type’ because, say, /home is a separate LUKS
partition), said service fails to start with:

Unbound variable: bytevector?

This is the ‘bytevector?’ referred to in ‘open-luks-device’.

As a result, the system just hangs at boot time because that
‘device-mapping-XXX’ service fails to start.

Ludo’.
L
L
Ludovic Courtès wrote on 7 Apr 23:54 +0200
(address . 70266@debbugs.gnu.org)
87cyr0on3d.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (10 lines)
> Commit 6f9d844d2ece7b369d17bbe678978462425f869c led to a regression:
> when a ‘luks-device-mapping’ mapped device is opened from a Shepherd
> service (for instance a ‘device-mapping-XXX’ service created by
> ‘device-mapping-service-type’ because, say, /home is a separate LUKS
> partition), said service fails to start with:
>
> Unbound variable: bytevector?
>
> This is the ‘bytevector?’ referred to in ‘open-luks-device’.

This is a situation with a non-top-level ‘use-modules’.

The problem can be illustrated like this:

Toggle snippet (38 lines)
$ cat ~/src/guile-debugging/non-top-level-use-modules.scm
;; (define-module (xxxx))

(define (foo x)
(use-modules (rnrs bytevectors)) ;bad!!
(bytevector? x))

;; (pk '-> (foo (call-with-input-string "#vu8(1 2 3)" read)))

(pk 'foo foo)

$ guild compile -O1 ~/src/guile-debugging/non-top-level-use-modules.scm
/home/ludo/src/guile-debugging/non-top-level-use-modules.scm:3:3: warning: possibly unbound variable `bytevector?'
wrote `/home/ludo/.cache/guile/ccache/3.0-LE-8-4.7/home/ludo/src/guile-debugging/non-top-level-use-modules.scm.go'
$ guile
GNU Guile 3.0.99-git
Copyright (C) 1995-2024 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,m(sdf)
scheme@(sdf)> ,use(guile)
scheme@(sdf)> (load-compiled "/home/ludo/.cache/guile/ccache/3.0-LE-8-4.7/home/ludo/src/guile-debugging/non-top-level-use-modules.scm.go")

;;; (foo #<procedure foo (x)>)
$1 = #<procedure foo (x)>
scheme@(sdf)> ,m(guile-user)
scheme@(guile-user)> ($1 123)
;;; <stdin>:7:1: warning: possibly unbound variable `$1'
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
Unbound variable: bytevector?

Entering a new prompt. Type `,bt' for a backtrace or `,q' to contin

‘use-modules’, when used this way, loads the specified modules in
(current-module) at that point (at run time). If you change what the
current module is, as I did above, then it breaks.

Ludo’.
A
L
L
Ludovic Courtès wrote on 8 Apr 01:13 +0200
control message for bug #70266
(address . control@debbugs.gnu.org)
877ch8ojgf.fsf@gnu.org
merge 70266 70051
quit
L
L
Ludovic Courtès wrote on 8 Apr 01:43 +0200
Re: bug#70266: Failure to open LUKS devices from a Shepherd service
(name . aurtzy)(address . aurtzy@gmail.com)
87wmp8n3h4.fsf@gnu.org
Hi aurtzy,

aurtzy <aurtzy@gmail.com> skribis:

Toggle quote (5 lines)
> 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

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: <mapped-device-type> can specify modules to import.

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

Thanks,
Ludo’.
A
A
aurtzy wrote on 8 Apr 03:05 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
a0e3d327-822e-4c8e-84cb-37f91369621c@gmail.com
Hi Ludo',

On 4/7/24 19:43, Ludovic Courtès wrote:
Toggle quote (10 lines)
> 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: <mapped-device-type> 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
L
L
Ludovic Courtès wrote on 8 Apr 14:19 +0200
control message for bug #70266
(address . control@debbugs.gnu.org)
87jzl8qc73.fsf@gnu.org
severity 70266 important
quit
L
L
Ludovic Courtès wrote on 8 Apr 14:19 +0200
Re: bug#70266: Failure to open LUKS devices from a Shepherd service
(name . aurtzy)(address . aurtzy@gmail.com)
87le5oqc7b.fsf@gnu.org
Hi,

aurtzy <aurtzy@gmail.com> skribis:

Toggle quote (14 lines)
> 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: <mapped-device-type> 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!

Awesome, thanks for confirming, and apologies for introducing this
regression in the first place!

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 70266@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 70266
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch