Created attachment 13778 [details]
Xorg.0.log of my first attempt to run X from the console at runlevel 2

search for vieux in the logfile

Created attachment 13779 [details]
corresponding xorg.conf

Created attachment 13780 [details]
modified xorg.conf that disables dri and v4l

As I had to find out disabling dri and v4l didn´t make the X-server start either. Error message had remained the same.

Created attachment 13781 [details]
/proc/$(pgrep Xorg)/maps

By now I have found out that I can run /usr/libexec/Xorg directly. I had still used the xorg.conf disabling v4l and dri. As you can see from the memory map of Xorg in /proc the dynamic .so libraries still get loaded if you disable these modules; this will be the reason why /bin/Xorg did not start (which is just a bash script that calls /usr/libexec/Xorg.wrap, being a ¡¿socket?!) with the xorg.conf.2.

Created attachment 13782 [details]
Xorg.0.log with lxdm in the initial setting with v4l & dri

Finally I had restored the old xorg.conf.1 with v4l & dri and /usr/libexec/Xorg did still run. The Xorg.0.log is from-after a reboot that booted directly into lxdm at runlevel 5.

Created attachment 13783 [details]
/proc/$(pgrep Xorg)/maps with an lxdm boot and the initial xorg.conf using dri & v4l

Here are two links to my current testing efforts regarding Xorg, s2ram and nouveau: https://gitlab.freedesktop.org/drm/nouveau/-/issues/194 , https://gitlab.gnome.org/tasali/webkit2gtk/-/issues/1 .

I don´t know exactly since when this error has appeared; I can only remember  that the X-server could most likely be started correctly from console when I suceeded to resolve screen distortions by unloading and re-loading the nouveau kernel module in the gitlab.freedesktop thread. If it wasn´t then it for sure was at the beginning of that thread.

Created attachment 13784 [details]
installed packages at the time of the report

Update to mesa-23.0.3-1.mga9 didn´t resolve the issue:
> ls -l /usr/lib/dri/
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 crocus_dri.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 i915_dri.so*
-rwxr-xr-x  1 root root  8330012 Feb  9 22:29 i965_drv_video.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 iris_dri.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 kms_swrast_dri.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 nouveau_dri.so*
-rwxr-xr-x  4 root root 13226624 Apr 22 04:12 nouveau_drv_video.so*
lrwxrwxrwx  1 root root       18 Feb  9 20:02 nvidia_drv_video.so -> vdpau_drv_video.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 r300_dri.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 r600_dri.so*
-rwxr-xr-x  4 root root 13226624 Apr 22 04:12 r600_drv_video.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 radeonsi_dri.so*
-rwxr-xr-x  4 root root 13226624 Apr 22 04:12 radeonsi_drv_video.so*
lrwxrwxrwx  1 root root       18 Feb  9 20:02 s3g_drv_video.so -> vdpau_drv_video.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 swrast_dri.so*
-rwxr-xr-x  1 root root   120680 Feb  9 20:02 vdpau_drv_video.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 virtio_gpu_dri.so*
-rwxr-xr-x  4 root root 13226624 Apr 22 04:12 virtio_gpu_drv_video.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 vmwgfx_dri.so*
-rwxr-xr-x 12 root root 32352912 Apr 22 04:12 zink_dri.so*

Initially I had tried to create a link from nouveau_dri.so and/or nouveau_drv_video.so to nouveau_vieux_dri.so, but that didn´t resolve the issue: "error nouveau_vieux exports no extension".

