A start job is running for /dev/disk/by-uuid | Fresh Installation

Hello!

After the installation finished I rebooted the system and went to the grub menu, the EndeavourOS menu entry was there and I pressed Enter. The system started to load, but it stopped at this:

[OK] Reached target Basic System
[***] A start job is running for /dev/disk/by-uuid/dd9680d5-25b9-4ae7-b8cb-8e29c8105190 (seconds/no limit)

Some info:

fdisk -l
Disk /dev/sda: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: GIGABYTE GP-GSTF
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FC539368-44CF-40FA-92EF-8C5CA8410C5F

Device         Start       End   Sectors   Size Type
/dev/sda1       2048   1026047   1024000   500M EFI System
/dev/sda2    1026048   1058815     32768    16M Microsoft reserved
/dev/sda3    1058816 397717503 396658688 189.1G Microsoft basic data
/dev/sda4  397717504 500118158 102400655  48.8G Linux filesystem


Disk /dev/sdb: 14.73 GiB, 15816720384 bytes, 30892032 sectors
Disk model: Cruzer Blade    
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf5448beb

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sdb1  *        2048 30826495 30824448 14.7G  7 HPFS/NTFS/exFAT
/dev/sdb2       30826496 30892031    65536   32M ef EFI (FAT-12/16/32)


Disk /dev/mapper/ventoy: 2.77 GiB, 2968961024 bytes, 5798752 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4a514722

Device                   Boot   Start     End Sectors  Size Id Type
/dev/mapper/ventoy-part1 *         64 5466911 5466848  2.6G  0 Empty
/dev/mapper/ventoy-part2      5466912 5798687  331776  162M ef EFI (FAT-12/16/32)


Disk /dev/loop0: 2.45 GiB, 2635329536 bytes, 5147128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
fsck
[liveuser@eos-2024.09.22 ~]$ sudo fsck.ext4 -v /dev/sda4
e2fsck 1.47.1 (20-May-2024)
endeavouros: clean, 182799/3203072 files, 1742515/12800081 blocks
cat /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>
UUID=E68A-5D5B                            /boot/efi      vfat    fmask=0137,dmask=0027 0 2
UUID=e16d5189-ebca-44ed-be34-a9a6ad49165d /              ext4    noatime    0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Feb  8 23:13 2024-09-22-10-45-49-00 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Feb  8 23:13 4E21-0000 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Feb  8 23:13 520fcd19-1021-4fd8-b244-722d5e0486ed -> ../../sda2
lrwxrwxrwx 1 root root 10 Feb  8 23:13 6090B23090B20D12 -> ../../sda3
lrwxrwxrwx 1 root root 10 Feb  8 23:13 7353-81B1 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Feb  8 23:13 e16d5189-ebca-44ed-be34-a9a6ad49165d -> ../../sda4
lrwxrwxrwx 1 root root 10 Feb  8 23:13 E68A-5D5B -> ../../sda1
lsblk -o name,uuid,size,fstype,mountpoints
NAME       UUID                                   SIZE FSTYPE   MOUNTPOINTS
loop0                                             2.5G squashfs /run/archiso/airootfs
sda                                             238.5G          
├─sda1     E68A-5D5B                              500M vfat     /opt/boot/efi
├─sda2     520fcd19-1021-4fd8-b244-722d5e0486ed    16M ext4     
├─sda3     6090B23090B20D12                     189.1G ntfs     
└─sda4     e16d5189-ebca-44ed-be34-a9a6ad49165d  48.8G ext4     /opt
sdb                                              14.7G          
├─sdb1     4E21-0000                             14.7G exfat    
│ └─ventoy 2024-09-22-10-45-49-00                 2.8G iso9660  /run/archiso/bootmnt
└─sdb2     7353-81B1                               32M vfat   
sudo cat /var/log/endeavour-install.log | eos-sendlog

https://dpaste.com/2C2RCTNZP

cat /boot/grub/grub.cfg | eos-sendlog

https://0x0.st/8PIg.txt

cat /etc/default/grub | eos-sendlog

https://0x0.st/Xa6u.txt

  • It does goes past 90 seconds.

  • sudo grep -r "/dev/disk/by-uuid/dd9680d5-25b9-4ae7-b8cb-8e29c8105190" /etc shows nothing

  • journalctl -b -0 shows:

[root@EndeavourOS /]# journalctl -b -0
No journal files were found.
-- No entries --
  • In /etc/systemd/journald.conf this line was: #Storage=auto, so I changed to Storage=persistent and saved, but there’s still no log. Although dmesg works:
sudo dmesg -r

https://0x0.st/8PIG.txt

