How2 install 12.3 encrypted LVM with TWO physical HD's

English Install/Boot/Login
1

Hello Forumers,

Due to a hard disk crash on my wonderful 12.1 machine I take the opportunity to do a fresh install with 12.3.
I have two empty Harddisks (each 2 TB) and want to install an encrypted LVM using both of these HD’s.

However, the installer only uses ONE of those two disks to install the encrypted LVM.
I found no way to make him use both. Using the expert partitioner within install does not give me the possibility to encrypt the LVM.

So I installed on just one HD and wanted to add the second HD later in Yast to that volume group. But I found no way for this. I tried to add a second volume group using the second HD, but then Yast chrashed.

After that, sadly sadly, Opensuse 12.3 does not support boot.crypto anymore I am forced to use LVM. OK, as I have no choice, I accept.

But hell, how can I use both of my disks encrypted (except the /boot partition)? Can anybody bring me on the right way? I googled with absolutely no usable results…

regards

Daniel

b.t.w. I tried various installations. I deleted all partitions. No success. I added each one unformated partition to the HDs. No success. I tried to add the second HD to the volume group (or adding a second volume group) without partition, with unformatted partition, and with formatted partition…

2

What exactly you call “encrypted LVM”? Please explain what configuration you try to achieve in details. Of course I can create two encrypted devices and volume group on top of them. This will give me fully encrypted LVM.

Using the expert partitioner within install does not give me the possibility to encrypt the LVM.

Yes, this is currently missing. Assuming we speak about the same. Please explain step by step what you do.

So I installed on just one HD and wanted to add the second HD later in Yast to that volume group. But I found no way for this. I tried to add a second volume group using the second HD, but then Yast chrashed.

Again your description is far too vague to be useful.

After that, sadly sadly, Opensuse 12.3 does not support boot.crypto anymore I am forced to use LVM.

Nobody was able to explain what is broken without boot.crypto. So far it is just town legend.

3

The ability to setup an encrypted LVM during install does seem limited.

I have been successful booting from a live CD (or, actually USB), and setting it up with Yast. Then, when installing at a later time, the installer will use the encrypted LVM, though that might require the expert partitioner.

I have not tried this with an LVM that spans two disks.

I’m not sure what “boot.crypto” problem you are having. As far as I know, systemd does the same thing.

I have a system setup with encrypted swap and encrypted “/home”, and it is working just fine.

One suggestion that I have seen: Setup your system with an encrypted LVM containing only the root file system. Then, after install, setup encrypted swap and encrypted “/home” separate from the LVM.[/QUOTE]

4

(I use the german version, so my translations will differ from what english installer actually shows…)

I boot the OS 12.3 installer dvd and go thru the steps until I can select the disk layout. There I choose “Use LVM”, “make separate /home” and check “encrypt LVM”.