(In reply to Elmar Stellnberger from comment #0)
> Whenever I boot directly into lxde using lxdm everything works fine. However
> if I start with runlevel 2 and want to invoke an xinit, the X-server won´t
> start:
> AIGLX error: dlopen of /usr/lib/dri/nouveau_vieux.dri.so failed
> 

Why do you or anyone else need to do start X like that? Why not start lxdm from the command line?

CC: (none) => marja11
Status: NEW => NEEDINFO

(In reply to Marja Van Waes from comment #11)

> 
> Why do you or anyone else need to do start X like that? Why not start lxdm
> from the command line?

I mean like this, as root: 

  systemctl start lxdm.service

  That has to work. I often run a second X-server for games in different resolution by use of xinit. Also you may decide not to use a display manager. What if you work on the console by default and only start an X-server for special cases? Also to my knowledge lxdm is the only possible choice for elder computers if you want autologin, because xdm does not do that and heavy weigth display managers like gdm and kdm won´t work. Thinking about my EEEPC it has little disk space and memory (like quite some i386 systems) and I don´t wanna be forced to use an autostarting dm, there.

  Apart from the fact that starting Xorg needs to be possible manually (otherwise it is clearly a bug) this report points out about a very different issue: DRI does not work and nouveau_vieux.dri.so is missing. It may just be a bug on its own that /usr/libexec/Xorg starts without a proper check for this.

Status: NEEDINFO => UNCONFIRMED
Ever confirmed: 1 => 0

You are using ancient hardware whose upstream support was removed from Mesa in march 2022:
https://docs.mesa3d.org/amber.html
Starting with mesa 22 (march 2022) your hardware is deprecated.

Mageia 8 had lib64dri-drivers-21.3.8-2.mga8 which contains nouveau_vieux.dri.so.
Mageia 9 has lib64dri-drivers-23.0.0-2.mga9 without nouveau_vieux.dri.so as upstream support got removed.

The noveau devs even reject bugreports for this deprecated drivers:
https://nouveau.freedesktop.org/MesaDrivers.html

Ouch. Elmar, try with adding xdriver=vesa to the command line.

Just fyi I normally use run level 3 on my non testing installs. A habit
developed when I was using very old hardware.

I just tested a fully up-to-date Mageia 9 x86_64 install, and after login at
run level 2 "startx startkde" is working for me.

Under systemd, run levels 2,3, and 4 are all treated the same as run level 3
was prior to systemd.

$ ll /lib/systemd/system/runlevel*|grep '>'
lrwxrwxrwx 1 root root   15 Nov 16 12:53 /lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root   13 Nov 16 12:53 /lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root   17 Nov 16 12:53 /lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root   17 Nov 16 12:53 /lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root   17 Nov 16 12:53 /lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root   16 Nov 16 12:53 /lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root   13 Nov 16 12:53 /lib/systemd/system/runlevel6.target -> reboot.target

CC: (none) => davidwhodgins

  You have cited a resource that tells the NV04-NV20 (GeForce 420 Go is NV17 due to Xorg.0.log) are still supported by the amber branch of Mesa. If you support the i386 architecture and Mageia´s support for it was quite well up to now, why don´t you use the amber branch for i386, then? Computers with PIV or elder CPUs usually come with elder graphics hardware. I386 is particularely useful exactly on these machines, especially if you don´t use HIGHMEM64G as kernel config option (which Mageia currently doesn´t use).
* https://www.kernelconfig.io/CONFIG_HIGHMEM64G?q=highmem64G&kernelversion=6.2.12&arch=x86
* zgrep HIGHMEM /proc/config.gz -> CONFIG_HIGHMEM4G=y - and not HMEM64G

Apparently I need to blacklist nouveau for that: Xorg.log says "Refusing to run, Framebuffer or dri device present". Dave, I have never heard or seen a xdriver=vesa command line option, also Xorg -xdriver=vesa does not work; I had to change my xorg.conf.

Blacklisting Nouveau and use of Vesa forces me to lower resolutions and there is no glx module or an xrandr for attaching an external monitor using that. Something I clearly don´t want for the PIV or newer machines. Please keep that supported! Why care that much if they don´t officially support bug reports for the amber branch; usually things can continue to work for just a long time if no one actively breaks them.

Can anyone point me onto how to open up an upstream report for Bug 31834? where should it be?: https://gitlab.freedesktop.org/drm, https://gitlab.freedesktop.org/search?search=mesa

> where should it be?

Issue a report and you may be guided there if right or wrong :)

From what we currently have, can we summon up and write something short symptom-remedy in errata or https://wiki.mageia.org/en/Setup_the_graphical_server ?

CC: (none) => fri

Any news here?