System Update Today Broke Lightdm - Error getting user list from org.freedesktop.Accounts: GDBus.??
All, Lightdm has been working fine up until pacman update today. After the update, lightdm fails with a garbled screen. The journal shows: Feb 07 00:58:57 valkyrie systemd[1]: Starting Light Display Manager... Feb 07 00:59:00 valkyrie systemd[1]: Started Light Display Manager. Feb 07 00:59:00 valkyrie lightdm[782]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Main process exited, code=exited, status=1/FAILURE Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Failed with result 'exit-code'. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 1. Feb 07 00:59:07 valkyrie systemd[1]: Stopped Light Display Manager. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time. Lightdm.log shows the same: [+0.01s] WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files What changed and what must be done to fix it? -- David C. Rankin, J.D.,P.E.
On 2/7/23 09:11, David C. Rankin wrote:
All,
Lightdm has been working fine up until pacman update today. After the update, lightdm fails with a garbled screen. The journal shows:
Feb 07 00:58:57 valkyrie systemd[1]: Starting Light Display Manager... Feb 07 00:59:00 valkyrie systemd[1]: Started Light Display Manager. Feb 07 00:59:00 valkyrie lightdm[782]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Main process exited, code=exited, status=1/FAILURE Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Failed with result 'exit-code'. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 1. Feb 07 00:59:07 valkyrie systemd[1]: Stopped Light Display Manager. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time.
Lightdm.log shows the same:
[+0.01s] WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
What changed and what must be done to fix it?
Fyi using lightdm 1.32.0-4 with lxqt I do see the same (warning) errors in my loggings. But I do not experience errors logging in with lightdm. Also last lightdm update on my arch system was in september last year. Maybe the cause lies elsewhere ? ~Z
"David C. Rankin" <drankinatty@gmail.com> wrote:
All,
Lightdm has been working fine up until pacman update today. After the update, lightdm fails with a garbled screen. The journal shows:
Could be an overwriten /etc/shells. https://bugs.archlinux.org/task/77404. -- u34
Feb 07 00:58:57 valkyrie systemd[1]: Starting Light Display Manager... Feb 07 00:59:00 valkyrie systemd[1]: Started Light Display Manager. Feb 07 00:59:00 valkyrie lightdm[782]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Main process exited, code=exited, status=1/FAILURE Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Failed with result 'exit-code'. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 1. Feb 07 00:59:07 valkyrie systemd[1]: Stopped Light Display Manager. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time.
Lightdm.log shows the same:
[+0.01s] WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
What changed and what must be done to fix it?
-- David C. Rankin, J.D.,P.E.
On 2/7/23 04:35, u34@net9.ga wrote:
All,
Lightdm has been working fine up until pacman update today. After the update, lightdm fails with a garbled screen. The journal shows:
Could be an overwriten /etc/shells. https://bugs.archlinux.org/task/77404. -- u34
Thank you both, But it seems the error is deeper than that. startx will not launch fluxbox either (which has worked since 2013 when the server was built). Command output say Cannot connect to X server?? Huh? I use the nvidia-390xx driver, but it is built and quite happy: $ lsmod | grep nvidia nvidia_drm 57344 0 nvidia_modeset 1318912 1 nvidia_drm nvidia_uvm 1912832 0 nvidia 19505152 2 nvidia_uvm,nvidia_modeset video 65536 1 nvidia ipmi_msghandler 81920 2 ipmi_devintf,nvidia From the /var/log/Xorg.0.log, nvidia is loaded fine: [ 500.265] (II) NVIDIA(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 500.265] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32 [ 500.265] (==) NVIDIA(0): RGB weight 888 [ 500.265] (==) NVIDIA(0): Default visual is TrueColor [ 500.265] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) [ 500.265] (II) Applying OutputClass "nvidia" options to /dev/dri/card0 [ 500.265] (**) NVIDIA(0): Option "AllowEmptyInitialConfiguration" [ 500.266] (**) NVIDIA(0): Enabling 2D acceleration [ 500.973] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 500.973] (--) NVIDIA(0): CRT-0 (boot) [ 500.973] (--) NVIDIA(0): CRT-1 [ 500.973] (--) NVIDIA(0): DFP-0 [ 500.973] (--) NVIDIA(0): DFP-1 [ 500.973] (--) NVIDIA(0): DFP-2 [ 500.974] (II) NVIDIA(0): NVIDIA GPU GeForce GTX 460 (GF104) at PCI:1:0:0 (GPU-0) [ 500.974] (--) NVIDIA(0): Memory: 1048576 kBytes [ 500.974] (--) NVIDIA(0): VideoBIOS: 70.04.1b.00.70 [ 500.974] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 501.019] (--) NVIDIA(GPU-0): NEC LCD1765 (CRT-0): connected [ 501.019] (--) NVIDIA(GPU-0): NEC LCD1765 (CRT-0): 400.0 MHz maximum pixel clock [ 501.019] (--) NVIDIA(GPU-0): [ 501.022] (--) NVIDIA(GPU-0): CRT-1: disconnected [ 501.022] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock [ 501.022] (--) NVIDIA(GPU-0): [ 501.052] (--) NVIDIA(GPU-0): DFP-0: disconnected [ 501.052] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS [ 501.052] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock [ 501.052] (--) NVIDIA(GPU-0): [ 501.052] (--) NVIDIA(GPU-0): DFP-1: disconnected [ 501.052] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS [ 501.052] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock [ 501.052] (--) NVIDIA(GPU-0): [ 501.055] (--) NVIDIA(GPU-0): DFP-2: disconnected [ 501.055] (--) NVIDIA(GPU-0): DFP-2: Internal TMDS [ 501.055] (--) NVIDIA(GPU-0): DFP-2: 330.0 MHz maximum pixel clock [ 501.055] (--) NVIDIA(GPU-0): [ 501.058] (==) NVIDIA(0): [ 501.058] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select" [ 501.058] (==) NVIDIA(0): will be used as the requested mode. [ 501.058] (==) NVIDIA(0): [ 501.058] (II) NVIDIA(0): Validated MetaModes: [ 501.058] (II) NVIDIA(0): "CRT-0:nvidia-auto-select" [ 501.058] (II) NVIDIA(0): Virtual screen size determined to be 1280 x 1024 [ 501.060] (--) NVIDIA(0): DPI set to (95, 96); computed from "UseEdidDpi" X config [ 501.060] (--) NVIDIA(0): option [ 501.060] (II) UnloadModule: "modesetting" [ 501.060] (II) Unloading modesetting [ 501.061] (II) NVIDIA: Using 6144.00 MB of virtual memory for indirect memory [ 501.061] (II) NVIDIA: access. [ 501.063] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon [ 501.063] (II) NVIDIA(0): may not be running or the "AcpidSocketPath" X [ 501.063] (II) NVIDIA(0): configuration option may not be set correctly. When the [ 501.063] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will [ 501.063] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For [ 501.063] (II) NVIDIA(0): details, please see the "ConnectToAcpid" and [ 501.063] (II) NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X [ 501.063] (II) NVIDIA(0): Config Options in the README. [ 501.094] (II) NVIDIA(0): Setting mode "CRT-0:nvidia-auto-select" [ 501.158] (==) NVIDIA(0): Disabling shared memory pixmaps [ 501.158] (==) NVIDIA(0): Backing store enabled [ 501.158] (==) NVIDIA(0): Silken mouse enabled [ 501.158] (==) NVIDIA(0): DPMS enabled [ 501.158] (II) Loading sub module "dri2" [ 501.158] (II) LoadModule: "dri2" [ 501.158] (II) Module "dri2" already built-in [ 501.158] (II) NVIDIA(0): [DRI2] Setup complete [ 501.158] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia So what else to check on why lightdm, fluxbox and startx just stopped working and why startx says in can no longer connect to the X server? -- David C. Rankin, J.D.,P.E.
"David C. Rankin" <drankinatty@gmail.com> wrote:
On 2/7/23 04:35, u34@net9.ga wrote:
All,
Lightdm has been working fine up until pacman update today. After the update, lightdm fails with a garbled screen. The journal shows:
Could be an overwriten /etc/shells. https://bugs.archlinux.org/task/77404. -- u34
Thank you both,
But it seems the error is deeper than that. startx will not launch fluxbox either (which has worked since 2013 when the server was built).
Command output say Cannot connect to X server?? Huh?
I use the nvidia-390xx driver, but it is built and quite happy:
$ lsmod | grep nvidia nvidia_drm 57344 0 nvidia_modeset 1318912 1 nvidia_drm nvidia_uvm 1912832 0 nvidia 19505152 2 nvidia_uvm,nvidia_modeset video 65536 1 nvidia ipmi_msghandler 81920 2 ipmi_devintf,nvidia
From the /var/log/Xorg.0.log, nvidia is loaded fine:
[ 500.265] (II) NVIDIA(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 500.265] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32 [ 500.265] (==) NVIDIA(0): RGB weight 888 [ 500.265] (==) NVIDIA(0): Default visual is TrueColor [ 500.265] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) [ 500.265] (II) Applying OutputClass "nvidia" options to /dev/dri/card0 [ 500.265] (**) NVIDIA(0): Option "AllowEmptyInitialConfiguration" [ 500.266] (**) NVIDIA(0): Enabling 2D acceleration [ 500.973] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 500.973] (--) NVIDIA(0): CRT-0 (boot) [ 500.973] (--) NVIDIA(0): CRT-1 [ 500.973] (--) NVIDIA(0): DFP-0 [ 500.973] (--) NVIDIA(0): DFP-1 [ 500.973] (--) NVIDIA(0): DFP-2 [ 500.974] (II) NVIDIA(0): NVIDIA GPU GeForce GTX 460 (GF104) at PCI:1:0:0 (GPU-0) [ 500.974] (--) NVIDIA(0): Memory: 1048576 kBytes [ 500.974] (--) NVIDIA(0): VideoBIOS: 70.04.1b.00.70 [ 500.974] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 501.019] (--) NVIDIA(GPU-0): NEC LCD1765 (CRT-0): connected [ 501.019] (--) NVIDIA(GPU-0): NEC LCD1765 (CRT-0): 400.0 MHz maximum pixel clock [ 501.019] (--) NVIDIA(GPU-0): [ 501.022] (--) NVIDIA(GPU-0): CRT-1: disconnected [ 501.022] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock [ 501.022] (--) NVIDIA(GPU-0): [ 501.052] (--) NVIDIA(GPU-0): DFP-0: disconnected [ 501.052] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS [ 501.052] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock [ 501.052] (--) NVIDIA(GPU-0): [ 501.052] (--) NVIDIA(GPU-0): DFP-1: disconnected [ 501.052] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS [ 501.052] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock [ 501.052] (--) NVIDIA(GPU-0): [ 501.055] (--) NVIDIA(GPU-0): DFP-2: disconnected [ 501.055] (--) NVIDIA(GPU-0): DFP-2: Internal TMDS [ 501.055] (--) NVIDIA(GPU-0): DFP-2: 330.0 MHz maximum pixel clock [ 501.055] (--) NVIDIA(GPU-0): [ 501.058] (==) NVIDIA(0): [ 501.058] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select" [ 501.058] (==) NVIDIA(0): will be used as the requested mode. [ 501.058] (==) NVIDIA(0): [ 501.058] (II) NVIDIA(0): Validated MetaModes: [ 501.058] (II) NVIDIA(0): "CRT-0:nvidia-auto-select" [ 501.058] (II) NVIDIA(0): Virtual screen size determined to be 1280 x 1024 [ 501.060] (--) NVIDIA(0): DPI set to (95, 96); computed from "UseEdidDpi" X config [ 501.060] (--) NVIDIA(0): option [ 501.060] (II) UnloadModule: "modesetting" [ 501.060] (II) Unloading modesetting [ 501.061] (II) NVIDIA: Using 6144.00 MB of virtual memory for indirect memory [ 501.061] (II) NVIDIA: access. [ 501.063] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon [ 501.063] (II) NVIDIA(0): may not be running or the "AcpidSocketPath" X [ 501.063] (II) NVIDIA(0): configuration option may not be set correctly. When the [ 501.063] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will [ 501.063] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For [ 501.063] (II) NVIDIA(0): details, please see the "ConnectToAcpid" and [ 501.063] (II) NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X [ 501.063] (II) NVIDIA(0): Config Options in the README. [ 501.094] (II) NVIDIA(0): Setting mode "CRT-0:nvidia-auto-select" [ 501.158] (==) NVIDIA(0): Disabling shared memory pixmaps [ 501.158] (==) NVIDIA(0): Backing store enabled [ 501.158] (==) NVIDIA(0): Silken mouse enabled [ 501.158] (==) NVIDIA(0): DPMS enabled [ 501.158] (II) Loading sub module "dri2" [ 501.158] (II) LoadModule: "dri2" [ 501.158] (II) Module "dri2" already built-in [ 501.158] (II) NVIDIA(0): [DRI2] Setup complete [ 501.158] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia
So what else to check on why lightdm, fluxbox and startx just stopped working and why startx says in can no longer connect to the X server?
-- David C. Rankin, J.D.,P.E.
Downgrading, reverting, the upgrade. Hopefully, everything will work, and upgrading each package own its own? What packages were upgraded? -- u34
On 2/7/23 06:30, u34@net9.ga wrote:
Downgrading, reverting, the upgrade. Hopefully, everything will work, and upgrading each package own its own? What packages were upgraded?
Yes, That may be a bit of a challenge. There were 2-days worth of updates, but from an overview standpoint -- it looks like the kernel is the most likely culprit and the nvidia driver. I have another Arch box with Intel graphics, and startx/fluxbox works fine there. Thinking it may be the AUR drivers, I rebuilt the nvidia drivers as well, e.g. $ pmq | grep nvidia nvidia-390xx-dkms 390.157-1 nvidia-390xx-settings 390.157-1 nvidia-390xx-utils 390.157-1 opencl-nvidia-390xx 390.157-1 The complete of packages pulled in when connecting to X broke is: [2023-02-07T00:46:53-0600] [ALPM] running '60-mkinitcpio-remove.hook'... [2023-02-07T00:46:53-0600] [ALPM] running '71-dkms-remove.hook'... [2023-02-07T00:47:14-0600] [ALPM] upgraded linux-api-headers (5.18.15-1 -> 6.1.9-1) [2023-02-07T00:47:14-0600] [ALPM] upgraded filesystem (2023.01.30-1 -> 2023.01.31-1) [2023-02-07T00:47:14-0600] [ALPM] upgraded glibc (2.36-7 -> 2.37-2) [2023-02-07T00:47:17-0600] [ALPM] upgraded gcc-libs (12.2.1-1 -> 12.2.1-2) [2023-02-07T00:47:17-0600] [ALPM] upgraded bash (5.1.016-1 -> 5.1.016-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded e2fsprogs (1.46.5-4 -> 1.46.6-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded libelf (0.188-2 -> 0.188-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded binutils (2.40-2 -> 2.40-4) [2023-02-07T00:47:17-0600] [ALPM] upgraded libsysprof-capture (3.46.0-3 -> 3.46.0-4) [2023-02-07T00:47:17-0600] [ALPM] upgraded cairo (1.17.6-2 -> 1.17.8-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded cargo-c (0.9.16-1 -> 0.9.16-2) [2023-02-07T00:47:17-0600] [ALPM] upgraded cdrdao (1.2.4-2 -> 1.2.5-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded debuginfod (0.188-2 -> 0.188-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded dnsmasq (2.88-1 -> 2.89-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded elfutils (0.188-2 -> 0.188-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded mpfr (4.2.0-2 -> 4.2.0-3) [2023-02-07T00:47:18-0600] [ALPM] upgraded gcc (12.2.1-1 -> 12.2.1-2) [2023-02-07T00:47:18-0600] [ALPM] upgraded grub (2:2.06.r440.g4de39a2af-1 -> 2:2.06.r456.g65bc45963-1) [2023-02-07T00:47:18-0600] [ALPM] upgraded htop (3.2.1-1 -> 3.2.2-1) [2023-02-07T00:47:18-0600] [ALPM] upgraded libtool (2.4.7+4+g1ec8fa28-1 -> 2.4.7+4+g1ec8fa28-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded imagemagick (7.1.0.60-1 -> 7.1.0.61-1) [2023-02-07T00:47:19-0600] [ALPM] upgraded lib32-glibc (2.36-7 -> 2.37-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded lib32-gcc-libs (12.2.1-1 -> 12.2.1-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded libgphoto2 (2.5.30-1 -> 2.5.30-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded libimobiledevice (1.3.0-5 -> 1.3.0-6) [2023-02-07T00:47:19-0600] [ALPM] upgraded libjxl (0.8.0-1 -> 0.8.1-1) [2023-02-07T00:47:19-0600] [ALPM] upgraded libsidplayfp (2.4.1-1 -> 2.4.2-1) [2023-02-07T00:47:21-0600] [ALPM] upgraded linux (6.1.9.arch1-1 -> 6.1.9.arch1-2) [2023-02-07T00:47:23-0600] [ALPM] upgraded linux-docs (6.1.9.arch1-1 -> 6.1.9.arch1-2) [2023-02-07T00:47:26-0600] [ALPM] upgraded linux-headers (6.1.9.arch1-1 -> 6.1.9.arch1-2) [2023-02-07T00:47:28-0600] [ALPM] upgraded linux-lts (5.15.91-1 -> 5.15.91-4) [2023-02-07T00:47:30-0600] [ALPM] upgraded linux-lts-headers (5.15.91-1 -> 5.15.91-4) [2023-02-07T00:47:30-0600] [ALPM] upgraded perl-cairo-gobject (1.004-12 -> 1.005-1) [2023-02-07T00:47:30-0600] [ALPM] upgraded perl-html-parser (3.80-1 -> 3.81-1) [2023-02-07T00:47:30-0600] [ALPM] upgraded python-cairo (1.23.0-2 -> 1.23.0-3) [2023-02-07T00:47:31-0600] [ALPM] upgraded qt5-base (5.15.8+kde+r178-1 -> 5.15.8+kde+r180-1) [2023-02-07T00:47:31-0600] [ALPM] upgraded python-pyqt5 (5.15.8-2 -> 5.15.9-1) [2023-02-07T00:47:31-0600] [ALPM] upgraded sox (14.4.2+r182+g42b3557e-2 -> 14.4.2+r182+g42b3557e-3) [2023-02-07T00:47:32-0600] [ALPM] upgraded texstudio (4.4.1-2 -> 4.5.1-1) [2023-02-07T00:47:32-0600] [ALPM] upgraded tigervnc (1.12.90-1 -> 1.13.0-1) [2023-02-07T00:47:32-0600] [ALPM] upgraded tmux (3.3_a-2 -> 3.3_a-3) [2023-02-07T00:47:33-0600] [ALPM] upgraded valgrind (3.19.0-6 -> 3.19.0-7) [2023-02-07T00:47:34-0600] [ALPM] upgraded vtk (9.1.0-25 -> 9.1.0-26) [2023-02-07T00:47:37-0600] [ALPM] running '20-systemd-sysusers.hook'... [2023-02-07T00:47:37-0600] [ALPM] running '30-systemd-daemon-reload.hook'... [2023-02-07T00:47:40-0600] [ALPM] running '30-systemd-hwdb.hook'... [2023-02-07T00:47:40-0600] [ALPM] running '30-systemd-sysctl.hook'... [2023-02-07T00:47:40-0600] [ALPM] running '30-systemd-tmpfiles.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '30-systemd-udev-reload.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '30-systemd-update.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '30-update-mime-database.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '60-depmod.hook'... [2023-02-07T00:47:45-0600] [ALPM] running '70-dkms-install.hook'... [2023-02-07T00:50:19-0600] [ALPM] running '80-cronie.hook'... [2023-02-07T00:50:19-0600] [ALPM] running '90-mkinitcpio-install.hook'... [2023-02-07T00:50:55-0600] [ALPM] running 'dbus-reload.hook'... [2023-02-07T00:50:55-0600] [ALPM] running 'detect-old-perl-modules.hook'... [2023-02-07T00:50:55-0600] [ALPM] running 'gdk-pixbuf-query-loaders.hook'... [2023-02-07T00:50:56-0600] [ALPM] running 'glib-compile-schemas.hook'... [2023-02-07T00:50:56-0600] [ALPM] running 'gtk-update-icon-cache.hook'... [2023-02-07T00:50:56-0600] [ALPM] running 'texinfo-install.hook'... [2023-02-07T00:50:59-0600] [ALPM] running 'update-desktop-database.hook'... Maybe I'm just not smart enough to pick out any other packages other than the kernel update that seems a likely candidate to cause issues with the X connection and nvidia driver. The rest of the packages look benign except for building or application specific stuff. The libjxl is just required by SDL2, so that shouldn't bork the X connection? Moreover linux 6.1.9.arch1-1 worked fine, so it is really curious that the 6.1.9.arch1-1 -> 6.1.9.arch1-2 would break -- but anything is possible. Will report back after further testing on downgrades and LTS. If something else looks pertinent, please let me know. -- David C. Rankin, J.D.,P.E.
On 2/7/23 19:29, David C. Rankin wrote:
graphics, and startx/fluxbox works fine there. Thinking it may be the AUR drivers, I rebuilt the nvidia drivers as well, e.g.
David Instead of recompiling them, did you try not using them, just try with nouveau instead - there's a non-zero probabity the problem is the nvidia driver and updated kernel I would imagine. best gene
On 2/7/23 06:30, u34@net9.ga wrote:
Downgrading, reverting, the upgrade. Hopefully, everything will work, and upgrading each package own its own? What packages were upgraded?
Yes, That may be a bit of a challenge. There were 2-days worth of updates, but from an overview standpoint -- it looks like the kernel is the most likely culprit and the nvidia driver. I have another Arch box with Intel graphics, and startx/fluxbox works fine there. Thinking it may be the AUR drivers, I rebuilt the nvidia drivers as well, e.g. $ pmq | grep nvidia nvidia-390xx-dkms 390.157-1 nvidia-390xx-settings 390.157-1 nvidia-390xx-utils 390.157-1 opencl-nvidia-390xx 390.157-1 The complete of packages pulled in when connecting to X broke is: [2023-02-07T00:46:53-0600] [ALPM] running '60-mkinitcpio-remove.hook'... [2023-02-07T00:46:53-0600] [ALPM] running '71-dkms-remove.hook'... [2023-02-07T00:47:14-0600] [ALPM] upgraded linux-api-headers (5.18.15-1 -> 6.1.9-1) [2023-02-07T00:47:14-0600] [ALPM] upgraded filesystem (2023.01.30-1 -> 2023.01.31-1) [2023-02-07T00:47:14-0600] [ALPM] upgraded glibc (2.36-7 -> 2.37-2) [2023-02-07T00:47:17-0600] [ALPM] upgraded gcc-libs (12.2.1-1 -> 12.2.1-2) [2023-02-07T00:47:17-0600] [ALPM] upgraded bash (5.1.016-1 -> 5.1.016-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded e2fsprogs (1.46.5-4 -> 1.46.6-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded libelf (0.188-2 -> 0.188-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded binutils (2.40-2 -> 2.40-4) [2023-02-07T00:47:17-0600] [ALPM] upgraded libsysprof-capture (3.46.0-3 -> 3.46.0-4) [2023-02-07T00:47:17-0600] [ALPM] upgraded cairo (1.17.6-2 -> 1.17.8-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded cargo-c (0.9.16-1 -> 0.9.16-2) [2023-02-07T00:47:17-0600] [ALPM] upgraded cdrdao (1.2.4-2 -> 1.2.5-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded debuginfod (0.188-2 -> 0.188-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded dnsmasq (2.88-1 -> 2.89-1) [2023-02-07T00:47:17-0600] [ALPM] upgraded elfutils (0.188-2 -> 0.188-3) [2023-02-07T00:47:17-0600] [ALPM] upgraded mpfr (4.2.0-2 -> 4.2.0-3) [2023-02-07T00:47:18-0600] [ALPM] upgraded gcc (12.2.1-1 -> 12.2.1-2) [2023-02-07T00:47:18-0600] [ALPM] upgraded grub (2:2.06.r440.g4de39a2af-1 -> 2:2.06.r456.g65bc45963-1) [2023-02-07T00:47:18-0600] [ALPM] upgraded htop (3.2.1-1 -> 3.2.2-1) [2023-02-07T00:47:18-0600] [ALPM] upgraded libtool (2.4.7+4+g1ec8fa28-1 -> 2.4.7+4+g1ec8fa28-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded imagemagick (7.1.0.60-1 -> 7.1.0.61-1) [2023-02-07T00:47:19-0600] [ALPM] upgraded lib32-glibc (2.36-7 -> 2.37-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded lib32-gcc-libs (12.2.1-1 -> 12.2.1-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded libgphoto2 (2.5.30-1 -> 2.5.30-2) [2023-02-07T00:47:19-0600] [ALPM] upgraded libimobiledevice (1.3.0-5 -> 1.3.0-6) [2023-02-07T00:47:19-0600] [ALPM] upgraded libjxl (0.8.0-1 -> 0.8.1-1) [2023-02-07T00:47:19-0600] [ALPM] upgraded libsidplayfp (2.4.1-1 -> 2.4.2-1) [2023-02-07T00:47:21-0600] [ALPM] upgraded linux (6.1.9.arch1-1 -> 6.1.9.arch1-2) [2023-02-07T00:47:23-0600] [ALPM] upgraded linux-docs (6.1.9.arch1-1 -> 6.1.9.arch1-2) [2023-02-07T00:47:26-0600] [ALPM] upgraded linux-headers (6.1.9.arch1-1 -> 6.1.9.arch1-2) [2023-02-07T00:47:28-0600] [ALPM] upgraded linux-lts (5.15.91-1 -> 5.15.91-4) [2023-02-07T00:47:30-0600] [ALPM] upgraded linux-lts-headers (5.15.91-1 -> 5.15.91-4) [2023-02-07T00:47:30-0600] [ALPM] upgraded perl-cairo-gobject (1.004-12 -> 1.005-1) [2023-02-07T00:47:30-0600] [ALPM] upgraded perl-html-parser (3.80-1 -> 3.81-1) [2023-02-07T00:47:30-0600] [ALPM] upgraded python-cairo (1.23.0-2 -> 1.23.0-3) [2023-02-07T00:47:31-0600] [ALPM] upgraded qt5-base (5.15.8+kde+r178-1 -> 5.15.8+kde+r180-1) [2023-02-07T00:47:31-0600] [ALPM] upgraded python-pyqt5 (5.15.8-2 -> 5.15.9-1) [2023-02-07T00:47:31-0600] [ALPM] upgraded sox (14.4.2+r182+g42b3557e-2 -> 14.4.2+r182+g42b3557e-3) [2023-02-07T00:47:32-0600] [ALPM] upgraded texstudio (4.4.1-2 -> 4.5.1-1) [2023-02-07T00:47:32-0600] [ALPM] upgraded tigervnc (1.12.90-1 -> 1.13.0-1) [2023-02-07T00:47:32-0600] [ALPM] upgraded tmux (3.3_a-2 -> 3.3_a-3) [2023-02-07T00:47:33-0600] [ALPM] upgraded valgrind (3.19.0-6 -> 3.19.0-7) [2023-02-07T00:47:34-0600] [ALPM] upgraded vtk (9.1.0-25 -> 9.1.0-26) [2023-02-07T00:47:37-0600] [ALPM] running '20-systemd-sysusers.hook'... [2023-02-07T00:47:37-0600] [ALPM] running '30-systemd-daemon-reload.hook'... [2023-02-07T00:47:40-0600] [ALPM] running '30-systemd-hwdb.hook'... [2023-02-07T00:47:40-0600] [ALPM] running '30-systemd-sysctl.hook'... [2023-02-07T00:47:40-0600] [ALPM] running '30-systemd-tmpfiles.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '30-systemd-udev-reload.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '30-systemd-update.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '30-update-mime-database.hook'... [2023-02-07T00:47:41-0600] [ALPM] running '60-depmod.hook'... [2023-02-07T00:47:45-0600] [ALPM] running '70-dkms-install.hook'... [2023-02-07T00:50:19-0600] [ALPM] running '80-cronie.hook'... [2023-02-07T00:50:19-0600] [ALPM] running '90-mkinitcpio-install.hook'... [2023-02-07T00:50:55-0600] [ALPM] running 'dbus-reload.hook'... [2023-02-07T00:50:55-0600] [ALPM] running 'detect-old-perl-modules.hook'... [2023-02-07T00:50:55-0600] [ALPM] running 'gdk-pixbuf-query-loaders.hook'... [2023-02-07T00:50:56-0600] [ALPM] running 'glib-compile-schemas.hook'... [2023-02-07T00:50:56-0600] [ALPM] running 'gtk-update-icon-cache.hook'... [2023-02-07T00:50:56-0600] [ALPM] running 'texinfo-install.hook'... [2023-02-07T00:50:59-0600] [ALPM] running 'update-desktop-database.hook'... Maybe I'm just not smart enough to pick out any other packages other than the kernel update that seems a likely candidate to cause issues with the X connection and nvidia driver. The rest of the packages look benign except for building or application specific stuff. The libjxl is just required by SDL2, so that shouldn't bork the X connection? Moreover linux 6.1.9.arch1-1 worked fine, so it is really curious that the 6.1.9.arch1-1 -> 6.1.9.arch1-2 would break -- but anything is possible. Will report back after further testing on downgrades and LTS. If something else looks pertinent, please let me know. -- David C. Rankin, J.D.,P.E.
Op di 7 feb. 2023 12:15 schreef David C. Rankin <drankinatty@gmail.com>:
On 2/7/23 04:35, u34@net9.ga wrote:
All,
Lightdm has been working fine up until pacman update today. After the update, lightdm fails with a garbled screen. The journal shows:
Could be an overwriten /etc/shells. https://bugs.archlinux.org/task/77404. [...] Thank you both,
But it seems the error is deeper than that. startx will not launch fluxbox either (which has worked since 2013 when the server was built).
Did you check if your login shell is (still) listed in /etc/shells? I can assume you did, but you didn't mention this :). Also, try capturing the output of startx. Perhaps there is something useful there that isn't in the journal. In the posted output, there was some dbus error. Did this one happen before also? Perhaps some daemon just needs a reload or restart. Did you try rebooting? Mvg, Guus
On 2/7/23 06:35, Guus Snijders wrote:
Did you check if your login shell is (still) listed in /etc/shells? I can assume you did, but you didn't mention this :).
Yes, I checked and all shells are there. No problem.
Also, try capturing the output of startx. Perhaps there is something useful there that isn't in the journal.
X will not start on the normal kernel or LTS. Exact startx error is "xinit: unable to connect to X server: Connection refused"
In the posted output, there was some dbus error. Did this one happen before also? Perhaps some daemon just needs a reload or restart. Did you try rebooting?
Rebooted and also tried on LTS. Same issue for both linux and linux-LTS, so that seems to eliminate the kernel as the cause. I don't know if the dbus error was there before as I had never had any problem. Checking the journal, the earliest dbus error was on Feb 2: Feb 02 03:24:50 valkyrie lightdm[787]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files But... lightdm, X, etc.. continued to work until the Feb 7 updates. This has "just worked" for nearly a decade. I saw updates to Xorg-server and openssl3 today. Didn't know if that could be related to "connection refused", but I fully upgraded and the problem remains. Xorg.0.log looks fine, there are no issues, so X itself is happy. What changed that now prevents a connection to it? -- David C. Rankin, J.D.,P.E.
On 2/7/23 3:11 AM, David C. Rankin wrote:
All,
Lightdm has been working fine up until pacman update today. After the update, lightdm fails with a garbled screen. The journal shows:
Feb 07 00:58:57 valkyrie systemd[1]: Starting Light Display Manager... Feb 07 00:59:00 valkyrie systemd[1]: Started Light Display Manager. Feb 07 00:59:00 valkyrie lightdm[782]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Main process exited, code=exited, status=1/FAILURE Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Failed with result 'exit-code'. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 1. Feb 07 00:59:07 valkyrie systemd[1]: Stopped Light Display Manager. Feb 07 00:59:07 valkyrie systemd[1]: lightdm.service: Consumed 1.177s CPU time.
I run a similar setup. But logs look different on my end Feb 06 10:16:02 titan systemd[1]: Starting Light Display Manager... ... Feb 06 10:16:02 titan systemd[1]: Started Light Display Manager. Feb 06 10:16:02 titan systemd[1]: Reached target User and Group Name Lookups. Feb 06 10:16:02 titan systemd[1]: Starting Accounts Service... ... Feb 06 10:16:02 titan systemd[1]: Started Accounts Service. ... Feb 06 10:16:03 titan lightdm[733]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=975) by (uid=0) The issue seems to be that "Accounts Service". When I look at what's running on my machine with the keyword "account" I see this: # ps aux | grep -i account root 666 0.0 0.0 237396 236 ? Ssl Feb06 0:00 /usr/lib/accounts-daemon # pacman -Qo /usr/lib/accounts-daemon /usr/lib/accounts-daemon is owned by accountsservice 22.08.8-2 Perhaps that "accountsservice" package somehow got uninstalled on your machine? A quick search turned up this page, which would seem to also suggest that: https://dev.to/nabbisen/fix-lightdm-error-the-name-org-freedesktop-accounts-... HTH, DR
On 2/7/23 19:20, David Rosenstrauch wrote:
I run a similar setup. But logs look different on my end
Feb 06 10:16:02 titan systemd[1]: Starting Light Display Manager... ... Feb 06 10:16:02 titan systemd[1]: Started Light Display Manager. Feb 06 10:16:02 titan systemd[1]: Reached target User and Group Name Lookups. Feb 06 10:16:02 titan systemd[1]: Starting Accounts Service... ... Feb 06 10:16:02 titan systemd[1]: Started Accounts Service. ... Feb 06 10:16:03 titan lightdm[733]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=975) by (uid=0)
The issue seems to be that "Accounts Service". When I look at what's running on my machine with the keyword "account" I see this:
# ps aux | grep -i account root 666 0.0 0.0 237396 236 ? Ssl Feb06 0:00 /usr/lib/accounts-daemon
# pacman -Qo /usr/lib/accounts-daemon /usr/lib/accounts-daemon is owned by accountsservice 22.08.8-2
Perhaps that "accountsservice" package somehow got uninstalled on your machine? A quick search turned up this page, which would seem to also suggest that: https://dev.to/nabbisen/fix-lightdm-error-the-name-org-freedesktop-accounts-...
Thanks David, Had already found the accountsservice posts -- unfortunately that isn't the issue here. (installed it, rebooted, checked with linux and linux-LTS, no difference -- uninstalled it) There is some distinct permission or auth change in the package updates from the last 3-4 days that is preventing an xorg connection resulting in "Connection Refused". I captured the full startx output in case that helps: $ startx X.Org X Server 1.21.1.7 X Protocol Version 11, Revision 0 Current Operating System: Linux valkyrie 6.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 03 Feb 2023 18:49:53 +0000 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=515ef9dc-769f-4548-9a08-3a92fa83d86b rw iommu=soft amd_iommu_dump= quiet audit=0 Current version of pixman: 0.42.2 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.1.log", Time: Tue Feb 7 21:02:15 2023 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE)xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error It appears I'm not the only one. Soon after posting to the AUR project for the nvidia-390xx drivers, another confirmed x broke for him as well. See latest comments at: https://aur.archlinux.org/pkgbase/nvidia-390xx-utils So it has to be some change that the nvidia-390xx driver isn't playing nice with. Like I said earlier, my Intel graphic box is happy as a clam. Also, xorg itself is happy with the nvidia-390xx driver, loads it fine, no errors in Xorg.0.log and X seems to fully start before being shutdown by the "Connection Refused" error. Nothing else has changed on this box. It's a server doing mail, web, dns, dhcpd4, etc... that just sits there doing its thing. Simple OLD AMD 8-core with 32G and 4T in 4 RAID1 partitions. That how I know NOTHING changed on the box -- other than pacman updates on 2/7 and then I rebuilt the nvidia-390xx driver packages (no difference, same issue) The server aspect also makes it a bit difficult to take offline for rollback and testing that takes the server down. (I have another Arch server doing backup dns and dhcpd for the local LAN and a backup mail host at the office, but even so, I'm a bit reluctant to purposefully take it off line unless the electric company does it for me...) So I'm a bit stumped on where to dig to find whatever changed? I mean do I strace the startx call -- would that be useful? -- David C. Rankin, J.D.,P.E.
On 2/7/23 10:26 PM, David C. Rankin wrote:
It appears I'm not the only one. Soon after posting to the AUR project for the nvidia-390xx drivers, another confirmed x broke for him as well. See latest comments at:
https://aur.archlinux.org/pkgbase/nvidia-390xx-utils
So it has to be some change that the nvidia-390xx driver isn't playing nice with. Like I said earlier, my Intel graphic box is happy as a clam.
Looks like another recent comment seems to indicate that it's a glibc update issue. DR
On 2/7/23 21:55, David Rosenstrauch wrote:
On 2/7/23 10:26 PM, David C. Rankin wrote:
It appears I'm not the only one. Soon after posting to the AUR project for the nvidia-390xx drivers, another confirmed x broke for him as well. See latest comments at:
https://aur.archlinux.org/pkgbase/nvidia-390xx-utils
So it has to be some change that the nvidia-390xx driver isn't playing nice with. Like I said earlier, my Intel graphic box is happy as a clam.
Looks like another recent comment seems to indicate that it's a glibc update issue.
DR
Things look very grim for the 110 Nvidia cards that use the nvidia-390xx driver. Seems the binary pieces built and supplied by nvidia and those that you build must be built using the same glibc. The last update by Nvidia for the 390xx driver was at the end of 2022. glibc 2.37 puts Arch ahead of the glibc used with the last 390xx driver. So unless this is a regression in glibc or Nvidia provides a "Goodness of it's Heart" update, those cards are dead on Arch and most revert to the nouveau driver. (I'm not holding my breath on either...) See: https://bbs.archlinux.org/viewtopic.php?id=283327 This is all GTX 580 and below, Quadro 6000(and M) and below and mobile GPUs from the GT 820M down. There are two good card references for looking up affected cards listed in the wiki https://wiki.archlinux.org/title/NVIDIA https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/ https://nouveau.freedesktop.org/CodeNames.html Frustrating when perfectly good hardware can no longer be used as intended due to a trivial glibc change. The double-edged sword of a rolling-release coupled with corporate greed to drive new hardware sales. Not much of an issue when top video cards cost $200, but in today's world with prices close to 8X that -- it's a much bigger issue. Nouveau is fine, but frame-rates pale in comparison to the nvidia driver. We will see where this goes... -- David C. Rankin, J.D.,P.E.
On Wed, 8 Feb 2023 12:52:47 -0600 "David C. Rankin" <drankinatty@gmail.com> wrote:
Things look very grim for the 110 Nvidia cards that use the nvidia-390xx driver. Seems the binary pieces built and supplied by nvidia and those that you build must be built using the same glibc. The last update by Nvidia for the 390xx driver was at the end of 2022. glibc 2.37 puts Arch ahead of the glibc used with the last 390xx driver. So unless this is a regression in glibc or Nvidia provides a "Goodness of it's Heart" update, those cards are dead on Arch and most revert to the nouveau driver. (I'm not holding my breath on either...)
See: https://bbs.archlinux.org/viewtopic.php?id=283327
This is all GTX 580 and below, Quadro 6000(and M) and below and mobile GPUs from the GT 820M down. There are two good card references for looking up affected cards listed in the wiki https://wiki.archlinux.org/title/NVIDIA
https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/
https://nouveau.freedesktop.org/CodeNames.html
Frustrating when perfectly good hardware can no longer be used as intended due to a trivial glibc change. The double-edged sword of a rolling-release coupled with corporate greed to drive new hardware sales. Not much of an issue when top video cards cost $200, but in today's world with prices close to 8X that -- it's a much bigger issue.
Nouveau is fine, but frame-rates pale in comparison to the nvidia driver. We will see where this goes...
Can't you just install the required version of glibc [1] to build the drivers, or does that lead to other incompatibilities [1] As discussed e.g at https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-sin...
On 2/8/23 15:20, arch@howorth.org.uk wrote:
Can't you just install the required version of glibc [1] to build the drivers, or does that lead to other incompatibilities
[1] As discussed e.g at https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-sin...
Damn good idea. I'll investigate. In the past, mixing glibc versions was never a good idea, but so long as you can segregate the build environments, that may be a solution. But then we may run into a kernel-module/kernel glibc complaint? Thanks for the suggestion, I'll look into it. -- David C. Rankin, J.D.,P.E.
On 2/8/23 15:20, arch@howorth.org.uk wrote:
Can't you just install the required version of glibc [1] to build the drivers, or does that lead to other incompatibilities
A working solution has been found and posted to both: https://bbs.archlinux.org/viewtopic.php?pid=2083698 and https://aur.archlinux.org/pkgbase/nvidia-390xx-utils The silver bullet is to make sure the current /usr/lib/tls is available to the nvidia driver. My hat is off to the creative minds that chased that down as a solution. I was sure things looked very grim. More than one way to skin a cat with Linux :) -- David C. Rankin, J.D.,P.E.
On 2/8/23 04:26, David C. Rankin wrote:
On 2/7/23 19:20, David Rosenstrauch wrote:
... There is some distinct permission or auth change in the package updates from the last 3-4 days that is preventing an xorg connection resulting in "Connection Refused". I captured the full startx output in case that helps:
$ startx
X.Org X Server 1.21.1.7 X Protocol Version 11, Revision 0 Current Operating System: Linux valkyrie 6.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 03 Feb 2023 18:49:53 +0000 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=515ef9dc-769f-4548-9a08-3a92fa83d86b rw iommu=soft amd_iommu_dump= quiet audit=0
Current version of pixman: 0.42.2 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.1.log", Time: Tue Feb 7 21:02:15 2023 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE)xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error
It appears I'm not the only one. Soon after posting to the AUR project for the nvidia-390xx drivers, another confirmed x broke for him as well. See latest comments at:
https://aur.archlinux.org/pkgbase/nvidia-390xx-utils
So it has to be some change that the nvidia-390xx driver isn't playing nice with. Like I said earlier, my Intel graphic box is happy as a clam.
Also, xorg itself is happy with the nvidia-390xx driver, loads it fine, no errors in Xorg.0.log and X seems to fully start before being shutdown by the "Connection Refused" error.
Nothing else has changed on this box. It's a server doing mail, web, dns, dhcpd4, etc... that just sits there doing its thing. Simple OLD AMD 8-core with 32G and 4T in 4 RAID1 partitions. That how I know NOTHING changed on the box -- other than pacman updates on 2/7 and then I rebuilt the nvidia-390xx driver packages (no difference, same issue)
The server aspect also makes it a bit difficult to take offline for rollback and testing that takes the server down. (I have another Arch server doing backup dns and dhcpd for the local LAN and a backup mail host at the office, but even so, I'm a bit reluctant to purposefully take it off line unless the electric company does it for me...)
So I'm a bit stumped on where to dig to find whatever changed? I mean do I strace the startx call -- would that be useful?
Don't know if this helps but below my X log having an Intel Graphical card: [ 11.169] X.Org X Server 1.21.1.6 X Protocol Version 11, Revision 0 [ 11.169] Current Operating System: Linux FLBE752NS 6.1.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 01 Feb 2023 17:07:39 +0000 x86_64 [ 11.169] Kernel command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root="LABEL=SSDLinux" rw loglevel=3 splash [ 11.169] [ 11.169] Current version of pixman: 0.42.2 [ 11.169] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 11.169] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 11.170] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 4 16:18:49 2023 [ 11.175] (==) Using system config directory "/usr/share/X11/xorg.conf.d" Comparing I did notice that you have X.Org X Server 1.21.1.7 while I do have 1.21.1.6. I did my last pacman -Syu last Saturday. I didn't see an update of X in your pacman.log of 7/2. Also you seem to have a xorg.conf, that is for the nvidia card ? Maybe this gives you some ideas to find the cause of the error. ~Z
participants (7)
-
arch＠howorth.org.uk
-
David C. Rankin
-
David Rosenstrauch
-
Genes Lists
-
Guus Snijders
-
u34＠net9.ga
-
Zero