Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#68308 - Linux 5.9.1 doest not boot
Attached to Project:
Arch Linux
Opened by Jamp (jamp) - Saturday, 17 October 2020, 21:23 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 10 November 2020, 15:04 GMT
Opened by Jamp (jamp) - Saturday, 17 October 2020, 21:23 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 10 November 2020, 15:04 GMT
|
DetailsDescription:
My Asus I7 4700HQ notebook does not boot after upgrade from kernel v.5.8.14 to 5.9.1 The grub menu appears but then the fan start to speed up and nothing happens. On the screen there is the "Loading Linux linux" message and the system remains stuck there Switching console does not work so I think that it isn't a graphics interface problem. Trying to downgrade... Additional info: * package version(s) * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: upgrade to 5.9.1 |
This task depends upon
https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-linux-kernel-5-9/157263
In the past I had problems with the Nvidia drivers but it never happened that the machine was completely inaccessible. I has been always able to login in text mode. Now the machine is apparently loaded (fan spins loud) but frozen.
I tried to downgrade by booting the usb flash, then chrooting to the mounted root partition and downgrading to the previous kernel (and everything related) version with pacman -U. Surprisingly the outcome with the downgraded kernel was the same. So maybe the problem is in something used to build the kernel. I was able to boot the machine by copying the kernel and the initramfs* files from the /boot of a virtual machine I had on another PC. Surprisingly again, for me, this is working fine.
At this point I'm somewhat surprised being apparently only one of the few that is complaining about this problem
and by the lack of any warning on arch's home page.
FS#68312the symptoms do not match what you are reporting. If you blacklist the nvidia modules (nvidia nvidia-drm nvidia-modeset nvidia-uvm) or remove the package supplying those modules can you then boot a 5.9 kernel?Booting 5.9.1 does not leave apparently any notice in the logs.
My system is an Asus N750JV.
Thank you
I noticed that the 5.9.1 initramfs* files generated by pacman on the physical machine are far smaller than the corresponding files generated by pacman on the VM
Physical
-rwxr-xr-x 1 root root 24413951 Oct 22 09:52 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root 2126369 Oct 22 09:52 initramfs-linux.img
-rwxr-xr-x 1 root root 8958080 Oct 22 09:52 vmlinuz-linux
VM
-rw-r--r-- 1 root root 32133661 Oct 22 09:43 initramfs-linux-fallback.img
-rw-r--r-- 1 root root 10011765 Oct 22 09:43 initramfs-linux.img
-rw-r--r-- 1 root root 8958080 Oct 22 09:43 vmlinuz-linux
With the latter files the 5.9.1 kernel and nvidia modules run fine also on the physical machine
With the shorter files the machine hangs at boot, then I take the files from the VM and put them on the Asus laptop and it starts fine.
I checked the various mkinitcpio.conf and related files on both machines but they look the same.
This problem happened upgrading from 5.8.14 to 5.9.1 and is still there.
Is there someone that could give advice about this problem?
Thank you
The /usr/bin/ldd script uses the /usr/lib64/ld-linux-x86-64.so.2 to find the dependencies of some executables that the mkinitcpio program stuffs into the initramfs files. Not finding the ld-linux-x86-64.so.2 utility the executables were reported as statically linked by ldd and the necessary shared libraries were not included in the final initramfs files.
I haven't yet found what happened and hope that was a faulty package that removed the symlink because I try to pay the maximun attention to the integrity of the system files and directories.