Arch boot and freeze at "Loading initial ramdisk" after Kernel Update

BLuR · 2023-12-10 14:47:21

Hello Forum!
Im new here, therefore i post here although this topic belongs to "Kernel & Hardware" or "Installation"

Yesterday i ran "pacman -Syu" and saw, that the standard 'linux' kernel get an update.
After a reboot the system get stuck at "Loading initial ramdisk", so i searched the forum and uninstalled the nvidia driver and switched to the linux-lts kernel as many suggested in [SOLVED] topics.

The only effect was, that the MSI logo shows up after "Loading initial ramdisk", then the system stuck at the logo.

So today i chroot'ed in my system, created a backup of my .configs and reinstalled Arch on the same nvme-disk with the 'linux-lts' kernel and get the exact same result like before were i have just switched to the lts-kernel. Just MSI logo... (Even the "Disk-LED" shows no reaction after the freeze).

Can someone Help me with this "Unbootable 'Kernel' problem"?
Similar post, just with "systemd-boot": https://bbs.archlinux.org/viewtopic.php?id=290941

Used Arch Linux x86_64 as intended and use GRUB-efi to boot.

Specs:
Fresh installed Arch (160 Packages), fully working in "chroot environment"
Kernel: 6.5.9-arch2-1
Mainboard: MSI Pro B7 60-P WIFI DDR4
CPU: Intel i7-13700
GPU: Nvidia RTX 4060
GPU: Intel Raptor Lake-S GT1 [UHD Graphics 770]
Memory: 48G DDR4

GRUB install args if they help out: #grub-install --removable --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB --recheck --debug

tl;dr: PC works fine, even with Nvidia-drivers until kernel-update yesterday (12.09.23), repair actions dont work. Please Help.

Last edited by BLuR (2023-12-10 20:39:42)

seth · 2023-12-13 15:45:33

The system also doesn't respond to pings (ie. just the GPU being stalled by the system boots and eg. the network works)?

Try to boot the multi-user.target (2nd link below), in doubt along the "nomodeset" kernel parameter and add https://wiki.archlinux.org/title/Genera … l_messages
Can you boot w/ "maxcpus=1"?

BLuR · 2023-12-16 22:01:49

Thank you seth for your answer, i appreciate your help and time!
It turned out that the boot process was not freezing in a "bad" way.

I removed the "quiet" option for the grub startparams and then i see the the real problem.

After the: "[OK] Reachd target Initrd Root Device" message comes this:
"[ *** ] A start job is running for /dev/disk/by-uuid/654501f0-5c54-4a94-9197-f4d8faf2eaa4 ('X'm 'X's / no limit)"
The time goes up infinite.

If i search the web, the only near stuff like this are broken fstab's but mine is okay. I compare the "blkid" UUID output with my fstab and they agree.
Even in the grub.cfg is the right UUID deposited.

The strange thing is, my computer make this UUID up.
If i chroot in the system, look in /dev/disk/by-uuid there only are the "blkid"-output UUID's.
I search the whole / with "grep -rl" and couldnt find "654501f0-5c54-4a94-9197-f4d8faf2eaa4" except in my .bash_history...

It get even stranger, because even after a complete new install, the exact same UUID is made up.
No disk has this UUID.

Where does it come from and why does systemd wants to do a 'start job' with this "Ghost Device"?
The install-stick is not to blame because this one worked fine until the said kernel-update.
This error happens on lts and standard kernel.

Im sorry for the misleading thread name, i didn't know any better at the beginning of my "investigation". Should i start a new thread with a more suitable name and link it to this one?
I really need help on this, because i cant find a similar error online and have no clue why this happen with the actual kernel.

[EDIT]:
It seems, i have the same problem like @beachcoder according to his post (https://bbs.archlinux.org/viewtopic.php?id=291044).

Seth, your solution approach "Adding the made up UUID with noauto" was really creative, but sadly shows no effect, even if i played along with other fstab-options.

Last edited by BLuR (2023-12-17 00:12:05)

seth · 2023-12-17 10:20:08

Also btrfs? luks?
Did you try to downgrade systemd to v254?
You're the 4th or 5th reporter of such device hallucination by systemd now.

BLuR · 2023-12-17 15:03:50

seth wrote:

Also btrfs? luks?
Did you try to downgrade systemd to v254?
You're the 4th or 5th reporter of such device hallucination by systemd now.

Did you mean to edit the filesystem tag from the said UUID in the fstab (in btrfs)?
I did this, sadly no change
I also never had an encrypted disk in my computer. I dont know what you mean else by "luks" (Sorry im a bloody beginner).

The downgrade to "systemd 254 (254.6-2-arch)" work perfectly fine! Thank you so much
So its no "Kernel issue".

Today the "Systemd 255.1-1" was released in the Core-Testing repo and i installed this one.
The error also occurs with the "Ghost device" but the difference was, the timer upper limit is set to 2mins.

After the time has elapsed, the system fully booted in my fresh arch install!

I would mark this thread as solved, because it wont freeze anymore, but the actual cause of the appearance was not found.
Either i dont do a "pacman -Syu" until systemd got a fixed version for my case, or i use the Core-Testing version and wait the two minute booting for my "Ghost device" to cancel its start job...
Both are semi-solutions.

What could possibly be the root of this appearance? Some have it, others dont.
Nonetheless, thank you seth for your help!

seth · 2023-12-17 15:51:09

Did you mean to

No, just whether this is a btrfs installation.

I dont know what you mean else by "luks"

Always ask the wiki, "luks" redirects to https://wiki.archlinux.org/title/Dm-crypt
I then assume you're not encrypting the installation?

What could possibly be the root of this appearance?

"lennartware" …
Some people think they're like, really smart, and if they can turn a computer into a blackbox that apparently works by magic, others will understand that they're, like, REALLY smart.
Problem is, maybe they're not.
The entire shit where systemd unpromptedly tries to mount devices that are not explicitly called for by your fstab is, like, incredibly silly.

And apparently it now manages to make up devices, either out of the TPM or from random tokens on the disk (since so far everyone reporting this uses btrfs, and btrfs has issues w/ eg. nested FS anyway, my money is on the latter, possibly from https://wiki.archlinux.org/title/Btrfs#Swap_file )

If you wanna try, upgrade systemdumb (yeah, I said that) again and add "systemd.gpt_auto=0 systemd.swap=0" to the https://wiki.archlinux.org/title/Kernel_parameters

Arch Linux

#1 2023-12-10 14:47:21

Arch boot and freeze at "Loading initial ramdisk" after Kernel Update

#2 2023-12-13 15:45:33

Re: Arch boot and freeze at "Loading initial ramdisk" after Kernel Update

#3 2023-12-16 22:01:49

Re: Arch boot and freeze at "Loading initial ramdisk" after Kernel Update

#4 2023-12-17 10:20:08

Re: Arch boot and freeze at "Loading initial ramdisk" after Kernel Update

#5 2023-12-17 15:03:50

Re: Arch boot and freeze at "Loading initial ramdisk" after Kernel Update

#6 2023-12-17 15:51:09

Re: Arch boot and freeze at "Loading initial ramdisk" after Kernel Update

Board footer