System waits infinitely for a UUID to boot

I installed a game the other day which filled all of my RAM (i only have 8GB) so i decided to increase the amount of swap i have (also 8GB at the time, now 16GB). At some point while playing the game (Cities skylines, i only scrape past the minimum specs), my PC entirely froze. When i expanded my swap size i shrunk a windows 7 partition i rarely touch, deleted my swap partition after turning it off. Set it going in gparted and then made a new swap partition. I did not replace the swap UUID in fstab, i intended to do it after as i tested but did not expect my whole PC to freeze and reboot.

Now upon boot i am forever stuck in the initial phase on:

A start job is running for /dev/disk/by-uuid/8c31dbc0-ef92-45a6-a509-11022f82c0bf (time / no limit).
I “fixed” the fstab UUID but none of the UUIDs inside ever matched the uuid above, which did not fix any issues.

I then went to check the disk partitions in a file manager, and some seemed to fail (D-bus interface error), but after checking them i(fscheck and a smart check iirc) t now works fine when i access them from a live iso. I still can’t boot though.

Any ideas what i can do?

Mount the disk from the live environment and edit /etc/fstab to comment out that line, or better yet change it to the UUID of your new swap partition.

Which line? it is currently:

# /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>
UUID=61dd8e9a-9002-4788-b90a-b2ce2e3dc741 /              ext4    defaults,noatime 0 1
UUID=636C-7A03                            /efi           vfat    defaults,noatime 0 2
UUID=e2ec2802-022a-4f12-a973-8d081d683040 /workspace_ssd1 ext4    defaults,noatime 0 2
UUID=cee1d92f-8403-4106-8f7a-d5fbb74bac4b /home          ext4    defaults,noatime 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

Let’s take a look at lsblk -f.

[liveuser@eos-2023.02.08 ~]$ lsblk -f
     squash 4.0                                                          0   100% /run/archiso/airootfs
│    ext4   1.0   Root        61dd8e9a-9002-4788-b90a-b2ce2e3dc741   13.6G    48% /run/media/liveuser/Root
│    vfat   FAT32 BOOTEFI     636C-7A03                                           
     ext4   1.0   Workspace   e2ec2802-022a-4f12-a973-8d081d683040  121.5G    35% /run/media/liveuser/Workspace
│    vfat   FAT32             D649-B724                                           
│    ntfs                     B2EE4B7FEE4B3B3D                       78.5G    52% /run/media/liveuser/B2EE4B7FEE4B3B3D
│    swap   1                 481b23d5-0f22-40fb-a71b-7543be97518c                
     ext4   1.0   Home        cee1d92f-8403-4106-8f7a-d5fbb74bac4b  144.5G    43% /run/media/liveuser/Home
│    ntfs         System Reserved
│                             20E898CAE8989F98                                    
     ntfs         DRIVE 1     105C00445C002756                      261.2G    72% /run/media/liveuser/DRIVE 1
sdd  iso966 Jolie EOS_202302  2023-02-08-15-44-26-00                              
│    iso966 Jolie EOS_202302  2023-02-08-15-44-26-00                     0   100% /run/archiso/bootmnt
     vfat   FAT16 ARCHISO_EFI 41B6-5B8A                                           

Hmm, I’m not sure but it may be your swap partition has not been set up correctly.

Go ahead and chroot to the disk from the live environment, then try giving that swap partition a redo.

swapoff /dev/sdb4
mkswap /dev/sdb4
swapon /dev/sdb4

Done this - arch-chroot’ed into my root partition and run those commands. Other than a new UUID nothing seems to of changed, and inxi still says no swap data.

I then used swapon and:

  ID-1: swap-1 type: partition size: 17.62 GiB used: 0 KiB (0.0%) priority: -2
    dev: /dev/sdb4

But i still get the error i had at the start,

Edit: i recorded with my phone, and noticed there arew several ACPI errors before the Welcome to Endeavour OS dracut-059 (initramfs)!

ACPI Error: Aborting Method \SB.PC10.SAT0.SPT3._GTF due to previous error (AE_NOT_FOUND) (20222033/psparse-529)
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC10.SATO.SPT4._GTF.DSSP], AE NOT FOUND (20220331/psparse-529)

This repeats itself around 6 times

Often these messages are related to the BIOS firmware manufacturer not properly following the ACPI specification. They basically make sure the MB is compatible with Windows and call it a day. In general they are safe to ignore. If there is a BIOS update available for your computer you should take it.

I’m not sure where that UUID is coming from. Maybe there is a unit file in /etc/systemd/ or something looking for it. Try running grep -ri 8c31dbc0 /etc/systemd /run/systemd /lib/systemd from the chroot to see if it is listed in a .mount file or similar. If it is, just remove it.

I recently faced a very similar problem.
I hope it can help you

Tried the grep method, nothing was returned. I looked round the systemctl files and din’t find anything related.
I tried the systemctl mask solution. it wouldn’t run systemctl status … in the chroot but it would run the mask function. I masked it in both the live-iso and the chroot terminal, no success on boot though.

have you tried sudo dracut-rebuild after modifying the swap partition?

hopped into the arch-chroot to try it and although it seemed to run fine, im still waiting for the same UUID on boot though :frowning:

When you can post the contents of folder /etc/dracut.conf.d/

add_dracutmodules+=" resume "

omit_dracutmodules+=" network cifs nfs brltty "

There is nothing else in the folder.

sorry to bump, any more possible solutions?


You can try disabling systemd gpt_auto generator by adding this to your kernel command line

systemd.gpt_auto=0 rd.systemd.gpt_auto=0

That should ™ only use fstab and completely skip systemd gpt autodiscovery stuff.