Kernel 5.10.1 locks up my computer while booting

Gordie · 12-20-2020, 06:57 PM

This is my old Lenovo W510 Thinkpad laptop. Have not been able to reboot with the upgraded 64-bit kernel.

Lucky I have saved the last kernel that worked as an entry in my lilo.conf so am able to boot and surf. Kernel 5.4.84 works.

I use lilo and both the generic and the huge kernels hang while booting. The only way to get running again is to force a reboot with the power button. Not sure how to get at a log to post but was able to take pics of the screen with my cellphone. Maybe there is a way to post the pics?

Whatever you need to see I can post

igadoter · 12-20-2020, 10:19 PM

Post what you got. Now I am guessing. Can be framebuffer issue?

Gordie · 12-20-2020, 10:54 PM

Have a picture each of the screen when things lock up but don't know what to do about posting them.

My lilo.conf

Code:

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append=" "

boot = /dev/sda
compact        # faster, but won't work on all systems.

# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/124827-slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
  bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
  bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
  bmp-timer = 65,27,0,255

# Standard menu.
# Or, you can comment out the bitmap menu above and 
# use a boot message with the standard menu:
#message = /boot/boot_message.txt

# Wait until the timeout to boot (if commented out, boot the
# first entry immediately):
prompt
# Timeout before the first entry boots.
# This is given in tenths of a second, so 600 for every minute:
timeout = 1200
# Override dangerous defaults that rewrite the partition table:
change-rules
  reset
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
#vga=791
# VESA framebuffer console @ 1024x768x32k
#vga=790
# VESA framebuffer console @ 1024x768x256
#vga=773
# VESA framebuffer console @ 800x600x64k
#vga=788
# VESA framebuffer console @ 800x600x32k
#vga=787
# VESA framebuffer console @ 800x600x256
#vga=771
# VESA framebuffer console @ 640x480x64k
#vga=785
# VESA framebuffer console @ 640x480x32k
#vga=784
# VESA framebuffer console @ 640x480x256
#vga=769
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda1
  label = Generic
  initrd = /boot/initrd.gz
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda1
  label = Huge
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux bootable partition config begins
image =  /boot/vmlinuz-generic-5.4.84-safe
  root = /dev/sda1
  label = Generic-safe
  initrd = /boot/initrd.gz-safe
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux bootable partition config begins
image = /boot/vmlinuz-huge-5.4.84-safe
  root = /dev/sda1
  label = Huge-safe
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux memtest86 config begins
image = /boot/memtest86.bin
  label = memtest86
  password = "0"
  read-only
# Linux memtest86 config ends
# Linux memtest86+ config begins
image = /boot/memtest86+.bin
  label = memtest86+
  password = "0"
  read-only
# Linux memtest86+ config ends

Got no logs. Things lock up way before logs are stored. Maybe I will look at the kernel configs and see what I can find

EDIT - Last evening I only had kernels huge and generic 5.4.84.x64 installed. After upgrading kernels to 5.10.1.x64 my computer wouldn't boot very far before lockup.
I used the install USB for Slackware64-current to install a kernel and then I booted my computer and made changes to the lilo.conf to allow me to boot the 5.4.84 kernels. Now that worked well and my computer at least boots now so I upgraded the kernel from the install USB to 5.10.1 just to see and it locked up again.
Generic and Huge both seem to lock up at a different spot in the boot process.

igadoter · 12-20-2020, 11:21 PM

For me you have incorrect entry in lilo.conf - link /boot/vmlinuz points to Huge and in the same Generic kernels - as it seems to be from labels. Just verify what really is /boot/vmlinuz - ln -l /boot/vmlinuz.

Edit: I am hesitating about lilo not complaining due to this incorrect (imo) entry in lilo.conf. I see this lilo picked up the first entry - so all the time you are booting only generic kernel - hangs on can be related to initrd - try to rerun makeinitrd for new generic kernel. Maybe just simpler show what you got here ls -l /boot - there maybe some mess.

