startx fails with xorg-server 1.20 [Solved, with conditions]

[seansmr]

Hi,

I need some help with xorg-server 1.20

I just tried to upgrade to xorg-server to 1.20 but it does not work when I use the startx command.
Strangely, there are no other reports of this problem in recent years. Maybe it works when used with a graphical login.

I think that the relevant error is this:

Code: Select all

parse_vt_settings: Cannot open /dev/tty0 (Permission denied)

I have it working by re-emerging version 1.19 however it would be nice to have a proper solution.
Here is the entire log:

Code: Select all

[  1007.957] 
X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
[  1007.957] Build Operating System: Linux 4.14.78-gentoo x86_64 Gentoo
[  1007.957] Current Operating System: Linux B360M-A 4.14.78-gentoo #1 SMP Sat Nov 3 14:14:36 +07 2018 x86_64
[  1007.957] Kernel command line: root=/dev/sda2 BOOT_IMAGE=/kernel-4.15.18-gentoo root=/dev/sda4 ro
[  1007.957] Build Date: 03 November 2018  03:46:18PM
[  1007.957]  
[  1007.957] Current version of pixman: 0.34.0
[  1007.957] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[  1007.957] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1007.957] (==) Log file: "/home/sean/.local/share/xorg/Xorg.0.log", Time: Sat Nov  3 16:22:21 2018
[  1007.957] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  1007.957] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1007.957] (==) No Layout section.  Using the first Screen section.
[  1007.957] (==) No screen section available. Using defaults.
[  1007.957] (**) |-->Screen "Default Screen Section" (0)
[  1007.957] (**) |   |-->Monitor "<default monitor>"
[  1007.957] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[  1007.957] (==) Automatically adding devices
[  1007.957] (==) Automatically enabling devices
[  1007.957] (==) Automatically adding GPU devices
[  1007.957] (==) Max clients allowed: 256, resource mask: 0x1fffff
[  1007.957] (WW) The directory "/usr/share/fonts/misc/" does not exist.
[  1007.957] 	Entry deleted from font path.
[  1007.957] (WW) The directory "/usr/share/fonts/TTF/" does not exist.
[  1007.957] 	Entry deleted from font path.
[  1007.957] (WW) The directory "/usr/share/fonts/OTF/" does not exist.
[  1007.957] 	Entry deleted from font path.
[  1007.957] (WW) The directory "/usr/share/fonts/Type1/" does not exist.
[  1007.957] 	Entry deleted from font path.
[  1007.957] (WW) The directory "/usr/share/fonts/100dpi/" does not exist.
[  1007.957] 	Entry deleted from font path.
[  1007.957] (WW) The directory "/usr/share/fonts/75dpi/" does not exist.
[  1007.957] 	Entry deleted from font path.
[  1007.957] (==) FontPath set to:
	
