Choosing full disk encryption with Leap 15.2 results in "minimal BASH-like interface"

Hi everyone!

I have been happily using OpenSuse Leap 15.1 for a while (XFCE4) also upgraded it to 15.2 without a problem.

Now…just recently I bought a 4 TB SSD (WD Red). After this I tried installing Leap 15.2 from the USB stick and the installation is generally working fine.

I choose guided setup, choose LVM and encryption, pick password, etc.

When the installation completes and reboots, I am greeted with the GRUB screen asking me for the encryption password.

I provide the password and it gives me the following prompt (not my screenshot, but identical except the Ubuntu part):

https://i.ytimg.com/vi/mnXI79j8iis/hqdefault.jpg

Now, I know my password is correct and I installed it multiple times.

To experiment, I also tried installing Fedora 33 with full disk encryption and it all works fine.

I also tried installing OpenSuse Leap 15.1, but it has exactly the same issue! It worked fine before.

Please help. I need this system up and running yesterday.

Thank you so much!

I get almost the same screen if I enter the wrong password – except it says “version 2.04”

I suggest you test whether you really have the right password.

Boot the installer to the rescue system. Use “fdisk -l” to identify the partition for the encrypted LVM.

Once you have identified that, try:

cryptsetup luksOpen /dev/sda5 cr_lvm

except replace “/dev/sda5” with the proper device name for the encrypted LVM.

This is just to test whether you really have the correct password. After checking that, you can shutdown or try rebooting. From the rescue system command line, use “shutdown -h now” to shutdown or “shutdown -r now” to reboot. Power-off is probably okay too, because your test won’t have written anything to the hard drive.

Which password?? user or root??

I assumed that this was a reference to the encryption password for the encrypted LVM.

Maybe but not clear what encryption is being used???:open_mouth:

I was referring to the lvm password. I am currently working on running the process.

When I do the above, it works fine from the rescue mode and I can see cr_lvm in /dev/mapper.

Any ideas?

Thank you for taking time to assist me.

The next possibility to check, is whether grub is even seeing that disk.

Looking at my test system, I entered a bad password to get that grub prompt.

At the grub prompt, I entered: ls

The response was:
(proc) (hd0) (hd0,gpt2) (hd0,gpt1)

That’s listing the partitions that it can see. Presumably “(proc)” is a virtual file system for grub processes. The others correspond to my single hard drive with two partitions.

Can you do something similar to see if you can determine whether grub is seeing your drive (the one where you installed opensuse).

And note: I’m testing in a virtual machine which I already had setup for other purposes.

Thank you for sticking with me.

When I run ls, I get the following output:


(lvm/system-root) (lvm/system-home)(lvm/system-swap) (crypto0) (proc) (hd0) (hd0,msdos1) (hd1) (hd1,gpt2) (hd1, gpt1) (hd2) (hd2,gpt2) (hd2,gpt1)

Please note, I also have another disk in my computer, but I did not touch it during the installation process.

I’m not sure what to make of that.

I think it means that the crypto is working, and grub is seeing inside your lvm. So something else is going wrong, but I’m not sure what.

Is this a UEFI system?

Yes, its UEFI. Thanks.

In GRUB CLI enter

set pager=1
set

It will print all environment variables in grub pausing at each full screen (you will need to press ENTER to continue). Post screenshot of each screen.

The long delay in replying is because of sleep.

I’ll now wait for your reply to arvidjaar, who is more familiar with grub issues than I am.

One possibility is that your BIOS could have limitations with a 4T hard drive, though I would not expect that if you are using UEFI. To boot your system, grub depends on the BIOS for disk operations. Once the system is up and running, the kernel handles I/O and BIOS limitations are usually not a problem.

Thank you for sticking with me!

Attached are the outputs of the commands set pager=1 and set.

I also include screenshots of my bios boot-related stuff.

You can find them here.

In addition to the above, I also created a Xubuntu bootable USB and booted into a live image.

From there I did cryptsetup /dev/sda2 lvm

Where sda2 is the encrypted volume belonging to OpenSuse (BTW, I enter the correct passphrase and it works as expected)

