Le Wed, Mar 27, 2024 at 10:39:36AM +0100, Adrien 'neox' Bourmault a écrit :
> Le mardi 26 mars 2024 à 18:58 +0100, Fulbert a écrit :
> > I forgot to mention : LUKS version 2 with PBKDF: argon2i. I remember reading
> > that guix supported LUKS2 except for /boot… but I might be wrong. At
> > least it
> > has worked for month on my computer until guix d5f857a (22 mar 2024).
> >
> > So, new question, do I have to convert to LUKS1 ?
> >
> > Le 26.03.24 à 16:15, Fulbert a écrit :
> >
> > > Hello! Seeking some help/suggestions to solve a problem preventing
> > > my system to boot up, which was working properly up to guix 9b84b36
> > > (21 mar 2024) (note: I confess that my system is not totally pure).
> > >
> > > Starting with guix d5f857a (22 mar 2024) up to my latest guix pull
> > > with 1415ea7, the **system hangs during boot**, and it does before
> > > anything is written to /var/log/messages. So, using a video capture
> > > of the screen at boot, I was abble to catch :
> > >
> > > #+begin_src boot
> > > shepherd[1]: Exception caught while while starting
> > > device-mapping-luks-homes:
> > > (unbound-variable #f "Unbound variable: "S" (bytevector?) #f)
> > > #+end_src
> > >
> > > … which appears to be the culprit ?!
> > >
> > > follows a long list of "shepherd[1]: Service XXX depends on YYY" and
> > > then
> > > #+begin_src boot
> > > shepherd[1]: The following services could not be started in the
> > > background:
> > >
> > > #+end_src
> > >
> > > From there : a blinking cursor and the only way out I found is
> > > CTRL-ALT-DEL, which triggers shepherd to stop some services. After
> > > that I have to shutdown using hardware button.
> > >
> > > My system and its config.scm have not changed and I see nothing
> > > relevant, related to LUKS/dm-crypt, in `guix pull -l`.
> > >
> > > My LUKS is configured like so :
> > >
> > > (mapped-devices
> > > (list
> > > (mapped-device
> > > (source (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))
> > > […]
> > >
> > > Any help would be appreciated.
> > >
> >
>
> Hi everyone, the exact same thing happens to me too since d5f857a.
>
> I'm using a pure GNU Guix installation with my /home as a LUKS partition.
>
> My fs configuration :
>
> (file-systems (cons*
> (file-system
> (mount-point "/home")
> (device "/dev/mapper/crypthome")
> (type "ext4")
> (dependencies mapped-devices))
> (file-system
> (mount-point "/boot/efi")
> (device (uuid "A012-A17A" 'fat32))
> (type "vfat"))
> (file-system
> (mount-point "/")
> (device (uuid "dfaec018-b99b-4d34-a206-eec25b833c45" 'ext4))
> (type "ext4")) %base-file-systems)))
>
> Happy hacking!
> --
> Adrien Bourmault
> Maintainer, GNU Boot project
> Associate member, Free Software Foundation
> GPG : 393D4CC68136F39799DA75F295F65F55F682A17A
>
>
Hello Adrien and everyone,
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 starting device-mapping-luks-homes:
(unbound-variable #f "Unbound variable: "S" (bytevector?) #f)
#+end_src
Maybe it's worth mentionning that I have 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 "…")', just in case.
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… at least in my case… and I am surprised that we are only 2 to report
about this, here.
Transfering the /home data to a clear (unencrypted) partition is my current
workaround to this problem.
Any suggestion still welcome, but I suppose the next step should be to send a
bug report, in due form.