[  1007.957] (==) ModulePath set to "/usr/lib64/xorg/modules"
[  1007.957] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[  1007.957] (II) Loader magic: 0x55b62d2c8c40
[  1007.957] (II) Module ABI versions:
[  1007.957] 	X.Org ANSI C Emulation: 0.4
[  1007.957] 	X.Org Video Driver: 24.0
[  1007.957] 	X.Org XInput driver : 24.1
[  1007.957] 	X.Org Server Extension : 10.0
[  1007.958] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1007.975] (--) PCI:*(0@0:2:0) 8086:3e92:1043:8694 rev 0, Mem @ 0xa0000000/16777216, 0x90000000/268435456, I/O @ 0x00004000/64, BIOS @ 0x????????/131072
[  1007.975] (II) LoadModule: "glx"
[  1007.975] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[  1007.976] (II) Module glx: vendor="X.Org Foundation"
[  1007.976] 	compiled for 1.20.3, module version = 1.0.0
[  1007.976] 	ABI class: X.Org Server Extension, version 10.0
[  1007.976] (==) Matched intel as autoconfigured driver 0
[  1007.976] (==) Matched modesetting as autoconfigured driver 1
[  1007.976] (==) Matched fbdev as autoconfigured driver 2
[  1007.976] (==) Matched vesa as autoconfigured driver 3
[  1007.976] (==) Assigned the driver to the xf86ConfigLayout
[  1007.976] (II) LoadModule: "intel"
[  1007.976] (WW) Warning, couldn't open module intel
[  1007.976] (EE) Failed to load module "intel" (module does not exist, 0)
[  1007.976] (II) LoadModule: "modesetting"
[  1007.976] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[  1007.976] (II) Module modesetting: vendor="X.Org Foundation"
[  1007.976] 	compiled for 1.20.3, module version = 1.20.3
[  1007.976] 	Module class: X.Org Video Driver
[  1007.976] 	ABI class: X.Org Video Driver, version 24.0
[  1007.976] (II) LoadModule: "fbdev"
[  1007.976] (WW) Warning, couldn't open module fbdev
[  1007.976] (EE) Failed to load module "fbdev" (module does not exist, 0)
[  1007.976] (II) LoadModule: "vesa"
[  1007.976] (WW) Warning, couldn't open module vesa
[  1007.976] (EE) Failed to load module "vesa" (module does not exist, 0)
[  1007.976] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  1007.976] (EE) 
Fatal server error:
[  1007.976] (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)
[  1007.976] (EE) 
[  1007.976] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[  1007.977] (EE) Please also check the log file at "/home/sean/.local/share/xorg/Xorg.0.log" for additional information.
[  1007.977] (EE) 
[  1007.977] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
[  1007.977] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
[  1007.977] (EE) Server terminated with error (1). Closing log file.

[saboya]

Enable "suid" USE flag, or configure Xorg properly so it works without it.

[Anon-E-moose]

Enable "suid" USE flag, or configure Xorg properly so it works without it.

Or if you don't want to recompile X just for suid, be root and do "chmod 4711 /usr/bin/Xorg" it does the same thing as using the suid flag in the ebuild.

[seansmr]

Thanks for the suggestions.

I have been through the Xorg and intel guide again, I cannot find anything that I can correct.
I still have the missing fbdev and vesa modules.

Is there some place that I can find the proper configuration for Xorg?

Would the 4.18 kernel help for the intel coffee lake?

I have been running Gentoo since 2005 without any problems, however this new system is never without a problem. It is not fully functional, there is a constant stream of other problems that limit the things that I can do.

[Chiitoo]

As mentioned, USE="suid" should restore old behaviour. Does it not?

The flag was recently re-added, defaulting off, which breaks the 'startx' method of starting X.

See also:

• [topic=1088682]Why is our xorg-server setuid, again?[/topic]
• [topic=1088842]/dev/tty0 permission error [SOLVED][/topic]
• [bug=669648]Bug 669648 - x11-base/xorg-server: add USE=suid so that /usr/bin/Xorg setuid can be disabled[/bug]
• Gentoo Wiki - Non root Xorg

[sebaro]

So USE="-suid" won't work with startx/xinit (without a display manager or systemd) unless I setuid the Xorg manually?

[Anon-E-moose]

So USE="-suid" won't work with startx/xinit (without a display manager or systemd) unless I setuid the Xorg manually?

It depends on which video card/driver you're using and how much you want to tinker with the system.

The gentoo wiki, from Chiitoo's links above tells most.

If you're using intel modesetting driver it won't work, at least I haven't been able to make it work yet.
Open source drivers nouveau, radeon, etc should work, I don't think the closed source ones will though.

[sebaro]

It depends on which video card/driver you're using and how much you want to tinker with the system.

I'm using amdgpu, I've created the udev rule and added my user to video and input groups, flags: glamor, udev, xorg.
X fails with:

