[Top][All Lists]

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

bug#30922: LUKS-encrypted root fails using device numbering, needs luksU

From: Ludovic Courtès
Subject: bug#30922: LUKS-encrypted root fails using device numbering, needs luksUUID
Date: Mon, 26 Mar 2018 15:37:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)


Jan Nieuwenhuizen <address@hidden> skribis:

> After booting I get
>     Device /dev/nvme0n1p1 doesn't exist or access denied

This message comes from ‘cryptsetup’.

The ‘init’ script for the config you posted does this:

--8<---------------cut here---------------start------------->8---
(boot-system #:mounts (map spec->file-system
                           (quote (("/dev/mapper/guix"
                                    device "/" "ext4" ()
                                    #f #t))))
             #:pre-mount (lambda ()
                           (and (let ((source "/dev/nvme0n1p1"))
                                  (use-modules (rnrs bytevectors)
                                               ((gnu build file-systems)
                                  (zero? (system*
                                          "open" "--type" "luks"
                                          (if (bytevector? source)
                                              (or (let loop ((tries-left 10))
                                                    (and (positive? tries-left)
(find-partition-by-luks-uuid source)
                                                               (sleep 1)
                                                               (loop (- 
tries-left 1))))))
                                                  (error "LUKS partition not 
found" source))
--8<---------------cut here---------------end--------------->8---

IOW, it does the right thing whether or not you’re using a UUID.

However, when using a UUID, it waits for the device to show up, whereas
otherwise it assumes the /dev node is already there and invokes
‘cryptsetup’ right away.

We should fix that and generalize the wait-for-device loop, which
already exists in a couple of instances.

There are connections with <https://bugs.gnu.org/30604>.


reply via email to

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