Xorg fails to start after installing the Hardware Enablement Stack due to missing symlink after purging old xserver-xorg

[Simon Strandman]

Bug:

The bug happens whenever the remaining configuration files of the original X stack is removed, ie purging. It does not happen for users who do not explicitly remove those.

Workaround:

For example, if upgraded 14.04 LTS to the 14.04.2 HWE stack (=14.10/utopic):

sudo dpkg-reconfigure xserver-xorg-lts-utopic

This restores the symlink /etc/X11/X -> /usr/bin/Xorg

---

After installing the hardware enablement stack on precise by running:
sudo apt-get install linux-generic-lts-quantal xserver-xorg-lts-quantal

Xorg fail to start. There is no error message or anything, just a black screen. Switching to a vt i possible and lightdm/x-0.log shows that a symlink is missing:
X: cannot stat /etc/X11/X (No such file or directory), aborting.

I updates two computers running precise x86_64 and both had the problem.

Just recreating the symlink fixes the problem and then precise runs perfectly fine with the new stack (in fact, it's more stable so far).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Malte S. Stretz (mss)]

To reproduce this do the following:

1. Install Ubuntu 12.04
2. Upgrade to the LTS enablement stack
3. Purge the old config via aptitude purge ~c

This will remove the files /etc/X11/X and /etc/X11/xorg.conf (and maybe /etc/X11/default-display-manager can't remember if this was caused by something else).

To fix this run (thanks to http://askubuntu.com/questions/232926/etc-x11-x-not-executable-error-when-startx)

sudo dpkg-reconfigure -phigh xserver-xorg

[Timo Jyrinki (timo-jyrinki)]

Confirming, just re-encountered this testing LTS-S enablement stack, after eventually cleaning the residual config packages via Synaptic.

[Maarten Lankhorst (mlankhorst)]

dpkg-reconfigure xserver-xorg-lts-whatever works to fix this. It's probably a bug, but not likely going to be fixable..

[Malte S. Stretz (mss)]

Wouldn't this be fixable by non-ltsing the package xserver-xorg (which is only owner of the symlink and a bunch of conffiles anyway) and changing the depends of the other packages, mybe introducing an empty/virtual package for dependency resolution? It looks like xorg-renamed-package-lts-foo is such a package already.

Not pretty but losing your X isn't pretty either.

[Dudan (d-tomasek)]

It happend to me on precise after:
install linux-generic-lts-saucy a xserver-xorg-lts-saucy and
and use ubuntu tweak janitor
Helps:
sudo dpkg-reconfigure -phigh xserver-xorg-lts-saucy

[Matthias Andree (matthias-andree)]

kernel upgrade, several cleanups of old kernels, dist-upgrade and boom.

The workaround of re-running dpkg-reconfigure on xserver-xorg-lts-saucy helped here, too.

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

Missing a tag for LTS-Enablement-Stack like HES or HWE

[Tristan Schmelcher (tschmelcher)]

I hit this after upgrading from the Raring HWE stack to the Trusty HWE stack. Fixed by manually recreating the symlink. (Also ran "sudo dpkg-reconfigure -phigh xserver-xorg-lts-trusty" after finding this bug, for good measure.)

[jerico (jerico-dev)]

This happened to me simply by upgrading from Precise LTS to Trusty LTS on two independent machines and then purging residual config of left-over packages from Precise.

Reinstalling/reconfiguring xserver-xorg-lts-trusty fixed the problem. This bug is high impact and hard to debug for an average user, though.

What about hacking the postrm scripts of conflicting packages to check whether a package that holds on to /etc/X11/X is still installed and fixing the issue there? Not a beautiful solution but better than leaving users without X after an upgrade...

[houstonbofh (leesharp)]

This bug just bit me when update the HME on Precise and removing old kernals. And digging for it is a chalange as googling most of the issues point to removing nvidia driver or flgrx drivers...

[Naël (nathanael-naeri)]

This bug affected me too (on Precise LTS) after purging xserver-xorg residual config once I installed xserver-xorg-lts-trusty.

I can confirm that reinstalling/reconfiguring xserver-xorg-lts-trusty fixed the problem (I used apt-get --reinstall install xserver-xorg-lts-trusty).

It took me a few hours to understand what was going on though. I agree with jerico that the bug is high impact and hard to debug for an average user.

It looks like it can affect anybody upgrading to Trusty LTS or Trusty HWE Stack.

[franglais.125 (franglais.125-deactivatedaccount)]

I encountered the same problem when upgrading from 14.04.1 to 14.0.2 (Well, not yet released but from -proposed).

No X session, I had to recreate the symlink...

[Maarten Lankhorst (mlankhorst)]

Solution 1: stop purging stuff..
Solution 2: Add fallback to /usr/bin/Xorg if solution 1 fails..

[Dennis Schridde (devurandom)]

Affects trusty with utopic hwe, too. Solution from comment #2 works.

[Timo Jyrinki (timo-jyrinki)]

Hmm, this may have been fixed now in the upcoming 14.04.3 LTS HWE upgrade, can anyone confirm?

That is, after purging the configuration files of -utopic packages, the link /etc/X11/X is removed but system continues to work.

I upgraded by temporarily enabling trusty-proposed updates and sudo apt install --install-recommends libgles2-mesa-lts-vivid libglapi-mesa-lts-vivid xserver-xorg-lts-vivid libgl1-mesa-dri-lts-vivid libegl1-mesa-lts-vivid libgl1-mesa-glx-lts-vivid:i386

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Naël (nathanael-naeri)]

Timo: I don't know exactly for the 14.04.3 LTS -utopic to -vivid HWE upgrade, but I can confirm this bug is still present for the 14.04.3 LTS -trusty to -vivid HWE upgrade.

I've just done a fresh install of 14.04.x LTS, using a PXE server so I'm not exactly sure what the x was in the image I used. On completion of the install and updates I was left with a 14.04.3 LTS and the original kernel and X server, i.e. linux-generic and xserver-xorg. I updated them to linux-generic-lts-vivid and xserver-xorg-lts-vivid. After purging the old xserver-xorg related packages, the /etc/X11/X link was gone.

I still believe this bug should not be left unfixed, but perhaps that's just me.

[Naël (nathanael-naeri)]

Removed "on precise" from bug title because it happens on trusty too.

[Naël (nathanael-naeri)]

Timo: sorry, I misread your comment, my bad. The symlink is gone, but indeed, as you mention, the system continues to work: X starts normally on the next boot. I wonder how.

Anyway, bug fixed, starting from when you update to -vivid HWE stack (xserver-xorg-lts-vivid). Good thing, thanks to whoever did that.

[Naël (nathanael-naeri)]

I've just updated another computer's HWE stack from Trusty (xserver-xorg) to Vivid (xserver-xorg-lts-vivid) and can confirm again that this bug has been fixed, starting from when you update to Vivid HWE stack.

The /etc/X11/X symlink is still deleted when one purges the remnants of the previous stack, but X nevertheless starts normally at boot time.

I've changed the bug status to Fix Released for xorg-lts-vivid.

[Brian Murray (brian-murray)]

I tried recreating this today by installing the -lts-utopic, -lts-vivid, -lts-wily HWE stacks and then purging the 3.13 kernel (linux-image-3.13.0-93-generic), and then running 'sudo aptitude purge ~c'. The removal of the /etc/X11/X symlink only caused a problem after rebooting with the -lts-utopic stack.

[Naël (nathanael-naeri)]

Still affects xorg-lts-trusty (for Precise users)

[Timo Aaltonen (tjaalton)]

utopic stack is EOL

[Naël (nathanael-naeri)]

Still affects xorg-lts-trusty for the users of releases < Trusty LTS, but all of those releases e.g. Precise LTS are EOL now.

There is therefore no point in fixing this package, it won't be installed by anybody any more.

[Robie Basak (racb)]

> 13:47 <nael_> Hi guys, anybody from Bug Control here can please switch bug 1132736 xorg-lts-trusty from Confirmed to Won't Fix? Please see last comment for rationale. Thanks!

Users may still want to upgrade from an EOL release to a supported release though. Surely we should encourage this!

I think the bug sounds valid for Trusty still and an SRU to Trusty shouldn't be rejected on this basis if someone wants to contribute one. Won't Fix generally implies that we'd reject a fix even if were contributed, and I don't think that's the case here.

[Naël (nathanael-naeri)]

Sounds right. I just assumed that there wasn't any users of releases < Trusty any more, as all those releases are EOL. But actually there may still be, indeed.

Bug should stay Confirmed until Trusty itself is EOL.