How to get a shell login when booted in graphical target

I am setting up to move to a Rocky 9 system from CentOS 7.
I downloaded and installed on a new laptop (Lenovo P16s Gen 2) the
Rocky 9 .iso from the Mate GUI website, as I want to use Mate, not
GNOME. This boots in graphical.target and provides only a graphical
mode login but otherwise works.
I am trying to make the bootup and login experience work the
way I want it. In CentOS 7, bootup or logoff in my setup goes
to a text (“console”) login. When a user logs in, their .login
runs and asks whether command (shell) or graphics login is wanted.
Command choice returns to the shell, graphics choice runs ‘startx’.
The only way I have found to get a shell login in Rocky is to
make the default startup multiuser.target, but then I can’t
just start up the GUI from a shell script. The system has ‘startx’
so all I think I need is:

How can I get a shell (non-graphics) login by default after bootup
or logoff while in graphical.target?

Any help with this would be most appreciated.
Thanks,
George Reeke

AFAIK, the startx in deprecated, and future (after el9) will probably be without X11.

The multiuser.target is about same as runlevel 3 used to be. If you can run startx, then you can run it. Can you?

The graphical.target (and runlevel 5 before systemd) does start display manager that displays GUI login dialog and starts GUI desktop session for user. (One can boot to multi-user and then systemctl isolate graphical.target to switch to graphical, but that is not a “by user” action.)


CentOS 7 has already systemd, so you ought to have the same “boot to multiuser.target” there as in Rocky 9.

Logging in as mself (cdr) or as root, running at multiuser.target, and typing
‘startx’ I get this output (The forum site wouldn’t let me upload, so just
copying here, not too long:
xauth: file /home/cdr/.serverauth.2863 does not exist
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: 5.4.188-104.359.amzn2.x86_64
Current Operating System: Linux marengo4 5.14.0-362.24.1.el9_3.0.1.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 4 22:31:43 UTC 2024 x86_64
Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-362.24.1.el9_3.0.1.x86_64 root=UUID=e1e5f118-f82e-4d67-a267-c2a3303e7dfc ro resume=UUID=f7db5028-614a-4cfe-9a1c-dc5f740359d5 rd.luks.uuid=luks-14485a23-b7fa-4e67-8f12-a7bd9cbfff3c rhgb quiet crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M
Build Date: 06 June 2023 12:00:00AM
Build ID: xorg-x11-server 1.20.11-19.el9
Current version of pixman: 0.40.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: “/var/log/Xorg.0.log”, Time: Tue Apr 30 13:40:09 2024
(==) Using config directory: “/etc/X11/xorg.conf.d”
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
(II) modeset(0): Initializing kms color map for depth 24, 8 bpc.
The XKEYBOARD keymap compiler (xkbcomp) reports:

Warning: Symbol map for key redefined
Using last definition for conflicting fields
Errors from xkbcomp are not fatal to the X server
xinit: connection to X server lost
^M
waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.
----End of quoted startx failure output----

Toward the end the
screen flashes briefly with my background color, then goes back to
the console login. So I think you are right, the infrastructure is there
for a GUI session, I just need to deal with the startx errors. Any pointers
where to start? Like find out how to provide the missing .serverauth file?

Sorry for the previous post, I should have checked more first. Looking in
/var/log/Xorg.0.log I see that it has loaded module ‘nvidia’ (yes, I
have nvidia graphics and installed the nvidia driver, and it works
when I boot in graphical) but then it also tries to ‘LoadModule nouveau’.
And that fails. I thought I had gotten rid of the nouveau driver by the
usual blacklist methods, but I guess I didn’t succeed. Getting rid of
this error is the clear path forward. Note: The nvidia driver installer
offers to remove nouveau from initramfs, and I always choose that
option. So maybe the error is more trying to load nouveau and not
finding it.

Don’t forget that Rocky is quite tighly integrated with gnome display manager “gdm” and Wayland (not x server).

That is as expected.

The X11 defaults to dynamic configuration and attempts to load various drivers. That is by design. Note that the “NVidia driver” is two things: kernel modules and “X11 drivers”. The kernel modules could be used also by CUDA runtime on systems that have no X11 at all. In this case the X11 tests whether it can load “X11 nouveau driver”, which is not possible when “nouveau kernel driver” is disabled.

The ‘gdm’ provides config in /usr/lib/udev/rules.d/61-gdm.rules that most likely disables Wayland since NVidia’s repo does not provide all the things tested within those rules. Yes, by default GDM runs with Wayland and offers Wayland-based GNOME session for user. However, with NVidia binaries that is not possible (might be with RPM Fusion version).


The ‘root’ is not supposed to have GUI session. Ever.

The root can run systemctl isolate graphical.target ; exit
Then regular users can use graphical login.

It might be the systemd, which creates user sessions in one way or other, that does not quite digest the “user starts X11” approach.