[ 2954.317] (WW) Falling back to old probe method for modesetting
[ 2954.317] (WW) Falling back to old probe method for fbdev
[ 2954.318] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 2954.552] (EE)
[ 2954.552] (EE) AddScreen/ScreenInit failed for driver 0
[ 2954.552] (EE)
[ 2954.552] (EE)
[ 2954.552] (EE) Please also check the log file at "/home/.local/share/xorg/Xorg.0.log" for additional information.
[ 2954.552] (EE)
[ 2954.572] (EE) Server terminated with error (1). Closing log file.

[Anon-E-moose]

You might be wanting to use amdgpu, but that's not what's being tried, you're using the modesetting driver, according to the log in your first post.
and modesetting driver doesn't work non-suid

post your xorg.conf file

[sebaro]

You might be wanting to use amdgpu, but that's not what's being tried, you're using the modesetting driver, according to the log in your first post.
and modesetting driver doesn't work non-suid

post your xorg.conf file

So only open-source/modesetting nvidia and intel works?
I don't use xorg.conf.

[Anon-E-moose]

xf86-video-{nouveau and intel} have been known to work but not the modesetting driver provided by xorg, which is ironic.
Some of the other xf86-video drivers might work, such as the amdgpu or ati one, but I haven't tested them.

If you're running a newer amd card, emerge xf86-video-amdgpu, or for the older ones xf86-video-ati, though if you have the VIDEO_CARDS set in make.conf it should pick those up.

Paste your "emerge --info"


ETA: https://wiki.archlinux.org/index.php/AMDGPU or https://wiki.gentoo.org/wiki/AMDGPU

[sebaro]

xf86-video-{nouveau and intel} have been known to work but not the modesetting driver provided by xorg, which is ironic.
Some of the other xf86-video drivers might work, such as the amdgpu or ati one, but I haven't tested them.

If you're running a newer amd card, emerge xf86-video-amdgpu, or for the older ones xf86-video-ati, though if you have the VIDEO_CARDS set in make.conf it should pick those up.

Paste your "emerge --info"


ETA: https://wiki.archlinux.org/index.php/AMDGPU or https://wiki.gentoo.org/wiki/AMDGPU

The amdgpu x11 driver is installed (xf86-video-amdgpu-9999) and I think xorg it's using it, I don't know what that warning is about:

