startx fails on first run with "Cannot run in framebuffer mode"

[Dan Kegel]

Fresh ubuntu 20.04 machine with a gtx 1080.

Configured to boot to commandline with sudo systemctl set-default multi-user.target

Proprietary driver nvidia 440 installed with 'ubuntu-driver install'.

Rebooted.

Logged in, ran startx.

Startx ran fine.

Configured system to log in automatically by creating /<email address hidden>/autologin.conf
containing

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin buildbot --noclear %I 38400 linux
[Unit]
Wants=network-online.target
After=network-online.target

Installed lwm and xterm, created a simple .xinitrc that just runs xterm and lwm:

/usr/bin/xterm -geometry 80x25+0-0 &
exec lwm

In .profile, added lines at the end to run startx if at console:

case `tty` in
/dev/tty1) startx;;
esac

Rebooted.

Startx failed with

(EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices

Running startx again manually worked fine.

Adding a second startx after the first one in .profile also worked fine.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: nvidia-driver-440 440.82+really.440.64-0ubuntu6
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckResult: skip
Date: Fri Apr 24 11:06:43 2020
InstallationDate: Installed on 2020-04-24 (0 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: nvidia-graphics-drivers-440
UpgradeStatus: No upgrade log present (probably fresh install)

[Dan Kegel (dank)]

BTW this worked fine on earlier versions of ubuntu, including 18.04 and 19.10.

(I'm perfectly happy to hear it's user error, and the login needs to wait for something other than network-online.target, or that I did the wait wrong. The wait didn't seem to be needed before. Also, I didn't mention this, but adding 'sleep 10' before startx didn't seem to help.)

[Dan Kegel (dank)]

The 2nd startx workaround turns out not to work, alas; I spoke too soon.

[Daniel van Vugt (vanvugt)]

Possibly related:

  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2755

which is fixed in gnome-shell 3.37.2.