emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#70051: closed (guix system hangs on boot with LUKS /home partition)


From: GNU bug Tracking System
Subject: bug#70051: closed (guix system hangs on boot with LUKS /home partition)
Date: Mon, 08 Apr 2024 12:20:02 +0000

Your message dated Mon, 08 Apr 2024 14:19:04 +0200
with message-id <87le5oqc7b.fsf@gnu.org>
and subject line Re: bug#70266: Failure to open LUKS devices from a Shepherd 
service
has caused the debbugs.gnu.org bug report #70051,
regarding guix system hangs on boot with LUKS /home partition
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
70051: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70051
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: guix system hangs on boot with LUKS /home partition Date: Thu, 28 Mar 2024 12:24:57 +0100
Hello,

Up to guix 9b84b36, my system was properly booting with a LUKS2 partition
mounted on /home. Starting with guix d5f857a (22 mar 2024), the boot hangs on
the same system using the same configuration.scm file. The only way out I found
when it hangs is hardware shutdown. There are no avaible console nor ssh server
started to help troubleshoot and there is nothing written to /var/log/messages
when it hangs.

I have tried to transfer my /home data to a brand new LUKS1 partition, (as well
as removing pointers to the old LUKS2 partition in my config.scm, of course) and
the problem remains exactly the same, including those error messages (obtained 
with
a video capture of the screen at boot, after removing 'quiet' from the kernel
command line in grub) :

#+begin_src boot
shepherd[1]: Starting service device-mapping-luks-homes...
shepherd[1]: Service device-mapping-luks-homes failed to start.
shepherd[1]: Exception caught while while starting device-mapping-luks-homes: 
(unbound-variable #f "Unbound variable: "S" (bytevector?) #f)
#+end_src

Maybe it's worth mentionning that I have then tried one configuration of the
'mapped-device' with 'luks-device-mapping' and another one with
'luks-device-mapping-with-options #:keyfile "/…"'. I also tried one
configuration with the 'source' declared in plain "/dev/..." and another one
declared with the luks '(uuid "…")', but this didnt change anything to the
"symptoms".

So, although I have learned in the process that LUKS2 is not yet fully
supported in guix, this problem also prevents booting using a LUKS1 /home
partition in my case.

Transfering the /home data to a clear (unencrypted) partition is my current
workaround to this problem.

Below is the configuration that has worked for several weeks, if not months, 
using my LUKS2 /home :

  (mapped-devices
    (list
      (mapped-device
        (source (uuid "<the uuid>"))
        (target "luks-homes")
        (type luks-device-mapping))))

  (file-systems
    (append
      (list
        […]
        (file-system (mount-point "/home")
                     (device (file-system-label "luks-homes"))
                     (type "ext4")
                     (dependencies mapped-devices))
        […]

Best regards and thanks for guix !



--- End Message ---
--- Begin Message --- Subject: Re: bug#70266: Failure to open LUKS devices from a Shepherd service Date: Mon, 08 Apr 2024 14:19:04 +0200 User-agent: Gnus/5.13 (Gnus v5.13)
Hi,

aurtzy <aurtzy@gmail.com> skribis:

> 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’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]