Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

lunario · 2017-12-14 21:10:03

I am using devuan ascii on several machines with great pleasure.
This week I got my librebooted Thinkpad X60. Devuan was installed via netinstall and worked fine, but when I upgraded it to ascii, I booted into a black screen afterwards with only the cursor in the upper left cornor (the system was frozen and did not react to any input). I tried several ways to solve the problem, such as reinstalling X in a failsafe root sell (the only thing I could boot into) but nothing helped. I reinstalled devuan and then did the upgrade again to make sure I did not accidentally delete important packages before. Same result though.

Today, I decided to give debian 9 on the system a try (please don't stop reading here ) just for what it's worth, which led to the same result. So the problem is definitely related to changes made between jessie and stretch.
I duckduckgo'ed around a bit and found out that I am not the only one with this problem and that a workaround consists in passing acpi=off as a kernel argument at boot. However, this is not really a desirable state since it disables important hardware features and e.g. prevents the system from shutting down (and I am not planning to just "pull the plug" whenever I want to power off the machine). I also tried passing acpi=noirq as an argument, which apparently solved the problem for some, but in my case it did not.

Has anybody else come across this problem with particular hardware or libreboot? I am not sure whether it is related to hardware or libreboot in my case, but it does not really matter since many people who do NOT use libreboot seem to have the problem as well, with debian 9 (and consequently would have it with devuan ascii too, most likely). Are there any possible explanations for this situation and does anybody maybe have a solution to it?

chillfan · 2017-12-15 10:35:56

It's helpful to narrow down the issue a bit. At what point does the screen go black? Is it immediate or only when the xserver starts?

Last edited by chillfan (2017-12-15 10:42:39)

lunario · 2017-12-15 11:22:44

It goes blank as soon as the login screen (slim/lightdm) would normally appear, in other words: when X starts.
After I deinstalled slim/lightdm to start x with "startx", it did no go blank anymore but instead it froze as soon as XFCE/i3wm started (so I save the basic XFCE desktop with the mouse in the middle but could neither move the mouse nor give any keyboard input, not even to open a virtual console).

chillfan · 2017-12-15 16:23:21

So it's probably the same as this issue.

You could try using noapic or nolapic as a kernel parameter, it's been known to fix some blank screen issues in the past.

Or try with the latest kernel from ascii-backports.

apt-get -t ascii-backports install linux-image-4.13.0-0.bpo.1-amd64

Failing that you could try to use the xorg vesa driver instead of the intel driver.

Last edited by chillfan (2017-12-15 16:25:44)

lunario · 2017-12-15 18:19:01

Would I have to install that kernel after upgrading, or before? Also, does it not break my sources.list if I am on ascii and at the same time add ascii backports?

ralph.ronnquist · 2017-12-15 20:55:05

You should "pin" backports, i.e., add a file "reluctant-backports" with the following into /etc/apt/preferences.d

Package: *
Pin: release a=ascii-backports
Pin-Priority: 100

With that, apt will not upgrade to backports versions of packages unless you ask for them explicitly.

The "-t ascii-backports" argument opens it up a little, so that the nominated package and its dependents get pulled from backports, but nothing else.

Later on, without "-t ascii-backports", only packages already from backports will be upgraded from backports.

lunario · 2017-12-15 22:36:10

Thank you for the explanation.

Just to make sure I am on the safe side and don't need to go through the reinstall process again for some silly mistake, did I get you right that the order of how I do things is the following for upgrading to ascii and installing the ascii-backports kernel:

1. pin the backports as you described
2. apt-get -t ascii-backports install linux-image-4.13.0-0.bpo.1-amd64
3. change etc/apt/sources.list for ascii and do normal apt-get dist-upgrade, which will heed the reluctant-backports file
4. reboot

Is that correct?

chillfan · 2017-12-16 01:02:43

You should upgrade the kernel after the dist-upgrade. If the backported kernel doesn't solve the problem you could just remove it and the backports repo.

To make testing the screen problem a bit easier you could disable the display manager.

update-rc.d -f slim remove

Do this before you dist-upgrade. That should let you upgrade the kernel and make other tests without having to recover.

To start the display manager and test the xserver you can just use

/etc/init.d/slim start

Last edited by chillfan (2017-12-16 01:33:51)

lunario · 2017-12-16 11:14:44

I just found out how to successfully run devuan ascii (mostly), however sadly none of your suggestions really solved the problem (thanks a lot though because they led me to the right track).

After upgrading and installing the new kernel as you suggested, the situation was exactly the same as before, I could not even get into a virtual console unless I was in recovery mode. What helped a bit was replacing the intel driver with vesa because then I could at least get into a normal virtual console, however starting slim or X still did not work (Permission denied).
I then created a xorg.conf (X -configure), which AFAIK should not be necessary these days anymore unless there are video driver issues, moved the xorg.conf.new from /root to /etc/X11, renamed it to xorg.conf and then "startx" would at least open XFCE, however with no reaction to my input. I also tried to manually add a section for the vesa driver in my xorg.conf, which did not solve it. The error error in Xorg.0.log was:

[ 43.712] (EE) modeset(0): drmSetMaster failed: Permission denied
[ 43.712] (EE)
Fatal server error:
[ 43.712] (EE) AddScreen/ScreenInit failed for driver 0

My solution to get devuan ascii running was to change the sources.list back to jessie after upgrading, then deinstall xserver + xorg, reinstall xserver + xorg, xserver-xorg-video-intel -> you get with all packages except X on ascii. After rebooting, some packages naturally needed to be autoremoved and I was worried that this might crash the system again, but somehow it did not.
I am aware that this is not a clean solution, but it solves it for me at least. It also does not allow you to install any ascii packages anymore as soon as you have changed the sources back to jessie of course, but if you really want/need packages from ascii, this works, provided you install them before reinstalling X.

Last edited by lunario (2017-12-16 11:15:38)

chillfan · 2017-12-16 19:45:19

lunario wrote:

After upgrading and installing the new kernel as you suggested, the situation was exactly the same as before, I could not even get into a virtual console unless I was in recovery mode. What helped a bit was replacing the intel driver with vesa because then I could at least get into a normal virtual console, however starting slim or X still did not work (Permission denied).

So you probably can get around the issue by forcing xorg to use only the vesa driver for now. That seems like the best option to me unless you really do need the accelerated driver, at least until you can find a better work-around.

I think the problem with xorg permissions is already known and I noticed there was an update yesterday for the xserver-xorg-legacy package that allows setting permissions for xorg (dpkg-reconfigure xserver-xorg-legacy). Using the console users only setting and starting as root works fine for me.

You seem to have narrowed it down quite a bit there. You only have problems when the intel driver loads so you could try a few work-arounds if you want, like disabling modesetting or maybe try the pci=noacpi boot parameter.

Last edited by chillfan (2017-12-16 20:19:13)

devuser · 2018-04-30 22:31:42

lunario wrote:

[ 43.712] (EE) modeset(0): drmSetMaster failed: Permission denied
[ 43.712] (EE)
Fatal server error:
[ 43.712] (EE) AddScreen/ScreenInit failed for driver 0

Ran into this issue after first upgrade of my devuan setup installed mostly from the beta DVD. What caused it exactly? I don't know. Upgraded kernel? Upgraded X packages (my bet)? I can't really say for sure.

Anyways, searching around yielded posts saying the problem would be related to the xserver-xorg-legacy package and either installing or removing it would fix it. Well, turn out this is already installed on Ascii and removing it changes nothing BUT adding needs_root_rights=yes to /etc/X11/Xwrapper.config actually makes X start. According to the manual page needs_root_rights is by default set to auto so i guess this detection fails somehow?

As far as i understand it the underlying problem seems to be that X needs root rights to init graphics but by default thats now somehow handled by systemd. I guess needs_root_rights=yes is basically synonym to SUID on /usr/lib/xorg/Xorg (at least setting this has the same effect) and somewhere during updates this got removed and coupled with the broken autodetection triggers this bug.

Hope this helps someone who is also baffled why it's desktop suddenly refuses to start.

Edit: https://dev1galaxy.org/viewtopic.php?id=1591 contains more information and points torwards needs_root_rights=yes maybe not being the best way to deal with this.

Last edited by devuser (2018-05-01 12:28:27)

GNUser · 2018-05-04 23:18:25

lunario wrote:

I am aware that this is not a clean solution, but it solves it for me at least. It also does not allow you to install any ascii packages anymore as soon as you have changed the sources back to jessie of course, but if you really want/need packages from ascii, this works, provided you install them before reinstalling X.

Lunario, I also had severe miscellaneous issues with graphics when I upgraded my ThinkPad (T400 with Libreboot) to Ascii. I found that either downgrading X (as you did) or using linux-libre 4.16.2 kernel fixed my problems.

If you choose to stick with the downgraded X, why don't you pin the downgraded packages so that you can go back to using ascii repositories? You just need to remember to pin not only the X packages you explicitly installed, but also their dependencies.

This was the command I used to install the X packages from Jessie:

sudo apt-get install xorg xserver-xorg xserver-xorg-core xserver-input-all xserver-xorg-video-intel xserver-xorg-video-vesa

Looking in /var/log/apt/history.log shows all those packages and their versions, as well as the dependencies and their versions:

Start-Date: 2018-05-01  18:14:37
Commandline: apt-get install xorg xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-video-intel xserver-xorg-video-vesa
Requested-By: bruno (1000)
Install: xserver-xorg-input-all:amd64 (1:7.7+7), xserver-xorg-input-synaptics:amd64 (1.8.1-1, automatic), xserver-xorg:amd64 (1:7.7+7), xserver-xorg-video-vesa:amd64 (1:2.3.3-1+b3), xserver-common:amd64 (2:1.16.4-1+deb8u2, automatic), xserver-xorg-core:amd64 (2:1.16.4-1+deb8u2), x11-apps:amd64 (7.7+4, automatic), xserver-xorg-input-wacom:amd64 (0.26.0+20140918-1, automatic), x11-session-utils:amd64 (7.7+1, automatic), xserver-xorg-input-vmmouse:amd64 (1:13.0.0-1+b3, automatic), xfonts-75dpi:amd64 (1:1.0.3, automatic), xorg-docs-core:amd64 (1:1.7-1, automatic), xserver-xorg-video-intel:amd64 (2:2.21.15-2+b2), xserver-xorg-input-evdev:amd64 (1:2.9.0-2, automatic), xorg:amd64 (1:7.7+7), xfonts-100dpi:amd64 (1:1.0.3, automatic), xfonts-scalable:amd64 (1:1.0.3-1, automatic), xserver-xorg-input-mouse:amd64 (1:1.9.1-1, automatic), libpng12-0:amd64 (1.2.50-2+deb8u3, automatic)
End-Date: 2018-05-01  18:14:46

So in my case, I created /etc/apt/preferences.d/pinned-xorg with this in it:

Package: xserver-xorg-input-all
Pin: version 1:7.7+7
Pin-Priority: 1001

Package: xserver-xorg-input-synaptics
Pin: version 1.8.1-1
Pin-Priority: 1001

Package: xserver-xorg
Pin: version 1:7.7+7
Pin-Priority: 1001

Package: xserver-xorg-video-vesa
Pin: version 1:2.3.3-1+b3
Pin-Priority: 1001

Package: xserver-common
Pin: version 2:1.16.4-1+deb8u2
Pin-Priority: 1001

Package: xserver-xorg-core
Pin: version 2:1.16.4-1+deb8u2
Pin-Priority: 1001

Package: x11-apps
Pin: version 7.7+4
Pin-Priority: 1001

Package: xserver-xorg-input-wacom
Pin: version 0.26.0+20140918-1
Pin-Priority: 1001

Package: x11-session-utils
Pin: version 7.7+1
Pin-Priority: 1001

Package: xserver-xorg-input-vmmouse
Pin: version 1:13.0.0-1+b3
Pin-Priority: 1001

Package: xfonts-75dpi
Pin: version 1:1.0.3
Pin-Priority: 1001

Package: xorg-docs-core
Pin: version 1:1.7-1
Pin-Priority: 1001

Package: xserver-xorg-video-intel
Pin: version 2:2.21.15-2+b2
Pin-Priority: 1001

Package: xserver-xorg-input-evdev
Pin: version 1:2.9.0-2
Pin-Priority: 1001 

Package: xorg
Pin: version 1:7.7+7
Pin-Priority: 1001

Package: xfonts-100dpi
Pin: version 1:1.0.3
Pin-Priority: 1001

Package: xfonts-scalable
Pin: version 1:1.0.3-1
Pin-Priority: 1001

Package: xserver-xorg-input-mouse
Pin: version 1:1.9.1-1
Pin-Priority: 1001

Package: libpng12-0
Pin: version 1.2.50-2+deb8u3
Pin-Priority: 1001

And after that, go ahead and restore ascii's /etc/apt/sources.list, do sudo apt-get update, and you're back to installing packages and upgrading your system normally while keeping the downgraded X packages. Surprisingly, this works well--it seems that the X packages are relatively independent from the rest of the system.

Last edited by GNUser (2018-05-05 18:06:04)

GNUser · 2018-05-05 18:02:12

Sorry for the overly complicated /etc/apt/preferences.d/pinned-xorg above. Here is a much simpler version, that prevents upgrade of these packages by simply giving highest priority to the currently-installed package versions. It accomplishes the same as the above, but is much easier on the eyes and brain:

Package: xserver-*
Pin: release a=now
Pin-Priority: 1001

Package: x11-*
Pin: release a=now
Pin-Priority: 1001

Package: xfonts-*
Pin: release a=now
Pin-Priority: 1001

Package: xorg*
Pin: release a=now
Pin-Priority: 1001

Package: libpng12-0
Pin: release a=now
Pin-Priority: 1001

Last edited by GNUser (2018-05-05 18:04:44)

Arc · 2018-06-12 07:59:31

I have a Libreboot ThinkPad X60 Tablet, and this is be the problem for me - https://bugs.debian.org/cgi-bin/bugrepo … bug=863532. Basically, it's looking for the Wacom digitizer for 4+ minutes because seconds instead of milliseconds. And, it does this every time you log out. So, not okay.

Removing xserver-xorg-input-wacom lets you boot up fastly like normal, but you lose your Wacom input, of course. So, gotta wait out a fix. Oh well! Unsure if it's fixed in backports or Buster like someone says there, but I tried that and also upgraded to Debian Sid a few weeks ago and it still hung. I've tried various distros since I've got my X60t and it's a problem on others as well.

Last edited by Arc (2018-06-12 18:53:10)

msi · 2018-06-12 15:46:03

As far as starting X from a TTY goes, there's some important info in the ASCII release notes:

### Starting X from a console (TTY)
In Devuan 2.0 ASCII, the X server no longer requires to be run with
root privileges. As a consequence, there are some additional
requirements to be met when launching X directly from a TTY (i.e.,
through 'xinit' or 'startx'), especially on systems upgraded from
Devuan Jessie.
In Devuan 2.0 ASCII it is sufficient to install 'elogind' and
'libpam-elogind', and then use either 'startx' or 'xinit' as usual
from a regular user account. In this case, the Xorg log file will be
available under '~/.local/share/xorg/'.
The system still needs to support Kernel Mode Setting (KMS).
Therefore, this solution may not work in some virtualization
environments (e.g. virtualbox) or if the kernel has no driver that
supports your graphic card.
Alternatively, it is still possible to run X with setuid root. In this
case, you need to install `xserver-xorg-legacy` and ensure that the
file '/etc/X11/Xwrapper.config' contains the (uncommented) line:
needs_root_rights=yes

If you have neither of the above configurations, X will freeze immediately after you start it.

Arc · 2018-06-16 06:41:45

To amend the Tablet PC problem, I installed the updated xserver-xorg-core from Ceres and installed the wacom driver, and it tablet now works without the startup delay. So I guess I did something wrong with regular Debian when I tried this before. But yes, good news if you have the Wacom delay problem!

Last edited by Arc (2018-06-16 06:42:23)

Sanssystemd · 2018-06-22 17:25:10

[ 43.712] (EE) modeset(0): drmSetMaster failed: Permission denied
[ 43.712] (EE)
Fatal server error:
[ 43.712] (EE) AddScreen/ScreenInit failed for driver 0

Upgraded to Ascii yesterday and also got this in Xorg.0.log.
Tried everything mentioned in previous posts with no result, downgraded back to Jessie (for now )

Is there a way out of this mess?

devuser · 2018-06-22 17:58:02

Sanssystemd wrote:

[ 43.712] (EE) modeset(0): drmSetMaster failed: Permission denied
[ 43.712] (EE)
Fatal server error:
[ 43.712] (EE) AddScreen/ScreenInit failed for driver 0
Upgraded to Ascii yesterday and also got this in Xorg.0.log.
Tried everything mentioned in previous posts with no result, downgraded back to Jessie (for now )
Is there a way out of this mess?

Did you install xserver-xorg-legacy and set needs_root_rights=yes in /etc/X11/Xwrapper.config?

Sanssystemd · 2018-06-22 18:47:48

Yes i did, without any result, alas.

devuser · 2018-06-22 19:03:12

Well, you could try doing chmod u+s /usr/lib/xorg/Xorg if startx works after that there is something wrong with xserver-xorg-legacy or it's config.

Sanssystemd · 2018-06-22 19:23:16

Oké, thanks, i will try that one.
I have this old i386 machine, i will upgrade that one to experiment with

Sanssystemd · 2018-06-26 13:15:34

I upgraded my other comp. (i386) from Jessie to Ascii, with no problems.
I tried (again) to upgrade my Intel i3, with no result, other then that SLIM failed to start X.

What i see in Xorg.0.log is that X is trying to use some driver called i965

[    20.577] (==) modeset(0): DPMS enabled
[    20.577] (II) modeset(0): [DRI2] Setup complete
[    20.577] (II) modeset(0): [DRI2]   DRI driver: i965
[    20.577] (II) modeset(0): [DRI2]   VDPAU driver: i965

While the kernel is talking about i915

[    5.054202] [drm] Initialized i915 1.6.0 20160919 for 0000:00:02.0 on minor 0
[    5.273640] fbcon: inteldrmfb (fb0) is primary device
[    5.334795] Console: switching to colour frame buffer device 128x48
[    5.352751] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

Is it possible to correct this situation, so that X is using the correct driver (i915 i presume)?

Greetz

cynwulf · 2018-06-26 13:45:44

i965 is part of mesa/dri, it's not the kernel module, so that is in fact correct.

What exactly happens when you install elogind and libpam-elogind as it suggests and try to startx normally, rather than running the older xserver as setuid root??

Sanssystemd · 2018-06-26 15:06:01

I,ve installed elogind and libpam-elogind
Under root-account with 'startx' i get a UI in 1024x768

I can't change the display settings

Thank's for the help

cynwulf · 2018-06-26 15:46:20

I'm not entirely sure as to why you're issuing startx as root? This is wrong irrespective of whether you're trying to run a rootless or setuid x.org. You need to stop doing that immediately if you want to troubleshoot this effectively.

The whole point of non setuid x.org is that it does not run the xserver as root (setuid xorg does), it's rootless.

Try issuing startx as a normal user. Remove stale ~/.Xauthority files if needed.

If you still get the same error, then it's possibly due to some legacy video driver and you might have to settle for running the older x.org with setuid root.

The officially official Devuan Forum!

#1 2017-12-14 21:10:03

Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#2 2017-12-15 10:35:56

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#3 2017-12-15 11:22:44

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#4 2017-12-15 16:23:21

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#5 2017-12-15 18:19:01

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#6 2017-12-15 20:55:05

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#7 2017-12-15 22:36:10

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#8 2017-12-16 01:02:43

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#9 2017-12-16 11:14:44

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#10 2017-12-16 19:45:19

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#11 2018-04-30 22:31:42

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#12 2018-05-04 23:18:25

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#13 2018-05-05 18:02:12

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#14 2018-06-12 07:59:31

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#15 2018-06-12 15:46:03

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#16 2018-06-16 06:41:45

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#17 2018-06-22 17:25:10

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#18 2018-06-22 17:58:02

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#19 2018-06-22 18:47:48

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#20 2018-06-22 19:03:12

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#21 2018-06-22 19:23:16

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#22 2018-06-26 13:15:34

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#23 2018-06-26 13:45:44

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#24 2018-06-26 15:06:01

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

#25 2018-06-26 15:46:20

Re: Black Screen on Devuan Ascii - acpi=off solves it (undesirable)

Board footer