coreutils
coreutils copied to clipboard
uutils
GDM with multiple displays (on Xorg) stops working when uutils replaces gnu coreutils
It seems like GNOME does not work properly on uutils.
I think this might be related to a bug somewhere?
System Details Report
Report details
- Date generated: 2023-11-08 19:55:43
Hardware Information:
- Hardware Model: HP OMEN by HP Laptop 15-ce0xx
- Memory: 16.0 GiB
- Processor: Intel® Core™ i7-7700HQ × 8
- Graphics: NVIDIA GeForce GTX 1050
- Graphics 1: NVIDIA GeForce GTX 1050
- Disk Capacity: 1.1 TB
Software Information:
- Firmware Version: F.24
- OS Name: Ultramarine Linux 39 (GNOME Edition)
- OS Build: (null)
- OS Type: 64-bit
- GNOME Version: 45.1
- Windowing System: X11
- Kernel Version: Linux 6.5.9-300.fc39.x86_64
not sure how this bug is actionable, sorry :( please provide more information (I have been using gnome & rust/coreutils for a year without any issue)
I'm using NVIDIA with Xorg, linked to an external display though HDMI.
I might try testing on other window managers just to be safe.
I just tested this on KDE Plasma. Displays also broken.
I may have pinpointed the issue to Xorg.
Does anyone know if Xorg use any weird coreutils features?
i don't think xorg relies much on the coreutils, less on weird features
do you see anything in the logs?
I recently found a place where gnome-session calls your $SHELL in "login" mode, probably so that it can initialise your environment variables as expected: https://gitlab.gnome.org/GNOME/gnome-session/-/blob/998ed1d8ee2ff5396583c284230648625b4103e5/gnome-session/gnome-session.in#L10
I discovered this, because I had some bugs in my shell configuration that did not handle this well, and prevented the GNOME session from starting successfully
This particular example is probably unrelated, but I wonder if there are other places where KDE/GNOME call out to utilities or our $SHELLs, or if some people have similarly-sensitive shell configurations?
ok, it would be nice if you could comment some of the content in gnome-session to see which lines cause the problem
I changed my $SHELL from fish to bash and the issue is still there.
Honestly, I don't know what part to comment to still have my session work.
Weirdly enough, using Wayland works fine.
I ran bpftrace execsnoop to see if this is somehow runs any executables owned by uutils, and it seems like GDM uses touch. So, I have pinpointed the issue to maybe the fact that touch may have some inconsistencies with GNU's version
TIME(ms) PID ARGS
1929 4467 /usr/bin/touch /run/udev/gdm-machine-has-hardware-gpu
1944 4468 /usr/bin/touch /run/udev/gdm-machine-has-hardware-gpu
Also just tried using LightDM, now X works fine. So it's GDM abusing GNU coreutils behaviour. Could anyone check the code whether if GDM does something with calling systems coreutils?
could you please replace your screenshot by text ? it is terrible for accessibility and search :) Thanks
could you please replace your screenshot by text ? it is terrible for accessibility and search :) Thanks
Sorry :p replaced with logs
I'll consider forwarding this issue to upstream GDM, since it seems like a weird quirk of GDM itself... But since inconsistencies between uutils and gnu are considered bugs, maybe we should keep it open since seems like GDM is relying on a GNU quirk
GDM runs some tests and uses touch to create some files in /run/udev/ for later reference. These are at 61-gdm.rules.in from the git source:
/usr/bin/touch /run/udev/gdm-machine-has-virtual-gpu
/usr/bin/touch /run/udev/gdm-machine-has-hardware-gpu
/usr/bin/touch /run/udev/gdm-machine-has-hybrid-graphics
/usr/bin/touch /run/udev/gdm-machine-has-vendor-nvidia-driver
but on my Debian machine, I have it here /usr/lib/udev/rules.d/61-gdm.rules and it also contains the line:
/usr/bin/touch /run/udev/gdm-machine-is-laptop
So... are we installing our touch in /usr/bin/touch? I think we are default to /usr/local/.
I placed touch on /usr/bin/touch since I'm packaging uutils to replace coreutils entirely