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

Ask Fedora
, ,
1

Hello,

On boot the following job hangs forever:

Screenshot_20240605_095814
Screenshot_20240605_0958141134×257 419 KB

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.

2 Likes
2

Added boot

3

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.

5 Likes
4

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
5

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

solved

6

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)

7

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.

8

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.

9

I am having a similar problem with the hang at boot. I have looked and tried a few things. Cat /proc/cmdline is blank. There is no entry for swap in fstab. There is a reference that I can set a timeout for the command but no description as to how. How do I set a timeout value?
Thank you,
Vince Radice

10

Please start your own thread. It appears your issue is similar but probably different so we need details about your case.

11

I did start one but have had no replies.
FC40 hangs at boot with message Job dev-disk-by\x2uuid…device start running

12

This thread had a solution posted on June 5
I am closing it.

Use the one you started elsewhere. but failed to link here

Apparently the topic on the other thread is not related to the boot hang.

I also note that you have only opened one thread of your own and that was more than 10 months ago. Hijacking others threads is not the way to get a specific answer for your problems.