Hang during boot: "A start job is running for dev-disk-by..."

English Applications
1

Hi all,

I recently bought an external USB harddrive, a Samsung T5.
I used Yast partioner to format the partition with ext4 and I selected to encrypt it.
I did not select to mount it. Then it asked me for a new password and everything went well.

The only problem now is that, if the USB harddrive is not connected to the pc, the pc hangs for 90 seconds with the message:

“A start job is running for dev-disk-by…”

After that it continues to boot and everything seems to work fine.

My question is how do I get rid of this delay?

The content of /etc/fstab:

UUID=fa4c4178-f3a2-42b2-ace2-2a4f9279b14d  /      ext4  acl,user_xattr  0  1
UUID=d8ccfe52-b211-499e-b54a-8bab811e8e01  /data  ext4  defaults        0  2

which is correct, these are the internal harddrives, not the external one.

This is part of the output of sudo journalctl:

systemd[1]: dev-disk-by\x2duuid-a8ddc1fd\x2db6c3\x2d4d1e\x2db97c\x2d6c04162e54fb.device: Job dev-disk-by\x2duuid-a8ddc1fd\x2db6c3\x2d4d1e\x2db97c\x2d6c04162e54fb.device/start timed out.
systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-a8ddc1fd\x2db6c3\x2d4d1e\x2db97c\x2d6c04162e54fb.device.
systemd[1]: Dependency failed for Cryptography Setup for cr_ata-Samsung_Portable_SSD_T5_S4B1NV0MB12949A-part1.
systemd[1]: Dependency failed for Local Encrypted Volumes.
systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
systemd[1]: systemd-cryptsetup@cr_ata\x2dSamsung_Portable_SSD_T5_S4B1NV0MB12949A\x2dpart1.service: Job systemd-cryptsetup@cr_ata\x2dSamsung_Portable_SSD_T5_S4B1NV0MB12949A\x2dpart1.service>
systemd[1]: dev-disk-by\x2duuid-a8ddc1fd\x2db6c3\x2d4d1e\x2db97c\x2d6c04162e54fb.device: Job dev-disk-by\x2duuid-a8ddc1fd\x2db6c3\x2d4d1e\x2db97c\x2d6c04162e54fb.device/start failed with r>

Thanks.

2

The logs that you show hint at crypto. But you did not mention any crypto.

What’s missing?

Is this disk mentioned in “/etc/crypttab”?

3

It is in the second line of his description :wink:

4

Somehow, I missed that.

Very likely, there is an entry in “/etc/crypttab”.

That entry should have 4 columns. However, it might only have two columns.

If there are only two columns, then insert “none” for the third column and “noauto” for the fourth column.

If there are already 4 columns, then change the 4th column from “none” to “noauto”, or insert “noauto,” at the beginning of that column entry (the options field). That will tell the system to ignore that entry during boot.

5

Thanks nrickert, tomorrow I’ll check and I’ll report back here.

6

I suggest nofail instead of noauto. That way it is subject to automount when connected.

7

Thank you everybody for your help and putting me in the direction of /etc/crypttab.
I simply deleted that file and everything works ok now. No need to have that file for external removable harddrives. Or am I overlooking something?

8

Yes, removing that file is probably okay. Or removing the relevant lines if there are other needed entries in the file. As far as I know, a file manager recognizes the LUKS header for the file system, and uses that to trigger for requesting the encryption key.

I would suggest that you run

mkinitrd

and then reboot to make sure all is okay. That’s because there is likely to be a copy of “/etc/crypttab” in the “initrd”. You would be testing that all works without that copy.

9

One last question, does this mean that there’s a bug in Yast partitioner?
I mean, how is one supposed to format & create an encrypted partition on a removable device without running into this trouble?

10

May be a somehere between “a bug” and “it is working as intended”?

It may be that creating encrypted file systems on removable devices was never the target of the design.

Remember that YaST is “only” a wrapper (not littaraly, but you can see it like that) around a lot of actions you can do of course with the “normal” Unix/Linux administration tools. And that it will never be able to cover all the combinations that all those tools offer. It will always be a subset based on what the majority of system managers will need most of the time.

(BTW, IMHO YaST is pretty good at that.)

I assume that when you want this feature, you better go for a feature request then reporting it as a bug. But I also assume that it would require another checkbox in the interface: Do you want this in /etc/cryptab or not.

11

I’m inclined to see it as a limitation, rather than as a bug.

If you say you want the partition mounted, it will add an entry to “/etc/fstab”. If you check the “do not mount” box, it won’t do that.

There’s no option in Yast partitioner about what it should do with the “/etc/crypttab” entry. If it creates that entry, then you will be prompted for password on boot – unless it is an external drive, in which case this post describes what happens. If it does not put an entry in “/etc/crypttab”, then you won’t be able to mount later without first being prompted for a password.

Maybe Yast Partitioner needs a “decrypt on boot / do not decrypt on boot” option. You could perhaps file a bug report ask for that as an enhancement. Or maybe the problem does not arise often enough to be worth a software change.

In my case, it is a partition on an internal hard drive. And it uses the same encryption passphrase as the root file system. So I do want that entry in “/etc/crypttab”. I am already giving the passphrase for the root file system, so it might as well make the data partition also available for easy mounting. But different people have different usage plans, and there isn’t any “one size fits all”.