installation with LUKS/cryptsetup - installer gives error code -3034

Hello everyone,

I’m attempting to re-install OpenSUSE - this time I was trying to use either of the following scenarios:

  1. sda1 [ext4 => “/boot”], sda2 [LUKS => BTRFS => “/”, etc]
  2. just sda1 [LUKS => BTRFS => “/”, “/boot”, etc]

In both cases installer throws error code -3034 at me, saying the following [also, screenshot attached]:

"Failure occured during following action:
configuring encrypted DM device X

VOLUME_CRYPTSETUP_FAILED

System error code was - 3034

Do you want to continue anyway?"

When I hit “yes”, it only installs regular BTRFS without any encryption.

https://i.imgur.com/BiUqrr9.png

Any clues? Thanks in advance!

PS I thought OpenQA checks all imaginable configurations … but mine seem quite exotic, I suppose?

Regards,

  • marc

I have the same behavior with OpenSUSE Leap 42.3 :frowning:

I tried to install using an encrypted LVM BTRFS volume including /boot on it. I had the same error, I can abort it or continue. If I continue, OpenSUSE is installed without any encryption.

EDIT: I have Lenovo Thinkpad T470s.

I know this problem too well …
My recommendation is to use a live system and prepare the disk in advance with encrypted partitions.
You can find a good howto in the Arch Wiki:
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system

Hendrik

Well, ok … as a long time Slack/Arch/Debian/BSD user I finally managed to do it, but it wasn’t via official installer, which is * saddening * :frowning:

Here’s procedure for anyone interrested [should be done via chrooted environment]:

We’d need another Linux installation on the same PC, or livecd/liveusb:

  1. Install the system as usual [in this case to sda5 partition], on a single disk formatted to whatever filesystem you like.
  2. Copy the system to an external location [directory] temporarily:

mkdir /tmp/mnt
mount /dev/sda5 /tmp/mnt
mkdir /mnt/data/temporary_dir
cp -ax /tmp/mnt/. /mnt/data/temporary_dir/.
umount -lf /tmp/mnt

  1. Prepare partition by encrypting it: [this will use strong twofish algorithm]

cryptsetup -y --cipher twofish-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda5

  1. Open LUKS device, format it and mount it:

cryptsetup luksOpen /dev/sda5 opensuse-rfs_decrypted
mkfs.btrfs /dev/mapper/opensuse-rfs_decrypted
mount /dev/mapper/opensuse-rfs_decrypted /tmp/mnt

  1. Copy the OS back to now-encrypted partition:

cp -ax /mnt/data/temporary_dir/. /tmp/mnt/.

  1. Chroot into new system:

cd /tmp/mnt
mount -t proc proc /tmp/mnt/proc/
mount --rbind /sys /tmp/mnt/sys/
mount --rbind /dev /tmp/mnt/dev/
chroot /tmp/mnt /bin/bash

then add the info of the encrypted partition to crypttab:

/etc/crypttab:

opensuse-rfs_decrypted /dev/sda5 none luks

… and update fstab as well:

/etc/fstab:

/dev/mapper/opensuse-rfs_decrypted / btrfs rw,errors=remount-ro 0 1

Finally, update initrd to include LUKS hooks:

[remove old initrd from /boot,then:] mkinitrd

Edit grub config to include full boot hooks: [this will make grub to ask about LUKS password twice - before boot menu appears and later during regular system boot]

/etc/default/grub:

GRUB_ENABLE_CRYPTODISK=“y”

Install grub:

grub2-install --root-filesystem=/ /dev/sda

Update grub:

grub2-mkconfig -o /boot/grub2/grub.cfg

  1. exit chrooted environment and unmount partition, then close encrypted device and reboot the system:

exit

umount -lf /tmp/mnt
cryptsetup luksClose opensuse-rfs_decrypted
reboot

===
To be honest, I think it is a shame that OpenSUSE installer has such limited installation options. It generally expects you to install the system without an encryption, as choosing installation on a LUKS device fails miserably no matter which encrypted scheme you choose … I might add that this is NOT the case in - for example - Debian, on which I have also checked it. Things just work there.

Also, as a side note: default BTRFS installation without encryption works, but then it does NOT allow you to boot into other snapshots [boot process hangs and timeouts on various systemd services]. BUT … that is a whole other topic which I won’t discuss here.

