inxi: root needed to run

On Tumbleweed (GNOME DE) I see permissions;

ls -la /run/issue
-rw------- 1 root root 61 Jun  1 09:33 /run/issue

On SLES 15 (GNOME DE) I see permissions;

 ls -la /run/issue
-rw-r--r-- 1 root root 102 May 31 13:27 /run/issue

Neither have issues running inxi.

There is not an entry in your /etc/permissions for /etc/issue?

Else maybe creating a file called /etc/permissions.d/issue and add something like;

/run/issue    root:root    0644

Seems to me it’s a bug somewhere and probably worth reporting.

KDE3 on 42.3:

ls -gG issue
-rw-r--r-- 1 50 Jul 19  2017 issue

Solution/work around?
All back to normal after following cmds,

sudo rm /etc/issue
sudo cp /run/issue /etc/issue
sudo chmod 644 /etc/issue


Since someone actually thought it was a good idea to make Tumbleweed use this method, and also thought it was a good idea to make a simple text file that has been used to identify distros for I believe decades only root readable, I suspect it will be very difficult to make that person or persons admit this was a silly thing to do, and accept it as a bug. Maybe they will, but I view it as unlikely.

My main purpose of posting in this thread was to determine first, why on earth anyone would have such a thing done in the first place, and, second, to see if it is something that inxi needs to work around or not.

Obviously the correct solution is to get such things fixed on the distro end, since it’s a bug, /etc/issue is, or should be, a simple text file, and there is no valid reason to make it root read only, but since my experience also shows me that often when people make decisions this absurd, they are very unlikely to admit their error, and much more likely to respond with some defensive rationalization of why such an action actually makes sense (a rationalization that is not worth listening to in my opinion), the ‘issue’ will have to be worked around by inxi, but really, someone needs to kicks omeone in the butt and get them to make the darned file world readable, as it has been on every distro in the world ever since linux began. So I’ll add a read test for /etc/issue, with a solid comment explaining why it’s needed, since otherwise there should be no valid reason if that file exists for it to not also be readable.

And that was because it was already the case before Linux.

It is so simple, it has only a three line description in the man page on HP-UX 10.0 (1995). And it existed way before that.

Again, I have installed Tumbleweed.

erlangen:~ # ll /etc/issue
lrwxrwxrwx 1 root root 12 Jun  9  2017 /etc/issue -> ../run/issue
erlangen:~ # ll  /run/issue
-rw------- 1 root root 100 Jun  2 16:36 /run/issue
erlangen:~ # 

I run inxi as normal user without problems:

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.7%) 
           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.54 GiB (52.7%) fs: ext4 dev: /dev/nvme0n1p2 
           ID-2: /home size: 406.34 GiB used: 171.72 GiB (42.3%) 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.5 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 279 Uptime: 4h 16m Memory: 31.11 GiB used: 3.11 GiB (10.0%) Shell: bash inxi: 3.0.10 

So when using defaults inxi works fine for a normal user. See also

I’ve added a workaround for this tumbleweed bug in the upcoming inxi, which will be 3.0.11

Since it actually prevents inxi from running, and since I can’t fix distro internal problems and decision processes, this is the only way to handle it. For suse /etc/issue also isn’t used, but that logic block does use it, so not reading or trying to read issue doesn’t matter for suse.

This workaround can be tested in the pinxi development branch: wget version 3.0.10-29

No comment on the actual bug beyond what I’ve say, but I would suggest since not everyone in the world is going to spend the time like i just did to figure out why a file that has always been world readable was made a symbolic link to a root only readable file, to post to the creator of this bug and have them change that idea so that other things that might be expecting to be able to read /etc/issue don’t also puke and choke on this. Good luck on that, lol.

Sure:, but it’s not so simple:

I don’t use TW but a quick bugzilla search reveals the possibility that something regarding /etc/issue has changed in TW and as far as I can tell it’s a feature not a bug
from the first comment

 /etc/issue handling has been converted to issue-generators a few months ago

