hi,
updated
inxi-2.3.40-1.1.noarch to inxi-3.0.10-1.1.noarch
now can only run with root privileges
same on both 32 and 64 bit installs
/etc/issue?
any work around?
thanks for any suggestions
First, I’ve never used, nor heard, of inxi, but that appears to be my problem.
Second, at first glance it is a system information and reporting tool;
with that in mind, that it could ever be truly effective without ‘root’
permissions seems unrealistic to me. As a result, since you are implying
that it used to be able to run differently, something appears to be off,
either your understanding of the tool, or the tool’s functionality, or the
tool’s defaults. We’ll see.
Third, the tool’s website shows how to setup /etc/sudoers so that it can
run with all functionality without a password; that seems to confirm my
suspicion that ‘root’ is, needed:
https://smxi.org/docs/inxi-configuration.htm
Third, if you compare the inxi binary itself you MAY find that it is now a
regular executable, where before it MAY have had something like the GUID
bit set, kind of like other system utilities used by regular users (e.g.
passwd). If that is the case, then it means you had ‘root’ all along when
calling that one executable, even though you may not have known it, or
added those privileges explicitly, any more than you do with other
utilities like ‘passwd’ (to change your user’s password in Linux.
Finally, the newer package’s changelog may have useful information about
this change:
rpm -q --changelog inxi
Please let us know what you find.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Hi
Strange, working fine here with the GNOME DE. There where some conf file
changes, if you check the inxi changelog, do the files/variables exist
on your system?
inxi -Fz
System: Host: big-bird.homelinux.org Kernel: 4.16.12-1-default x86_64 bits: 64 Console: tty 1
Distro: openSUSE Tumbleweed 20180529
Machine: Type: Laptop System: HP product: HP Notebook v: Type1ProductConfigId serial: <filter>
Mobo: HP model: 8305 v: KBC Version 73.16 serial: <filter> UEFI: Insyde v: F.30 date: 11/09/2017
Battery: ID-1: BAT0 charge: 30.6 Wh condition: 30.6/30.6 Wh (100%)
CPU: Topology: Quad Core model: AMD E2-7110 APU with AMD Radeon R2 Graphics bits: 64 type: MCP
L2 cache: 2048 KiB
Speed: 1704 MHz min/max: 1000/1800 MHz Core speeds (MHz): 1: 1704 2: 1653 3: 1599 4: 1684
Graphics: Card-1: Advanced Micro Devices [AMD/ATI] Mullins [Radeon R3 Graphics] driver: amdgpu v: kernel
Display: server: X.org 1.19.6 driver: amdgpu tty: 167x30
Message: Advanced graphics data unavailable in console. Try -G --display
Audio: Card-1: Advanced Micro Devices [AMD/ATI] Kabini HDMI/DP Audio driver: snd_hda_intel
Card-2: Advanced Micro Devices [AMD] FCH Azalia driver: snd_hda_intel
Sound Server: ALSA v: k4.16.12-1-default
Network: Card-1: Realtek RTL810xE PCI Express Fast Ethernet driver: r8169
IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter>
Card-2: Intel Wireless 3165 driver: iwlwifi
IF: wlp3s0 state: down mac: <filter>
Drives: HDD Total Size: 111.79 GiB used: 23.65 GiB (21.2%)
ID-1: /dev/sda vendor: OCZ model: VERTEX460A size: 111.79 GiB
Partition: ID-1: / size: 40.00 GiB used: 8.51 GiB (21.3%) fs: btrfs dev: /dev/sda3
ID-2: /home size: 40.00 GiB used: 8.51 GiB (21.3%) fs: btrfs dev: /dev/sda3
ID-3: /opt size: 40.00 GiB used: 8.51 GiB (21.3%) fs: btrfs dev: /dev/sda3
ID-4: /tmp size: 40.00 GiB used: 8.51 GiB (21.3%) fs: btrfs dev: /dev/sda3
ID-5: /var size: 40.00 GiB used: 8.51 GiB (21.3%) fs: btrfs dev: /dev/sda3
ID-6: swap-1 size: 4.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda5
Sensors: System Temperatures: cpu: 40.0 C mobo: 0.0 C gpu: amdgpu temp: 57 C
Fan Speeds (RPM): N/A
Info: Processes: 268 Uptime: N/A Memory: 6.78 GiB used: 1.71 GiB (25.2%) Init: systemd runlevel: 5
Shell: bash inxi: 3.0.10
If you create a test user and login does it duplicate?
thanks for the feedback
to make sure the install was correct the cmd
inxi --recommends
was used which showed all was in order
from a user level the outcome is,
hp-17-p105ng-m1<2018-05-31 15:30:00><~>… inxi -Fz
Error 45: Error opening file: /etc/issue
Error: Permission denied
hp-17-p105ng-m1<2018-05-31 15:30:21><~>…
as this happens on an hp (64bit) and toshiba (32bit) its assumed its kde related.
inxi has been used with multiple upgrades for at least a decade with kde, but will
look into clearing the config files in /home/<user> directory
thanks again
Hi
As my user cannot see /etc/issue, is yours customized?
~> cat /etc/issue cat: /etc/issue: Permission denied
~> ls -la /etc/issue lrwxrwxrwx 1 root root 12 Apr 27 11:03 /etc/issue -> ../run/issue
# cat /etc/issue
Welcome to openSUSE Tumbleweed 20180529 - Kernel \r (\l).
enp2s0: \4{enp2s0} \6{enp2s0}
Did your perl 5.26.1 update ok?
/etc/issue is probably a link to /run/issue. Delete the link and create a /etc/issue file. Then chmod 755 /etc/issue.
From hvcc:
thanks for the info
with no file /etc/issue
inxi works as expected
not sure what else will be effected though
cheers
On Thu 31 May 2018 02:36:03 PM CDT, keellambert wrote:
d3vnull;2867573 Wrote:
> /etc/issue is probably a link to /run/issue. Delete the link and
> create a /etc/issue file. Then chmod 755 /etc/issue.
>
thanks for the info
with no file /etc/issue
inxi works as expected
not sure what else will be effected though
cheers
Hi
Then that would appear to be a bug in your system/setup if that’s
creating an (excuse the pun) issue…
If you re-create the symlink now to …/run/issue does it continue to
work?
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 RC4 | GNOME Shell 3.26.2 | 4.12.14-18-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
hi Malcolm
if /etc/issue is there, the issue remains the same
cheers
On Thu 31 May 2018 04:06:03 PM CDT, keellambert wrote:
hi Malcolm
malcolmlewis;2867582 Wrote:
> If you re-create the symlink now to …/run/issue does it continue to
> work?
if /etc/issue is there, the issue remains the same
cheers
Hi
Even for a test user with a fresh login?
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 RC4 | GNOME Shell 3.26.2 | 4.12.14-18-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
I came across this thread by coincidence, and wanted to correct some assumptions made (I am the inxi author):
-
the vast majority of inxi features do not require root. The page on sudo permissions is for how to set up the few things that do require root, like hddtemp. A few features, like -m, --slots, do require dmidecode, which requires root, but outside of those, pretty much everything can be gotten as user, which is actually a core rule for inxi, to get as much data as possible without requiring root/sudo. I’d estimate that at least 95%, if not more, of all the data inxi can collect is grabbed as user, not root. And 100% of the normal data users would generally want to see, or be asked to provide by support people, with -b or -F does not require root, that’s by design.
-
The initial bug here is only related to a clearly misconfigured permission rule on /etc/issue, the example above shows explicitly that all users have read permissions on /etc/issue, yet it’s returning an error that it can’t be read, which must be a bug somewhere, but certainly not in inxi. There is no other issue about inxi that I can see from the posts and data above beyond this one. Since on every system I’ve ever seen over 10 plus years, /etc/issue has read permissions, clearly something went wrong somewhere unknown, and happened to trip the fallback error handler which applies when inxi is passed a file to read which turns out to not be readable, despite the fact that it should be all measures be readable.
-
Technically speaking, inxi is a single file, Perl, so there’s no ‘inxi binary’.
Installed 3.0.10-1.1 and get nice output as normal user:
karl@erlangen:~> inxi --recommends
...
/proc/scsi/scsi: -D Advanced hard disk data (used rarely)........................................... Present
/var/log/Xorg.0.log: -G graphics driver load status................................................. Present
The following recommended files are missing:
File: /etc/lsb-release
File: /proc/mdstat
----------------------------------------------------------------------------------------------------------------
Ok, all done with the checks. Have a nice day.
karl@erlangen:~>
karl@erlangen:~> inxi -zF
System: Host: erlangen Kernel: 4.16.12-1-default x86_64 bits: 64 Desktop: KDE Plasma 5.12.5
Distro: openSUSE Tumbleweed 20180530
Machine: Type: Desktop Mobo: ASRock model: Z170 Pro4S serial: <filter> UEFI: American Megatrends v: P3.50
date: 06/23/2016
CPU: Topology: Quad Core model: Intel Core i7-6700K bits: 64 type: MT MCP L2 cache: 8192 KiB
Speed: 800 MHz min/max: 800/4200 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800
7: 800 8: 800
Graphics: Card-1: Intel HD Graphics 530 driver: i915 v: kernel
Display: x11 server: X.Org 1.19.6 driver: intel unloaded: fbdev,modesetting,vesa
resolution: 1920x1200~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2) v: 4.5 Mesa 18.1.0
Audio: Card-1: Intel Sunrise Point-H HD Audio driver: snd_hda_intel
Sound Server: ALSA v: k4.16.12-1-default
Network: Card-1: Intel Ethernet Connection I219-V driver: e1000e
IF: enp0s31f6 state: down mac: <filter>
Card-2: Qualcomm Atheros AR9287 Wireless Network Adapter driver: ath9k
IF: wlp3s0 state: up mac: <filter>
Drives: HDD Total Size: 4.56 TiB used: 1.81 TiB (39.6%)
ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 950 PRO 512GB size: 476.94 GiB
ID-2: /dev/sda vendor: Western Digital model: WD40EZRX-22SPEB0 size: 3.64 TiB
ID-3: /dev/sdb vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB
Partition: ID-1: / size: 31.37 GiB used: 16.03 GiB (51.1%) fs: ext4 dev: /dev/nvme0n1p2
ID-2: /home size: 406.34 GiB used: 170.35 GiB (41.9%) fs: ext4 dev: /dev/nvme0n1p3
ID-3: swap-1 size: 31.90 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p1
Sensors: System Temperatures: cpu: 53.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info: Processes: 279 Uptime: 1h 33m Memory: 31.11 GiB used: 3.02 GiB (9.7%) Shell: bash inxi: 3.0.10
karl@erlangen:~>
erlangen:~ # ll /etc/issue
lrwxrwxrwx 1 root root 12 Jun 9 2017 /etc/issue -> ../run/issue
erlangen:~ # readlink -f /etc/issue
/run/issue
erlangen:~ # ll /run/issue
-rw------- 1 root root 100 May 31 20:37 /run/issue
erlangen:~ #
Possibly may recreate the link to /run/issue when you reboot. I haven’t actually done this though, I just read of the “issue”. I would be curious to know 
That is a good guess, I had just this problem when upgrading a system where I'd inadvertently copied /var/run from one disk to another, not realizing it was a symbolic link created at boot, to /run, so the same thing may well apply here, I fixed it by deleting the directory /var/run and then rebooting, just to see if it would work, and it did, the link was recreated. I would try that before anything else if /etc/issue is actually a link to /run/issue (odd, but I guess it makes sense to whatever does that). When I tried simply removing the directory, then creating my own symbolic link manually, it did not work, it had to be made by the kernel/system on boot to actually work. And it would not get made if anything else already existed there, whether a symbolic link or real directory.
just an FYI:
kvm:~ # ls -ld /var/run
lrwxrwxrwx 1 root root 4 Apr 24 16:53 /var/run -> /run
kvm:~ #
hi,
Did as shown below then inxi worked without root privileges
Will now see if it survives a cold boot
cheers
user@A780GM-m2:~> inxi -c 0 -Fz
Error 45: Error opening file: /etc/issue
Error: Permission denied
user@A780GM-m2:~> sudo rm /etc/issue
user@A780GM-m2:/run> sudo cp /run/issue /etc/issue
user@A780GM-m2:/etc> sudo chmod 755 /etc/issue
user@A780GM-m2:/etc> inxi -c 0 -Fz
System: Host: A780GM-m2.fritzbox Kernel: 4.16.12-1.g39c7522-default x86_64 bits: 64
Desktop: KDE Plasma 5.12.5 Distro: openSUSE Tumbleweed 20180529
Machine: Type: Desktop Mobo: ASRock model: A780GM-LE serial: <filter> BIOS: American Megatrends
v: P1.10 date: 02/13/2009
CPU: Topology: Quad Core model: AMD Phenom II X4 940 bits: 64 type: MCP L2 cache: 2048 KiB
Speed: 800 MHz min/max: 800/3000 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800
Graphics: Card-1: AMD RS780 [Radeon HD 3200] driver: radeon v: kernel
Display: x11 server: X.Org 1.19.6 driver: ati,radeon unloaded: fbdev,modesetting,vesa
resolution: 1680x1050~60Hz, 1920x1080~60Hz
OpenGL: renderer: AMD RS780 (DRM 2.50.0 / 4.16.12-1.g39c7522-default LLVM 6.0.0)
v: 3.3 Mesa 18.1.0
Audio: Card-1: AMD SBx00 Azalia driver: snd_hda_intel
Card-2: AMD RS780 HDMI Audio [Radeon 3000/3100 / HD 3200/3300] driver: snd_hda_intel
Sound Server: ALSA v: k4.16.12-1.g39c7522-default
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives: HDD Total Size: 465.76 GiB used: 112.25 GiB (24.1%)
ID-1: /dev/sda vendor: Western Digital model: WD5000AAKS-00A7B2 size: 465.76 GiB
Partition: ID-1: / size: 218.65 GiB used: 112.20 GiB (51.3%) fs: ext4 dev: /dev/sda4
ID-2: swap-1 size: 5.87 GiB used: 56.0 MiB (0.9%) fs: swap dev: /dev/sda1
Sensors: System Temperatures: cpu: 46.5 C mobo: 36.0 C
Fan Speeds (RPM): cpu: 3245 fan-1: 2678 fan-3: 0 fan-5: 0
Info: Processes: 176 Uptime: 2h 30m Memory: 1.70 GiB used: 941.5 MiB (54.0%) Shell: bash
inxi: 3.0.10
user@A780GM-m2:/etc>
PS. After a cold boot inxi still works without root privileges
This doesn’t actually solve the problem, it’s more of a work around. If OpenSuse has some file in /run that links to /etc/issue, what you want to do is delete /etc/issue, then reboot, then test.
First, see if /etc/issue is there, as a link, check its permissions, see if you as user can read it, forget about inxi, it’s totally unrelated to your issue: cat /etc/issue
that will then either show no file, which means the kernel does not create that file on boot, or it will say it can’t read the file, or it will read the file. Then you will know exactly what happened, and roughly why.
No chmod, no cp, that’s simply making a copy of the file, then making it world readable, and not actually fixing the real problem if what people here say is correct.
Good luck.
Again, this is not an inxi problem, it’s just a simple file permissions/boot logic problem, which inxi happened to expose, so you’re best off ignoring inxi because that simply masks the actual problem, which is users being able to read a simple text file.
In Leap 42.3 and 15 /etc/issue is a file, not a link.
In Tumbleweed it is a link. Just removing the link and rebooting re-creates the link. Removing the link and creating /etc/issue as it’s own file makes the link not be re-created.
I don’t know why the Tumbleweed developers decided to do this, but it is not considered a bug.
I didn’t think I’d ever install Tumbleweed to test, but I did 
hi,
thanks for all the comments
observations (not withstanding prior statements)
-
/etc/issue is created by the os on boot if it does not exist
-
the file permissions appears to change in /etc/issue on booting (/run/issue)
-
new or old users can only be guaranteed to run inxi after the cmd “sudo chmod 755 /etc/issue”
independent of whether /etc/issue existed or not, on boot the following sequence is repeatable
-rw------- 1 root root 85 1. Jun 17:31 issue (/run/)
hp-17-p105ng-m1<2018-06-01 17:33:47><~>... inxi -c 00 -Fz
Error 45: Error opening file: /etc/issue
Error: Permission denied
hp-17-p105ng-m1<2018-06-01 17:34:25><~>... cat /etc/issue
cat: /etc/issue: Permission denied
hp-17-p105ng-m1<2018-06-01 17:34:43><~>... sudo chmod 755 /etc/issue
[sudo] password for root:
hp-17-p105ng-m1<2018-06-01 17:35:35><~>... cat /etc/issue
Welcome to openSUSE Tumbleweed 20180529 - Kernel \r (\l).
eth0: \4{eth0} \6{eth0}
hp-17-p105ng-m1<2018-06-01 17:35:48><~>...
-rwxr-xr-x 1 root root 85 1. Jun 17:37 issue (/run/)
then inxi can be used by any user until the next boot
cheers
ps. the performance is the same on all kde installs: pc’s, laptops, 32 and 64 bit.
from comments this is not the case for Leap or gnome installs