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
1 Like

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

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.