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.
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 smxi.org/pinxi 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.
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 https://bugzilla.opensuse.org/show_bug.cgi?id=1044819
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 https://bugzilla.opensuse.org
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”
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.