Blank screen after update

Stutz Jr · 2012-03-18 07:55:54

G'day,

So after typing a long and detailed post explaining exactly my issue your forum saw fit to log me out and delete my post for no reason.
I can't be bothered to type it all again, and I'm not going to type it all again.

Here's the basic issue:
Compaq Armada E500 laptop. Arch, XFCE desktop with gdm login.
ran 'pacman -Syu' today and was asked whether I wanted to replace mach64-dri with extra/libgl.
checked Arch webpage, racent package updates, this forum and google and all were in agreeance that replacing this file was necessary and ok. Notably there were no warnings about this extra/libgl conflict anyway.
As I've said, I typed all this in detail before and it's not my problem that the post was lost.
Anyway, pacman completed the update with no issues.
Upon reboot, system boots, grub loads, Arch enters runlevel 5 and briefly flashes the tty1 console login before switching to the gdm login screen as normal. Except instead of showing the gdm login the screen remains blank and the computer is totally unresponsive including CTRL-ALT-whatever and requires a hard poweroff to reboot.

So here are my questions:
1: How do I get back to the console from this unresponsive blank screen?
2. How do I recover X to work the way it always has before?
3. Do I need to reinstall mach64-dri, and if so how do I avoid future conflicts?

I'm sorry for the attitude but if there's one thing that pisses me off more than an unresponsive blank screen it's losing a long post due to crappy forum bug. I really shouldn't have to copy everything I type to notepad just in case a page randomly times out. Anyway I look forward to a barrage of requests for random irrelevant logs which I won't be able to provide due to the BLANK SCREEN!

Cheers!

/dev/zero · 2012-03-18 08:02:30

Stutz Jr wrote:

Anyway I look forward to a barrage of requests for random irrelevant logs which I won't be able to provide due to the BLANK SCREEN!

If you boot from a LiveCD, you'll be able to mount your Arch installation and get your last logs. You'll also be able to chroot in and see whether you can do something to fix the problem - maybe something with pacman, or maybe disable certain things in your daemons array (like gdm ...).

Stutz Jr · 2012-03-18 10:39:24

So the answer to 1) was to boot livecd and edit /etc/inittab from the mounted system partition.

That's thinking outside the box! We don't pay you to think outside the box!
Just kidding, cheers /dev/zero

So I'm back at the console and it's onward to address 2) and 3)
Most pressing to me would be avoiding this potential conflict between mach64-dri and /extra/libgl.
I'd rather not deviate from the "standard model" of current packages if possible so would I be safe to
simply remove lib32-libgl "Mesa 3-D graphics library and DRI software rasterizer (32-bit)" and
reinstall mach32-dri OR start using some other display driver OR are there other implications / issues to address?

/var/log/pacman.log

[today] removed mach64-dri (7.11.2-1)
...
[today] upgraded libgl (7.11.2-1 -> 8.0.1-2)

/etc/X11/xorg.conf.d/10-monitor.conf

Section "Device"
  Identifier "Device0"
  Driver "mach64"
EndSection

Section "Screen"
  Device "Device0"
...

:: Replace mach64-dri with extra/libgl? [Y/n]

Winston: Ray, when someone asks you if you're a god, you say "YES"!

ewaller · 2012-03-18 16:33:40

Now that you can see again Take a look at /var/log/Xorg.0.log and see if there is anything interesting in there.

When the system was unresponsive, were your keyboard LEDs flashing? That would indicate a kernel panic.
Did the caps lock LED respond to pressing of the Caps Lock key? That would indicate that the kernel at least had a pulse.

Stutz Jr · 2012-03-19 00:07:58

When I run startx from the console, the screen blanks after the line "(==using config... " but it flashes away before I can read any more. Keyboard leds are not flashing, but capslock key has no effect. There disk activity light did flash briefly once or twice.
It does not appear to generate/update /var/log/Xorg.0.log as the contents still show a previous successful run.
A colleague suggested I try to substitute the "vesa " driver in place of mach64 but it seems I don't have that installed. I'll have to try when I get home as I don't have the laptop online here. I had a quick look at the changelog for mesa 8.0 that states mach64 driver was removed but I can't find and suggested path for replacement? Sorry I can't seem to get copy/paste working on this tablet atm.

Birkov · 2012-03-20 00:23:58

I have the same problem as Stutz Jr: screen goes blank and the keyboard is no longer responsive after replacing mach64-dri with libgl.

1) when seeing the grub boot screen, hit 'e' and add a '3' to your kernel boot line, than hit 'enter' and 'b' to boot into runlevel 3. (no permanent change is made)

2) move your old Xorg config to /root :

# mv /etc/X11/xorg.conf.d/10-monitor.conf /root/

install the vesa driver:

# pacman -S xf86-video-vesa

start x:

# startx

and you have your desktop back.
However X is not working as before for example: the vesa driver is not good enough to play movies on my box. The mach64-dri driver had no problem with that.

3) I moved 10-monitor.conf back to its old place, downgraded libgl to version 7.11.2-1 and reinstalled mach64-dri-7.11.2-1-i686.pkg.tar.xz, rebooted and got the blank screen again. Seems that the vesa driver is the best option for now.

I see that a bug has been posted on https://bugs.archlinux.org/task/28938 so I guess we either wait for the devs to fix this or build the mach64-dri-8.0.1-2 version from source by ourself (at the moment I dont have time for that)

Edit: Closed by Andreas Radke (AndyRTR)
Saturday, 17 March 2012, 06:07 GMT-4
Reason for closing: Won't fix

My box is building the PKGBUILD provided by Connor Behan and I am going to sleep.

Last edited by Birkov (2012-03-20 01:01:21)

Stutz Jr · 2012-03-20 11:18:49

Unfortunately I have zero experience with PKGBUILD and AUR and I don't really have time to look into that at the moment. The fact he's said they could fix it but are not going to is very frustrating. I'm not clear if this means that there will be a new version of the mach64 driver coming when available 'upstream' (nice buck passing), or if it means that I'll have to figure out how to downgrade libgl permanently along with anything else that depends on it. I'd be happy to stick with the vesa option but I need to use gstreamer as the main function for this laptop is to process a webcam feed for analogue scale measurements and OCR.

Birkov · 2012-03-20 13:14:13

I totally agree, the least Andreas Radke could have done was posting a warning on the front page.

The package I build from the PKGBUILD didn't fix the problem, nor did:

# pacman -U /var/cache/pacman/pkg/libgl-7.11.2-1-i686.pkg.tar.xz /var/cache/pacman/pkg/mach64-dri-7.11.2-1-i686.pkg.tar.xz /var/cache/pacman/pkg/mesa-7.11.2-1-i686.pkg.tar.xz

Can you give me:

# cat /var/log/pacman.log

Because last upgrade gave me 198 new packages and I have no idea what to downgrade.

Ps since you don't use mach64drm from AUR, you have a good chance that the vesa driver is good enough for you.

Pps if everything fails, we can allways upgrade to debian stable, at least we don't have to retype our posts because of some stupid forum error (yes, it happened to me too)

Birkov · 2012-03-20 21:22:18

It looks solved with:

# cd /var/cache/pacman/pkg/
# pacman -U xorg-server-common-1.11.4-1-i686.pkg.tar.xz xorg-server-1.11.4-1-i686.pkg.tar.xz xorg-server-utils-7.6-2-any.pkg.tar.xz xf86-input-evdev-2.6.0-4-i686.pkg.tar.xz xf86-input-keyboard-1.6.1-1-i686.pkg.tar.xz xf86-input-mouse-1.7.1-2-i686.pkg.tar.xz xf86-video-mach64-6.9.0-3-i686.pkg.tar.xz

and the PKGBUILD provided by Connor Behan, thanks Conner!

I added the line

IgnorePkg = mach64-dri xorg-server-common xorg-server xorg-server-utils xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-video-mach64

to /etc/pacman.conf to instruct Pacman to ignore any upgrades for selected packages when performing a --sysupgrade.