After doing that, the system automatically mounts two medias automatically (please see rescuetest screenshot in the above link):

  1. First media: Containing single directory named after my user name. Inside that directory there is nothing but the bin directory.
  2. Second media: containing the normal Linux directory structure (e.g., /dev/, /home/ (empty), /etc/, /tmp/, /boot/ etc.)

Do not know if this is useful.

Yes, the information that you provided is useful. It is consistent with my earlier guess, that grub (via BIOS) is not able to read your 4T disk.

Apart from that, it looks as if your installed system is intact.

Here’s a bit of my analysis.

Your first grub screen shows: cmdpath=(hd1,gpt1)/EFI/opensuse

That’s good. I get something similar on my local tests.

Your second grub screen shows: prefix=(hd1,gpt1)/boot/grub2
That’s bad. It should show: prefix=(lvm/system-root)/boot/grub2

So it has processed the line setting prefix. But it failed to find your root volume in the LVM.

So what can you do about it?

Suggestion 1: You could copy parts of “/boot” into the EFI partition, and boot your system that way. But it will be awkward and high maintenance, because you will have to repeat that copying after every kernel update.

Suggestion 2: Do a reinstall without the LVM.

In the reinstall, again go with the guided setup.

On the first screen of the guided setup, check the boxes to allow it to delete linux partitions and maybe other partitions as needed. Note that you can abort without changing anything if you don’t like the proposal.

On the next screen, choose encryption but do not choose an LVM setup.
On the next screen, select the option for a separate “/home”. And this one is important (I’ll explain why, a little later)

I just tested doing this, though I aborted before doing any actual install.
In my test, it setup a root partition, a home partition and a swap partition with all of then encrypted. Since it only asked once for an encryption key, I presume it used the same key for all.

What you will want to check, is that it puts all of these on your same disk (the 4T disk). If it does something you don’t like, you can abort the install and try again using the expert partitioner. But that is a bit harder to explain, so first see if this works.

Doing it this way, the root partition should be toward the start of the disk. You want it to be within the first 2T. The reason for a separate “/home” is related to this. If you do not use a separate “/home” then the installer will setup a huge root partition which will be most of the 4T in space, and you will have the same problem as with the LVM setup. With a separate “/home” that should not happen. Maybe grub won’t be able to read the home partition, but it doesn’t need to actually read that. You will probably end up with partition 2 as root, partition 3 as “/home” and partition 4 as swap.

grub was loaded from this path, so hd1,gpt1 must be ESP.

Your second grub screen shows: prefix=(hd1,gpt1)/boot/grub2

That is most likely wrong. /boot is expected to be on different partition than ESP.

That’s bad. It should show: prefix=(lvm/system-root)/boot/grub2

So it has processed the line setting prefix. But it failed to find your root volume in the LVM.

I am not sure what do you mean. Somehow grub image that was loaded contains wrong prefix. I guess at this point we need output of

efibootmgr -v
grep -v '^#' /etc/default/grub

where /etc/default/grub is from the root of installed system.

Suggestion 1:
Suggestion 2:

Suggestion 3 - simply reinstall bootloader from chroot. But having above output before doing it is certainly helpful.

I’m not sure how that would help.

Normally for UEFI systems, prefix is set in “/boot/efi/EFI/opensuse/grub.cfg”. I did think of asking for that, but I have never seen a case where that was wrong so it did not seem worth asking.

Thank you. I am currently trying suggestion 2. Hoping for the best. Will report once the installation completes.

Looks like you’re installed on BTRFS.
BTRFS volumes are similar to, but are not the same as LVM volumes.
So, your current efforts based on LVM volumes likely won’t lead anywhere.

Although tools like YaST work for both LVM and BTRFS volumes, be aware that LVM tools cannot be guaranteed to work on BTRFS volumes.

Here is the BTRFS FAQ on encrypted and encrypting BTRFS volumes, which is a good place to start.

https://btrfs.wiki.kernel.org/index.php/FAQ#:~:text=All%20data%20(except%20the%20boot,dm%2Dcrypt%20write%20barrier%20support.

TSU