When my netbook boots, it stalls for 1min 30sec while one "start job" tries and fails to complete. It times out and generates an error, but then the system boots. It's particularly a problem since I use this system to try testing kernels and other things, so I reboot it frequently.

The problem is, since this "start job" isn't a systemd "unit" I don't know how to find out what is wrong with it. I really don't know what this job is trying to do. The job is "dev-disk-by-uuid-<UUID>.device", where <UUID> looks like a UUID to me...except for two problems:

1) No such device with that UUID exists
2) I don't understand how these start jobs are created. I understand systemd units well enough, but I don't understand how to trace this failing job back to a broken unit or whatever is wrong.

Can someone help me troubleshoot this?

Hi,

I have faced similar problems in the past.

Mine had been caused by a reformatted partition.
Reformatting changed the UUID of the partition, while the old UUID was still referred in GRUB configuration.
I just had to put the correct and new UUID in RUB configuration, rebuild it, and reboots were fixed.
For information the partition was the swap.

Hi! Wow, that's something I hadn't considered.

I checked my system, which is EFI, BTW, and this bogus UUID does not appear in the grub.cfg.

I liked what you are saying about a reformatted partition; that fits. A while ago, I tried to use ecryptfs-setup-swap script to encrypt the swap partition. I think I've used it successfully a couple times before, but, converting swap on this system didn't work.

Thinking of that gave me somewhere to start. Assuming it was a crypt-related service, I found the systemd-cryptsetup@cryptswap1.device in systemdctl list-units. 'systemdctl show' on that *did* have the bogus UUID in it. I didn't know how to fix that though. Poking around more led to /etc/crypttab, which I never touched, but must have been setup by ecryptfs-setup-swap. It also had the wrong UUID in it. I fixed this file, after reading about how it works. I then replaced the regular swap entry in /etc/fstab with /dev/mapper/cryptswap1, which is the device name I configured in /etc/crypttab. I rebooted and it *didn't* stall on that non-existent device!

Oddly, now I have both /dev/mapper/swap, the old swap device, and /dev/mapper/cryptswap1 which is the one that is now mounted as swap. I don't know what causes that, but I don't think it's broken. It might not be exactly right; I'm not sure.

If you know how it should look, please tell me.

Hi,

For the active swap you can launch
swapon -s

Generally there is a parameter resume in /etc/cmdline that specifies the swap partition used for hibernating.
Have a look at that.

Yeah, my active swap is the right one; it's the new one I encrypted. I'm just saying the old one is still around. Maybe it is okay. The old one is a LVM device; I guess they all get mapper names, now. So, the encrypted device is inside the LVM device. Yeah, I guess that's right. In the past, I think I had encrypted swap on raw partition, no LVM, so I my expectations may be inaccurate.

You mean /proc/cmdline? In mine, I see all LVM devices are listed, but there isn't anything that selects the swap device or hibernation device. Is there a kernel param that selects a file for hibernation independently of the swap device? I've never heard of that. AFAIK, it isn't possible to hibernate when using encrypted swap. If that has changed, I'm not aware of it.

Hi,

Yes, I meant /proc/cmdline.
Mine is as below.
BOOT_IMAGE=/vmlinuz-4.4.8-300.fc23.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root resume=/dev/disk/by-uuid/1b28b7c7-26f9-4763-9ea8-21f2c99c9f96 rhgb quiet LANG=en_US.UTF-8

The bold part is the one related to swap used for hibernation.