You are not logged in.
Pages: 1
My laptop has a LUKS-encrypted root partition and an unencrypted boot partition. As of right now, boot is failing after a long wait on
Loading initial ramdisk ...with
Timed out waiting for device /dev/mapper/arch-root, which fails dependencies for Initrd Root Device, /sysroot, Initrd Root File System, and File System Check on /dev/mapper/arch-root. Then
Cannot open access to console, the root account is locked, so I'll have to do something from the arch install iso, but I don't know what. I suspect a problem with my initramfs.
What led to this: I updated my laptop a few days ago for the first time since early November. On reboot, it asked me for the root partition password as usual. I entered it, then it sat at the line
arch-root: clean, $a/$b files, $c/$d blocks. It blinked a couple times but otherwise did nothing. It was possible to switch to terminal 3 and log in there. iwctl wasn't working and I couldn't launch my plasma desktop, but I didn't dig into those issues; things otherwise seemed normal in the shell. Regenerating initramfs with
mkinitcpio -Pseemed to execute successfully but on reboot nothing changed. After some conferring with chatgpt, I realized that my /etc/mkinitcpio.old with
HOOKS=(base udev autodetect keyboard modconf block encrypt filesystems fsck +maybe more stuff that I couldn't see in my screenshot)was from 2021, and I had /etc/mkinitcpio.conf.pacnew from a couple weeks ago. The .pacnew version apparently uses
HOOKS=(base systemd autodetect microcode modconf kms keyboard keymap sd-vconsole block filesystems fsck). I was grasping at straws so swapped them out and regenerated initramfs, which led me to the worse problem above of waiting for arch-root.
So I suspect I ought to switch back to the old mkinitcpio.conf that doesn't include systemd and regenerate initramfs, since it was working for so long, but then I don't know what's going wrong that's keeping me stuck at
arch-root: clean, $a/$b files, $c/$d blocks. I tried looking quickly through journalctl but didn't see anything that looked like a relevant error.
Anyone got any guidance on this?
Last edited by ttshaw1 (2025-12-02 03:38:19)
Offline
https://wiki.archlinux.org/title/Dm-cry … mkinitcpio
Once you're back to the original problem, first thing to check is `uname -r`, and compare that with pacman -Q linux (substitute your kernel package, if using something else). If they don't match, that's your problem.
Last edited by Scimmia (2025-11-28 23:17:31)
Offline
I reverted to the old mkinitcpio.conf and regenerated initramfs, and I'm back to the original problem. When logging into terminal 3, I see that I'm on Arch Linux 6.17.9-arch1 -1. `uname -r` outputs 6.17.9-arch1-1, so the problem's not that.
After more struggling with chatgpt our best theory is that it's a problem with the graphics system. /dev/dri lists card1 but not card 0, and supposedly plasma is trying to use card0. It could be that this is the result of my plugging in an external monitor during the pacman update that kicked this off. I've tried reinstalling linux and linux-firmware to see if that would revert what changed thanks to a poorly-timed monitor hotplug, but so far, no luck. Chatgpt is stuck on trying to get me to use a udev rule to force the iGPU to card0, which I see as a hack. I'd rather figure out what changed during the update and revert it (The udev hack it suggested also didn't work). But I can't get any farther at this point.
Anyone have ideas for what could make my sole GPU show up as card1? Or if that is indeed the problem?
Last edited by ttshaw1 (2025-11-29 20:34:06)
Offline
simpledrm is the likely culprit then as that takes card0 very early in the boot process and other drivers get card1 , card2 etc.
Please execute as root /with root rights
# journalctl -b | curl -F 'file=@-' 0x0.stIt will upload your system journal of the current boot to a public hosting site and output a link.
Post that link .
Also post the full output of lspci -k (as normal user).
Keep in mind that chatbots repeat things without understanding their meaning and are very bad at troubleshooting.
Edit: double | in command was a mistake, corrected
Last edited by Lone_Wolf (2025-12-01 10:21:00)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
journalctl logs at http://0x0.st/KJZB.txt, lspci -k at http://0x0.st/KJZa.txt . Agreed on chatgpt, I was hoping it would save other posters time on troubleshooting and it at least got me to the point of realizing it was a graphics problem, but after that it was just going in circles.
Offline
Nov 30 11:31:53 name-laptop sddm[589]: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_OhYpxC -noreset -displayfd 16
Nov 30 11:31:54 name-laptop sddm[589]: Failed to read display number from pipe
Nov 30 11:31:54 name-laptop sddm[589]: Display server stopping...
Nov 30 11:31:54 name-laptop sddm[589]: Attempt 1 starting the Display server on vt 2 failedNov 30 11:31:54 name-laptop systemd-coredump[770]: Process 665 (Xorg) of user 0 dumped core.
Stack trace of thread 665:
#0 0x000077fd3709890c n/a (libc.so.6 + 0x9890c)
#1 0x000077fd3703e3a0 raise (libc.so.6 + 0x3e3a0)
#2 0x000077fd3702557a abort (libc.so.6 + 0x2557a)
#3 0x000062cbe709a1be OsAbort (/usr/lib/Xorg + 0x1601be)
#4 0x000062cbe70a7510 FatalError (/usr/lib/Xorg + 0x16d510)
#5 0x000062cbe709c6b3 n/a (/usr/lib/Xorg + 0x1626b3)
#6 0x000077fd3703e4d0 n/a (libc.so.6 + 0x3e4d0)
#7 0x000077fd2eaa0430 n/a (libLLVM.so.21.1 + 0x48a0430)
#8 0x000077fd2a8df533 n/a (libLLVM.so.21.1 + 0x6df533)
#9 0x000077fd377332a7 n/a (ld-linux-x86-64.so.2 + 0x62a7)
#10 0x000077fd3773337d n/a (ld-linux-x86-64.so.2 + 0x637d)
#11 0x000077fd3772f4f5 _dl_catch_exception (ld-linux-x86-64.so.2 + 0x24f5)
#12 0x000077fd3773a2a9 n/a (ld-linux-x86-64.so.2 + 0xd2a9)
#13 0x000077fd3772f456 _dl_catch_exception (ld-linux-x86-64.so.2 + 0x2456)
#14 0x000077fd3773a75a n/a (ld-linux-x86-64.so.2 + 0xd75a)
#15 0x000077fd37092cc4 n/a (libc.so.6 + 0x92cc4)
#16 0x000077fd3772f456 _dl_catch_exception (ld-linux-x86-64.so.2 + 0x2456)
#17 0x000077fd3772f5a9 n/a (ld-linux-x86-64.so.2 + 0x25a9)
#18 0x000077fd370927b3 n/a (libc.so.6 + 0x927b3)
#19 0x000077fd37092d7b dlopen (libc.so.6 + 0x92d7b)
#20 0x000077fd376edd33 n/a (libgbm.so.1 + 0x2d33)
#21 0x000077fd376ed176 n/a (libgbm.so.1 + 0x2176)
#22 0x000077fd376ed377 gbm_create_device (libgbm.so.1 + 0x2377)
#23 0x000077fd3694b2c7 glamor_egl_init (libglamoregl.so + 0x92c7)
#24 0x000077fd36c04c63 n/a (modesetting_drv.so + 0x12c63)
#25 0x000062cbe70c25f1 InitOutput (/usr/lib/Xorg + 0x1885f1)
#26 0x000062cbe6f6d6d5 n/a (/usr/lib/Xorg + 0x336d5)
#27 0x000077fd37027635 n/a (libc.so.6 + 0x27635)
#28 0x000077fd370276e9 __libc_start_main (libc.so.6 + 0x276e9)
#29 0x000062cbe6f6ed05 _start (/usr/lib/Xorg + 0x34d05)
ELF object binary architecture: AMD x86-64Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General and afterwards try to downgrade xorg-server to 21.1.18
pacman -U https://archive.archlinux.org/packages/x/xorg-server-common/xorg-server-common-21.1.18-2-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/x/xorg-server/xorg-server-21.1.18-2-x86_64.pkg.tar.zstOffline
Downgrading xorg-server and xorg-server-common hasn't resolved the symptoms. /dev/dri still lists by-path, card1, and renderD128 but no card0
Xorg.0.log before downgrading xorg-server and xorg-server-common: http://0x0.st/KJcL.txt
After downgrading: http://0x0.st/KJc2.txt
An Xorg.2.log from back in June when things were working fine: http://0x0.st/KJcf.txt . Not necessarily helpful but maybe there's something useful in there.
Offline
dev/dri still lists by-path, card1, and renderD128 but no card0
Thanks to the simplydumb device that's completely normal and usully no concern.
pacman -Qikk mesa llvm llvm-libs
pacman -Qs 'llvm|mesa'Offline
pacman -Qikk mesa llvm llvm-libs -> http://0x0.st/KJTu.txt , with `error: package 'llvm' was not found` and `warning: llvm-libs: /usr/lib/libLLVM.so.21.1 (SHA256 checksum mismatch)`
pacman -Qs 'llvm|mesa' -> http://0x0.st/KJTQ.txt
Last edited by ttshaw1 (2025-11-30 23:17:16)
Offline
"error: package 'llvm' was not found" is ok, but "llvm-libs: /usr/lib/libLLVM.so.21.1 (SHA256 checksum mismatch)" is not.
=> Re-install llvm-libs
pacman -Syu llvm-libs(it's most likely ok to update the xorg-server again, .21 isn't supposed to have the problems of .19 and .20)
Offline
Thanks, reinstalled llvm-libs and SDDM's working as it is for the OP of the other thread. The update that kicked this off did include llvm-libs but I don't see anything in my pacman log indicating a problem from that update.
Offline
Pages: 1