|
incomplete -G output on Fedora 31
There doesn't seem to be any relevant support missing. Am I wrong?:
:: Code :: # pinxi --recommends | grep Missing
file: -o unmounted file system (if no lsblk)....................................................................... Missing ifconfig: -i ip LAN (deprecated)................................................................................... Missing strings: -I sysvinit version....................................................................................... Missing upower: -sx attached device battery info........................................................................... Missing Time::HiRes: -C cpu sleep (not required); --debug timers........................................................... Missing /etc/lsb-release: -S distro version data (older version)........................................................... Missing # inxi -V | head -n1 pinxi 3.0.36-02 (2019-09-10) # pinxi -GxxSM System: Host: ab250 Kernel: 5.3.1-300.fc31.x86_64 x86_64 bits: 64 compiler: gcc v: 9.2.1 Desktop: KDE Plasma 5.16.4 tk: Qt 5.12.4 wm: kwin_x11 dm: startx Distro: Fedora release 31 (Thirty One) Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B250M-C v: Rev X.0x serial: 171013077301155 UEFI: American Megatrends v: 1402 date: 11/16/2018 Graphics: Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5912 Display: server: Fedora Project X.org 1.20.5 driver: modesetting alternate: fbdev,vesa compositor: kwin_x11 resolution: 1920x1200~60Hz OpenGL: renderer: N/A v: N/A direct render: N/A Back to top |
|
You're missing glxinfo. Wait, no, I take that back, you ran this as root, glxinfo and other X tools used to allow being run as root, then they stopped some time ago. Actually, going way back, first, tools like glxinfo did not work for root, then for a long time they did, then relatively recently, they stopped again.
Other tools that don't work are xprop, which is sometimes used for desktop data as well. Note that if you use sudo: sudo pinxi -SGxxx it should work as expected, and of course, without sudo it will work for normal user. :: Code :: $ pinxi -SGxxx --no-host --memory-short
System: Kernel: 4.17.0-17.3-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 Distro: Debian GNU/Linux 10 (buster) Memory: RAM: total: 31.43 GiB used: 18.51 GiB (58.9%) RAM Report: permissions: Unable to run dmidecode. Root privileges required. Graphics: Device-1: NVIDIA GT218 [GeForce 210] vendor: Gigabyte driver: nvidia v: 340.107 bus ID: 09:00.0 chip ID: 10de:0a65 Display: x11 server: X.Org 1.20.4 driver: nvidia resolution: 1280x1024~60Hz, 1280x1024~60Hz OpenGL: renderer: GeForce 210/PCIe/SSE2 v: 3.3.0 NVIDIA 340.107 direct render: Yes $ sudo pinxi -SGxxx --no-host --memory-short System: Kernel: 4.17.0-17.3-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 Distro: Debian GNU/Linux 10 (buster) Memory: RAM: total: 31.43 GiB used: 18.67 GiB (59.4%) Report: arrays: 1 slots: 4 modules: 2 type: DDR4 Graphics: Device-1: NVIDIA GT218 [GeForce 210] vendor: Gigabyte driver: nvidia v: 340.107 bus ID: 09:00.0 chip ID: 10de:0a65 Display: server: X.Org 1.20.4 driver: nvidia resolution: 1280x1024~60Hz, 1280x1024~60Hz OpenGL: renderer: GeForce 210/PCIe/SSE2 v: 3.3.0 NVIDIA 340.107 direct render: Yes # pinxi -SGxxx --no-host --memory-short System: Kernel: 4.17.0-17.3-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 7.3.0 Console: tty 10 dm: LightDM 1.26.0 Distro: Debian GNU/Linux 10 (buster) Memory: RAM: total: 31.43 GiB used: 18.49 GiB (58.8%) Report: arrays: 1 slots: 4 modules: 2 type: DDR4 Graphics: Device-1: NVIDIA GT218 [GeForce 210] vendor: Gigabyte driver: nvidia v: 340.107 bus ID: 09:00.0 chip ID: 10de:0a65 Display: server: X.org 1.20.4 driver: nvidia tty: 125x40 Message: Advanced graphics data unavailable in console for root. and that's how that works. I tossed in --memory-short to show when root is active or not. Note that I can't explain why Debian shows the expected no graphic advanced data for root but fedora doesn't. My guess is that the resolution tools got your resolution, but on mine, they failed due to root. Back to top |
|
Checked, what happens is if $DISPLAY is set, pinxi/inxi believes it is in a desktop situation, if it is not, it believes that it is in console, out of desktop/windows etc.
So technically my behavior is wrong, and your system's is right according to what inxi expects. Again, not too long ago, $DISPLAY was set for root in X, I have no idea why they change things like this, but I can't control it. Note that starting inxi/pinxi with sudo as regular user bypasses this issue. I believe this means that Fedora sets $DISPLAY for root in X, or you could be using wayland, of course, then the behaviors are very weakly tested and I don't really know exactly what happens. Since $DISPLAY was set in your system for root, you might be able to use the --display :0 option with X, that may or may not work, it used to work in some cases, but it was never consistent. Anyway, this was all just a bunch of sort of random changes distro to distro, for years, it was all reliable and consistent, then now, it's not, upstream changes out of inxi control. Back to top |
|
:: Code :: # pinxi --recommends | grep Missing
file: -o unmounted file system (if no lsblk)....................................................................... Missing ifconfig: -i ip LAN (deprecated)................................................................................... Missing strings: -I sysvinit version....................................................................................... Missing Time::HiRes: -C cpu sleep (not required); --debug timers........................................................... Missing /etc/lsb-release: -S distro version data (older version)........................................................... Missing # echo $DISPLAY :0 # rpm -qa | egrep -i 'mesa|glx|peng' | sort glx-utils-8.4.0-4.20181118git1830dcb.fc31.x86_64 libglvnd-glx-1.1.1-5.fc31.x86_64 mesa-filesystem-19.2.0-1.fc31.x86_64 mesa-libEGL-19.2.0-1.fc31.x86_64 mesa-libgbm-19.2.0-1.fc31.x86_64 mesa-libGL-19.2.0-1.fc31.x86_64 mesa-libglapi-19.2.0-1.fc31.x86_64 mesa-libGLU-9.0.1-1.fc31.x86_64 mesa-libGLw-8.0.0-18.fc31.x86_64 perl-OpenGL-0.7000-10.fc31.x86_64 # whoami root # tail /etc/passwd nm-openvpn:x:994:990:Default user for running openvpn spawned by NetworkManager:/:/sbin/nologin backuppc:x:993:989::/var/lib/BackupPC:/sbin/nologin chrony:x:992:988::/var/lib/chrony:/sbin/nologin sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin avahi:x:70:70:Avahi mDNS/DNS-SD Stack:/var/run/avahi-daemon:/sbin/nologin polkitd:x:991:987:User for polkitd:/:/sbin/nologin rtkit:x:172:172:RealtimeKit:/proc:/sbin/nologin pulse:x:171:171:PulseAudio System Daemon:/var/run/pulse:/sbin/nologin # sudo pinxi -GxxxS --no-host --memory-short System: Kernel: 5.3.1-300.fc31.x86_64 x86_64 bits: 64 compiler: gcc v: 9.2.1 Desktop: mwm wm: kwin_x11 dm: KDM Distro: Fedora release 31 (Thirty One) Memory: RAM: total: 15.53 GiB used: 415.4 MiB (2.6%) Report: arrays: 1 slots: 4 modules: 2 type: DDR4 Graphics: Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5912 Display: server: Fedora Project X.org 1.20.5 driver: modesetting alternate: fbdev,vesa compositor: kwin_x11 resolution: 1920x1200~60Hz OpenGL: renderer: N/A v: N/A direct render: N/A Back to top |
|
You're running the commands in root. sudo in root just means stay root.
Notice on my examples the '$' which means I'm running it as user, with or without sudo. there's a few variations between Fedora and Debian I find interesting, but I can't really fix them since there's not really any data to use. But get out of root, then magically your graphics data will re-appear. As noted, I feel that Fedora may be more 'right' than Debian in the case of in X, running as root, though the graphics tools are the same in both cases, since neither will show the glxinfo data as root, but Fedora seems to have retained the $DISPLAY data for root where Debian did not retain it, thus forcing inxi to believe it's running out of X. There's also the question of if you are running in wayland, or xwayland, or just plain X. You don't need to post your non related data, all I need to see is that you are running the command as root, not with sudo from regular user. Back to top |
|
The tail of /etc/passwd was there as an indicator that the only configured user login on the system is the superuser. Anything the superuser can't do can't be expected to be done by an inferior user. It's a testing installation, not used for intentional internet interaction except for system updates.
Back to top |
|
That doesn't change anything, if the only user is root, that will trigger the behaviors you see, wouldn't matter if there were regular users present in system but not active or not.
inxi just cares about what is running it at the moment you run it, not about the general system setup re users. These changes came mostly from upstream, though maybe the decision to set $DISPLAY for root comes from the distro, or maybe it's a result of having only one user, root, and logging in with that user. That might well be now that I think of it. But that still leaves you trying to run glxinfo as root, which returns this result: :: Code :: # glxinfo -B
Error: unable to open display It was to me quite annoying when the old root behavior stopped working with X tools, since it had taken a while to get it all nice and reliable with the right error messages in the right places, for example, I'd like to improve the error case for my current system, it should say advanced graphics data not available for root, regardless of whether in X environment or in console environment. But that relies on knowing if $DISPLAY is set or not, and if root is not setting that, I'm out of ideas about how to handle it. Since your stuff is just a test case, I'm not going to worry about it specifically, since it's really just a matter of how errors messages are presented, nothing really changes. Note that the desktop detections worked because you're using the desktops that don't rely on the xprop data to be identified, either kde or mwm, the latter which is identified I think by ps aux showing it, at least as a fallback. Back to top |
|
Logging in as root also may explain why you got your desktop dimensions, which surprised me, but given your setup, that's not an issue I'm going to worry much about either, but it's good to know how that happened.
Back to top |
|
All times are GMT - 8 Hours |