@Stutz Jr: using a PKGBUILD is easy all you have to do is put the PKGBUILD in some directory (for example /home/<your username>/builds/mesa-dri1 and type as a normal user:

$ makepkg -s

You will be asked for your root password and after typing that, pacman will automagically install all the dependency's needed. When all dependency's are installed, the compiling begins. When compiling is finished, do (as root):

# pacman -U mach64-dri-7.11.2-1-i686.pkg.tar.xz

And reboot. If you have the time, install packer from the PKGBUILD at https://aur.archlinux.org/packages.php?ID=33378 and do:

# packer -S mach64drm

to install the drm part of the mach64 driver. Read https://wiki.archlinux.org/index.php/Mach64 and tweak your /etc/X11/xorg.conf.d/10-monitor.conf file to get the full power of your GPU.

ConnorBehan · 2012-03-21 02:37:40

I strongly suspect that this is a problem with the new xorg-server (which has always been more unstable than the LibGL <-> DRI interface). If you uninstall a DRI driver like mach64-dri that your card uses (or install one that's been improperly compiled or linked) it shouldn't have the effect of breaking the Xserver. It will just make 3D apps revert to software and render slowly.

ninian · 2012-03-21 11:27:07

Thanks guys (and Connor) for your work on this. I have 4 old workhorse systems affected by the dropping of support for dri1; these have 3 x Matrox adapters, and 1 x ATI Rage Pro. So frustrating, and I've encountered nothing but blank screens with the need for a hard poweroff when trying to recover the Rage Pro system. (Haven't dared to look at the Matrox ones yet.) Will try Birkov's last "solution" later ... here's hoping.

PS: Meantime, I managed to get the system going again with the vesa driver, but it completely hangs the system (an old Dell Optiplex) when I exit X!

Update: Birkov's solution worked for me too, except that I had to revert to: xf86-video-mach64-6.9.0-2-i686.pkg.tar.xz

Last edited by ninian (2012-03-21 23:10:51)

Stutz Jr · 2012-03-25 10:30:56

I haven't had a lot of time to investigate some of the suggestions above but I will say that after rereading the instructions for AUR and PKGBUILD I can see now it's not nearly as complicacted as I'd believed.
Nonetheless it appears that there has been a change of heart and in an update to the bug report previously mentioned, the decision to replace the mach64 etc. dr1 drivers appears to have been overturned? I'm sure it's not as simple as that, but in a pacman-Syu update today I noticed updates to xf86, mesa and mach64. When I reverted my /etc/inittab and /etc/X11/xorg.conf.d/10-monitor.conf back to as before I can again boot straight into GDM / XFCE again now. I'll tentatively suggest that this issue may be solved for now (for me anyway) but I expect this will need to be addressed more directly before too long with a proper DR2 driver perhaps?
Anyway I do note that when I booted and tried my gstreamer webcam app I noticed a VERY slow / delayed framerate which may or may not be related to the above issue.

ConnorBehan · 2012-03-25 18:58:12

The solution to your problem probably had more to do with this bug report. Porting mach64 et al to DRI2 would be great but from what I understand, this is a very difficult task.

Arch Linux

#1 2012-03-18 07:55:54

Blank screen after update

#2 2012-03-18 08:02:30

Re: Blank screen after update

#3 2012-03-18 10:39:24

Re: Blank screen after update

#4 2012-03-18 16:33:40

Re: Blank screen after update

#5 2012-03-19 00:07:58

Re: Blank screen after update

#6 2012-03-20 00:23:58

Re: Blank screen after update

#7 2012-03-20 11:18:49

Re: Blank screen after update

#8 2012-03-20 13:14:13

Re: Blank screen after update

#9 2012-03-20 21:22:18

Re: Blank screen after update

#10 2012-03-21 02:37:40

Re: Blank screen after update

#11 2012-03-21 11:27:07

Re: Blank screen after update

#12 2012-03-25 10:30:56

Re: Blank screen after update

#13 2012-03-25 18:58:12

Re: Blank screen after update

Board footer