You are not logged in.
I'm running Arch inside a virtual machine, with Virtualbox.
I ran 'sudo pacman -Syu' and let it install everything. It updated a bunch of xorg-* packages, among a few other things, and then I rebooted. Now it seems like X has stopped working. Normally I use SLiM for starting X, but SLiM itself isn't starting up. I tried 'startx' manually but that didn't work either. I can get into a normal CLI-environment just fine though.
Here are pacman.log: http://ix.io/4MK and Xorg.0.log: http://ix.io/4MJ
I notice the errors in Xorg.0.log but I'm not sure what to make of them.
I'm not sure what else to add here, I hope I'm not missing something obvious.
Last edited by CrashLog (2013-03-18 20:34:33)
"There are no problems, only opportunities for solutions."
Offline
try downgrade xorg-server to 1.13 version because
[ 9.363] Module class: X.Org Video Driver
[ 9.363] ABI class: X.Org Video Driver, version 13.0
[ 9.363] (EE) module ABI major version (13) doesn't match the server's version (14)Last edited by Linkas (2013-03-18 20:16:35)
Offline
Okay, I ran 'sudo pacman -R xorg-server' and then tried 'sudo pacman -U xorg-server-1.13.3-1-x86_64.pkg.tar.xz' inside /var/cache/pacman/pkg and here's what happened:
looking for inter-conflicts...
:: xorg-server and xf86-input evdev are in conflict. Remove xf86-input-evdev? [y/N] y
:: xorg-server and xf86-video-fbdev are in conflict. Remove xf86-video-fbdev? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: xorg-server: requires xf86-input-evdevIf I say no to removing one of those two packages, it just says "unresolvable package conflicts detected" and doesn't work either.
"There are no problems, only opportunities for solutions."
Offline
First, revert old xf86-input-evdev package. Check which exactly version reqires old xorg-server
pacman -Qi -p /var/cache/pacman/pkg/xorg-server-1.13.3-1-x86_64.pkg.tar.xzLast edited by Linkas (2013-03-18 20:33:00)
Offline
Thanks, that's what was wrong. Reverted to xf86-input-evdev 2.7.3-2 and then after that also reverted to xorg-server 1.13.3-1. Now X works again.
Solved.
Last edited by CrashLog (2013-03-18 20:37:36)
"There are no problems, only opportunities for solutions."
Offline
Great. You are lucky because you have old packages on disk.
Offline
I did this too, but was forced to revert xf86-video-vesa as well... xorg.0.log had also complained about the vbox module...
reverted xf86-input-evdev-2.7.3-3-x86_64 to 2.7.3-2
reverted xf86-video-vesa-2.3.2-3-x86_64 to 2.3.2-2
then reverted xorg-server-1.14.0-2-x86_64 to 1.13.3-1
...then off to tea with Zebedee
Offline
Thanks for the info
I had the same problem...
However for some reason I didn't have xf86-input-evdev and xf86-video-vesa's old versions...
For anybody not having them as well:
Here is how to get them and solve the issue:
1.Go to https://www.archlinux.org/mirrors/status/ and picked one of the servers with high delay,
2.Then open the mirror in a web browser and go to extra/<your architecture>/
3.search for xf86-input-evdev and xf86-video-vesa in the page.
4.download the packages and put them in my virtualbox's shared folder
From there copy them to /var/cache/pacman/pkg/ and run:
sudo pacman -U /var/cache/pacman/pkg/xf86-input-evdev-2.7.3-2-x86_64.pkg.tar.xz /var/cache/pacman/pkg/xf86-video-vesa-2.3.2-2-x86_64.pkg.tar.xz /var/cache/pacman/pkg/xorg-server-1.13.2.901-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/xorg-server-common-1.13.2-1-x86_64.pkg.tar.xzwhich reverts xorg-server, xorg-server-common, xf86-input-evdev and xf86-video-vesa.
Offline
This worked for me, thanks! But why is this issue occuring? Going forward, do we need to just always not upgrade these packages? Thanks again!
Offline
I was able to update today without any trouble. I don't know what changed, but it seems like it was just a temporary problem.
"There are no problems, only opportunities for solutions."
Offline
I had this problem when I similarly made this update. I'm running Arch on a Dell Inspiron 1100, after the update X wouldn't start. I attempted to roll back to previous versions (as stipulated here and seeing as I had them in my cache) to no avail (gave up in frustration). Finally, I was able to get into X in two different ways:
First, I removed xf86-video-intel and installed xf86-video-vesa, when I rebooted I added the i915.modeset=0 parameter to the boot options at runtime in GRUB. For whatever reason X wouldn't load if I allowed the modeset to happen (bigger console area). This enabled me to boot into a slower X which I was still dissatisfied with, but at the very least it allowed me to isolate the problem as the intel driver as everything else is fully up to date.
Second, I created /etc/X11/xorg.conf.d/20-intel.conf with the following contents:
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "NoAccel" "True"
EndSectionThis also meant switching back to xf86-video-intel (instead of using xf86-video-vesa) for X. I tried both the "uxa" (supposed to be default) and "sna" options for "AccelMethod" and neither worked, only explicitly using the "NoAccel" "True" option allowed me to get X to function anew. In this manner I don't have to disable the modeset option during boot in GRUB and I'm still utilizing the latest intel driver.
The only inference (albeit perhaps misguided or ignorant) I can make is that something changed in UXA that broke how it worked before (I say this because this laptop is too old to support SNA).
Offline