boot process waiting for removable HDD device

English Install/Boot/Login
1

Hi,
I am using Leap 15.0 with a separate boot partition (sda1) as well as root, home and swap filesystem inside an encrypted LVM (sda2).
Now, recently, I have formatted an external HDD with Yast. It had NTFS in the original state, but I changed the filesystem to ext4 (encrypted). If I connect this HDD I can access it fine (store data, read etc.). It appears as sdb1 after plugging in and typing the passphrase. After use, I can unmount, and it disappears.
However, during the boot process (when, of course, the removable HDD is not connected) “a start job is running …” that is looking for the LUKS device associated with the removable HDD and waiting for 1:30 min. This is annoying because the waiting period is longer than the boot process itself (I feel).
When I changed the formatting options in Yast, I also set the mounting options to “Do not mount device”, but when applying this, I see as message

The system might not be able to boot: 

 


  - Missing device with size equal or bigger than 2 MiB and partition id bios_boot


 Do you want to continue?

Well, there is the sda1 boot partition that has been used in the boot process all the time before the external HDD was formatted, so I figured that I wanted to continue. However, the “Do not mount device” does not seem to be persistent, because after rebooting (and connecting the HDD), the mounting options again show “Mount device” and a mount point.
Can anyone help me to find the reason for this behavior and a way to achieve the goal to eliminate waiting for the external, removable HDD during the boot process?
Thank you.

2

There are too many possibilities here.

I will make a wild guess. Try the command:

grep resume /etc/default/grub

That might need root (depends on the permissions for “/etc/default/grub”.

Does the output of that command contain a UUID which matches what you see in the “waiting for” message?

If not, I’ll try some other guesses. But this problem – picking the wrong swap partition for the “resume=” was an issue with Leap 15.0 (but fixed for Leap 15.1).

If my wild guess is right, then you need to change that UUID parameter to the UUID of your swap partition/volume. You can actually make that change with Yast bootloader, where you go to the kernel parameter tab.

3

Please look at the file /etc/fstab
If you see a line referring to your removable HDD, try to delete it and reboot.
Or you might open a terminal and post here between CODE tags (the # button above the editing line) the result of:

cat /etc/fstab

EDIT: Well, try nrickert’s suggestion first :wink:

4

Yes, I am aware that we might have many possibilities here. I’ll follow the suggestions already been made to narrow down the problem. Thanks for responding so quickly.
So, first as a response to nrickert’s mail:
The resume= parameter in /etc/default/grub refers to a different UUID, in fact exactly that one that is reported by the command

lsblk -o name,uuid,mountpoint

for swap. Thus, this can not be the reason.
Other guesses that can be tested?

5

Well, here is the contents of /etc/fstab:


/dev/system/root                           /      ext4  acl,user_xattr  0  1
/dev/system/home                           /home  ext4  defaults        0  2
UUID=e920a247-b5d0-4199-a405-b66d18258c0e  /boot  ext4  defaults        0  2

The uuid shown here for /boot is exactly that for the separate boot partition /dev/sda1. So, no obvious (at least for me) problem here.

6

The next one I would suggest checking, is “/etc/crypttab”. See if there is an entry there for a partition on the external drive. If there is, mark it as “noauto”.

Each line is supposed to have 4 columns. Recently the installer has been using only the first two columns. If you have to change anything in that file, then I recommend that you make it 4 columns for each entry. You can use “none none” for the third and fourth column if you don’t have anything else to put there.

If there’s an entry for a partition on your external drive, then put “noauto” in the fourth column for that entry. And, if you do make any changes to that file, run

mkinitrd

to appropriately update the “initrd” files.

7

OK, that did the trick! In fact /etc/crypttab is the only file in /etc that contains the uuid of the encrypted device. /etc/crypttab now looks like this

cr-auto-1  /dev/sda2 none none
cr_usb-WD_Elements_25A2_575832314141383035363331-0:0-part1  UUID=6f56ca7d-ae2d-4165-abbb-ed34369ff7c3 none noauto

where the first “none” means that no password file is supplied, and the passphrase has to be given after the device is plugged into the USB connection and before it can be accessed. That is exactly what I expect.

Thanks! But having done that: do I have to repeat this edit of /etc/crypttab and recreating the initrd file once a new kernel version is installed or is the change persistent?

8

That change should be persistent. So you should be set.