bug#21843: Generated grub.cfg does not support encrypted roots

2016-11-23 Thread Ludovic Courtès
Hello! (And apologies Christopher for not replying earlier!) I’m happy to report that this issue is finally fixed in f7f292d359e0eb77617f4ecf6b3164f868ec1784! The complete list of relevant commits is this: --8<---cut here---start->8--- f7f292d * install:

bug#21843: Generated grub.cfg does not support encrypted roots

2016-10-26 Thread Christopher Baines
On 01/05/16 23:07, Ludovic Courtès wrote: l...@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

bug#21843: Generated grub.cfg does not support encrypted roots

2016-04-27 Thread Ludovic Courtès
Andreas Enge skribis: > 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 is a UUID, as is the case with the modified bare-bones.tmpl example:

bug#21843: Generated grub.cfg does not support encrypted roots

2016-04-17 Thread Ludovic Courtès
l...@gnu.org (Ludovic Courtès) skribis: > 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

bug#21843: Generated grub.cfg does not support encrypted roots

2016-04-16 Thread Ludovic Courtès
l...@gnu.org (Ludovic Courtès) skribis: > 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:

bug#21843: Generated grub.cfg does not support encrypted roots

2016-03-19 Thread Andreas Enge
On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote: > 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") >

bug#21843: Generated grub.cfg does not support encrypted roots

2016-03-19 Thread Andreas Enge
On Wed, Mar 16, 2016 at 09:40:00PM +0100, Andreas Enge wrote: > 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

bug#21843: Generated grub.cfg does not support encrypted roots

2016-03-10 Thread Andreas Enge
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

bug#21843: Generated grub.cfg does not support encrypted roots

2016-03-08 Thread Andreas Enge
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

bug#21843: Generated grub.cfg does not support encrypted roots

2016-03-08 Thread Andreas Enge
I tried the installation with unencrypted /boot, encrypted / using the following snippet in the configuration file: (bootloader (grub-configuration (device "/dev/sda"))) (mapped-devices (list (mapped-device (source "/dev/sda2") (target "root")

bug#21843: Generated grub.cfg does not support encrypted roots

2015-11-06 Thread Ludovic Courtès
As reported by 宋文武 at : 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