[SOLVED] Kernel 5.10.29 causing endless reboots on Celeron 1017U

I've upgraded this laptop last week to -current 64bits. Today I finally decided to bite the bullet and upgrade the kernel as well. Unfortunately I haven't been able to get it to boot with 5.10.29. I am using eLilo, and generated an initrd.gz exactly the same as for the previous kernel which I have installed and working. After elilo, I can see only the following two messages

Loading kernel ... done
Loading initrd.gz ... done

... and then it immediately reboots.

1. Currently working kernel is 4.9.45 - I have managed to boot back into it fine - as I kept the kernel and modules for it just in case.
2. This is an Acer B113 laptop with Celeron 1017U
3. I have generated the initrd.gz with the same parameters as for the kernel which is working (I use dm-crypt for root partition):

mkinitrd -c -k 5.10.29 -f ext4 -m uhci-hid:usbhid:hid-generic -r /dev/mapper/lukssda3 -C /dev/sda3 -L

I tried to append "noapic" and "nomodeset" - but they don't seem to make any difference. Are there any other parameters I could try to pass to the kernel - to at least get some meaningful error message?

Hello xj25vm
One fix would be building your own kernel from source possibly using the "make localmodconfig" to catch all that is presently loaded and running while keeping it lean (may not even need an initrd unless you encrypt root) OR you could just try the "Huge" version of 5.10.29 to confirm that it isn't a fault in the kernel version but far more likely a problem in your initrd. I won't know what that is or even could be since I never use an initrd but it surely seems that is at issue.

Thank you for the suggestions. I do already use the huge kernel - both for 4.9.45 and for the new 5.10.29. Also, the root partition is encrypted, so I have to use an initrd. I'm not sure if building my own kernel wold actually solve the problem, as there is no esoteric hardware on this laptop - and it might be an initrd issue after all.

Hi.
I had a very similar problem using rEFInd instead of elilo. Two lines very similar to those you posted, and then nothing. After a lot of poking, reverting to rEFInd's default settings solved the problem for me, though it was introduced with a kernel update in -current. I also think it is related to graphics (KMS?) stuff.
I'm using the kernel's EFI stub loader after rEFInd (documentation), and also have an encrypted /root.
I hope this helps.

edit: One difference I notice is that when I `mkinitrd`, the -r parameter just has the "cryptsetup name" of the encrypted partition, without "/dev/mapper/" in front.

Originally Posted by someone named bert Hi. I had a very similar problem using rEFInd instead of elilo. Two lines very similar to those you posted, and then nothing. After a lot of poking, reverting to rEFInd's default settings solved the problem for me, though it was introduced with a kernel update in -current. I also think it is related to graphics (KMS?) stuff. I'm using the kernel's EFI stub loader after rEFInd (documentation), and also have an encrypted /root. I hope this helps. edit: One difference I notice is that when I `mkinitrd`, the -r parameter just has the "cryptsetup name" of the encrypted partition, without "/dev/mapper/" in front.

Thank you very much for that. I couldn't really revert anything to default, as elilo.conf has a very simple structure with only a few essential options. However, your comments gave me an idea. I went to check the elilo binary in the EFI partition, and the one in /boot - and discovered that the one in /boot was from 2018 and the one in the EFI partition was from 2016. There must have been an update at some point. I copied the newest elilo binary to the EFI partition - and now I can boot kernel 5.10.29 without any errors. Very happy!