Anyhow, I hope someone will find this short howto useful. It does what I wanted [simple root filesystem snapshots done manually, lack of snapper support, as snapper seems to be NOT working properly, and default BTRFS subvolume scheme is bad [just take a look at postgresql, etc subvols, which most of you won’t even use on a desktop/workstation].

I have never experienced this problem myself and apparently openQA also never hits this issue as well so fixing it depends on those who do experience it to troubleshoot and provide useful information what is required to reproduce the issue. My guess is that it is related to pre-existing disk setup which is not correctly removed when re-partitioning disks.

I’d be more than happy to report this issue to hopefully solve it for all.
Where would be the best to report it?

PS it is really strange that such trivial operation as installation on an encrypted device gives so much headaches. I’m quite shocked it went almost unnoticed for so many years. Perhaps OpenSUSE users do not tend to use such setup for stronger system security? but if so, then why does this feature even exist in the installer?

For bugs: Bugzilla Main Page
same username/password as here.

And please give a step by step explanation of what you did.

PS it is really strange that such trivial operation as installation on an encrypted device gives so much headaches. I’m quite shocked it went almost unnoticed for so many years. Perhaps OpenSUSE users do not tend to use such setup for stronger system security? but if so, then why does this feature even exist in the installer?

Like @avidjaar tried to explain, it is not the normal experience. The conclusion that it does not work correct for everybody based on your experience might be a bit a quicky. And your bug report might help in finding out if there is something basically wrong, or it is something peculiar to your case that was never thought of and thus might be addresses as a result of your report.

Will do my best to report it … but guys - I have tried to install the system on an encrypted devices on a real machine [existing disks] and also VMs with clean disk … I don’t think it is something installer should break. If there’s an option to install on an encrypted device, then it definitely should work.
I wouldn’t say that user blaming is something we should be doing here.

That is NOT what I did.
The only thing I did was explaining that blaming the system because this hits everybody (cleary expressed by you in saying things like

'm quite shocked it went almost unnoticed for so many years.
might be wrong where you can be sure that people do use encrypted systems. And I am pretty sure that some of them are contributing members here, but maybe they are still on holiday. I still hope they can contribute to this thread.

Please see the difference between blaming the user and searching for an explanation why something goes wrong in a particular user’s situation (and we did not identify that particular situation either, thus there is a lot to investigate). When I would think you were to blame, I would not have encouraged you to make a bug report.

I’m not completely clear what you are trying to do.

It looks as if you wanted an encrypted root partition. But that is not a supported option for install. Yes, you can get it by installing unencrypted, then backup and encrypt later, rebuild the “initrd” and reinstall booting. But it is tricky to get that right.

What is supported, is to install to an encrypted LVM. Typically, the LVM would contain volumes for root, home and swap. However, you can have an encrypted LVM with just a root volume inside. And that’s pretty close to encrypted root partition, and is actually supported.

I normally use an encrypted LVM with root, home, swap volumes. I usually prepare the LVM before I start the install (maybe boot to a live Tumbleweed rescue system to set it up). But I have also done it preparing the LVM during the install (expert partitioner). Doing it all during install is more confusing (in my opinion) than preparing the LVM before starting the install.

It may have been in the past, but with current Tumbleweed it is just one checkbox on initial proposal screen.

Yes, that’s easy enough.

I guess I should have been clearer that I was talking about doing something other than the default encrypted LVM setup.

Well, that’s exactly what I was trying to do with various filesystems. I was simply trying to use separate boot partition and root filesystem on top of encrypted LVM.
To make this clear:

sda1 - /boot
sda2 - encrypted LVM [/dev/opensuse-rfs_decrypted]

That’s basically all I wanted the installer to do, but it failed … no matter which filesystem I was selecting as a root filesystem “/”] - ext4/btrfs, etc].

Also, I did not really give up on OpenSUSE - in fact, I am still using it and will continue to do so, as - so far - it seems to be more stable than Debian, which I also use. I have my awesome setup now, where I have btrfs for “/”, which sits on encrypted LVM [opensuse-rfs_decrypted]. This works great, but I had to add some kernel parameters to /etc/default/grub to mitigate performance problems with recent disclosure of Meltdown/Spectre bug. Plus, some BTRFS tweaks as mounting options and I am PERFECTLY happy with OpenSUSE. And I am not affraid to do an upgrade [finally!].

Thanks for your help.

I’m just testing that now.

The installer proposed partitioning.

On that screen, there’s a button for “Edit proposal settings”.
I click that.

I then check the box “Encrypted LVM based proposal”
I also set root file system to use “ext4” and home file system to use “ext4”.

Then it gives a new proposal. However, unfortunately, it does not use as separate “/boot”. The effect of no separate “/boot” is that you have to enter the encryption password twice (once for grub, once for the booted kernel).

The other option is to click the button for “Create Partition Setup”.

If you do that, then you have to do it all in the expert partitioner. You can start with “/boot” at a reasonable size. I’ve been using 500M recently. For a UEFI box, first create the EFI partition (if it doesn’t already exist), and then “/boot”. After that, put the rest into a single partition, and set it to not be formatted. When I last tried that, the partitioner marked it as an LVM. You can then set it to be encrypted. And, after that, you have to click on the logical volume setup in the partition.

In the logical volume setup, you have to first use “Add” to create a new physical volume. You give it a name, and add the encrypted partition. After that, a series of “Add” to add volumes within that LVM structure. Typically, you will need root, home, swap.