I'm currently dual-booting Windows 10 and PopOS. Every time I boot in PopOS, a grey screen appears. If I press ESC, a black console says

"A start job is running for /dev/disk/by_uuid/f054b... (0s / 1m 30s)"

It lasts 90 seconds, then the system loads the user menu normally.
I looked at the /etc/fstab file but there is no mount point with that UUID. I also tried to write in the terminal

lsblk -f

to look for all the partitions' UUID, but none of them has the one which is causing the problem.
So, how can I get rid of the annoying waiting time at every boot?

/etc/fstab content:

  GNU nano 6.2                                              /etc/fstab                                                        
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system>  <mount point>  <type>  <options>  <dump>  <pass>
#PARTUUID=9c9397b4-a42e-4d1e-aa2e-0b30ec436f90  /boot/efi  vfat  umask=0077  0  0

# PARTUUID=b21d74d2-c2fe-46be-baf8-afe8d79bb415  /recovery  vfat  umask=0077  0  0

# root
UUID=261d70d0-0d12-4459-804a-6861766925f4  /  ext4  noatime,errors=remount-ro,x-systemd.device-timeout=1ms  0  0

# Boot partition
UUID=BC69-3211  /boot/efi       vfat    defaults      0       1

# Recovery partition
UUID=BC69-3242  /recovery       vfat    defaults      0       0

Output of "lsblk -f":

liuk23@pop-os:~$ lsblk -f
NAME        FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
└─sda3      ntfs         Dati       66F0B5B0F0B58739                                    
└─sdb1      ntfs         WindowsApp F86CE68B6CE6444A                                    
├─nvme0n1p1 vfat   FAT32 BOOT       BC69-3211                               219M    56% /boot/efi
├─nvme0n1p2 vfat   FAT32 RECOVERY   BC69-3242                             703.2M    83% /recovery
├─nvme0n1p3 ext4   1.0              261d70d0-0d12-4459-804a-6861766925f4  213.2G     9% /
├─nvme0n1p4 swap   1     swap       8adebc72-bf7a-42c8-b013-eb4b2820b1d9                [SWAP]
└─nvme0n1p6 ntfs         Windows10  928AD7718AD75079     

The UUID which is causing the problem is:

f054b7a2-0c78- and so on...


1 Answer 1


Run grep -r f054b7a2-0c78 /etc to see if that UUID is mentioned anywhere under /etc. It might be a reference to an old filesystem or swap area that used to be there but isn't any more.

The reference might already be removed from your actual /etc, but a copy of it might still be left in your current initramfs; try sudo update-initramfs -u to rebuild it. Apparently that should automatically run kernelstub also; however, running a manual sudo kernelstub just to be sure should not hurt.

  • I ran sudo grep -r UUID /etc and I actually found a file containing that UUID in /etc/crypttab. I just commented it and rebooted, and the problem is now fixed without more ado. I'm sorry if I didn't think to use grep before, it was such an obvious thing to try! Thanks for your piece of advice.
    – Liuk23
    Aug 12, 2022 at 19:26
  • Welcome to StackExchange. You won't be able to upvote answers just yet, but as a question author, you can click on the green checkmark to mark the answer as accepted; it's worth a vote and a half. Marking the answer as accepted also stops the SE automation from popping up the old question every once in a while, and tells others searching for solution to a similar problem that the answer was good. Normal practice would be to wait a day or two to see if there will be other answers before accepting, but your question was a rather straightforward one.
    – telcoM
    Aug 12, 2022 at 19:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .