Devuan bug report logs - #617
initscripts: brightness init script sets brightness to zero, thus blanking laptop display

Reply or subscribe to this bug.

Toggle useless messages

---

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

Package: initscripts
Version: 2.96-7+devuan1
Severity: normal
X-Debbugs-Cc: martin@lichtvoll.de

Just updated Devuan Ceres today and found the display being blanked during
the boot process. I was able to recover over SSH using

% brightnessctl
Device 'intel_backlight' of class 'backlight':
        Current brightness: 0 (0%)
        Max brightness: 512

% brightnessctl set 100%
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
        Current brightness: 512 (100%)
        Max brightness: 512

Yet running '/etc/init.d/brightness start' blanked the display again. This
is due to:

% cat /var/lib/initscripts/brightness.intel
0

I have no idea how this value got into this file. The display was certainly
not at 0% brightness as I rebooted after the update.

Expected result:

Never ever blank the display on boot even in case
'/var/lib/initscripts/brightness.intel' contains the value zero.

Just don't.

Expected result 2:

Safe the right value to '/var/lib/initscripts/brightness.intel'. Zero is
definitly not it.

If I run:

% echo 512 > /var/lib/initscripts/brightness.intel
% /etc/init.d/brightness start

After sending this bug report I will reboot and see whether it will remember
this value. Otherwise I will 'chattr +i' this file for now.

This is on a ThinkPax X260 with Intel on board graphics from
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz CPU.

Thanks,
Martin

-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 4 (daedalus/ceres)
Release:	5
Codename:	daedalus/ceres
Architecture: x86_64

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages initscripts depends on:
ii  lsb-base  11.1.0
ii  sysv-rc   2.96-7+devuan1

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.4-1
ii  psmisc     23.4-2

initscripts suggests no packages.

-- no debconf information

---

Message #8 received at 617@bugs.devuan.org (full text, mbox, reply):

Martin,

Thanks for this.

The brightness initscript seems to save
/sys/class/backlight/intel_backlight/brightness to
/var/lib/initscripts/brightness when it is stopped.

On your system, what does the /sys/class/backlight/intel_backlight/brightness
contain?

Mark

---

Message #13 received at 617@bugs.devuan.org (full text, mbox, reply):

Dear Mark.

Mark Hindley - 11.10.21, 19:06:44 CEST:
> The brightness initscript seems to save
> /sys/class/backlight/intel_backlight/brightness to
> /var/lib/initscripts/brightness when it is stopped.
> 
> On your system, what does the
> /sys/class/backlight/intel_backlight/brightness contain?

I can check tomorrow again. However… after I wrote "512" to the
"/var/lib/initscripts/brightness" file, brightness is set correctly after 
reboot. So I am not sure I can reproduce the original condition after 
the update anymore.

So or so, I think it would be good to ensure a minimum brightness level, 
as a completely blank display can only be fixed with a live Linux, SSH 
access or some other out of band management access.

Best,
-- 
Martin

---

Message #18 received at 617@bugs.devuan.org (full text, mbox, reply):

Dear Mark.

Mark Hindley - 11.10.21, 19:06:44 CEST:
> Thanks for this.
> 
> The brightness initscript seems to save
> /sys/class/backlight/intel_backlight/brightness to
> /var/lib/initscripts/brightness when it is stopped.
> 
> On your system, what does the
> /sys/class/backlight/intel_backlight/brightness contain?

I think I know what happened.

After booting the laptop I get:

% cat /sys/class/backlight/intel_backlight/brightness
512

However after KDE Plasma blanked the screen due to inactivity I got:

% cat /sys/class/backlight/intel_backlight/brightness
0

Now when I shutdown the system regularly using the GUI, Plasma would 
raise the brightness again as I move the mouse pointer. However, when I 
reboot from SSH as I did yesterday after the update, it won't.

The script takes writes zero into its state file and that it is.

Due to that I think the whole assumption that it is a sane idea to 
restore the backlight state to what has been set at the time of 
rebooting is fundamentally broken.

Actually it was one of the reasons why I switched from systemd to runit. 
Cause at one point Systemd in Debian was configured to do something 
similar and it causes some of my machines to boot up with blank and at a 
later at least very dark display.

Of course you may argue not to reboot a desktop machine via SSH. But why 
wouldn't I do so for my music player laptop?

I do not have a good idea on how to fix this issue at the moment. A work-
around would be to ensure a minimum brightness of at least 10% or 20%. 
Another idea would be to tell the desktop environment to unblank the 
screen before logging off or ask the desktop environment developers to do 
so in all cases. Or you'd just use say 80% of brightness as a default 
value and put a file into /etc to let the user manually configure it.

The best solution would be to somehow grab the *intended* brightness 
value during operation and not ever take the one during inactivity where 
the screen is blanked. But also this depends on the desktop environment. 
So… it is likely to become messy and complex.

My personal work-around for now will likely be to disable the stop 
operation of that script.

Best,
-- 
Martin

---

Message #23 received at 617@bugs.devuan.org (full text, mbox, reply):

Martin,

Thanks for your analysis. At least that makes sense, even if a clean solution is
not immediately obvious.

Creating and artificial minimum seems rather arbitrary and would a minimum of,
say, 20% of the maximum value even be sane and suitable on all hardware? I don't
have any suitable hardware for real testing, so would have to rely on reports
from you and others.

Getting all DEs to cooperate in unblanking seems a tall order.

I agree the script seems suboptimal in many ways.

Maybe we could support configuring a minimum in /etc/default/brightness?

At least you have a workaround that will avoid the issue for you again. If you
get any other ideas about clean fixes, do say.

Mark

---

Message #28 received at 617@bugs.devuan.org (full text, mbox, reply):

Hi,

Martin Steigerwald writes:

> Dear Mark.
>
> Mark Hindley - 11.10.21, 19:06:44 CEST:
>> The brightness initscript seems to save
>> /sys/class/backlight/intel_backlight/brightness to
>> /var/lib/initscripts/brightness when it is stopped.
>>
>> On your system, what does the
>> /sys/class/backlight/intel_backlight/brightness contain?
>
> I can check tomorrow again. However… after I wrote "512" to the
> "/var/lib/initscripts/brightness" file, brightness is set correctly after
> reboot. So I am not sure I can reproduce the original condition after
> the update anymore.
>
> So or so, I think it would be good to ensure a minimum brightness level,
> as a completely blank display can only be fixed with a live Linux, SSH
> access or some other out of band management access.

Does this mean that even switching to the console (Ctrl-Alt-F1, etc)
doesn't give you a screen where can see what you're doing?

Just wondering,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join

---

Message #33 received at 617@bugs.devuan.org (full text, mbox, reply):

Olaf Meeuwissen - 12.10.21, 13:14:17 CEST:
> Hi,
> 
> Martin Steigerwald writes:
> > Dear Mark.
> > 
> > Mark Hindley - 11.10.21, 19:06:44 CEST:
> >> The brightness initscript seems to save
> >> /sys/class/backlight/intel_backlight/brightness to
> >> /var/lib/initscripts/brightness when it is stopped.
> >> 
> >> On your system, what does the
> >> /sys/class/backlight/intel_backlight/brightness contain?
> > 
> > I can check tomorrow again. However… after I wrote "512" to the
> > "/var/lib/initscripts/brightness" file, brightness is set correctly
> > after reboot. So I am not sure I can reproduce the original
> > condition after the update anymore.
> > 
> > So or so, I think it would be good to ensure a minimum brightness
> > level, as a completely blank display can only be fixed with a live
> > Linux, SSH access or some other out of band management access.
> 
> Does this mean that even switching to the console (Ctrl-Alt-F1, etc)
> doesn't give you a screen where can see what you're doing?

Yes. I tried via Ctrl-Alt-F1 on the laptop and via SSH with "chvt 1". 
Nothing.

Ciao,
-- 
Martin

---

Message #38 received at 617@bugs.devuan.org (full text, mbox, reply):

On Tue, Oct 12, 2021 at 11:07:53AM +0100, Mark Hindley wrote:
> At least you have a workaround that will avoid the issue for you again. If you
> get any other ideas about clean fixes, do say.

Why not just refuse to *update* to 0 at shutdown.  It seems like 0 is a 
special case the user is fairly unlikely to have set it to themself (but 
if they do want 0 they are probably technical enough to update the 
setting file on their own).

-Jacob

---

Message #43 received at 617@bugs.devuan.org (full text, mbox, reply):

Dear Mark, dear Jacob

Jacob Lundberg - 12.10.21, 19:19:50 CET:
> On Tue, Oct 12, 2021 at 11:07:53AM +0100, Mark Hindley wrote:
> > At least you have a workaround that will avoid the issue for you
> > again. If you get any other ideas about clean fixes, do say.
> 
> Why not just refuse to *update* to 0 at shutdown.  It seems like 0 is
> a special case the user is fairly unlikely to have set it to themself
> (but if they do want 0 they are probably technical enough to update
> the setting file on their own).

I think that would be a good idea.

I'd really welcome this after I "bricked" another device due to exactly 
this bug. I needed to put GRML to an USB stick and boot from there in 
order to recover.

Have a relaxing, quiet and peaceful time, a merry Christmas!

Best,
-- 
Martin

---

Message #48 received at 617@bugs.devuan.org (full text, mbox, reply):

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

Martin,

On Wed, Dec 22, 2021 at 11:19:17AM +0100, Martin Steigerwald wrote:
> I'd really welcome this after I "bricked" another device due to exactly 
> this bug. I needed to put GRML to an USB stick and boot from there in 
> order to recover.

How does the attached patch look? Are you able to test?

Thanks.

Mark

[0001-brightness-initscript-don-t-save-value-of-0-when-sto.patch (text/x-diff, attachment)]

---

Message #53 received at 617@bugs.devuan.org (full text, mbox, reply):

Hi Mark.

Mark Hindley - 22.12.21, 12:47:55 CET:
> On Wed, Dec 22, 2021 at 11:19:17AM +0100, Martin Steigerwald wrote:
> > I'd really welcome this after I "bricked" another device due to
> > exactly this bug. I needed to put GRML to an USB stick and boot
> > from there in order to recover.
> 
> How does the attached patch look? Are you able to test?

The patch looks good to me. I think I am able to test it on one machine. 
May take some time though.

Best,
-- 
Martin

---

Message #58 received at 617@bugs.devuan.org (full text, mbox, reply):

Mark,

Mark Hindley - 22.12.21, 12:47:55 CET:
> On Wed, Dec 22, 2021 at 11:19:17AM +0100, Martin Steigerwald wrote:
> > I'd really welcome this after I "bricked" another device due to
> > exactly this bug. I needed to put GRML to an USB stick and boot
> > from there in order to recover.
> 
> How does the attached patch look? Are you able to test?

I tested on a ThinkPad laptop with Intel graphics:

Without patch:

root@somehost:/var/lib/initscripts# cat brightness.intel 
512
root@somehost:/var/lib/initscripts# /etc/init.d/brightness stop
root@somehost:/var/lib/initscripts# cat brightness.intel 
0

With patch:

root@somehost:/var/lib/initscripts# echo 512 > brightness.intel 
root@somehost:/var/lib/initscripts# cat brightness.intel 
512

root@somehost:/var/lib/initscripts# /etc/init.d/brightness stop
root@somehost:/var/lib/initscripts# cat brightness.intel 
512

I think it should work.

Thanks,
-- 
Martin

---

Message #63 received at 617@bugs.devuan.org (full text, mbox, reply):

Martin,

On Thu, Dec 23, 2021 at 02:47:19PM +0100, Martin Steigerwald wrote:
> I think it should work.

Thanks.  I will build a new version over the next few days.

Mark

---

Message #66 received at 617@bugs.devuan.org (full text, mbox, reply):

Control: tags -1 pending patch

Martin,

On Sun, Dec 26, 2021 at 09:56:07AM +0000, Mark Hindley wrote:
> Martin,
> 
> On Thu, Dec 23, 2021 at 02:47:19PM +0100, Martin Steigerwald wrote:
> > I think it should work.
> 
> Thanks.  I will build a new version over the next few days.

My apologies, this completely slipped my mind.

I have merged it for the next upload.

Mark

---

Message #73 received at 617-done@bugs.devuan.org (full text, mbox, reply):

Version: 3.06-4devuan3

Source package sysvinit (3.06-4devuan3) added to Devuan suite unstable.

This closes bug report 617.

Thanks

DAK managing the Devuan archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 17 Apr 2023 10:59:34 +0100
Source: sysvinit
Architecture: source
Version: 3.06-4devuan3
Distribution: unstable
Urgency: medium
Maintainer: Devuan Developers <devuan-dev@lists.dyne.org>
Changed-By: Mark Hindley <mark@hindley.org.uk>
Closes: 617
Changes:
 sysvinit (3.06-4devuan3) unstable; urgency=medium
 .
   * brightness initscript: don't save value of 0 when stopping (Closes: #617).
Checksums-Sha1:
 f91bac2caac34718b879f266ee583a3b5ab76f60 2008 sysvinit_3.06-4devuan3.dsc
 ccb9ab39513f07db02c9f292ae3e5d14d38ed4dd 135856 sysvinit_3.06-4devuan3.debian.tar.xz
 1953ee8f7e0d6b75f925d29257c3f66fd648b1e2 5446 sysvinit_3.06-4devuan3_source.buildinfo
Checksums-Sha256:
 5d70b322d5e1865a20d926c81bc8ac8ee8df229c68c0585552d6b090856fd1bd 2008 sysvinit_3.06-4devuan3.dsc
 da30a29185db600cc85ce50b756fd181aea18889c70d4f2258e112ec398ec7ea 135856 sysvinit_3.06-4devuan3.debian.tar.xz
 a3f158f5294124b4ef38fe279659910253ad26d8523c23b25ea3d6998a78147f 5446 sysvinit_3.06-4devuan3_source.buildinfo
Files:
 1442d1b067dd85e06b9945b17de88c63 2008 admin required sysvinit_3.06-4devuan3.dsc
 be0b36355bf802c32b969cb897666a3f 135856 admin required sysvinit_3.06-4devuan3.debian.tar.xz
 9b7c709e5f4f92a8362c3b9cf6bcb4fc 5446 admin required sysvinit_3.06-4devuan3_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEcuPLdzMV36LkZHQ9lFMhJFQZIvsFAmQ9Gx8ACgkQlFMhJFQZ
Ivswcgf9GeJ1n3P2jXo/9wfKx2V1meSE/fqWcSTEC5O4wU8tXbwZAeioc1ot+JOl
Xvr43figZIWuIq5vlabJrlNZJj6vNnDFutelmQqqDIsR74YKLRKWOvGppDoj7Qr2
X3jmqx8dfLUERYTqSM+OB5WndYYbh9McdSYOi1J6bPA7rjvGrMhKUucX6k0lpZe2
HcWIKBNTV0JkHNb45YhiFWeBHl3p2Tqclf+ENDmcI7yiSVtkJnZjmmImy0Ojim9E
mA2f8alMs/r/6EV3lWc5Tko13294dSJStPmxu8MOePGQ5OsYGWDOnRy0s1NFvJdQ
FyItJJq5W9KwppGzxuLwqM+ozkkm6A==
=u96r
-----END PGP SIGNATURE-----

---

Send a report that this bug log contains spam.

---