Generated grub.cfg does not support encrypted roots

DoneSubmitted by Ludovic Courtès.
Details
3 participants
  • Andreas Enge
  • Ludovic Courtès
  • Christopher Baines
Owner
unassigned
Severity
important
L
L
Ludovic Courtès wrote on 6 Nov 2015 16:52
(address . bug-guix@gnu.org)
87twozi0ql.fsf@gnu.org
As reported by 宋文武 athttps://lists.gnu.org/archive/html/guix-devel/2015-11/msg00096.html:
Follow the manual to setup encryted root, using the desktop.scm template, but at the final step, it failed with:
Path '/mnt/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting.
(can be reproduced by `grub-install /dev/sdb --boot-directory /mnt/boot')
After search, it seems that an un-encrypted boot partition is needed:
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Preparing_the_boot_partition
So, I run fdisk to add a boot partiotion, finally install finished!
But it can't boot, I have to mount the encrypted root in Grub's cmdline:
insmod cryptodisk insmod luks cryptomount hd0,msdos2
Ludo’.
L
L
Ludovic Courtès wrote on 29 Feb 2016 15:24
control message for bug #21843
(address . control@debbugs.gnu.org)
8760x7h9wj.fsf@gnu.org
severity 21843 important
A
A
Andreas Enge wrote on 8 Mar 2016 20:21
Re: bug#21843: Generated grub.cfg does not support encrypted roots
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160308192104.GA22722@solar
I tried the installation with unencrypted /boot, encrypted / using thefollowing snippet in the configuration file: (bootloader (grub-configuration (device "/dev/sda"))) (mapped-devices (list (mapped-device (source "/dev/sda2") (target "root") (type luks-device-mapping)))) (file-systems (cons* (file-system (device "/dev/mapper/root") (title 'device) (mount-point "/") (type "ext4") (needed-for-boot? #t)) (file-system (device "boot") (title 'label) (mount-point "/boot") (type "ext4") (needed-for-boot? #t)) %base-file-systems))
Grub did not start, as it did not find the kernel etc. in /gnu/store.
So I typed "c" at the grub menu (in text mode without the splash screen,which also resides in /gnu/store), and issued the following two commands: insmod luks cryptomount hd0,msdos2
This prompted me for the password a first time. The "insmod cryptodisk" wasnot necessary. There was a new device called "(crypto0)" now; "ls (crypto0)/"showed, among others, the /gnu directory.
Now I still needed to define the kernel; running "boot" was not enough.
I executed configfile (hd0,msdos1)/grub/grub.cfgand now obtained the normal grub menu (with the splash screen) and could nowboot as usual. I was prompted a second time for the password.According to the grub.cfg, grub searches for the kernel by file name anduses the device where it is found automatically as root. So the second timeit must also have searched (crypto0).

This can be automated; I just added the two lines insmod luks cryptomount hd0,msdos2to the top of grub.cfg, and the next time everything worked out of the box(with two password prompts: the first one in text mode before grub was visiblystarted, then the grub splash screen appeared, then during the normal boot).
The only difficulty here is the mapping between the mapped-device /dev/sda2and the grub device hd0,msdos2. We would need to determine this automaticallywhen creating the grub.cfg during the call to "guix system init".

Maybe UUIDs can help. The command crytsetup luksUUID /dev/sda2returns a hex string with dashes, in my case 1aa...-...This could be run during "guix system init" with the source field ofmapped-device.The grub manual at: https://www.gnu.org/software/grub/manual/html_node/Device-syntax.html#Device-syntaxmentions a device syntax such as (cryptouuid/123456789abcdef0123456789abcdef0)I tried replacing cryptomount hd0,msdos2by cryptomount cryptouuid/1aa...(without the dashes), but this did not work.The strange thing is that grub somehow knows this uuid; when I type cryptomount hd0,msdos2I am presented with the prompt Enter passphrase for hd0,msdos2 (1aa...):
So I am stuck here.

A first tentative solution would be to look for mapped-devices of typeluks-device-mapping that correspond to file-systems with needed-for-boot?set to #t, and then add the corresponding "cryptomount" lines to grub.cfg,with the obvious mapping sda->hd0, sdb->hd1,..., and 1->msdos1, 2->msdos2and so on.
This would not be perfect, but at least better than what we have now.
And the line "insmod luks" could be added unconditionally (or only in thepresence of a mapped-device of type luks-device-mapping).
Andreas
A
A
Andreas Enge wrote on 8 Mar 2016 20:33
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160308193309.GA2251@solar
What is needed are the following two lines at the beginning of grub.cfg:
insmod lukscryptomount -u 1aa...
where 1aa... is the result of "cryptsetup luksUUID /dev/sda2".
So the logic outlined in my previous message works:Determine the mapped-devices /dev/sdXY of type luks-device-mapping thatlead to a file-system with needed-for-boot? set to #t.Using cryptsetup luksUUID /dev/sdXYdetermine a corresponding uuid 12345...0.If any such mapped-device exists, add insmod luksas the first line of grub.cfg. For any such mapped-device, add a line cryptomount -u 12345...0right after that.
To simplify the logic, we could also move the needed-for-boot? parameterto mapped-device, or add such a parameter there.
Andreas
L
L
Ludovic Courtès wrote on 10 Mar 2016 10:17
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
8760wuy9mt.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (19 lines)> What is needed are the following two lines at the beginning of grub.cfg:>> insmod luks> cryptomount -u 1aa...>> where 1aa... is the result of "cryptsetup luksUUID /dev/sda2".>> So the logic outlined in my previous message works:> Determine the mapped-devices /dev/sdXY of type luks-device-mapping that> lead to a file-system with needed-for-boot? set to #t.> Using> cryptsetup luksUUID /dev/sdXY> determine a corresponding uuid 12345...0.> If any such mapped-device exists, add> insmod luks> as the first line of grub.cfg. For any such mapped-device, add a line> cryptomount -u 12345...0> right after that.
IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could alsopass the device name, in GRUB format, which would allow us to use thesame strategy as in ‘grub-root-search’ in (gnu system grub)… with thedifficulty that we’d have to be able to map Linux /dev node names toGRUB device names.
Furthermore, to allow users to specify a LUKS UUID as the ‘source’ oftheir ‘mapped-device’ form, as in:
(mapped-device (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID (target "root") (type luks-device-mapping))
we’d have to extend <mapped-device-kind> with a method to resolve UUIDs(in this case, to map a UUID to a /dev node.)
Thoughts? Looks like more work than I initially thought.
Besides, I think we should only worry about the mapped device(s) thatback / and /boot, rather than any mapped device, no?
Thanks for looking into it,Ludo’.
A
A
Andreas Enge wrote on 10 Mar 2016 10:48
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160310094837.GA30197@solar
On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:
Toggle quote (3 lines)> IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also> pass the device name, in GRUB format
Yes, but my idea was that the uuid is something we can determineat instantiation time. If the mapped device is /dev/sdd3, we can run (system* "cryptsetup" "luksUUID" "/dev/sdd3")and obtain the uuid.
I suppose we could also use the grub device (hd3,msdos3) in this case,but I do not know what is the mapping between /dev nodes and these devices,and if it is actually a function that could be computed from the file namein /dev only or not.
Toggle quote (7 lines)> (mapped-device> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID> (target "root")> (type luks-device-mapping))> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs> (in this case, to map a UUID to a /dev node.)
We can also let the users do the work (and document this in the manual),by having them supply all the informatin:
(mapped-device (source "/dev/sdd3") (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44") ;LUKS UUID (target "root") (type luks-device-mapping) (needed-for-boot? #t))
Toggle quote (3 lines)> Besides, I think we should only worry about the mapped device(s) that> back / and /boot, rather than any mapped device, no?
This could either be solved by determining which file systems haveneeded-for-boot? #t and determine the corresponding mapped devices,or by adding such a parameter for the mapped-device as in my suggestionabove.
Or we do it all automatically for / and /boot and drop the parameterneeded-for-boot? everywhere.
Andreas
L
L
Ludovic Courtès wrote on 11 Mar 2016 09:45
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
87r3fh4d4c.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (9 lines)> On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:>> IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also>> pass the device name, in GRUB format>> Yes, but my idea was that the uuid is something we can determine> at instantiation time. If the mapped device is /dev/sdd3, we can run> (system* "cryptsetup" "luksUUID" "/dev/sdd3")> and obtain the uuid.
Hmm yeah, but we don’t even do that for regular partitions.
Toggle quote (5 lines)> I suppose we could also use the grub device (hd3,msdos3) in this case,> but I do not know what is the mapping between /dev nodes and these devices,> and if it is actually a function that could be computed from the file name> in /dev only or not.
‘grub-probe’ should know, I think.
Toggle quote (17 lines)>> (mapped-device>> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID>> (target "root")>> (type luks-device-mapping))>> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs>> (in this case, to map a UUID to a /dev node.)>> We can also let the users do the work (and document this in the manual),> by having them supply all the informatin:>> (mapped-device> (source "/dev/sdd3")> (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44") ;LUKS UUID> (target "root")> (type luks-device-mapping)> (needed-for-boot? #t))
I think the goal of providing a UUID is to not have to worry about theactual device name (which could change).
The ‘needed-for-boot?’ flag should be unnecessary because it can beinferred from corresponding file systems, as is already the case.
Toggle quote (11 lines)>> Besides, I think we should only worry about the mapped device(s) that>> back / and /boot, rather than any mapped device, no?>> This could either be solved by determining which file systems have> needed-for-boot? #t and determine the corresponding mapped devices,> or by adding such a parameter for the mapped-device as in my suggestion> above.>> Or we do it all automatically for / and /boot and drop the parameter> needed-for-boot? everywhere.
We keep it only in ‘file-system’, I think.
Anyway, sounds like quite a bit of work here. :-)
Ludo’.
A
A
Andreas Enge wrote on 16 Mar 2016 21:40
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160316204000.GA8709@solar
On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:
Toggle quote (9 lines)> Furthermore, to allow users to specify a LUKS UUID as the ‘source’ of> their ‘mapped-device’ form, as in:> (mapped-device> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID> (target "root")> (type luks-device-mapping))> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs> (in this case, to map a UUID to a /dev node.)
I just read a bit of the cryptsetup manual; we do not need to do theresolution, in the above example we would have the line cryptomount -u cb67fc72-0d54-4c88-9d4b-b225f30b0f44(as discussed previously; it works at least without the dashes, we can alsotry to keep the dashes).And then it should be possible to open the device with cryptsetup luksOpen UUID=cb67fc72-0d54-4c88-9d4b-b225f30b0f44 rootThis looks for the given uuid in /dev/disk/by-uuid.
I wanted to give it a try with the installation image, but unfortunately itdoes not contain the directory /dev/disk.
Andreas
A
A
Andreas Enge wrote on 17 Mar 2016 14:14
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160317131435.GA12731@solar
On Wed, Mar 16, 2016 at 09:40:00PM +0100, Andreas Enge wrote:
Toggle quote (12 lines)> I just read a bit of the cryptsetup manual; we do not need to do the> resolution, in the above example we would have the line> cryptomount -u cb67fc72-0d54-4c88-9d4b-b225f30b0f44> (as discussed previously; it works at least without the dashes, we can also> try to keep the dashes).> And then it should be possible to open the device with> cryptsetup luksOpen UUID=cb67fc72-0d54-4c88-9d4b-b225f30b0f44 root> This looks for the given uuid in /dev/disk/by-uuid.> > I wanted to give it a try with the installation image, but unfortunately it> does not contain the directory /dev/disk.
I tried it out with an already installed (and reconfigured, but that shouldnot make a difference) GuixSD, and the above "cryptsetup" line works as well(with the dashes).
Andreas
L
L
Ludovic Courtès wrote on 16 Apr 2016 18:09
(address . 21843@debbugs.gnu.org)
878u0dfscg.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:
Toggle quote (6 lines)> Path '/mnt/boot/grub' is not readable by GRUB on boot.> Installation is impossible. Aborting.>> (can be reproduced by `grub-install /dev/sdb --boot-directory> /mnt/boot')
On this topic, see the story about ‘grub-probe’ at:
https://lists.gnu.org/archive/html/help-guix/2016-01/msg00118.html
Ludo’.
L
L
Ludovic Courtès wrote on 18 Apr 2016 01:29
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
87potnlsq5.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:
Toggle quote (11 lines)> Furthermore, to allow users to specify a LUKS UUID as the ‘source’ of> their ‘mapped-device’ form, as in:>> (mapped-device> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID> (target "root")> (type luks-device-mapping))>> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs> (in this case, to map a UUID to a /dev node.)
Commit ffba7d498d36618ad21af3961a1a685ae91bae57 makes it possible,building on ‘find-partition-by-luks-uuid’ added ina1ccefaa122df7c0045eda1fe6b65d83b65ed238.
(Tested on my system where /home is LUKS-encrypted.)
Ludo’.
L
L
Ludovic Courtès wrote on 27 Apr 2016 22:58
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
87y47ywyy4.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (5 lines)> What is needed are the following two lines at the beginning of grub.cfg:>> insmod luks> cryptomount -u 1aa...
The attached patch does exactly that when the ‘mapped-device’ source isa UUID, as is the case with the modified bare-bones.tmpl example:
Toggle diff (195 lines)diff --git a/gnu/system.scm b/gnu/system.scmindex 768ca9c..da41ba6 100644--- a/gnu/system.scm+++ b/gnu/system.scm@@ -210,6 +210,16 @@ as 'needed-for-boot'." (string=? (file-system-device fs) target))) file-systems))) +(define (file-system-mapped-device file-system devices)+ "Return the mapped-device among DEVICES that backs FILE-SYSTEM, or #f."+ (and (eq? 'device (file-system-title file-system))+ (string-prefix? "/dev/mapper/" (file-system-device file-system))+ (let ((name (string-drop (file-system-device file-system)+ (string-length "/dev/mapper/"))))+ (find (lambda (md)+ (string=? (mapped-device-target md) name))+ devices))))+ (define (operating-system-user-mapped-devices os) "Return the subset of mapped devices that can be installed in user-land--i.e., those not needed during boot."@@ -674,6 +684,15 @@ listed in OS. The C library expects to find it under "Return the file system that contains the store of OS." (store-file-system (operating-system-file-systems os))) +(define (grub-config-for-store-file-system os)+ (let ((md (file-system-mapped-device (operating-system-store-file-system os)+ (operating-system-mapped-devices os))))+ (if md+ (let* ((type (mapped-device-type md))+ (grub (mapped-device-kind-grub type)))+ (grub (mapped-device-source md) (mapped-device-target md)))+ '())))+ (define* (operating-system-grub.cfg os #:optional (old-entries '())) "Return the GRUB configuration file for OS. Use OLD-ENTRIES to populate the \"old entries\" menu."@@ -694,7 +713,8 @@ listed in OS. The C library expects to find it under #~(string-append "--load=" #$system "/boot") (operating-system-kernel-arguments os)))- (initrd #~(string-append #$system "/initrd"))))))+ (initrd #~(string-append #$system "/initrd"))+ (extra-lines (grub-config-for-store-file-system os)))))) (grub-configuration-file (operating-system-bootloader os) store-fs entries #:old-entries old-entries)))diff --git a/gnu/system/examples/bare-bones.tmpl b/gnu/system/examples/bare-bones.tmplindex 87e8d1e..b85593d 100644--- a/gnu/system/examples/bare-bones.tmpl+++ b/gnu/system/examples/bare-bones.tmpl@@ -13,9 +13,13 @@ ;; Assuming /dev/sdX is the target hard disk, and "my-root" is ;; the label of the target root file system. (bootloader (grub-configuration (device "/dev/sdX")))+ (mapped-devices (list (mapped-device+ (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))+ (target "foo")+ (type luks-device-mapping)))) (file-systems (cons (file-system- (device "my-root")- (title 'label)+ (device "/dev/mapper/foo")+ (title 'device) (mount-point "/") (type "ext4")) %base-file-systems))diff --git a/gnu/system/grub.scm b/gnu/system/grub.scmindex 45b46ca..60cc044 100644--- a/gnu/system/grub.scm+++ b/gnu/system/grub.scm@@ -114,7 +114,9 @@ (linux menu-entry-linux) (linux-arguments menu-entry-linux-arguments (default '())) ; list of string-valued gexps- (initrd menu-entry-initrd)) ; file name of the initrd as a gexp+ (initrd menu-entry-initrd) ; file name of the initrd as a gexp+ (extra-lines menu-entry-extra-lines ; list of string-valued gexps+ (default '()))) ;;;@@ -253,13 +255,14 @@ corresponding to old generations of the system." (define entry->gexp (match-lambda- (($ <menu-entry> label linux arguments initrd)- #~(format port "menuentry ~s {+ (($ <menu-entry> label linux arguments initrd extra-lines)+ #~(format port "menuentry ~s {~{~% ~a~} ~a linux ~a/~a ~a initrd ~a }~%" #$label+ (list #$@extra-lines) #$(grub-root-search store-fs #~(string-append #$linux "/" #$linux-image-name))@@ -268,22 +271,25 @@ corresponding to old generations of the system." (mlet %store-monad ((sugar (eye-candy config store-fs system #~port))) (define builder- #~(call-with-output-file #$output- (lambda (port)- #$sugar- (format port "+ #~(begin+ (use-modules (ice-9 format))++ (call-with-output-file #$output+ (lambda (port)+ #$sugar+ (format port " set default=~a set timeout=~a~%"- #$(grub-configuration-default-entry config)- #$(grub-configuration-timeout config))- #$@(map entry->gexp all-entries)+ #$(grub-configuration-default-entry config)+ #$(grub-configuration-timeout config))+ #$@(map entry->gexp all-entries) - #$@(if (pair? old-entries)- #~((format port "+ #$@(if (pair? old-entries)+ #~((format port " submenu \"GNU system, old configurations...\" {~%")- #$@(map entry->gexp old-entries)- (format port "}~%"))- #~()))))+ #$@(map entry->gexp old-entries)+ (format port "}~%"))+ #~()))))) (gexp->derivation "grub.cfg" builder))) diff --git a/gnu/system/mapped-devices.scm b/gnu/system/mapped-devices.scmindex 450b473..ddb6c8d 100644--- a/gnu/system/mapped-devices.scm+++ b/gnu/system/mapped-devices.scm@@ -22,7 +22,11 @@ #:use-module (gnu services) #:use-module (gnu services shepherd) #:autoload (gnu packages cryptsetup) (cryptsetup)+ #:autoload (gnu build file-systems) (uuid->string) #:use-module (srfi srfi-1)+ #:use-module (srfi srfi-34)+ #:use-module (srfi srfi-35)+ #:use-module (rnrs bytevectors) #:use-module (ice-9 match) #:export (mapped-device mapped-device?@@ -34,6 +38,7 @@ mapped-device-kind? mapped-device-kind-open mapped-device-kind-close+ mapped-device-kind-grub device-mapping-service-type device-mapping-service@@ -59,7 +64,9 @@ mapped-device-kind? (open mapped-device-kind-open) ;source target -> gexp (close mapped-device-kind-close ;source target -> gexp- (default (const #~(const #f)))))+ (default (const #~(const #f))))+ (grub mapped-device-kind-grub ;source target -> gexp list+ (default #f))) ;| #f ;;;@@ -121,10 +128,21 @@ #~(zero? (system* (string-append #$cryptsetup "/sbin/cryptsetup") "close" #$target))) +(define (grub-luks-device source target)+ (if (bytevector? source)+ (list "insmod luks"+ (string-append "cryptomount -u " (uuid->string source)))+ (raise+ (condition+ (&message+ (message (format #f "LUKS mapped-device source must be a UUID: ~s"+ source)))))))+ (define luks-device-mapping ;; The type of LUKS mapped devices. (mapped-device-kind (open open-luks-device)- (close close-luks-device)))+ (close close-luks-device)+ (grub grub-luks-device))) ;;; mapped-devices.scm ends here
A good way to test it (not as root!) is:
Toggle snippet (7 lines)$ ./pre-inst-env guix system reconfigure gnu/system/examples/bare-bones.tmpl/gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system/gnu/store/9l0dfdxj7ybck63r9zrgnxbyryn6f0kh-grub.cfg/gnu/store/myrc5cinlhpj2yilhzv5y0szz2ax2i6z-grub-2.00guix system: error: symlink: Mankas permeso: "/var/guix/profiles/system-192-link"
The generated grub.cfg whose name appears above has this entry:
Toggle snippet (9 lines)menuentry "GNU with Linux-Libre 4.5.2 (beta)" { insmod luks cryptomount -u cb67fc72-0d54-4c88-9d4b-b225f30b0f44 search --file --set /gnu/store/dd2qbz6a5pszwnzay3s8mm9yim531nz0-linux-libre-4.5.2/bzImage linux /gnu/store/dd2qbz6a5pszwnzay3s8mm9yim531nz0-linux-libre-4.5.2/bzImage --root=/dev/mapper/foo --system=/gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system --load=/gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system/boot initrd /gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system/initrd}
Now, I haven’t tested this in reality and would appreciate help here.
We may have to add the patch to ‘guix-devel’ in (gnu packagespackage-management) to test it.
Ludo’.
L
L
Ludovic Courtès wrote on 1 May 2016 23:29
control message for bug #21843
(address . control@debbugs.gnu.org)
871t5la2lw.fsf@gnu.org
tags 21843 patch
L
L
Ludovic Courtès wrote on 2 May 2016 00:07
Re: bug#21843: Generated grub.cfg does not support encrypted roots
(address . 21843@debbugs.gnu.org)
87vb2x8mac.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:
Toggle quote (2 lines)> Now, I haven’t tested this in reality and would appreciate help here.
I’m in the process of implementing automated tests for the installationprocess.
Ludo’.
C
C
Christopher Baines wrote on 26 Oct 2016 08:56
7778a48f-1d46-9fb6-dfa3-92e398f0bbeb@cbaines.net
On 01/05/16 23:07, Ludovic Courtès wrote:
Toggle quote (7 lines)> ludo@gnu.org (Ludovic Courtès) skribis:>>> Now, I haven’t tested this in reality and would appreciate help here.>> I’m in the process of implementing automated tests for the installation> process.
I've been looking at this bug, as I've got a new laptop which I would like to install GuixSD on, and I would like to use an encrypted root partition.
Regarding the system tests, it looks to me like they do exist now, but so far I've been unable to run them (I get an error related to hash mismatch of module-import-compiled, I want to try getting it to fallback, but first I need to work out where Guix is being invoked...).
L
L
Ludovic Courtès wrote on 23 Nov 2016 21:21
(name . Christopher Baines)(address . mail@cbaines.net)(address . 21843@debbugs.gnu.org)
877f7u6j7y.fsf@gnu.org
Hello!
(And apologies Christopher for not replying earlier!)
I’m happy to report that this issue is finally fixed inf7f292d359e0eb77617f4ecf6b3164f868ec1784!
The complete list of relevant commits is this:
Toggle snippet (12 lines)f7f292d * install: Enable "cryptodisk" handling in GRUB.b7d408e * mapped-devices: Use 'cryptsetup-static' in 'luks-device-mapping'.fe93383 * marionette: Add 'marionette-screen-text' using OCR.f25c9eb * marionette: Delay synchronization with the host's REPL.
[...]
106b389 * gnu: Add 'cryptsetup-static'.01f94cc * gnu: Add 'lvm2-static'.10da75d * gnu: grub: Add dependency on LVM2.
Without LVM2 support, ‘grub-install’ and ‘grub-probe’ would fail todetermine what to do with the LUKS-encrypted partition.
When using ‘cryptsetup’ instead of ‘cryptsetup-static’, we were pullingthe whole closure of ‘cryptsetup’ (105 MiB) in the initrd, which wasclearly unreasonable. ;-)
The guts was to come up with a test strategy that would work. Thedifficulty here is that we have to enter a passphrase early one in GRUB,and then once again once the kernel has booted, when ‘cryptsetup’ isinvoked from the initrd. At this point, we have no good communicationchannel with the hosts, hence the screenshots with OCR! (Idea stolenfrom NixOS’ own tests.)
You can run the test with:
make check-system TESTS=encrypted-root-os
Further testing welcome!
Ludo’.
L
L
Ludovic Courtès wrote on 23 Nov 2016 21:21
control message for bug #21843
(address . control@debbugs.gnu.org)
8760ne6j79.fsf@gnu.org
tags 21843 fixedclose 21843
?
Your comment

This issue is archived.

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