grub2 freezes on "loading initial ramdisks"

Something very weird is happening in the latest version of openSUSE Tumbleweed; After restarting my computer, I suddenly discovered that grub2 was broken by an update! It would no longer reach the GUI (forgot the exact error message) and entered a grub2 recovery prompt. I had to boot the openSUSE DVD in rescue mode, and reinstall grub2 entirely. After that, the boot loader started showing up and working again… but now I run into another problem:

Whenever I attempt to start openSUSE normally, it freezes at the message “loading initial ramdisks”, exactly before the screen would normally go blank for a bit then the splash screen begins showing. The issue seems to be probabilistic, but most of the time the system will never boot and just remains stuck that way. I seem to be able to work around this by selecting “Advanced options for openSUSE” and selecting my kernel manually.

This problem has never happened before, and only seems to be occurring as of today or last night. Does anyone know what’s causing grub2 to freeze on “loading initial ramdisks” and can replicate this problem?

It is probably not grub2 causing your problem. Perhaps it is plymouth. When you use recovery mode, the plymouth splash screen is not shown, and that seems to be what works for you.

Ah… it’s possible in that case. Although normally, grub2 goes through the following steps for me:

  1. I briefly see a piece of text in the console, saying “welcome to grub” or something similar. This lasts for less than a second.
  2. The resolution changes and I’m in the themed grub2 GUI, where the timer counts down from 7 and I can choose between “openSUSE” or “Advanced options for openSUSE”.
  3. A black panel appears on top of this GUI, saying which kernel is being booted followed by the message “loading initial ramdisks”. This normally shows for about 3 seconds at most… the problem is that it’s now indefinite.
  4. I’m taken to a black console where a few messages are printed, most about loading kernel modules and beginning with a green [ok] label. This also lasts for about 3 seconds.
  5. The plymouth splash screen starts showing.

The problem with that possibility is, the machine freezes at step 3, not at 4. Also step 1 is where I was stuck when I noticed the bootloader got corrupted, which is a separate problem that might exist in Tumbleweed right now!

At present, on one system, here’s what I see:

First, I see the grub menu.
Then I see it load the kernel. Then I see two more lines. And, after that, nothing happens.

However, if I then use CTRL-ALT-F7, I see the plymouth screen where it is prompting me for disk encryption key. I enter that, and booting continues.

So something is messed up related to plymouth.

I discussed this on IRC in parallel, and people are suggesting this might be plymouth related. I tried the following: “dracut -f” to remake initrd, reinstalled grub2 from YaST - Boot Loader, reinstalling all plymouth related packages.

I rebooted once more: Normal boot option causes the freeze, advanced boot option works. But here’s the funny thing: I do in fact see the splash screen for the advanced choice as well, with which I seem to not be getting issues! Mind you, the splash screen has been broken for some time… it’s just a gray background with three green ??? characters instead of images. I think this is a different issue however, as it’s been like this for much much longer.

Grub2 is broken again.


I have this problem when Tumbleweed is installed on a different partition or drive.

Adding GRUB_GFXPAYLOAD_LINUX=keep to /etc/default/grub should enable Plymouth.

Is it related to this freeze though? Because again, one boot option works the other doesn’t, but the one that does still shows the (broken) plymouth screen meaning it isn’t disabling it entirely! It would be a relief to see this crash officially confirmed.

After a major package update today, the issue appears to have been fixed; I was able to boot the system twice using the normal boot option, and no more freezes have occurred. Please wait a few days until closing this issue to be safe, considering the crash seemed to have a probabilistic factor: I will comment again if it keeps happening, otherwise this has been solved.

After the update, check the change log to see what was changed. I also create a bug report as soon as I experience these issues asap to get bugs fixed quickly especially with the kernel.
This is how you confirm that bugs exist. More people need to report these critical errors.

I added to GRUB_CMDLINE_LINUX_DEFAULT=“debug irqpoll ipv6.disable=1” to /etc/default/grub following the “grub2-mkconfig -o /boot/grub/grub.cfg” ( without the quotes)
as this is the way to get additional information on what may be causing this problem with the kernel.

Another option to try is to add to kernel boot parameters: