After update: Boot process stops at Load initial ramdisk

**PolderPenguin** · 25-Nov-2020, 07:49

My wife works with an Asus Zenbook UX305 laptop with openSUSE Leap 15.2, for long years without any trouble. Kernel version is now 5.3.18-lp152.50-default, still no problems. Today I had to install lots of updates, 98 in total. After that update, boot process stops at Load initial ramdisk. Of course Snapper helped me undoing the update. I suspected some problems with grub and shim and mok, so for a second try I did an update without updating kernel-firmware and grub, but all for the same, boot did not continue. Am I now stuck without updating possibility? System IS a dual boot with Windows 7 which we never use, but is of course present. Nothing special in /boot/efi/EFI/opensuse or in /boot/grub2. Secure boot is on. I've tried booting with nomodeset, without result. What is happening? I work with openSUSE since more than 20 years now -- first time I'm having this kind of problem.

Thanks for any help!

**arvidjaar** · 25-Nov-2020, 08:09

Try booting without "quiet" and with plymouth.enable=0 on kernel command line. This may give some more information how far kernel was able to boot.

**nrickert** · 25-Nov-2020, 08:57

Originally Posted by PolderPenguin

Am I now stuck without updating possibility?

Firstly, I'll agree with arvidjaar on attempting to boot without plymouth -- to see if that gives additional information.

Secondly, I would next try booting with the previous kernel. You can select that with the "Advanced options" grub menu entry. If the previous kernel works, but this one doesn't, then you might have run into a kernel bug.

Assuming that the previous kernel works, my next step would be to edit "/etc/zypp/zypp.conf". Look for the line:

Code:

multiversion.kernels = latest,latest-1,running

and change that to:

Code:

multiversion.kernels = oldest,latest,latest-1,running

That is, insert "oldest" in the list of kernels to retain. That way, the kernel that you know to work will not go away until you revert that line.

After that, I would continue to install updates, knowing that I could always boot with that older kernel.

There might already be a bug report for the kernel that is giving problems. If not, you could report a bug yourself.

**PolderPenguin** · 26-Nov-2020, 08:03

Thanks for your help! In fact, what caused the trouble was one of the 105 updates and I needed some time to be sure which one. It was no kernel or shim matter ... it was update 2020-1923 UCODE-INTEL (version 20201027) that completely blocked every booting (without quiet and with plymouth.enable=0 I got absolutely nothing on my screen, nothing at all was happening). So I could install every update without problems BUT NOT THAT ONE. My ASUS ZenBook UX305 has 4 Intel processors, so it seems a bit strange that precisely Suse's update of “this package that contains the microcode update blobs for Intel x86 and x86-64 CPUs" should block every booting ...
For me the case is closed, everything works and I won't update that ********** “ucode-intel” anymore. Should I claim a bug, I don't know, I never did that, I'm asking your advice ...
Have a nice day, all of you!

**nrickert** · 26-Nov-2020, 08:33

Originally Posted by PolderPenguin

Should I claim a bug, I don't know, I never did that, I'm asking your advice ...

Yes, file a bug report. In the meantime, you can lock that package so that it is never update until you remove the lock. Easiest way to lock is with Yast Software Management. Search for the package, then right-click to see the lock option.

For filing a bug report, use: https://en.opensuse.org/openSUSE:Submitting_bug_reports
The same login/password that you use for the forums should work.