GNU bug report logs - #76554
Laptop screen blank after kexec reboot

Previous Next

To reply to this bug, email your comments to 76554 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Laptop screen blank after kexec reboot
Date: Tue, 25 Feb 2025 15:50:55 +0100

Hello,

After rebooting with ‘reboot -k’, my laptop’s screen remains blank.  I
have to type my LUKS passphrase blindly and then it boots fine, even
displays stuff normally on its external monitor, but its own monitor
remains desperately blank.

That’s a 2016 HP laptop with Intel graphics.

Are there known remedies?

At the Guix Days, someday said they experienced a similar problem.

Ludo’.

Message #8 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 76554 <at> debbugs.gnu.org
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Wed, 26 Feb 2025 23:10:50 +0100

Hello Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> After rebooting with ‘reboot -k’, my laptop’s screen remains blank.  I
> have to type my LUKS passphrase blindly and then it boots fine, even
> displays stuff normally on its external monitor, but its own monitor
> remains desperately blank.

Interesting.  I just tested it and both internal and external monitor
will remain blank until the passphrase is entered.

Reconnecting the external monitor will not help either.  They appear to
be switched off.


Kind regards

-- 
Simon

Message #11 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Simon Streit <simon <at> netpanic.org>
Cc: 76554 <at> debbugs.gnu.org
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Thu, 27 Feb 2025 17:30:51 +0100

Hello,

Simon Streit <simon <at> netpanic.org> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> After rebooting with ‘reboot -k’, my laptop’s screen remains blank.  I
>> have to type my LUKS passphrase blindly and then it boots fine, even
>> displays stuff normally on its external monitor, but its own monitor
>> remains desperately blank.
>
> Interesting.  I just tested it and both internal and external monitor
> will remain blank until the passphrase is entered.
>
> Reconnecting the external monitor will not help either.  They appear to
> be switched off.

Oh, worse that what I experienced.

Do you happen to know if it works on other distros with the same
hardware?

It seems to me that it’s a Linux issue because there’s very little we
can do as kexec users, but who knows.

Ludo’.

Message #14 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 76554 <at> debbugs.gnu.org
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Sun, 02 Mar 2025 19:06:09 +0100

Ludovic Courtès <ludo <at> gnu.org> writes:

> Oh, worse than what I experienced.

Still more convenient than typing in the password two times.  I first
thought kexec was not working.  It is an improvement for me already. :)

I just did a reboot with kexec from kexec-tools on an identical machine
running Debian Bookworm with LUKS encryption:

The screen goes on with a blinking prompt.  The external video is on too
and can plug it in and out again.

I just tried it manually with kexec from kexec-tools in Guix.  The
display stayed dark here too and I somehow didn't manage to unlock
the device.  The HDD-Lamp hinted that something was happening.

I looked into dmesg and /var/log/messages.  I see a time gap until the
partition is mounted.  But no hint that a video or state of hardware is
being changed:

--8<---------------cut here---------------start------------->8---
[    2.735156] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.735161] usb 1-2: Product: Biometric Coprocessor
[    2.735165] usb 1-2: Manufacturer: STMicroelectronics
[    2.874331] Btrfs loaded, zoned=yes, fsverity=yes
[   32.859424] PM: Image not found (code -22)
[   32.874392] BTRFS: device label LABEL devid 1 transid 408044 /dev/dm-0 (253:0) scanned by init (1)
[   32.875143] BTRFS info (device dm-0): first mount of filesystem HASHVALUE
[   32.875162] BTRFS info (device dm-0): using crc32c (crc32c-generic) checksum algorithm
[   32.875179] BTRFS info (device dm-0): using free-space-tree
[   35.910187] shepherd[1]: GNU Shepherd 1.0.2 (Guile 3.0.9, x86_64-unknown-linux-gnu)
[   35.910434] shepherd[1]: Starting service root...
[   35.911316] shepherd[1]: Service root started.
[   35.911676] shepherd[1]: Service root running with value #<<process> id: 1 command: #f>.
[   35.912303] shepherd[1]: Service root has been started.
[   35.918603] shepherd[1]: starting services...
--8<---------------cut here---------------end--------------->8---

Hope that is getting us a bit further.


Kind regards

-- 
Simon

Message #17 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Simon Streit <simon <at> netpanic.org>
Cc: 76554 <at> debbugs.gnu.org, Wilko Meyer <w <at> wmeyer.eu>,
 Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Tue, 04 Mar 2025 15:36:00 +0100

Hi Simon,

(Cc: kernel team.)

Simon Streit <simon <at> netpanic.org> skribis:

> I just did a reboot with kexec from kexec-tools on an identical machine
> running Debian Bookworm with LUKS encryption:
>
> The screen goes on with a blinking prompt.  The external video is on too
> and can plug it in and out again.
>
> I just tried it manually with kexec from kexec-tools in Guix.  The
> display stayed dark here too and I somehow didn't manage to unlock
> the device.  The HDD-Lamp hinted that something was happening.
>
> I looked into dmesg and /var/log/messages.  I see a time gap until the
> partition is mounted.  But no hint that a video or state of hardware is
> being changed:

Interesting.  Could it be that we’re missing something from the kernel?
The syscall interface that we use in Guix (kexec_file_load(2)) and
Shepherd (reboot(2)) is very high-level and we cannot get more control
on graphics or whatever at that level.

I just checked and systemd invokes the ‘kexec’ program from kexec-tools.
I don’t think the ‘kexec’ program is doing anything more in the
‘kexec_file_load’ case (it can also use the obsolescent kexec_load(2)
and in fact most of the code is here to handle that case).

Thoughts?

Ludo’.

Message #20 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Evgeny Pisemsky <mail <at> pisemsky.site>
To: 76554 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Simon Streit <simon <at> netpanic.org>
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Sat, 12 Apr 2025 17:29:44 +0300

Hi, in my case I can see something on the screen after reboot, but
very dark. This hints that the problem in a backlight, and it is so:

#+begin_example
cd /sys/class/backlight/intel_backlight/

cat brightness
0

cat max_brightness
4437

cat max_brightness > brightness
#+end_example

The last command (run from root) makes my screen light up again.

Message #23 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Evgeny Pisemsky <mail <at> pisemsky.site>
Cc: 76554 <at> debbugs.gnu.org, Simon Streit <simon <at> netpanic.org>
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Mon, 14 Apr 2025 09:04:31 +0200

Hi,

Evgeny Pisemsky <mail <at> pisemsky.site> writes:

> Hi, in my case I can see something on the screen after reboot, but
> very dark. This hints that the problem in a backlight, and it is so:

Good catch; I just checked and it’s exactly the same for me.

> #+begin_example
> cd /sys/class/backlight/intel_backlight/
>
> cat brightness
> 0
>
> cat max_brightness
> 4437
>
> cat max_brightness > brightness

Which makes me wonder: should we do this in an activation snippet?

Is this an Intel-specific problem?

Thanks,
Ludo’.

Message #26 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Noé Lopez <noe <at> xn--no-cja.eu>
To: 76554 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Evgeny Pisemsky <mail <at> pisemsky.site>, Simon Streit <simon <at> netpanic.org>
Subject: Re: Laptop screen blank after kexec reboot
Date: Mon, 14 Apr 2025 16:11:36 +0200

[Message part 1 (text/plain, inline)]

> Hi,
> 
> Evgeny Pisemsky <mail <at> pisemsky.site> writes:
> 
> > Hi, in my case I can see something on the screen after reboot, but
> > very dark. This hints that the problem in a backlight, and it is so:
> 
> Good catch; I just checked and it’s exactly the same for me.
> 
> > #+begin_example
> > cd /sys/class/backlight/intel_backlight/
> >
> > cat brightness
> > 0
> >
> > cat max_brightness
> > 4437
> >
> > cat max_brightness > brightness
> 
> Which makes me wonder: should we do this in an activation snippet?
> 
> Is this an Intel-specific problem?
> 
> Thanks,
> Ludo’.

I can confirm that on my end with an intel_backlight the tty is set on
minimal brightness only on kexec reboot. And I don’t use LUKS.

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Streit <simon <at> netpanic.org>
Cc: 76554 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Sat, 26 Apr 2025 22:32:28 +0900

Hi Simon,

Simon Streit <simon <at> netpanic.org> writes:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Oh, worse than what I experienced.
>
> Still more convenient than typing in the password two times.  I first
> thought kexec was not working.  It is an improvement for me already. :)
>
> I just did a reboot with kexec from kexec-tools on an identical machine
> running Debian Bookworm with LUKS encryption:
>
> The screen goes on with a blinking prompt.  The external video is on too
> and can plug it in and out again.
>
> I just tried it manually with kexec from kexec-tools in Guix.  The
> display stayed dark here too and I somehow didn't manage to unlock
> the device.  The HDD-Lamp hinted that something was happening.

So just to make sure I got that right, it works correctly on Debian but
incorrectly (black screen) on Guix System on the *same* hardware?

If correct, that'd probably point to our kernel configuration (or
non-free firmware?  do you you use linux-firmware on Debian and not on
Guix System (through nonguix or the likes)) ?

It'd be interesting to see what happens if you use Linux-libre on your
Debian machine and try the same.  Perhaps attach your Debian's
/proc/config.gz that works so that we can diff with ours for clues.

As another data point: I have the black screen issue when I use 'reboot
--kexec', but in my case it's not the backlight that is too low, the
video signal is completely cut and my external monitor (it's a desktop)
goes into standby.  That's with a modern Ryzen 9 machine and its iGPU
for the video (which sadly requires firmware blobs for 3D acceleration
and hardware video decoding).

-- 
Thanks,
Maxim

Message #32 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 76554 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Sun, 27 Apr 2025 19:53:52 +0200

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> So just to make sure I got that right, it works correctly on Debian
> but incorrectly (black screen) on Guix System on the *same* hardware?

correct.

> If correct, that'd probably point to our kernel configuration (or
> non-free firmware?  do you you use linux-firmware on Debian and not on
> Guix System (through nonguix or the likes)) ?

Just booted a libre kernel and confirm that it is still the case: A
blank screen to enter the password.


Kind regards

-- 
Simon

Message #35 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Simon Streit <simon <at> netpanic.org>
Cc: 76554 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Mon, 05 May 2025 15:25:40 +0200

Simon Streit <simon <at> netpanic.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> So just to make sure I got that right, it works correctly on Debian
>> but incorrectly (black screen) on Guix System on the *same* hardware?
>
> correct.

Actually we “just” need to set screen brightness at activation-time:

  https://issues.guix.gnu.org/76554#5

Ludo’.

Message #38 received at 76554 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 76554 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#76554: Laptop screen blank after kexec reboot
Date: Tue, 06 May 2025 07:56:27 +0200

Ludovic Courtès <ludo <at> gnu.org> writes:

> Simon Streit <simon <at> netpanic.org> writes:
>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>>
>>> So just to make sure I got that right, it works correctly on Debian
>>> but incorrectly (black screen) on Guix System on the *same* hardware?
>>
>> correct.
>
> Actually we “just” need to set screen brightness at activation-time:
>
>   https://issues.guix.gnu.org/76554#5

Unfortunately it is not just the brightness at its lowest setting.  I
have no video signal on my machine to begin with.  If that would be the
case, then the back light of the screen is usually visible while powered
on.  Despite that, once the disk is unlocked and the boot process
completed the screen does activate at the lowest brightness level.

This might mean that on some machines the screen does go on, while on
others it doesn't.  Maybe there are others that can report on this
issue?

I currently don't have a different type of machine to test this
scenario.


Kind regards

-- 
Simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.