You are not logged in.
I installed arch on my computer and everything was going great but suddenly it won't boot anymore...
I have a dual boot Arch / Windows 10 with grub as a boot loader.
I can successfully access grub and windows but not arch.
It echos 'Loading initial ramdisk ...' and then does nothing.
I assume it can't load the image of the kernel since the next line in grub is 'initrd /initramfs-linux.img'.
I still have access to everything in it by chroot-ing from an arch image I burned on a USB key.
Tried:
rebuilding the image with pacman && grub-mkconfig && mkinitcpio
installing another kernel (linux-lts)
removing 'quiet' and/or adding 'splash' to the kernel argument to get some error messages
But still nothing...
I don't know if I should post here or in Kernel & Hardware since I'm a newbie, sorry.
I'm not sure what's happening, please help me understand what I did wrong ![]()
Last edited by VokunGahrotLaas (2020-09-24 18:46:11)
Offline
Welcome to the boards.
And post the actual commands with outputs between code tags.
Have you rebuilded the initramfs?
From archiso, do after arch-chroot:
# pacman -Syu linux; grub-mkconfig -o /boot/grub/grub.cfgAre you using mkinitcpio or dracut?
For mkinitcpio or dracut + dracut-hook installing the kernel makes the initramfs get rebuilt.
Or you can rebuild the initramfs manually.
And change the path of grub.cfg if you have it somewhere else.
Since you have WIN, have you disabled fast boot and hibernation? https://wiki.archlinux.org/index.php/Du … ibernation
Have you tried a cold boot? Sometimes UEFI gets derped and starts behaving all wrong until you shutdown, wait, and cold boot.
Offline
First i tried rebuilding the initramfs with:
# pacman -Syu linux
# grub-mkconfig -o /boot/grub/brug.cfg
# mkinitcpio -p linuxBut that did not work so I tried using linux-lts instead:
# pacman -Syu linux-lts
# grub-mkconfig -o /boot/grub/brug.cfg
# mkinitcpio -p linux-ltsBut neither of these two worked.
Windows fast boot was on so I disabled it.
I already disabled hibernation mode beforehand.
And I cold boot each time I try to boot into arch.
PS: I don't know if I was clear enough on the fact that windows still boots normally from grub, it's just arch that freezes on boot.
Offline
Do you have "splash" kernel argument? I've been having an issue where that causes the boot to hang.
Offline
What caused the issue to occur? Package update? Configuration change?
Offline
Do you have "splash" kernel argument? I've been having an issue where that causes the boot to hang.
Yup, tried that one, still nothing...
Offline
What caused the issue to occur? Package update? Configuration change?
The thing is I do not remember doing any important modifications before the problem.
The last thing I did was installing&making cling from AUR with yay...
Offline
If you press the power button after the screen goes blank does the system shutdown? Indicating the issue with the display.
What is the version of the linux / linux-lts with the issue and the version on live media without the issue?
Last edited by loqs (2020-09-24 18:31:45)
Offline
If you press the power button after the screen goes blank does the system shutdown? Indicating the issue with the display.
What is the version of the linux / linux-lts with the issue and the version on live media without the issue?
I have to hold press of the button for it to shutdown.
For the versions, pacman tell me:
linux 5.8.10.arch1-1
linux-lts 5.4.66-1As for the archiso it's:
archlinux-2020.08.01-x86_64Offline
If not secret, some information about system could be useful. Computer brand & model, cpu brand & model, for instance. One idea is to edit grub configuration to temporarily disable those microcode updates for cpu, see if it then boots. In that case you should probably use (for a while) an older version of microcode, and prevent pacman updating microcode automatically.
Last edited by euromatlox (2020-09-24 19:13:11)
Offline
archlinux-2020.08.01-x86_64 uses 5.7.11. If you downgrade the kernel to a 5.7.X release if you have one in your cache, if not the oldest release you do have in the cache.
This may break out of tree modules but that can be fixed after the boot progresses beyond loading the kernel.
Offline
If not secret, some information about system could be useful. Computer brand & model, cpu brand & model, for instance. One idea is to edit grub configuration to temporarily disable those microcode updates for cpu, see if it then boots. In that case you should probably use (for a while) an older version of microcode, and prevent pacman updating microcode automatically.
Computer: Thinkpad E14 gen2
CPU: AMD Ryzen 5 4500U
Offline
Earlier case with random freeze (including solution) on Ryzen cpu here.
Offline
archlinux-2020.08.01-x86_64 uses 5.7.11. If you downgrade the kernel to a 5.7.X release if you have one in your cache, if not the oldest release you do have in the cache.
This may break out of tree modules but that can be fixed after the boot progresses beyond loading the kernel.
Downgraded to 5.8.3 which is the oldest that I have in cache but still nothing.
Offline
In grub edit the boot options remove both initrds the microcode one and the actual initrd. The kernel should then fail with a panic but should confirm the booted kernel is 5.8.3.
Offline
Earlier case with random freeze (including solution) on Ryzen cpu here.
I do not have random freezes but systematic ones.
processor.max_cstate=1 does not change a thing on my side.
In addition:
journalctl | grep -i "hardware err"does not give out anything.
Offline
If booting directly into graphical target, it would be better (at least temporarily) switch into multi-user.target, which boots into command line. For graphical mode, just type startx and press enter. I have this multi-user setup all the time.
Offline
In grub edit the boot options remove both initrds the microcode one and the actual initrd. The kernel should then fail with a panic but should confirm the booted kernel is 5.8.3.
Removing the initrd line from grub doesn't do anything, it just freezes like usual after Loading initial ramdisk... ?!
Offline
Did you remove one or two initrd entries? If it was just one the microcode initrd would still be loaded. Try passing the boot option dis_ucode_ldr to disable microcode updates.
Offline
If you have earlier kernels (which worked without problems) try downgrading. Check the package cache for packages.
~]$ ls /var/cache/pacman/pkg/linux*
/var/cache/pacman/pkg/linux-5.8.10.arch1-1-x86_64.pkg.tar.zst
/var/cache/pacman/pkg/linux-5.8.9.arch2-1-x86_64.pkg.tar.zst
/var/cache/pacman/pkg/linux-api-headers-5.8-1-any.pkg.tar.zst
/var/cache/pacman/pkg/linux-firmware-20200817.7a30af1-1-any.pkg.tar.zstIf earlier kernel works, remember to prevent pacman updates (look for IgnorePkg in the config file) of that package for a while (till it probably gets fixed soon).
In case of kernel, inside pacman.conf should be line:
IgnorePkg = linux nvidiaand possibly also some other kernel dependent packages (nvidia included there as an example, I have noticed that it's released often when kernel is updated, I'm not sure how dependent it is.)
Last edited by euromatlox (2020-09-24 20:16:18)
Offline
If you have earlier kernels (which worked without problems) try downgrading. Check the package cache for packages.
~]$ ls /var/cache/pacman/pkg/linux* /var/cache/pacman/pkg/linux-5.8.10.arch1-1-x86_64.pkg.tar.zst /var/cache/pacman/pkg/linux-5.8.9.arch2-1-x86_64.pkg.tar.zst /var/cache/pacman/pkg/linux-api-headers-5.8-1-any.pkg.tar.zst /var/cache/pacman/pkg/linux-firmware-20200817.7a30af1-1-any.pkg.tar.zstIf earlier kernel works, remember to prevent pacman updates (look for IgnorePkg in the config file) of that package for a while (till it probably gets fixed soon).
In case of kernel, inside pacman.conf should be line:
IgnorePkg = linux nvidiaand possibly also some other kernel dependent packages (nvidia included there as an example, I have noticed that it's released often when kernel is updated, I'm not sure how dependent it is.)
Already downgraded to 5.8.3 but still not booting...
Offline
Might not be kernel related, but perhaps a late 5.7 kernel could be tried to be more sure. Lots of Intel/AMD changes (new cpus) on Linux 5.8 kernel
As said under this post (next post by logs), journalctl can be handy. Just tried it myself.
ls /var/log/journal/journalctl --directory=/var/log/journal/<machine-id>Last edited by euromatlox (2020-09-24 20:54:43)
Offline
After chrooting in the journal for the last boot would show the last kernel that did work.
If microcode was still being loaded is unanswered from post #19.
Offline
After chrooting in the journal for the last boot would show the last kernel that did work.
If microcode was still being loaded is unanswered from post #19.
Did not have any microcode initrd.
The last kernel that did work was linux 5.8.10-arch1-1 two days ago (according to journalctl).
But that's the latest kernel, I don't think that's where the problem comes from...
I remember having a bios update not so long ago, that might be the cause ?
(Thinkpad bios updated from Lenovo Vantage app on Windows)
But the thing is it got installed on the 21 and last successful arch boot was on the 23...
Tried to boot with linux 5.7.11-arch1-1 and it's modules but that did not work either...
Offline
I think microcode might be needed, since it fixes things with cpus. So it's probably better put it back.
For AMD processors, install the amd-ucode package.
For Intel processors, install the intel-ucode package.
After that, of course bootloader should be refreshed, if install does not do it. Then reboot. Look ArchWiki microcode page for details.
Package linux-firmware is also important, but I guess it does install automatically with core components. Easy to check anyway.
Last edited by euromatlox (2020-09-25 16:46:08)
Offline