Home | News | Download | Packages | Forum | Wiki | Github

[Solved] Newbie problem with X


#1

I’m kicking myself. I had just installed void and got pekwm working fine. I thought I’d try a graphical login per the post-install notes and installed lightdm and the greeter. It didn’t work and it wasn’t important to me anyway, so I unstalled it. Since it had brought in a whole bunch of dependencies, I did an orphan removal as well. Now, when I run “startx”, I get a black screen with an underline cursor in the top left corner and the keyboard and mouse are unusable. Caps/Num Lock don’t turn on the lights. I can ssh in and the system is still running. Xorg shows as defunct. The Xorg log doesn’t show any errors other than the failed attempts at finding the right video driver, and it does eventually find the right one. dmesg doesn’t show any errors either. I have to reboot.

I’ve done a -Su to make sure everything is up-to-date but don’t know what else to try.

Any suggestions as to how to troubleshoot this?


Blackscreen on Xorg start
(Stefan Mühlinghaus) #2

I would check to see what Xorg currently has to say on TTY1 (CTRL + ALT + F1, return to Xorg with CTRL + ALT + F7) and go from what you see there :slight_smile:

Did you start the lightdm service? If so, is it still running?


#3

Just reinstall xorg? If that is the culprit, that should fix it.


#4

“lightdm … didn’t work … so I unstalled it.”
“the keyboard … [is] unusable.”
“have to reboot.”


#5

Thanks. I tried “xbps-install -Sf xorg-minimal” and the other packages including pekwm. No change. It still locks up. FWIW, the last line in Xorg.0.log consistently is:
… (II) glamor: OpenGL accelerated X.org driver based.

An old Xorg log from Arch running on the same machine (I don’t know how to get the current Xorg log in Arch) has many lines after that. Up to that point, the logs are almost identical. In Arch, the following line is:
… (II) glamor: EGL version 1.4 (DRI2):


#6

What’s inside your Xorg.conf?
Which graphic drivers did you install?


(Stefan Mühlinghaus) #7

Ah, sorry, I thought “unusable” just meant that you couldn’t type anything in Xorg. In that case switching the TTY might still have worked.

You can do a “startx >~/xorg.log 2>&1” to redirect the output to a file and check that after reboot.


#8

BTW, “Newbie” meant with Void. I’ve been using Linux for about 18 years but don’t get into the technical stuff unless I have to. This is my production machine and I’m dual booting with Arch Linux. Unfortunately, I’m swamped with work or else I’d just wipe the partition and re-install everything. I’m beginning to suspect that’s going to be my best option.

@AnachronGuy: Nothing in Xorg.conf. It was working and it works without any configuration in Arch.
Graphics driver is ATI/Radeon.

@jazzman: The keyboard doesn’t work at all.


(Masato the Empty) #9

This is the current norm. Xorg.conf is unnecessary these days, unless you need to do something specific with it. (I was still using one right up until I moved to Void)

@Myshkin
Double-check the kernel driver in use. To my knowledge, the default for radeon cards would be the catalyst-based “radeon” but I could be mistaken (amdgpu is newer, based on the new “crimson” drivers). You’ll want to make sure you’ve got the necessary xf86-video-ati drivers installed (or xf86-video-amdgpu if you use the newer driver series).

I don’t know if your problem is related to this or not, but it’s something to check. Odd that it worked before. Systems like Void shouldn’t break that easily (our package manager seems pretty robust to me so far). So barring that, it could be that a package was present before you added/removed lightdm and orphans that was no longer present after.

Maybe the rest of your Xorg log has something interesting or useful in it. (EE lines, information on loaded modules etc).


#10

I have a Xorg.0.log from about 6 months ago from Arch on the same machine. The logs are almost identical up to the point it stops. The only significant difference is the version numbers. All the (EE) lines are the same: attempting fglrx, fbdev, and vesa which don’t exist. The radeon driver recognizes the video as the same chipset, etc. The only difference I can see is that the Void run stops on the line I mentioned above after loading libglamoregl.so.

I’m inclined to agree with you that the orphan removal perhaps removed something it shouldn’t have, perhaps something I manually installed. I could compare what is in the xbps cache with what is still installed, but that sounds pretty time consuming to me.

FWIW, I had the same symptoms mentioned in this thread, https://forum.voidlinux.eu/t/i-cannot-login-to-the-void-live-image-error-in-service-module/1005 and had to use an older .iso to install. I have wondered if doing the -Su could have updated to whatever was causing that problem.


(Masato the Empty) #11

Save this to a script and run it. (try and read it first to make sure i’m not doing something evil! Never trust strangers on the interwebs!)

#!/bin/sh

pkgs_installed=$(xbps-query -s "" | awk '{ print $2} ' | sed 's/-[0-9].*//;s/-git[0-9].*//')

(cd /var/cache/xbps
while read _not; do
    echo "$pkgs_installed" | grep ${_not} >/dev/null && continue
    if [ -z $pkgs_not ]; then
        pkgs_not=${_not}
    else
        pkgs_not=$pkgs_not'\n'${_not}
    fi
done <<_EOT
$(ls *.xbps | sed 's/-[0-9].*//' | uniq)
_EOT

echo -e "$pkgs_not")

This reads the files you have in your xbps cache and compares them with the list of installed programs. Once finished, it spits out the list of things in your cache directory that aren’t installed (it strips version numbers, so it only checks package names)

Are you on a desktop or laptop? Does it make any difference if you boot the original 4.5.2 kernel that installed from the CD (or did you do a net install?)


#12

On my CD install the xbps packages from the CD don’t get copied to the cache, only later updates go in there.
Putting the CD in:
$ sudo mount -t auto /dev/sr0 /mnt
$ ls /mnt/LiveOS/
squashfs.img

The package files are in that img, there’s no package list immediately available.

$ sudo mount -t squashfs /mnt/LiveOS/squashfs.img /media/squashfs/
$ ls /media/squashfs/LiveOS/
ext3fs.img
$ sudo mount -o loop /media/squashfs/LiveOS/ext3fs.img /media/ext3fs/
$ ls /media/ext3fs/
bin boot dev etc home lib lib32 lib64 lost+found media mnt opt proc root run sbin sys tmp usr var
$ ls /media/ext3fs/var/cache/xbps/
Nothing in here either.
The hidden . files here seem to give a package list:
$ ls -a /media/ext3fs/var/db/xbps/

A shortcut might be looking at $ man xbps-pkgdb
xbps-pkgdb – XBPS utility to report/fix issues and modify the package database (pkgdb)
I haven’t used it myself but it looks like it could fix this sort of problem, could it even be run from a live CD on a damaged installation?


(Masato the Empty) #13

Good point, and I shouldn’t be surprised at that… The install script from the CD copies the live image, then does a reconfigure to make sure the package db is consistent.

In order to get the package list from there, you’d have to run a query within the environment (or extract the metadata from the image - which you just beat me to with your last edit!)
command to get just package names from running env
xbps-query -s "" | awk '{print $2}' | sed 's/-[0-9].*//;s/-git[0-9].*//'

the second sed command is to filter out revision numbers that start with -git (of which there aren’t any on the basic CD, but I don’t know about the ones with DEs)

EDIT: so yeah, it’s a bit more work than just running that script…

Also, there are at least three packages on the CD’s that are installed but don’t have a .plist as they’re metapackages. On the baseCD they are “base-system” “linux” “wifi-firmware” and again, I don’t know what’s on the DE ones, though I’d bet more metapackages.


(Masato the Empty) #14

I don’t think we could quite do that since the CD doesn’t act as a repo; the transfer to your disk is a simple cp command from the CD to the new filesystem.
EDIT: I’ve only used it to change package modes between manual and auto and to put libharfbuzz on hold (that’s another issue…)

@Myshkin As much fun as it is coming up with weird shell commands (I can’t be the only one can I?) at this point, I must concede it would probably be faster to start over, assuming you haven’t added many files/configuration changes to the system (Void install is pretty fast from the base CD…)

I’d recommend the following: do an install from your CD; if it’s one of the DE ones, test Xorg and if it works, next step. Otherwise, just next step.
update - xbps-install -S
and then xbps-install -u, as many times as it takes (usually you have xbps packages updating on their own) - probably just twice


#15

@masato I just now saw your last message but had reached the same conclusion. I didn’t do things exactly as you suggested but fairly close (GMTA). This is on a laptop and I’m using a USB flash disk to boot.

I think I must have gotten the order of events mixed up in the OP. Some of it was done in the wee hours of the morning and I generally turn into a pumpkin (or at least a pumpkin-head) at midnight. I said I did an xbps-install -Su, but I didn’t realize until later that you have to repeat that to completely update. So, I probably only did it once which probably only updated xbps. Later, I did it again while installing lightdm. I remember something weird happening while setting up the service links to lightdm which caused me to reboot. My mistake was blaming the problem on lightdm. I’m convinced now that the problem was caused by the -Su.

To test that theory, I reinstalled and did -Su until no more upgrades were done. Installed X and stuff and got the lockup at startx. Reinstalled again and did NOT -Su. Installed X and stuff and after upgrading zlib (got an error), everything seems to work. Getting synergy to work required upgrading libstdc++ which also upgraded libgcc. Everything still working but I still haven’t done an -Su and am fairly confident that if I do, it will break things.

Is my conclusion reasonable? If so, what do I do now? Upgrade packages one at a time? Would I even recognize the offending package without doing a reboot after every change?


(Masato the Empty) #16

well, xorg is pretty low-level, and since it’s hanging your whole input system, it’s probably happening closer to kernel drivers.

So if that’s the approach you want to try taking, think of low-level stuff first; xorg core/drivers if those weren’t upgraded as dependencies, and linux kernel if you haven’t done that yet.

Something that might be relevant, depending on what packages you can narrow the problem down to: Does your laptop have two GPUs by any chance (hybrid graphics?)


#17

Well, I can’t say it’s the approach I want to take, I just can’t think of any other. Well, other than forgetting the whole idea and continuing with Arch or booting into Void every few weeks and do an -Su hoping the problem eventually goes away.

Wouldn’t all the xorg stuff have come from the current repo since I installed it after a reboot into the newly installed system?

As for the GPUs, I have no idea. Xorg identifies it as a KAVERI 0x1318. “lspci” only lists one graphics controller.

I’ll try a newer kernel first.
Edit: Yep, that broke it. Even if I boot into the old 4.4.5 it is now broken. Ouch! Is there any way to go back to it without reinstalling? As someone pointed out above, the packages from the live boot aren’t in the cache. I notice that Arch is on 4.8.13 so it’s possible I would have eventually run into this problem there. I also notice that no Linux update is available there yet. Is Void more bleeding edge than Arch?


(Masato the Empty) #18

4.4.5? Do you mean 4.5.2 (that was the one on the CD last I checked).
And then the same problem when booting the older kernel after the upgrade?

If that’s the case, the only thing I can think of is the microcode; it gets updated when you update the “linux” metapackage, and unlike the kernel, firmware blobs live in a common directory and get overwritten with updates. (package on CDs is 20160402_1, current pkg is 20161206_1)

(unless you happened to notice if any other packages got pulled in with the linux update)

short of pulling the Kaveri firmware files from the CD (there are 16 of them) the only other thing we can do is look to find out if any module options are known to resolve this. although I suppose that is an option, except every update would overwite the files, and you’d have to put them back. Not a good way to work, though it may be a decent test.

Note Kaveri is one of AMD’s APUs (radeon chip together with CPU). Knowing that may or may not be helpful in finding the actual cause/fix…

If you can ssh into your laptop when it’s frozen like that, see if dmesg tells you about any errors (recent kernels now require root privs when running dmesg, so use root, or sudo).


(Masato the Empty) #19

Another thing you might want to try is to use the newer amdgpu drivers; you’ll need to blacklist radeon (make sure to do it in both /etc/modprobe.d and /lib/modprobe.d (which is used by dracut. On my system, I wiped one of them out and made a symlink to the other to solve that issue), and update your initramfs)

You might also have to modprobe amdgpu if it’s not loaded at boot (you can add it to /etc/modprobe.d)

Lastly, you’ll need xf86-video-amdgpu rather than xf86-video-radeon (I don’t think they’ll conflict so you don’t have to remove one; it depends on the kernel driver loaded).

EDIT: one more thing, you’re probably not entirely dead in the water. There’s a good chance you can pass the nomodeset option to the kernel to disable KMS and that will temporarily solve your problem, with the tradeoff of no acceleration.


#20

4.4.5. See the FWIW in post # 10 above.

And, yes, the same problem booting either kernel. There were a couple of other packages that were either installed or updated: linux-firmware-intel-20161206 and linux-firmware-nvidia-2016-1206, which struck me as rather odd since I don’t have Intel or Nvidia. linux-firmware-amd was NOT upgraded.

I didn’t do it this time, but in previous fails, I did ssh into the frozen machine and dmesg had no errors and the Xorg log ended abruptly as mentioned in previous posts.

Edit: We cross posted. I’m in work mode now so I won’t be able to play with this until this evening. But I’ll try the amdgpu. I notice it’s installed on Arch but I don’t think it is being used, probably for the reasons you mention. Also, I’m using xf86-video-ati rather than xf86-video-radeon. Is there a difference?