sudo dmesg -rl warn,err,crit
<3>[    0.117384] x86/cpu: SGX disabled by BIOS.
<4>[    0.148427] MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details.
<4>[    1.311853] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
<3>[    2.770090] Invalid ELF header magic: != \x7fELF
<3>[    2.770123] Invalid ELF header magic: != \x7fELF
<3>[    2.773281] Invalid ELF header magic: != \x7fELF
<3>[    2.773324] Invalid ELF header magic: != \x7fELF
<3>[    2.774686] Invalid ELF header magic: != \x7fELF
<3>[    2.774713] Invalid ELF header magic: != \x7fELF
<3>[    2.777838] Invalid ELF header magic: != \x7fELF
<3>[    2.777882] Invalid ELF header magic: != \x7fELF
<3>[    2.779585] Invalid ELF header magic: != \x7fELF
<3>[    9.129486] Module pcspkr is blacklisted
<4>[   11.206885] MXM: GUID detected in BIOS
<4>[   11.584055] kauditd_printk_skb: 72 callbacks suppressed
<3>[   15.414680] Module nvidia is blacklisted
<3>[   15.495328] Module nvidia is blacklisted
<4>[   33.563275] kauditd_printk_skb: 27 callbacks suppressed
<4>[   59.193506] kauditd_printk_skb: 16 callbacks suppressed
<3>[   65.059094] Module nvidia is blacklisted
<4>[   68.248375] kauditd_printk_skb: 4 callbacks suppressed
<3>[   76.627832] Module nvidia is blacklisted
<3>[   80.119575] Module nvidia is blacklisted

I looked at these links:

What I did:

  • Reinstalled EndeavourOS 2 times (both gave me the same problem)
  • arch-chroot from a Live USB
  • pacman -Syu: No updates to install
  • Tried adding the UUID to /etc/fstab: UUID=dd9680d5-25b9-4ae7-b8cb-8e29c8105190 noauto 0 0, but mount -a gives: mount: none: can't find UUID=dd9680d5-25b9-4ae7-b8cb-8e29c8105190. So I think this didn’t work.

Most likely thing is that something has recreated a disk volume since installation (possibly by installing another distro or Windows somewhat incorrectly).
If that is the case, the easiest solution is probably (since you’re a fresh install), just install it again from scratch.
If you wish you can chase down the swap (my guess) UUID from the kernel boot cmdline, where I believe it says RESUME=<UUID>. It would need to be fixed in your bootloader (grub I guess in your case?)
Of course I could be wrong and your uuids just magically switched themselves, in which case, I haven’t a clue to manually fixing it. Maybe a bad disk somewhere?

I was writing a response to @dbarronoss comment, and after reading grub in the text, I pondered: “is grub really my boot loader?”

Lo and behold:

[root@EndeavourOS /]# bootctl status
System:
Not booted with EFI

Available Boot Loaders on ESP:
          ESP: /efi
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 256.6-1-arch)
               ├─/EFI/BOOT/BOOTIA32.EFI
               ├─/EFI/BOOT/fbia32.efi
               ├─/EFI/BOOT/fbx64.efi
               └─/EFI/BOOT/bootx64.efi

Boot Loader Entries:
        $BOOT: /efi
        token: endeavouros

Default Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: EndeavourOS (6.13.1-arch1-1)
           id: fbdbf73def124179a6e7179eba7dd399-6.13.1-arch1-1.conf
       source: /efi//loader/entries/fbdbf73def124179a6e7179eba7dd399-6.13.1-arch1-1.conf (on the EFI System Partition)
     sort-key: endeavouros-6.13.1-arch1-1
      version: 6.13.1-arch1-1
   machine-id: fbdbf73def124179a6e7179eba7dd399
        linux: /efi//fbdbf73def124179a6e7179eba7dd399/6.13.1-arch1-1/linux
       initrd: /efi//fbdbf73def124179a6e7179eba7dd399/6.13.1-arch1-1/initrd
      options: nvme_load=YES nowatchdog rw root=UUID=dd9680d5-25b9-4ae7-b8cb-8e29c8105190 rw root=UUID=dd9680d5-25b9-4ae7-b8cb-8e29c8105190 systemd.machine_id=fbdbf73def124179a6e7179eba7dd399

Damn, systemd-boot default screen looks very similar to grub. So, this seems to be the problem: an old version of systemd-boot is running and it is trying to boot from a partition that does not exist.

What I did:

  1. Remove any installed versions of systemd-boot from the EFI partition with bootctl remove
  2. Edit efibootmgr to remove unnecessary entries and reorder grub as the first one

That’d do it…and i’ve had similar experiences, but didn’t think of this exact combo of circumstances.