You are not logged in.
I ran a pacman -Syu on my laptop while ssh'd in from a different laptop (not sure if that's relevant).
Pacman update was successful but immediately upon reboot I got errors:
Failed to listen on udev Control Socket.
Failed to listen on udev Kernel Socket.
After those two fails and another ten [ OK ] all my device partitions timeout and fail to mount. Then I see "A start job is running for ... " for about minute before it drops me into emergency mode.
I am able to boot from a usb, mount my devices, arch-chroot and run: pacman -S linux
That doesn't fix it and that's about as far as I've gotten.
No idea how to escape this. Can anyone help out?
Offline
Do you use UUIDs to identify your volumes in your boot loader and your fstab? Or do you use device names?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Fstab is using UUIDs. Not sure about what the boot loader is using.
Offline
It is not clear to me yet where it is failing. I think the kernel is loaded, but the kernel cannot find it's root. I don't think you have gotten as far as reading /etc/fstab.
When you boot into the install media, can you see all of your volumes? can you mount them? What boot loader are you using?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Yes, I can see and mount all my volumes. Can also arch-chroot in.
I'm using systemd-boot I think.
Fstab seems to look fine. Nothing changed in there and all the UUIDs match up with what I see in /dev/disk/by-uudi
Offline
Post the contents of loader/loader.conf from your boot volume.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Sorry if there's typos, just typing out by hand what I'm seeing in that boot folder. Then cat out the loader.conf.
/boot $ ls -a
. .. efi initramfs-linux-fallback.img initramfs-linux.img vmlinuz-linux
/boot $ ls -a efi/
. .. EFI home initramfs-linux-fallback.img initramfs-linux.img loader vmlinuz-linux
/boot $ cat efi/loader/loader.conf
default arch
timeout 1
editor 0Offline
Seems like there's some actual configuration in this config. Didn't type it out this time:
$ cat boot/efi/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=86....ca rwI also realized that when I'm in emergency mode I can't mount /home volume.
No error displays. Not sure if that's unusual.
I realized this after reading another post. I can't tell if maybe that ticket solves a similar issue?
https://bbs.archlinux.org/viewtopic.php?pid=1187920
Last edited by ooXei1sh (2020-08-16 22:16:36)
Offline
I was able to fix the issue after looking deeper into the journal -xb output.
journalctl -xb
The first warning line before the "Failed to listen on udev.." error said this:
"Unit system-udevd.service has a bad unit file setting."
The problem file had the line ".include" at the top referencing a different file:
cat /etc/systemd/system/systemd-udevd.service
To fix it I removed the ".include" line and copied the contents of the referenced unit file:
cat /usr/lib/systemd/system/systemd-udevd.service >> /etc/systemd/system/systemd-udevd.service
After this I was able to reboot without issue. Launched right to my desktop login screen.
Seems I should have looked for the first warning signs in the journalctl -xb output before focusing on the [ FAIL ] that appeared in the bootup spew.
Sorry for the bother. I appreciated your patience and efforts.
Offline