The installer creates a partition table (that I can see after clicking “edit partition”): a small /boot, and encrypted LVM volume group, containing /, /home and swap. All on the first physical HD, the second remains unused (and can be seen under “unused devices”.

…

Again your description is far too vague to be useful.

I simply accepted the partition layout as the installer gave (see above) and finished the install. Booted and let the installation complete. Then rebooted, went to Yast and searched for a way to add the second physical HD to the encrypted volume group, so that it will be part of that and encrypted as well.

I can’t give you a list of all the ways I tried (too many), but I found no way to add the second physical drive.

Nobody was able to explain what is broken without boot.crypto. So far it is just town legend.

On my last system (12.1) I had a /boot partition, and encrypted my other partitions (not LVM) /root, /home, swap using cryptsetup, installed the filesystem on them, adjusted fstab etc. I needed to run boot.crypto so that at boot the password was asked. I had to enter the password only once and all three partitions were available for use.

I’d be more than happy if I can achieve the same without having to use LVM.

I read that systemd now takes the task of what earlier did boot.crypto, but I have not found any description of how to achieve, that at boot the password for the encrypted /root will be asked and then the other encrypted partitions (/home and /swap) will be mounted using the passphrase that is saved in /root.

I really googled a lot, but al I found was “systemd makes boot.crypto obsolete”. But I can’t find out what I have to do. This is the ONLY reason why I tried with LVM.

However my computer is still empty and I can try out what ever somebody suggests… If only in the end I have a fully encrypted system :slight_smile:

regards

Daniel

5

I also tried another approach with the installer:

After choosing “Use LVM” just as above, I clicked “create partitions”. There I created a /boot (to format with ext2), and a UNformatted partiton with remaining space on physical drive 1, and a UNformatted partition of the complete available space on physical drive 2. When creating those unformatted partitions I selected “encrypt device” and entered the passphrase, for both the same.

Then I created a volume group using “Volume manager”, added the two unformatted, encrypted partitions, and created /, /home and swap as logical volumes within that volume group. lt went fine. But at boot I am asked 3 times for the passphrase. First “Please enter LUKS passphrase”, after that “enter passphrase for disk 1” and the same for disk 2. Then it boots and works normal. But entering the passphrase 3 times is really too much…

6

On 2013-04-04 05:16, arvidjaar wrote:
>> After that, sadly sadly, Opensuse 12.3 does not support boot.crypto
>> > anymore I am forced to use LVM.
> Nobody was able to explain what is broken without boot.crypto. So far
> it is just town legend.

Nobody has documented how to do with systemd what we did with
boot.crypto, AFAIK.

For example, to manually mount an encrypted data partition, that is not
mounted at boot, I currently do:


> Telcontar:~ # rccrypto start cr_other
> Unlocking cr_other (/dev/disk/by-id/ata-ST3500418AS_9VM7ZCQQ-part10)
> Enter passphrase for /dev/disk/by-id/ata-ST3500418AS_9VM7ZCQQ-part10:
> [/sbin/fsck.xfs (1) -- /data/other] fsck.xfs -a /dev/mapper/cr_other
> /sbin/fsck.xfs: XFS file system.
> cr_other...                                             done
> Telcontar:~ #

This takes configuration data from fstab and /etc/crypttab. Notice that
the above sequence is also doing an fsck previous to mounting the partition.

How do I do all that with systemd?

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

7

Surprise - systemd takes configuration data from fstab and /etc/crypttab. So I once more try to ask - what does not work? The fact that systemd does not cache and reuse passphrase for multiple containers is known, but it hardly qualifies as “broken”.

8

On 2013-04-04 13:26, arvidjaar wrote:
> So I once more try to ask - what does not work?

Again: how do I manually mount an encrypted partition at a moment of my
choosing, not at boot? Ie, the command I posted, what is the systemd
equivalent? Including the fsck, of course.

> The
> fact that systemd does not cache and reuse passphrase for multiple
> containers is known, but it hardly qualifies as “broken”.

I would call that as a broken feature, yes. :slight_smile:

It means that you have to use a single LVM container instead of plain
partitions, or suffer multiple prompts for the same password.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

9

I don’t have a multi-disk setup where I could try that here.

What I would do, in that case, is run:


# mkinitrd

to rebuild the “initrd”. My experience with crypto, is that the initrd is built based on the currently running system. When this is done during install, it is done in a “chroot” environment, which doesn’t always get everything right. Another “mkinitrd” done after booting the real system will do a better job.

I don’t know if it will fix your problem. Normally, “plymouth” is supposed to handle the crypto, caching the passphrase. And the “initrd” is supposed to guide some of that.

10

Yes, this looks one of those YaST limitations (unrelated to systemd). And even when I try to create simple encrypted partition without using it for something else, it fails - not even partition itself is created.

It is possible during initial installation though - manually create (encrypted) partitions, create new volume group and add all these partition at once when creating new group. This works.

Care to file bug report about inability to extend volume group?

11

Thanks for the clear explanation.

Let me reword it. In addition to being used in the bootup procedure, “boot.crypto” could also be called as a script to mount a volume not normally mounted at boot (maybe with “noauto” in its "/etc/crypttab entry).

So “systemd” has taken over the bootup procedure, and boot.crypto is no longer needed for that. But you still want something to mount a volume at a later time.

Clearly, what is needed, is some sort of script probably to go in “/usr/sbin”. The use of “boot.crypto” for this was probably always a bad idea. However, some people have been doing it that way, and need an alternative.

Personally, I have always just used “cryptsetup” manually for that, so I never thought of scripting it. But that shouldn’t be particularly hard.

12 
linux-vmd4:~ # cat /etc/fstab
/dev/disk/by-id/md-uuid-6e84eb82:f000a5bb:6903dc87:58c42366 /                    ext4       acl,user_xattr        1 1
/dev/sdb1 /boot            ext2       defaults  0 0
/dev/sda1 /boot/efi            vfat       umask=0002,utf8=true  0 0
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
/dev/mapper/cr_sde1          /v1                  ext4       noauto,acl,user_xattr        1 2


linux-vmd4:~ # cat /etc/crypttab
cr_sde1         /dev/sde1            none       noauto

linux-vmd4:~ # systemctl status systemd-cryptsetup@cr_sde1.service
systemd-cryptsetup@cr_sde1.service - Cryptography Setup for cr_sde1
          Loaded: loaded (/etc/crypttab)
          Active: inactive (dead)
            Docs: man:systemd-cryptsetup@.service(8)
                  man:crypttab(5)
          CGroup: name=systemd:/system/systemd-cryptsetup@.service/cr_sde1


linux-vmd4:~ # systemctl status v1.mount
v1.mount - /v1
          Loaded: loaded (/etc/fstab)
          Active: inactive (dead)
           Where: /v1
            What: /dev/mapper/cr_sde1
          CGroup: name=systemd:/system/v1.mount


linux-vmd4:~ # systemctl start v1.mount
Please enter passphrase for disk VMware_Virtual_S (cr_sde1) on /v1! *****
linux-vmd4:~ # systemctl status v1.mount
v1.mount - /v1
          Loaded: loaded (/etc/fstab)
          Active: active (mounted) since Thu, 2013-04-04 16:32:11 MSK; 3s ago
           Where: /v1
            What: /dev/mapper/cr_sde1
         Process: 1726 ExecMount=/bin/mount /dev/mapper/cr_sde1 /v1 -t ext4 -o noauto,acl,user_xattr (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/v1.mount

Apr 04 16:32:11 linux-vmd4.site systemd[1]: Mounted /v1.
linux-vmd4:~ # systemctl status systemd-cryptsetup@cr_sde1.service
systemd-cryptsetup@cr_sde1.service - Cryptography Setup for cr_sde1
          Loaded: loaded (/etc/crypttab)
          Active: active (exited) since Thu, 2013-04-04 16:32:10 MSK; 6s ago
            Docs: man:systemd-cryptsetup@.service(8)
                  man:crypttab(5)
         Process: 1675 ExecStart=/usr/lib/systemd/systemd-cryptsetup attach cr_sde1 /dev/sde1 none noauto (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/systemd-cryptsetup@.service/cr_sde1

Apr 04 16:32:05 linux-vmd4.site systemd-cryptsetup[1675]: Set cipher aes, mod...
Apr 04 16:32:10 linux-vmd4.site systemd[1]: Started Cryptography Setup for c....

Unfortunately integration with LVM is incomplete, so in this case you will currently need to manually start all encrypted containers, do “pvscan; vgchange -a y” and then mount.

> The
> fact that systemd does not cache and reuse passphrase for multiple
> containers is known, but it hardly qualifies as “broken”.

I would call that as a broken feature, yes. :slight_smile:

Something needs to cache them. As 99% of users (on this forum) use GUI, GUI password agent looks like the most natural place to do it.

In 12.2 password agent was broken. Needs to retest in 12.3.

13

On 2013-04-04 14:36, nrickert wrote:
>
> robin_listas;2544401 Wrote:
>> For example, to manually mount an encrypted data partition, that is not
>> mounted at boot, I currently do: …
> Thanks for the clear explanation.
>
> Let me reword it. In addition to being used in the bootup procedure,
> “boot.crypto” could also be called as a script to mount a volume not
> normally mounted at boot (maybe with “noauto” in its "/etc/crypttab
> entry).

Yes, exactly that.

> So “systemd” has taken over the bootup procedure, and boot.crypto is no
> longer needed for that. But you still want something to mount a volume
> at a later time.

Yes.

> Clearly, what is needed, is some sort of script probably to go in
> “/usr/sbin”. The use of “boot.crypto” for this was probably always a
> bad idea. However, some people have been doing it that way, and need an
> alternative.

Yes.

I believe that “boot.crypto” was expanded to accommodate all those usage
patterns.

I have entered several bugzillas on this (systemv times) and AFAIK all
were resolved satisfactorily. For example, I requested this trivial
addition, and they did it:


> Telcontar:~ # which rccrypto
> /sbin/rccrypto
> Telcontar:~ # l /sbin/rccrypto
> lrwxrwxrwx 1 root root 23 Aug 19  2012 /sbin/rccrypto -> /etc/init.d/boot.crypto*
> Telcontar:~ #

They never told us, in those bugzillas, not to use the script…

> Personally, I have always just used “cryptsetup” manually for that, so
> I never thought of scripting it. But that shouldn’t be particularly
> hard.

I have thought of extracting the script from 11.4 and put it directly in
12.3, if it works. Yes, I know how to use “cryptsetup” manually, that’s
how I create my partitions. But the script is very convenient. It does
things like automatically running fsck on the filesytem when needed, for
instance!

I even have encrypted DVDs, XFS formatted, that I mount via that…

True, the desktop automount feature also does that, to some extent
(LUKS). Last time I tried, if you failed on entering the password, you
had to remove the media to try again. With the script, you simply run it
again. And it runs in plain text mode, of course, if needed.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

14

It could be converted into standalone utility in crypto utils package. Do you volunteer to maintain this script? :slight_smile:

15

arvidjaar wrote:
> Unfortunately integration with LVM is incomplete, so in this case you
> will currently need to manually start all encrypted containers, do
> “pvscan; vgchange -a y” and then mount.
>
>>> The
>>> fact that systemd does not cache and reuse passphrase for multiple
>>> containers is known, but it hardly qualifies as “broken”.
>> I would call that as a broken feature, yes. :slight_smile:
>
> Something needs to cache them. As 99% of users (on this forum) use GUI,
> GUI password agent looks like the most natural place to do it.

I’m confused and worried. Immediately above you were recommending using
the command line to enable LVM, but then you want to switch to some GUI
tool for passwords? What if it’s a headless server?

At least 99% of people on a web-based forum will be using a GUI (it
implies 1% are using lnyx to view the forum :slight_smile: but NNTP users may not be
using a GUI. And those who choose not to use the forum but use instead
the mailing lists are all openSUSE users too.

16

I did not recommend anything. I simply pointed out lack of proper integration of LVM into systemd, that’s all.

but then you want to switch to some GUI
tool for passwords?

Where did you find word “switch”? Where have you got “want” from?

I answered the question what is systemd equivalent to “rccrypto start crypto_device”. I am not even sure whether “rccrypto start” will itself configure LVM, so it is quite possible that systemd is on par here … checking 12.2 … no, it does not.

As for multiple password requests … please explain, when you get them when manually starting rccrypto? This is honest question - I do not know.

And multiple passphrases requests during boot are handled by Plymouth.

To summarize

  1. During boot with plymouth (default setup when you install openSUSE) plymouth handles multiple password requests. And it can also be used in text, non framebuffer, mode.
  2. There is full systemd replacement for “rccrypto start single-crypto-container” when LVM is not used.
  3. When LVM is used neither will work for full
    stack (from device to filesystem), but you still have systemd tool to setup each encrypted device one by one. Just like you would do it with rccrypto.
17

arvidjaar wrote:
> djh-novell;2544459 Wrote:
>> Immediately above you were recommending using
>> the command line to enable LVM,
>
> I did not recommend anything. I simply pointed out lack of proper
> integration of LVM into systemd, that’s all.
>
>> but then you want to switch to some GUI
>> tool for passwords?
>
> Where did you find word “-switch-”? Where have you got “-want-” from?

People can look at the thread and make their own mind up in context.

18

Sooo, back after x trials…

As said before, I already tried to create two encrypted partitions and add them to a freshly created volume group. This worked, but password was asked several times. I don’t want that.

So I tried a new approach (with, I hope, one missing last step…):

I installed OS 12.3 “normal”, without encryption:

/dev/sda1 ext2 /boot
/dev/sda2 swap
/dev/sda3 reiser /home (shall later be encrypted /)
/dev/sda4 reiser / (shall later be enrypted /home)
/dev/sdb1 reiser /home/fotos (will later be encrypted)

Then I encrypted the swap partition:

  • created a file /etc/crypt-swap.key with 2048 bytes of random content
  • swapoff /dev/sda2
  • cryptsetup -v --key-size 256 luksFormat /dev/sda2 /etc/crypt-swap.key
  • created a file /etc/crypttab and entered:
    cr_sda2 /dev/disk/by-id/…-part2 /etc/crypt-swap.key swap
  • changed fstab, commented out existing swap entry and added
    /dev/mapper/cr_sda2 swap swap defaults 0 0

rebooted, checked with “free” - and I worked, hurray!

So I wanted to go on with /dev/sda3 but could not unmount it, although at logon I selected “console” where I logged in as root. Still it said /dev/sda3 (current /home) is in use. So started the Live-DVD and encrypted what was /home:

  • mounted /dev/sda4 (current /) to /mnt/altsys
  • prepared /dev/sda3 with random bytes
  • cryptsetup -v --key-size 256 luksFormat /dev/sda3 /mnt/altsys/etc/crypt-swap.key
  • added a second key, that I will use to type manually
  • checked with cryptsetup luksDump /dev/sda3, all ok
  • opened the partition: cryptsetup luksOpen /dev/sda3 root
  • installed file-system: /sbin/mkfs.reiserfs -j /dev/mapper/root /dev/mapper/root
  • mounted the encrypted partition: mount /dev/mapper/root /mnt/root
    and copied current / to new encrypted part: rsync -ax -v /mnt/altsys/ /mnt/root/
  • changed entry in /mnt/root/etc/fstab:
    commented out current /home line, added
    /dev/mapper/root / reiserfs acl,user_xattr 1 1
    changed current / line to / home and changed the flag at the end from 1 to 2:
    und den jetzigen / Eintrag ändern nach /home und am Schluss 1 2 (statt bisher 1 1):
    /dev/disk/by-id/…-part4 /home reiserfs acl,user_xattr 1 2

So this is where I am stuck now.

  • How can I tell grub2 that it should use my /dev/mapper/root?
  • Do I have to enter something else to crypttab? What?
  • Do I have to run mkinitrd as I had to before? And then adjust something in the bootloader? What? Where?

At the moment it boots only to console and uses the old / on /dev/sda4, which seems quite logical to mee: from where should it know what I have changed… How to I tell it?

Please help! Thanks.

Daniel

19

Oh, stupid me! You go in YaST2 and say “Resize” for your Volume Group. The only feeble excuse for me is that I had only text mode YaST when I wrote it.

20

On 2013-04-04 16:46, arvidjaar wrote:

> As for multiple password requests … please explain, when you get them
> when manually starting rccrypto? This is honest question - I do not
> know.

On manual calls it is not cached. There is a trick, of course:


#  echo passphrase
passphrase
# rccrypto status cr_other
.....
# rccrypto status cr_otherbis
.....
#

Notice the space before the echo.

You copy-paste the password with the mouse - triple clicks selects the
line -, then paste it on each script call.

This is, of course, for manual mounting.

For automated mounting during boot there was another method I read about
for entering the passphrase just once if you had several partitions, but
I have never used it, personally. YaST did not set it up, it used the
encrypted LVM method instead. I read about the method in the security
mail list once.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)