again I don’t use TW and I’m not a developer so I don’t know what that means
but if you think this is a bug open a bug report about it

hcvv, all the more reason then to post a bug report that forces whoever made that decision to fix it. If they are so stubborn to refuse, then one has to suspect this is a systemd setting, and we all know how it goes to when you try to get Poettering to admit anything he does is a mistake, so that’s probably not a good way to spend your time. If it’s simply an OpenSuse bug, maybe you’ll have better luck trying to get them to fix this ‘issue’, since you can point to decades of tradition and history and expectations to back you up. If you still get a refusal, it’s time to walk away and find a better way to spend your time, at least that’s my experience (such silly refusal on a trivial distro id file change, as a historical point, is exactly what made me fork the original code to inxi in the first place. So that turned out well, heh).

I_A, as noted, nothing is less interesting than reading rationalizations for bad / stupid technical decisions, we all know, at least all of us who are tech professionals, how easy it is to make up reasons for bad practices, downright mistakes, excuses for bad ideas, etc, which is why I stepped away from distro specific stuff years ago. Since there was certainly a better way to have done this, the fact it was done in a bad way simply shows that whoever made the decision there isn’t worth talking to, at least that’s my experience.

All inxi and i concern ourselves with is dealing with sloppy ideas like this so that end users can still get their system data no matter how many absurd ideas or changes are made by upstream, wherever or whoever they may be. I do like internally in inxi to record the process of such things so that the code is understandable, otherwise you’d read it now and ask, why on earth is this specific /etc/issue readable check here? And I also like to include the names of the guilty parties/distros so it’s easy to remember the actual reasons…

karlmistelberger, again, the fact that someone decided to ignore a core system file and it’s description: A TEXT FILE, not a link to a auto generated root only readable virtual file in /run, I’d say you have an uphill struggle to get them to fix the bug, and admit their error, and find a smarter way to do it. There’s always a smarter way to do these types of mistakes, but the fact that anyone decided to ignore all this reality and make up their own thing is in my experience a bad sign, and at least for my sake, a red flag warning to walk away, before I waste more of my time, sigh. Which is what I’m now going to do, since this is exactly the type of thing that made me leave active distro participation in the first place, sad to say. In particular I find unpleasant watching such mistakes be rationalized away, rather than the person who made it go, oh, darn it, I had not realized this is a core system file with decades of history, let me fix that as soon as possible! which is the technically correct response, that’s the type of response you’d get from me if you filed a good bug report.

so good luck with getting this person or persons to admit they made a mistake, figure out what they really meant to do, and do it right.

Core system file? I don’t have this file, inxi is working well on my machine. Installing inxi and using it is a pleasent experience! I ignore /etc/issue and I am doing well.

You might check for the presence of the file and take action accordingly. Don’t blame people ignoring that file.

“Es kommt nicht darauf an, mit dem Kopf durch die Wand zu gehen, sondern mit den Augen die Tür zu finden”

Werner von Siemens

bug raised see

bug closed with,

Thorsten Kukuk 2018-06-04 09:33:58 UTC

Fixed, hardcoded 644

[reply] −] Comment 3 Swamp Workflow Management 2018-06-04 09:50:18 UTC

This is an autogenerated message for OBS integration:
This bug (1095697) was mentioned in Factory

[reply] −] Comment 5 Swamp Workflow Management 2018-06-04 14:10:12 UTC

This is an autogenerated message for OBS integration:
This bug (1095697) was mentioned in Factory

I’m very glad to see this ‘issue’ is fixed, since only inxi 3.0.11 and newer will handle this situation (now checks more carefully about read for /etc/issue, along with several other distro ID oddities from non SuSe distros. I’m glad tumbleweed exposed this problem, and that someone posted about it, and that it got fixed, that’s always the best hoped for case. 3.0.11 will be out shortly, with far too many new features and fixes.

You obviously found the door. Glad to hear!