[SOLVED] Boot hang - Job dev-disk-by\x2uuid... [no limit]

Hello,

On boot the following job hangs forever:

This happens with kernel 6.8.10-300.fc40.x86_64 and 6.8.11-300.fc40.x86_64. Kernel 6.8.9-300.fc40.x86_64 boots quickly to desktop.

Here is /etc/fstab:

$ cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Apr  4 19:51:01 2024
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=73875c79-d107-48f1-b8c6-2391be03002a /                       btrfs   defaults        0 0
UUID=493A-5A8A          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=2dcc25c9-02b8-4011-8baf-3466568ad71c /home                   btrfs   defaults        0 0
# UUID=bdc712fc-8366-4620-845b-017b333dba32 none                    swap    defaults        0 0

I was experiencing a similar boot delay a few months ago, but it would time out at 1m30s and continue to desktop. The problem was solved when I commented out the swap partition in fstab above; I figured zram would be enough for my uses. But here is my swap info:

$ swapon -s
Filename                                Type            Size            Used   Priority
/dev/zram0                              partition       8388604         0      100
/dev/nvme0n1p3                          partition       27291440        0      -2

And here is my partition arrangement:

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 178.9G  0 disk 
├─sda1        8:1    0   600M  0 part 
├─sda2        8:2    0     1G  0 part 
└─sda3        8:3    0 177.3G  0 part 
sdb           8:16   0 931.5G  0 disk 
└─sdb1        8:17   0 931.5G  0 part 
zram0       252:0    0     8G  0 disk [SWAP]
nvme1n1     259:0    0 465.8G  0 disk 
└─nvme1n1p1 259:1    0 465.8G  0 part /home
nvme0n1     259:2    0   1.9T  0 disk 
├─nvme0n1p1 259:3    0     1G  0 part /boot/efi
├─nvme0n1p2 259:4    0   1.8T  0 part /
└─nvme0n1p3 259:5    0    26G  0 part [SWAP]

What do I do? What is the job waiting for? Why did it change in the most recent two kernels, and why is it allowed to wait forever?

This is Fedora 40 x86_64 KDE, custom desktop. Thanks in advance for any guidance.

1 Like

Added boot

The upgrade from 6.8.9 to 6.8.10 revealed a change in the boot process that causes this for some fedora users.

Please run cat /proc/cmdline and post it here.

The gist of the revealed change is that some users had a resume=UUID=xxxx option in the command line and in situations where that swap volume no longer exists it will hang indefinitely trying to start it. With kernel 6.8.9 and earlier that check had a defined timeout so it would continue. With 6.8.10 the timeout was removed.

If you see a string such as that in the output when you run the cat command and as long as you are booting with grub then the grub command
sudo grubby --remove-args=<resume=UUID=xxx> --update-kernel=ALL should remove that failing option from all locations where it is a problem and ensure it carries forward with future updates. Replace the <resume=UUID=xxx> portion of that command with the EXACT string you see in the output of the cat command above. Try rebooting after running that command.

In your case it seems you disabled (in fstab) starting of the swap partition on nvme0n1p3 so it cannot start even though the partition actually does exist.

4 Likes

Not quite. In the early boot the program systemd-gpt-auto-generator is run and if it finds a swap partition it will enable it, even when no fstab exists for it. See man systemd-gpt-auto-generator for details.

1 Like

This worked! Thanks to both of you for your help.

solved

Maybe this is supposed to happen, but it does not.
I manually created a swap partition since I have one app that during certain events will consume all the RAM, all the swap, and sometimes even die due to OOM with 32G RAM and 128G swap. Until the problem with this particular app appeared I have never used anything more than the default ZRAM swap for several years.

My system does not automatically start that swap partition even after a kernel upgrade and several reboots ( I want it enabled only when I am using that app so having it not start automatically is great: But your statement indicates it ‘should’ be enabled automatically)

From the message from the OP you see the swap line in fstab commented out and yet swapon shows it to be enabled. Notice if you have more than one disk, the generator only looks at the boot disk.

You may just as well add “systemd.gpt_auto=0” to the kernel command line, so the generator doesn’t wast time finding things to automount.

This then appears to be a different issue – in that the swap partition exists but cannot be started at that stage of the boot where the hang occurs.

During boot the swap partition is automatically activated, is commented out in /etc/fstab, yet because it was in the kernel command line with the resume= option it still caused the hang during boot with trying to start that swap partition.

It would seem the systemd-gpt-auto-generator and the kernel command line option are conflicting and in this case caused the hang. Maybe the same applies to most of those who had a similar problem.

I thought the resume= option was only applicable to systems with hibernation enabled so it may not apply to everyone.