(II) LoadModule: "amdgpu"
(II) Loading /usr/lib64/xorg/modules/drivers/amdgpu_drv.so
(II) LoadModule: "modesetting"
(II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
...
(II) AMDGPU(0): [KMS] Kernel modesetting enabled.
(WW) Falling back to old probe method for modesetting
..
(II) UnloadModule: "modesetting"
(II) Unloading modesetting
Unable to retrieve master
(EE) Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 0

With USE="suid" after unloading the modesetting module:

(II) AMDGPU(0): [DRI2] Setup complete
(II) AMDGPU(0): [DRI2] DRI driver: radeonsi
(II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
(II) AMDGPU(0): Front buffer pitch: 5120 bytes
(II) AMDGPU(0): SYNC extension fences enabled
(II) AMDGPU(0): Present extension enabled
(==) AMDGPU(0): DRI3 enabled
(==) AMDGPU(0): Backing store enabled
(II) AMDGPU(0): Direct rendering enabled
(II) AMDGPU(0): Use GLAMOR acceleration.
(II) AMDGPU(0): Acceleration enabled
(==) AMDGPU(0): DPMS enabled
(==) AMDGPU(0): Silken mouse enabled
(II) AMDGPU(0): Set up textured video (glamor)

[jonathan183]

xf86-video-{nouveau and intel} have been known to work but not the modesetting driver provided by xorg, which is ironic.

I am using

Code: Select all

[ebuild   R    ] x11-base/xorg-server-1.20.3:0/1.20.3::gentoo  USE="glamor kdrive xephyr xorg xvfb -debug -dmx -doc -ipv6 -libressl -minimal (-selinux) -static-libs -suid -systemd -udev -unwind -wayland -xcsecurity -xnest" 0 KiB

although I have

Code: Select all

[ebuild   R    ] x11-base/xorg-drivers-1.20::gentoo  INPUT_DEVICES="keyboard mouse synaptics -elographics -evdev -joystick -libinput (-tslib) -vmmouse -void -wacom" VIDEO_CARDS="nouveau radeon vesa -amdgpu -ast -dummy -fbdev (-freedreno) (-geode) -glint -i915 -i965 -intel -mga -nv -nvidia (-omap) -qxl -r128 -radeonsi -siliconmotion (-tdfx) (-tegra) (-vc4) -via -virtualbox -vmware (-voodoo)" 0 KiB

This system has

Code: Select all

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [GeForce GT 610] [10de:104a] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device [1043:8496]
        Flags: bus master, fast devsel, latency 0, IRQ 28, NUMA node 0
        Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
        Memory at d0000000 (64-bit, prefetchable) [size=128M]
        Memory at d8000000 (64-bit, prefetchable) [size=32M]
        I/O ports at e000 [size=128]
        Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Endpoint, MSI 00
        Capabilities: [b4] Vendor Specific Information: Len=14 <?>
        Capabilities: [100] Virtual Channel
        Capabilities: [128] Power Budgeting <?>
        Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Kernel driver in use: nouveau
        Kernel modules: nouveau

I am using mdev as a device manager, have root mounted readonly and run in /etc/local.d/002-fix-device-ownerships.start

Code: Select all

### DRI for none root Xorg
### ======================

chown root:video /dev/dri/card0 -R 1> /dev/null 2> /dev/null

# change ownership and group information for Xorg - should only really needed after re-emerge but need to remount read/write to update /usr/bin/Xorg group properties
chown -v :input /usr/bin/Xorg 1> /dev/null 2> /dev/null
chmod g+s /usr/bin/Xorg 1> /dev/null 2> /dev/null

# put message on screen during startup to give a clue to the potential fix for X stopping working
echo "If X stops working try remounting read/write and running /etc/local.d/002-fix-device-ownerships.start ;-)"

### Set permissions for Kensington Expert Mouse Trackball - for none root Xorg
### ==========================================================================

chown :input /dev/input/mice
chown :input /dev/input/mouse*

This is sufficient to allow X to work with

Code: Select all

startx -- vt1

This works for me but only allows a single X session at a time; I used to be able to run startx and get X in tty7 and be able to use startx in another tty and get the second X in tty8 etc. There is no doubt a better way of doing this which I will pick up at some point ... I think it is better from a security point of view than suid but I could be wrong

[sebaro]

@jonathan183

chown -v :input /usr/bin/Xorg 1> /dev/null 2> /dev/null
chmod g+s /usr/bin/Xorg 1> /dev/null 2> /dev/null

If you add the user to the input group you don't have to setgid the Xorg binary.
Maybe this is better than running it as root (setuid) but this shouldn't be required to run it as normal user.

[JustAnother]

I just had the same problem:

Code: Select all

parse_vt_settings: cannot open /dev/tty0

happen on a 32 bit machine and a 64 bit machine. The power went off when I was out, forcing a reboot, so the output from the emerge update was gone. To my surprise, I couldn't get into my system using startxfce4.

This is a serious issue. One thing that freaks people out is to suddenly get shut out of their own machine. Assuming one has access to the Internet,
what shows up is about ten years worth of very technical discussion, with lots of ambiguous and overlapping advice, and no obvious concrete solutions.

I too fixed it (I hope) by putting this into an /etc/portage/package.use file:

Code: Select all

x11-base/xorg-server suid

Two suggestions and one question:

When discussing these matters please keep in mind that people are upset when this stuff happens, so specific advice as opposed to generalities will go a
long way to unfreak out the freaked out people. Also, a little whitepaper concerning this topic would help -- a little context, the underlying problem,
several ways to attack it, etc. An x11 expert would have to write this.

The other suggestion: these complex packages like gnome and x11 are written by people who are probably up to their eyeballs fixing a whole bunch of things.
What would really help is for some other party to write sniffer programs that explain and verify all the strange things that have to fall into place to
make these monolithic software suites work without any bizarre and unintelligible errors. Complex permission scenarios are a good example of this need. These sniffer programs are really the bottom rung of a test suite that builds up to the full software suite. I've always felt that a suite such as gnome needs 3 to 4 layers of sniffers.

Here's my question: when x11 was still broken, I was able to run

Code: Select all

startxfce4

as root, or using

Code: Select all

sudo

. But the x11 graphics came up in the root account, when I wanted to use the graphics in my usual account. Is there any way to do this -- that is, start x11 as root out of necessity, then use x11
as if it was started from my user account?

[Anon-E-moose]

startx <path to users .xinitrc>, everything will still start as root, but system will start with what you expect

If it ever happens again "chmod 4711 /usr/bin/Xorg" as root should get you going.

[Hu]

Maybe this is better than running it as root (setuid) but this shouldn't be required to run it as normal user.

Maybe, but maybe not. If you add the user to the input group, then everything the user runs is in the input group. That gives all user processes the ability to read every device that is restricted to the input group, even when the user is not logged in on the console. If you make the server setuid root, only the server has root. Ideally, you want to run the user programs without the input group and the server with as little extra access as possible. Giving the server root is overkill. It only needs certain groups, such as input and possibly video.

[jonathan183]

@jonathan183

chown -v :input /usr/bin/Xorg 1> /dev/null 2> /dev/null
chmod g+s /usr/bin/Xorg 1> /dev/null 2> /dev/null

If you add the user to the input group you don't have to setgid the Xorg binary.
Maybe this is better than running it as root (setuid) but this shouldn't be required to run it as normal user.

Thanks for the suggestion, but having read Gentoo Wiki - Non root Xorg security concerns I decided it was probably a good idea not to add my user to the input group ... my user is still in the video and users groups.

[hackernotcracker]

Split this and the five (5) following posts from [topic=1077662]Unable to start X as normal user[/topic], as it's a bit older and while related, not /exactly/ about the same issue (the recent change that enables several people to experience it right now). —[profile=215889]Chiitoo[/profile]

Take a look at the Non Root Xorg entry at the Wiki.

At the time this thread was made, I think non-root mode X11 was only in testing.
However, I just did an emerge --sync, today, Nov 8,2018; and it is now mainstream but non-functional.
I have the same "unable to retrieve master" error message as in the opening post.
I followed the wiki's instructions ... and no joy for me, because I use AMD GPU's.

I'm unable to do work right now .. because the upgrade broke my computer.
I'm puzzled why this bug was not fixed or at least a warning issued before Gentoo released "X11 non-root" as the default for all unsuspecting Gentoo users.
Where do I complain?

Gentoo is designed to run without systemd as a default "feature"; that's one major reason I migrated to Gentoo from Slackware.
I'm sure there are lots of other users who don't want sytemd either.

But a non-root, X11 upgrade (and the WIKI you cited) breaks anyone's computer with an AMD graphics card (especially newer ones, Radeons, R290, R300.... etc.) and uses the Gentoo init script system and not systemd. There are a lot of potentially broken gentoo systems that are going to happen as soon as people "sync".

The problem has been known since 2015
https://unix.stackexchange.com/question ... thout-root

Yet it was released on Gentoo with an un-patched X11 that breaks AMD GPU's without so much as a WARNING to people?
I mean, the final post cites a link from the Gentoo organization ... so someone knew ???
https://archives.gentoo.org/gentoo-user ... 35c11154f1

WTF?

I've had Gentoo upgrades break two programs in the last six months, hostapd, dnsmasq;
https://superuser.com/questions/1371432 ... -addresses
Hostapd isn't able to find or read the configuation file, even though it's installed in the same place as always.
In fact, the only reason I "syncd" again, was to see if hostapd was fixed yet ; but now it and X11 are both broken.
I don't like the direction Gentoo is going right now...


If I put a "suid" use flag on the Xorg server, I'm concerned that I will have a larger security risk, because the Gentoo developers are assuming suid is not set. Who knows what assumptions they will make in the future ...

What's the safest way for me to get my computer back?

[Anon-E-moose]

If I put a "suid" use flag on the Xorg server, I'm concerned that I will have a larger security risk, because the Gentoo developers are assuming suid is not set. Who knows what assumptions they will make in the future ...

What's the safest way for me to get my computer back?

Up until this latest release it was always suid.

non-suid works for some cases, but not all, if you run startx then suid is the way to go.
If you run a DM (lightdm, sddm, gdm, etc) then they should take care of non-suid X, though to be honest it's running root behind the scenes.

If you just want to get it running then "chmod 4711 /usr/bin/Xorg" as root, it's now back to suid.

[hackernotcracker]

Up until this latest release it was always suid.
...
If you just want to get it running then "chmod 4711 /usr/bin/Xorg" as root, it's now back to suid.

I've always run X11 as startx with open-box, because I try to run a minimalist linux system. It's getting harder to do...
I'll go ahead and do the chmod for now.

I get/understand that SUID is safe at the moment ... The developers haven't had a chance to introduce new code that depends on X11 running without root priveleges;
I'm still concerned about assumptions developers will make in the future (and accidents) that compromise my computer if I can't run X11 as non root in the future.

But if the X11 managers handle stuff as root in the background, like you say, then chances are that developers will have to assume X11 is running as root. If that's the case, I don't need to worry; but I wonder why they bothered making X11 not have the suid bit on it?

The removal doesn't really enhance security in any way, but gives developers a false sense that X is not running as root (ever) ... when it occasionally is? Did I understand you correctly?

[Anon-E-moose]

You can do a little song and dance, with certain video card/x11 drivers and have it work as non-root, though it involves being part of a input and video groups, so that makes it a little less than secure right there, and for some drivers, modesetting by xorg, it doesn't even work then, at least I haven't been able to make it work.

For me, I run a single user machine, with a hardened firewall and don't run things foolishly, so I feel pretty secure.

In the case of a DM, they start X as root, though I'm not sure if it constantly runs as root, or if they relinquish those privileges after it starts, but it still runs as root for part of it's life.
If I'm not mistaken, running it under systemd, does the same thing, root for a while.

X being non-suid doesn't necessarily mean it's secure.

What should happen is that X should start as root, do what it needs to do with tty, input, video, etc and then relinquish privileges in favor of the user who started it.
And they may get there eventually.

[Hu]

The removal doesn't really enhance security in any way, but gives developers a false sense that X is not running as root (ever) ... when it occasionally is? Did I understand you correctly?

Not exactly. The recent vulnerability is related to a privileged (root) Xorg server receiving untrusted arguments, not validating them sufficiently, then taking action (as root) influenced by those arguments. If Xorg is not suid, and is instead run as root by a wrapper program, and we assume the wrapper does not pass dangerous arguments, then that input sanitization vulnerability would have been irrelevant because the wrapper does not pass unsafe inputs, and any user who did would be running as himself, not as root. Instead, if Xorg is suid, any user can invoke it with any crazy arguments he wants, and if the input sanitization is inadequate, bad things happen. So in that area, making Xorg not suid is a good thing. It restricts the ability of untrusted users to pass dangerous arguments to a privileged program, because now the arguments must make it through the wrapper. Good wrappers will limit or completely forbid untrusted users' ability to pass arbitrary arguments. As discussed in this thread, there are plenty of drawbacks to removing suid, which is why this move is not met with universal approval.

[roboto]

I haven't upgraded X11 since March and I don't plan on doing it regardless of the security vulnerabilities because I don't want to end up with the hassle of a broken system.

[seansmr]

Thanks for the help. Understanding is better than following instructions, but it takes a while.

It was a new machine, without easy backup procedures in place (had an older backup) and it had become my main work machine, so I was suitable freaked out.

A change with such an effect should really have some kind of notification. It seems that this would also affect people following the Xorg guide.

I know what to do with my desktop, graphical login.
Does this mean that the startx method for starting a window manager should no longer be used for any reason?