Gordie · 12-21-2020, 12:24 AM

OK. I tried to fix my lilo.conf.
Good catch. Lilo never complained and who knows how long it was like that.

I use a small script to generate my init and it runs lilo also:

Code:

OK: /lib/modules/5.10.1/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/5.10.1/kernel/fs/mbcache.ko added.
OK: /lib/modules/5.10.1/kernel/fs/ext4/ext4.ko added.
54520 blocks
/boot/initrd.gz created.
Be sure to run lilo again if you use it.
Warning: LBA32 addressing assumed
Added Generic  +  *
Added Huge
Added Generic-safe  +
Added Huge-safe
Added memtest86
Added memtest86+
One warning was issued.
bash-5.1#

My corrected lilo.conf:

Code:

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append=" "

boot = /dev/sda
compact        # faster, but won't work on all systems.

# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/124827-slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
  bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
  bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
  bmp-timer = 65,27,0,255

# Standard menu.
# Or, you can comment out the bitmap menu above and 
# use a boot message with the standard menu:
#message = /boot/boot_message.txt

# Wait until the timeout to boot (if commented out, boot the
# first entry immediately):
prompt
# Timeout before the first entry boots.
# This is given in tenths of a second, so 600 for every minute:
timeout = 1200
# Override dangerous defaults that rewrite the partition table:
change-rules
  reset
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
#vga=791
# VESA framebuffer console @ 1024x768x32k
#vga=790
# VESA framebuffer console @ 1024x768x256
#vga=773
# VESA framebuffer console @ 800x600x64k
#vga=788
# VESA framebuffer console @ 800x600x32k
#vga=787
# VESA framebuffer console @ 800x600x256
#vga=771
# VESA framebuffer console @ 640x480x64k
#vga=785
# VESA framebuffer console @ 640x480x32k
#vga=784
# VESA framebuffer console @ 640x480x256
#vga=769
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz-generic
  root = /dev/sda1
  label = Generic
  initrd = /boot/initrd.gz
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda1
  label = Huge
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux bootable partition config begins
image =  /boot/vmlinuz-generic-5.4.84-safe
  root = /dev/sda1
  label = Generic-safe
  initrd = /boot/initrd.gz-safe
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux bootable partition config begins
image = /boot/vmlinuz-huge-5.4.84-safe
  root = /dev/sda1
  label = Huge-safe
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux memtest86 config begins
image = /boot/memtest86.bin
  label = memtest86
  password = newpassword
  read-only
# Linux memtest86 config ends
# Linux memtest86+ config begins
image = /boot/memtest86+.bin
  label = memtest86+
  password = newpassword
  read-only
# Linux memtest86+ config ends

NOW will try and boot the generic and huge kernels 5.10.1

Gordie · 12-21-2020, 01:09 AM

Well, they both lock up but at different spots.

Generic just after the USB ports are mentioned it trips over the ACPI driver and locks up. I will type out the last line on the screen:
"[ 10.615386] ACPI: If an ACPI driver is available for this device, you should
use it instead of the native driver."

This is repeated 3 times on the final screen and then lock up.

Huge - just after the touchpad driver is loaded. I will type out the last line on the screen:

"kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. U"

Code:

bash-5.1$ ls -l /boot
total 65100
-rwxrwxrwx  1 root root    52748 Apr 21  2017 124827-slack.bmp
lrwxrwxrwx  1 root root       38 Dec 18 20:52 README.initrd -> /usr/doc/mkinitrd-1.4.11/README.initrd
lrwxrwxrwx  1 root root       22 Dec 20 13:02 System.map -> System.map-huge-5.10.1
-rw-r--r--  1 root root  4868353 Dec 19 18:26 System.map-generic-5.10.1
-rw-r--r--  1 root root  6559759 Dec 19 18:25 System.map-huge-5.10.1
-rw-r--r--  1 root root      512 Dec 22  2019 boot.0800
-rw-r--r--  1 root root      353 Oct 31 19:56 boot_message.txt
lrwxrwxrwx  1 root root       22 Dec 20 13:02 config -> config-huge-5.10.1.x64
-rw-r--r--  1 root root   230231 Dec 19 16:59 config-generic-5.10.1.x64
-rw-r--r--  1 root root   230231 Dec 19 16:59 config-huge-5.10.1.x64
-rwxr-xr-x  1 root root   216219 Jun 12  2018 elilo-ia32.efi
-rwxr-xr-x  1 root root   238531 Jun 12  2018 elilo-x86_64.efi
drwxr-xr-x  5 root root     4096 Dec  5 20:44 grub
drwxr-xr-x 14 root root     4096 Dec 21 01:16 initrd-tree
-rw-r--r--  1 root root  9549302 Dec 21 01:16 initrd.gz
-rw-r--r--  1 root root  9498986 Dec 20 01:42 initrd.gz-safe
-rw-r--r--  1 root root    22578 May 17  2020 inside.bmp
-rw-r--r--  1 root root      432 May 17  2020 inside.dat
drwxr-xr-x  2 root root     4096 Dec 13 22:47 install
-rw-------  1 root root    84480 Dec 21 01:16 map
lrwxrwxrwx  1 root root       15 Dec 19 00:57 memtest86 -> memtest86-4.3.7
lrwxrwxrwx  1 root root       15 Dec 19 00:57 memtest86+ -> memtest86+-5.01
-rwxr-xr-x  1 root root   184380 Jul 24 19:16 memtest86+-5.01
-rw-r--r--  1 root root   182704 Jul 24 19:16 memtest86+-5.01.bin
lrwxrwxrwx  1 root root       19 Dec 19 00:57 memtest86+.bin -> memtest86+-5.01.bin
-rwxr-xr-x  1 root root   104732 Jul 24 19:15 memtest86-4.3.7
-rw-r--r--  1 root root   103056 Jul 24 19:15 memtest86-4.3.7.bin
lrwxrwxrwx  1 root root       19 Dec 19 00:57 memtest86.bin -> memtest86-4.3.7.bin
-rw-r--r--  1 root root     6878 May 17  2020 onlyblue.bmp
-rw-r--r--  1 root root      424 May 17  2020 onlyblue.dat
-rw-r--r--  1 root root    15634 Mar 27  2011 slack.bmp
-rw-r--r--  1 root root    33192 May 17  2020 tuxlogo.bmp
-rw-r--r--  1 root root      423 May 17  2020 tuxlogo.dat
lrwxrwxrwx  1 root root       19 Dec 20 13:02 vmlinuz -> vmlinuz-huge-5.10.1
lrwxrwxrwx  1 root root       22 Dec 20 13:02 vmlinuz-generic -> vmlinuz-generic-5.10.1
-rw-r--r--  1 root root  7074048 Dec 19 18:26 vmlinuz-generic-5.10.1
-rw-r--r--  1 root root  6637888 Dec 16 16:23 vmlinuz-generic-5.4.84-safe
lrwxrwxrwx  1 root root       19 Dec 20 13:02 vmlinuz-huge -> vmlinuz-huge-5.10.1
-rw-r--r--  1 root root 10574080 Dec 19 18:25 vmlinuz-huge-5.10.1
-rw-r--r--  1 root root 10111296 Dec 16 16:23 vmlinuz-huge-5.4.84-safe
bash-5.1$

igadoter · 12-21-2020, 02:06 AM

noacpi option for generic kernel? kvm is for virtualization - I don't get it.

gegechris99 · 12-21-2020, 03:54 AM

for the generic kernel, the next step in boot would be

Code:

xhci_hcd 0000:00:14.0: xHCI Host Controller

Using /usr/share/mkinitrd/mkinitrd_command_generator.sh, the initrd.gz file contains these modules:

Code:

usb-storage:ums-realtek:xhci-hcd:jbd2:mbcache:ext4

I would suggest that you use mkinitrd_command_genetrator to create the command line for generating the initrd.gz file.

For the huge kernel, can you mention the timestamp of the last message (kvm) to check where it blocks.

Gordie · 12-21-2020, 11:17 AM

"[ 14.009843] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. U"

Gordie · 12-21-2020, 11:21 AM

Quote:

Originally Posted by gegechris99

for the generic kernel, the next step in boot would be

Code:

xhci_hcd 0000:00:14.0: xHCI Host Controller

Using /usr/share/mkinitrd/mkinitrd_command_generator.sh, the initrd.gz file contains these modules:

Code:

usb-storage:ums-realtek:xhci-hcd:jbd2:mbcache:ext4

I would suggest that you use mkinitrd_command_genetrator to create the command line for generating the initrd.gz file.

For the huge kernel, can you mention the timestamp of the last message (kvm) to check where it blocks.

This is the script I am using:

Code:

#!/bin/sh
#
cd /boot
# DOUBLE CHECK THE DRIVE FORMAT.
mkinitrd -c -k "$(readlink /boot/vmlinuz | cut -d- -f3-)" -m ext4 # EDIT KERNEL VERSION AND DRIVE FORMAT AS REQUIRED.
#
lilo

This script has been serving me well for a couple of years. It is no good?

Loomx · 12-21-2020, 02:44 PM

No, that command is reading the `/boot/vmlinux' symlink, which is the huge kernel on your system based on what you posted, when you need the modules that the generic kernel needs.
Also it only adds the ext4 module, when as @gegechris99 said you need a whole lot more modules.
Use the `/usr/share/mkinitrd/mkinitrd_command_generator.sh' script to get a full list.

enorbet · 12-21-2020, 03:46 PM

Since you are using MBR boot, let me suggest that you either assign names to your different kernels, or use the ones they have as long as you immediately recognize them (and lilo does, too) and stop using vmlinuz or any variation of a symlink in lilo.conf. Use the full kernel name always in each stanza. It shouldn't hurt if the one you expect to use most has a linked "System.map.foo > System.map" since the generic kernel will also invoke it's initrd.

Gordie · 12-21-2020, 09:01 PM

Quote:

Originally Posted by igadoter

Post what you got. Now I am guessing. Can be framebuffer issue?

I have had a lot of time to observe the screen while booting. It appears that about the time when the screen should blink and the font size gets smaller is when the boot process locks up. Not sure what to try now

Gordie · 12-21-2020, 09:02 PM

Quote:

Originally Posted by Loomx

No, that command is reading the `/boot/vmlinux' symlink, which is the huge kernel on your system based on what you posted, when you need the modules that the generic kernel needs.
Also it only adds the ext4 module, when as @gegechris99 said you need a whole lot more modules.
Use the `/usr/share/mkinitrd/mkinitrd_command_generator.sh' script to get a full list.

Code:

mkinitrd -c -k 5.4.84 -f ext4 -r /dev/sda1 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:crc32c_intel:crc32c_generic:ext4 -u -o /boot/initrd.gz

This is my first time using it. Anyway,no boot either in generic or huge 5.10.1 kernel.

I made changes to my lilo.conf as enorbet instructed. No joy.

My mind raced to the mirror I used and so went to two other mirrors and downloaded the kernel files again just in case something was corrupt.
Rebooted and ONCE the generic kernel booted. ONLY ONCE. The boot process stops in a different place almost every time.

When I use the 5.4.84 kernel there is no problem but the 5.10.1 kernel gives me no joy.

tramtrist · 12-21-2020, 09:42 PM

Do you have another PC you could try to SSH in from to see the logs? My Lenovo had similar issues with the framebuffer. For whatever reason using grub or rEFInd fixed the framebuffer issue.