Wed 02 Mar 2016 11:07:44 AM UTC, comment #13:
My update only meant that it's not a blocker for 2.02. Nothing else
|
Wed 02 Mar 2016 10:56:14 AM UTC, comment #12:
I see the update. Excellent.
It's my intention to have my volume group span multiple PVs so as to avoid constant modifications.
Looking forward to the update on the debian repo.
|
Thu 11 Feb 2016 09:51:18 AM UTC, comment #11:
Volume groups can span multiple physical volumes. The way I understood LVM was it was meant to allow physical drives to be used seamlessly and partitions resized without worrying about where things landed.
The most recent version of grub on Debian demands sdb1 be activated or it refuses to boot. sdb1 has a keyfile so that's not an option.
I'd rather not jump through hoops and with multiple VGs. The current version of grub on Debian is just confused by multiple PVs.
So you're saying I should try the upstream grub?
|
Thu 11 Feb 2016 09:33:25 AM UTC, comment #10:
You misunderstand how LVM works. If you want two devices to be independent, you need to create two VGs, not one. You need all devices in VG to activate it. While it may be possible to start it in degraded mode, it is exception, not a rule.
As I said - using current upstream master you should be able to boot as long as your VG and /boot volume can be accessed with one available device only.
|
Thu 11 Feb 2016 07:22:14 AM UTC, comment #9:
Finally, got it.
I couldn't figure out why the command kept failing.
It doesn't like spaces between column names.
$ sudo pvs -o pv_name,vg_name
PV VG
/dev/mapper/sda5_crypt cryptvolume
/dev/mapper/sdb1_crypt cryptvolume
sda5 has a passphrase and contains /, /boot, /home, /var, /usr
sdb1 has a keyfile and will have mount points in /srv for all my different collections
|
Thu 11 Feb 2016 07:02:37 AM UTC, comment #8:
Please show output of command I asked you, not some random permutation of it.
To compile current master clone sources (https://savannah.gnu.org/git/?group=grub), then do
./autogen.sh
./configure ...
make
Default is to compile for i386-pc, use --with-platform=efi if you have EFI. To ease installation you could use alternative grub directory --with-grubdir and/or --with-bootdir.
|
Wed 10 Feb 2016 07:08:13 PM UTC, comment #7:
Only sda5 is necessary to boot. The other drive is mounted after boot. I might even want to put the key on a flash drive in the future.
But here's the problem:
/boot is encrypted.
It does not have access to /boot/grub/grub.cfg until after I give it the passphrase for sda5 (hd0,msdos5).
What would be useful is for it do something like this:
Encrypted partition found hd0,msdos5.
Choose (P)assphrase, (E)xternal key, (N)etwork auth, (S)kip, (D)one: P
Enter passphrase:
Slot 0 opened
Encrypted partition found hd1,msdos1.
Choose (P)assphrase, (E)xternal key, (N)etwork auth, (S)kip, (D)one: S or D
Skipping mount
Or even better
Partitions found (* encrypted): hd0,msdo5 (h0m5), hd1,msdos1 (h1m1)
Enter list of partitions to access for boot (shortnames accepted): h0m5
Choose (P)assphrase, (E)xternal key, (N)etwork auth, (S)kip, (D)one: P
Enter passphrase:
Slot 0 opened
Also could embed small bare minimum configuration vars in boot sector
GRUB_BOOT_ACTIVATION_LIST="hd0,msdos5=passphrase:hd1,msdos1=external"
What do I need to set up on debian to test the GIT release?
|
Wed 10 Feb 2016 06:27:21 PM UTC, comment #6:
Well, there are several issues.
1. Malformed cryptomount line with multi-device disk. This was likely fixed by
commit 12bf55703940cde06448a1c1a19001556c1450f9
Author: Andrei Borzenkov <arvidjaar@gmail.com>
Date: Sat Mar 28 22:13:35 2015 +0300
do not emit cryptomount without crypto UUID
Feel free to open bug report for your distribution and point to this commit.
2. You have VG consisting of two devices. Both devices must be present (in general, we need all devices in VG to be able to use it). Unfortunately, as of now GRUB does not support use of keyfiles.
3. It still could be possible to access LV if it is completely contained on passphrase protected disk, but error in embedded config prevents entering normal mode. This was (hopefully) fixed in
commit 609c049dcc318fae3af1ba29f0ceb348172769f0
Author: Andrei Borzenkov <arvidjaar@gmail.com>
Date: Wed Dec 16 21:20:30 2015 +0300
kernel: print and reset grub_errno after each embedded config line
Are you willing to test current GIT?
|
Wed 10 Feb 2016 06:09:38 PM UTC, comment #5:
# pvs -o pv_name, /dev/mapper/sda5_crypt
PV
/dev/mapper/sda5_crypt
# pvs -o vg_name, /dev/mapper/sda5_crypt
VG
cryptvolume
# pvs -o pv_name, /dev/mapper/sdb1_crypt
PV
/dev/mapper/sdb1_crypt
# pvs -o vg_name, /dev/mapper/sdb1_crypt
VG
cryptvolume
|
Wed 10 Feb 2016 05:59:31 PM UTC, comment #4:
Oh, you have LVM on top. OK, what
pvs -o pv_name, vg_name
says?
|
Wed 10 Feb 2016 02:58:03 PM UTC, comment #3:
/boot/grub/grub.cfg
/etc/default/cryptdisks (does CRYPTDISKS_ENABLE=Yes have to also be included when /etc/default/grub has GRUB_ENABLE_CRYPTDISKS=y)
/etc/crypttab
/etc/fstab
attached
(file #36294, file #36295, file #36296, file #36297)
|
Wed 10 Feb 2016 02:17:08 PM UTC, comment #2:
Please attach full grub.cfg, /etc/fstab and /etc/crypttab (remove passwords it needed).
|
Wed 10 Feb 2016 09:04:15 AM UTC, comment #1:
Also grub.cfc puts the identifiers for the drives on separate lines. This might also be why it drops to prompt.
example:
insmod part_msdos
insmod part_msdos
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha1
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha1
insmod lvm
insmod ext2
sda5 cryptomount -u 5f81644689724590b81affe666ce17a9
sdb1 99edb069aaef4b1dbf60449a445335e4
|
Wed 10 Feb 2016 08:55:05 AM UTC, original submission:
I am using grub 2.02~beta2-36.
I have two drives.
Partitions /dev/sda5 and /dev/sdb1 are both encrypted. /dev/sdb1 uses a key, not a passphrase. Grub asks for a passphrase for /dev/sda5 and then /sdb1.
When it does not receive the key for /dev/sdb1 it drops to the grub> prompt and gives up.
It only needs to find /dev/sda5 to find the encrypted /boot.
When I disable the /dev/sdb1 partition it has no problem.
|