[quote=“squidflame,post:20,topic:147185”]
That’s what I was hoping, but I guess not if a script is going to be overwriting it regularly.[/QUOTE]
You can edit the /etc/sysconfig/issue-generator file with YaST -> System -> Sysconfig Editor -> System -> Login -> NETWORK_INTERFACE_REGEX. When using YaST, the settings should be permanent and protected from automatic overwrites, I believe.
I just found out, that by removing the regex “[1]” in YaST, all my network interfaces which are detected are showing now on my boot console. Even those without any IP or with loopback. So maybe another option to get rig of it for good is to uninstall the pkg issue-generator and lock it so it won’t get installed again.
be ↩︎
I changed defaults by providing an empty /etc/issue.d/70-eth0.conf overriding /run/issue.d/70-eth0.conf resulting in the following issue file:
**3400G:~ #** cat /run/issue
Welcome to openSUSE Tumbleweed 20210817 - Kernel \r (\l).
**3400G:~ #**
Yes, but, there is a danger that, at the next update or patch of the package which either placed the files in those directories – which should result in either an ‘.rpmsave’ or, an ‘.rpmnew’ version of the concerned configuration file – or, generates the files in those directories – which may well result in an undefined behaviour – possibly simply overwriting the file with the administrator’s changes –
Which is why, directories such as ‘/etc/issue.d/’ have appeared, as a work-around of this issue –
No, this isn’t a parallel to Jasper Carrot’s text where he reported that he spent a night sitting on a stool in his garden with a shotgun – until the police came along and asked what on earth he was doing?
So, as I’ve explained to arvidjaar, the reason is, there are RPM package maintainers out there in the wild who, haven’t yet, learnt to respect to configuration changes made by administrators …
“man 5 issue” –
issue - prelogin message and identification file
/etc/issue is a text file which contains a message or system identification to be printed before the login prompt. It may contain various @char and \char sequences, if supported by the getty-type program employed on the system.
You may, if you wish, take note of the following discussion in the Linux.Org Forum – <https://www.linux.org/threads/etc-issue.28791/>.
Also, you may take note of this StackExchange serverfault discussion – <linux - what is the difference between /etc/issue.net and /etc/issue - Server Fault.
[HR][/HR]OK – so the SUSE implementation around the text displayed pre VT logins isn’t to your taste and, it seems that the methods proposed to alleviate your woes are also not what you would prefer to do …
The script only adds new settings from template if package update installs updated template (this covers initial package installation when there is no existing file so it is created from template). This script never overwrites existing settings (if it does, it is a bug that must be reported).
Amusing. Before you “explain” something make some efforts to actually understand what you are talking about.
I don’t get that reference, but I was referring to this game which is spelled that way, though maybe it would be technically correct to capitalize it.
What I meant was that adding (potentially more than one) issue.d file does not fix the problem at its source, which is the regex that chooses which interfaces to print out information for.
Unless there is a simple enable/disable boolean to toggle the feature as a whole, the best solution is probably just to make the regex itself match nothing.
So this sysconfig file (/etc/sysconfig/issue-generator) is probably the best place to make this change. Is YaST just modifying this file when you use YaST to set the regex as described by Atronach?
If so, when modifying the sysconfig file by hand, then later via YaST, does this cause any issues? Does YaST reset comments or do something similar if the sysconfig file was first modified by hand.
Yes. YaST Sysconfig Editor just modifies files under /etc/sysconfig (it also handles files in some other locations).
If so, when modifying the sysconfig file by hand, then later via YaST, does this cause any issues?
If you just change values and are careful to not break quoting (like missing closing double quote) I do not expect any issues (besides /etc/issue 
)
Does YaST reset comments or do something similar if the sysconfig file was first modified by hand.
YaST interprets comments as metadata about settings (like group where setting appears, description what it does etc). You better avoid changing anything that starts with double hash characters (##); and adding such comments may confuse YaST. Comments with single hash immediately preceding setting are present to user as explanation and should be preserved. Comments following setting may be lost.
But really, either you edit by hand or you use YaST. It is never good idea to mix unless you are absolutely sure you understand implications. I never used YaST for it (OK, maybe when I first started to use SUSE, but that must have been very long ago). But I well understand that for beginners using YaST is easier (I myself often use it for tasks I have to do infrequently).