Bug#922234: Stretch stuck after loading initial ramdisk

[Franz Danzi]

Package: linux-image-amd64
Version: 4.9+80+deb9u6

Trying to boot will lead to a hung system after the message "loading
initial ramdisk". Ctrl-Alt-Del will not work. I have to switch off the
machine the hard way.

Workaround I:
This behavior first appeared a while ago (maybe 2-3 months) after an
update (as usual simply with synaptic) and after switching the machine
off and on again the second try was always successful.

Workaround II:
Today the behavior changed and the problem became more severe. Switching
the machine off and on again will no longer solve the problem. Instead I
boot the same kernel into recovery mode. Then I press Ctrl-D to continue
the boot process and everything seems normal.

Environment:
There are 3 operating systems present on my machine. Windows10, Debian
Jessie and Debian Stretch. All started by the bootloader of Stretch.
I use the XFCE Desktop environment.
Kernel: Linux deb9tst 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27)
x86_64 GNU/Linux

An additional remark:
I remember there was quite recently a kernel update which asked me
something about the configuration. I had the options to view the
configurations, change them and so on. I decided to just use the old
configuration file. The problem started short after this.

[Franz Danzi]

I just wanted to let you know the behavior cannot be reproduced with
100% success. After I wrote the initial bugreport I performed updates
with synaptic and then a reboot. With "touch /forcefsck" first and then
reboot the system came up normal.

[Franz Danzi]

Hello.

It seems as if I found a solution for the problem (Stretch stuck after
loading initial ramdisk).

Recently I installed two driver packages:
firmware-misc-nonfree 20161130-4
nvidia-driver 390.87-8~deb9u1

Obviously this replaced the nouveau driver which was used before.

The boot problem did not happen again since then.

Best regards!

[j***@guillain.net]

I have the exact same problem on one of my servers.
To be precise, no boot problem with Debian kernels up to 4.9.0-7
included.
But I encounter the same issue whith 4.9.0-8 and 4.9.0-9 : a blank
screen with a blinking cursor just after the 'Loading initial ramdisk
..." message.

What is really frustrating is that I couldn't find a way to have a
message about what is happening. I tried all the 'break' parameter
values on the kernel command line, I tried the debug parameter, I
changed the rootdelay. Nothing but this blinking cursor.

The only workaround is acutally to remove firmware-misc-nonfree.
(I also try to use the backport version of this package with no luck...)

But this breaks some of the depencies of my setup, so I will just boot
on 4.9.0-7 until this issue is solved.

I'll be very happy to help if you tell me how to generate any message
during the boot.

[o***@shivaserv.fr]

Hi,

Got the same bug on 4.9.0-9 running on a DELL T630 server.

After removing firmware-misc-nonfree and update initramfs, it's booting fine.
4.9.0-8 was not working too. I had to get back to 4.9.0-4 (didn't have other versions).

[Christian Balzer]

Hello,

just wanted to confirm that this is still ongoing and turned a significant
number of my sparse hairs gray in the middle of last night.

This is on a Supermicro SYS-2028TP-DC0FR/X10DRT-PIBF with
Intel I350 and 82575EB ethernet interfaces and Mellanox ConnectX-3 in case
anybody is taking notes which firmware driver might be the culprit.

I also had to revert to the oldest (4.9.0-4) kernel to get this working and
have to basically consider everything with Stretch backport kernels to be
non-bootable at this point.

would be nice if somebody from the kernel team could pipe up so we can
provide more info if needed.

Regards,

Christian

[Debian Bug Tracking System]

Your message dated Tue, 24 Sep 2019 15:28:32 +0100
with message-id <***@decadent.org.uk>
and subject line Re: possibly solved
has caused the Debian Bug report #922234,
regarding Stretch stuck after loading initial ramdisk
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)