1-issue-generator not generating; 2-last login absent
I have multiple installations where I removed issue-generator for some period until I decided to reverse my attitude about it. The main idea was, and remains, I don't want to see IP addresses onscreen with VT logins. Now I have some installations where even though it has been reinstalled, login prompts on VTs are simply hostname login: on an otherwise blank screen until such time as I systemctl start issue-generator.service Also on all these installations, logging in fails to report date last logged in. Reinstalling issue-generator hasn't helped. # inxi -S System: Host: msi85 Kernel: 6.6.30-1-longterm arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Tumbleweed 20240514 # systemctl list-units --type target --state active | grep graphical # systemctl status graphical.target ○ graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; preset: disabled) Active: inactive (dead) Docs: man:systemd.special(7) # dmesg | grep issue # journalctl -b | grep issue # systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled # ls -glG /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue ls: cannot access '/etc/motd': No such file or directory ls: cannot access '/run/issue': No such file or directory lrwxrwxrwx 1 12 Apr 29 2022 /etc/issue -> ../run/issue -rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/70-eth0.conf -rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/90-openSUSE.conf -rw-rw-r-- 1 27 Oct 3 2015 /etc/motd.d/welcome # cat /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue Have a lot of MSI85 fun... cat: /etc/motd: No such file or directory cat: /etc/issue: No such file or directory cat: /run/issue: No such file or directory # How can these installations be troubleshot? What else is missing? What's responsible for reporting last login timestamp? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 25.05.2024 08:24, Felix Miata wrote:
I have multiple installations where I removed issue-generator for some period until I decided to reverse my attitude about it. The main idea was, and remains, I don't want to see IP addresses onscreen with VT logins. Now I have some installations where even though it has been reinstalled, login prompts on VTs are simply
hostname login:
on an otherwise blank screen until such time as I
systemctl start issue-generator.service
Also on all these installations, logging in fails to report date last logged in. Reinstalling issue-generator hasn't helped.
# inxi -S System: Host: msi85 Kernel: 6.6.30-1-longterm arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Tumbleweed 20240514 # systemctl list-units --type target --state active | grep graphical # systemctl status graphical.target ○ graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; preset: disabled) Active: inactive (dead) Docs: man:systemd.special(7) # dmesg | grep issue # journalctl -b | grep issue # systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled # ls -glG /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue ls: cannot access '/etc/motd': No such file or directory ls: cannot access '/run/issue': No such file or directory lrwxrwxrwx 1 12 Apr 29 2022 /etc/issue -> ../run/issue -rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/70-eth0.conf
You configured your system to ignore generated IP address information and now you are asking why it ignores it?
-rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/90-openSUSE.conf -rw-rw-r-- 1 27 Oct 3 2015 /etc/motd.d/welcome # cat /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue Have a lot of MSI85 fun... cat: /etc/motd: No such file or directory cat: /etc/issue: No such file or directory cat: /run/issue: No such file or directory #
How can these installations be troubleshot? What else is missing? What's responsible for reporting last login timestamp?
Andrei Borzenkov composed on 2024-05-25 08:34 (UTC+0300):
Felix Miata wrote:
I have multiple installations where I removed issue-generator for some period until I decided to reverse my attitude about it. The main idea was, and remains, I don't want to see IP addresses onscreen with VT logins. Now I have some installations where even though it has been reinstalled, login prompts on VTs are simply
hostname login:
on an otherwise blank screen until such time as I
systemctl start issue-generator.service
Also on all these installations, logging in fails to report date last logged in. Reinstalling issue-generator hasn't helped.
# inxi -S System: Host: msi85 Kernel: 6.6.30-1-longterm arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Tumbleweed 20240514 # systemctl list-units --type target --state active | grep graphical # systemctl status graphical.target ○ graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; preset: disabled) Active: inactive (dead) Docs: man:systemd.special(7) # dmesg | grep issue # journalctl -b | grep issue # systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled # ls -glG /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue ls: cannot access '/etc/motd': No such file or directory ls: cannot access '/run/issue': No such file or directory lrwxrwxrwx 1 12 Apr 29 2022 /etc/issue -> ../run/issue -rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/70-eth0.conf
You configured your system to ignore generated IP address information and now you are asking why it ignores it?
The goals are: 1-to have unused VTs look like they did before there was systemd, a Welcome to ... line at top of screen, and nothing but black between it and login prompt a line or two or three below it. 2-to have passwd submission responded to with an announcement of last login.
-rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/90-openSUSE.conf -rw-rw-r-- 1 27 Oct 3 2015 /etc/motd.d/welcome # cat /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue Have a lot of MSI85 fun... cat: /etc/motd: No such file or directory cat: /etc/issue: No such file or directory cat: /run/issue: No such file or directory #
How can these installations be troubleshot? What else is missing? What's responsible for reporting last login timestamp? -- Evolution as taught in public schools is, like religion, based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-05-25 07:54, Felix Miata wrote:
Andrei Borzenkov composed on 2024-05-25 08:34 (UTC+0300):
Felix Miata wrote:
...
You configured your system to ignore generated IP address information and now you are asking why it ignores it?
The goals are:
1-to have unused VTs look like they did before there was systemd, a Welcome to ... line at top of screen, and nothing but black between it and login prompt a line or two or three below it.
2-to have passwd submission responded to with an announcement of last login.
I had a look, and what I get is: Welcome to openSUSE Leap 15.5 - Kernel 5.14.21-150500.55.59-default (tty2). eth0: 192.168.1.14 fe80::2d8:61ff:fea1:5abd Telcontar login: You simply want the IP address gone? I don't know what is the rationale for printing it. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 25.05.2024 08:24, Felix Miata wrote:
I have multiple installations where I removed issue-generator for some period until I decided to reverse my attitude about it. The main idea was, and remains, I don't want to see IP addresses onscreen with VT logins. Now I have some installations where even though it has been reinstalled, login prompts on VTs are simply
hostname login:
on an otherwise blank screen until such time as I
systemctl start issue-generator.service
Also on all these installations, logging in fails to report date last logged in. Reinstalling issue-generator hasn't helped.
# inxi -S System: Host: msi85 Kernel: 6.6.30-1-longterm arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Tumbleweed 20240514 # systemctl list-units --type target --state active | grep graphical # systemctl status graphical.target ○ graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; preset: disabled) Active: inactive (dead) Docs: man:systemd.special(7) # dmesg | grep issue
User space does not normally log into dmesg unless you explicitly configured it (dracut being the notable exception).
# journalctl -b | grep issue # systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled
issue-generator.service is WantedBy=default.target. Is default.target actually used during boot?
# ls -glG /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue > ls: cannot access '/etc/motd': No such file or directory ls: cannot access '/run/issue': No such file or directory lrwxrwxrwx 1 12 Apr 29 2022 /etc/issue -> ../run/issue -rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/70-eth0.conf -rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/90-openSUSE.conf -rw-rw-r-- 1 27 Oct 3 2015 /etc/motd.d/welcome # cat /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue Have a lot of MSI85 fun... cat: /etc/motd: No such file or directory cat: /etc/issue: No such file or directory cat: /run/issue: No such file or directory #
How can these installations be troubleshot? What else is missing? What's responsible for reporting last login timestamp?
pam_lastlog2
Andrei Borzenkov composed on 2024-05-25 09:17 (UTC+0300):
Felix Miata wrote:
I have multiple installations where I removed issue-generator for some period until I decided to reverse my attitude about it. The main idea was, and remains, I don't want to see IP addresses onscreen with VT logins. Now I have some installations where even though it has been reinstalled, login prompts on VTs are simply
hostname login:
on an otherwise blank screen until such time as I
systemctl start issue-generator.service
Also on all these installations, logging in fails to report date last logged in. Reinstalling issue-generator hasn't helped.
# journalctl -b | grep issue # systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled
issue-generator.service is WantedBy=default.target. Is default.target actually used during boot?
More often than not, no. Usually default is defined as graphical, but most boots are maintenance boots, so kernel cmdline includes a 3. I tried systemd.unit=multi-user.target instead of 3, but result is no different. I tried changing WantedBy from default to multi-user, but it didn't help. On affected installations, "Welcome to openSUSE Tumbleweed 20240524 - Kernel \r (\l)." only puts output on VTs if default.target graphical is allowed. # inxi -S System: Host: fi965 Kernel: 6.6.31-1-longterm arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.10 Distro: openSUSE Tumbleweed 20240524 # cat /etc/systemd/system/issue-generator.service.d/override.conf [Install] WantedBy=multi-user.target # systemctl cat issue-generator.service # /usr/lib/systemd/system/issue-generator.service [Unit] Description=Generate issue file for login session Before=systemd-user-sessions.service [Service] Type=oneshot ExecStart=/usr/sbin/issue-generator [Install] WantedBy=default.target # /etc/systemd/system/issue-generator.service.d/override.conf [Install] WantedBy=multi-user.target # systemctl status issue-generator.service ○ issue-generator.service - Generate issue file for login session Loaded: loaded (/usr/lib/systemd/system/issue-generator.service; enabled; preset: enabled) Drop-In: /etc/systemd/system/issue-generator.service.d └─override.conf Active: inactive (dead) # cat /proc/cmdline root=LABEL=sTWp21w71 ipv6.disable=1 net.ifnames=0 radeon.si_support=0 amdgpu.si_support=1 noresume consoleblank=0 mitigations=off vga=791 video=1440x900@60 3 # systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Thu, May 30, 2024 at 1:10 AM Felix Miata <mrmazda@earthlink.net> wrote:
issue-generator.service is WantedBy=default.target. Is default.target actually used during boot?
More often than not, no. Usually default is defined as graphical, but most boots are maintenance boots, so kernel cmdline includes a 3.
Which explains your problem.
I tried changing WantedBy from default to multi-user, but it didn't help.
Explain step by step what you did.
Andrei Borzenkov composed on 2024-05-30 09:14 (UTC+0300):
Felix Miata wrote:
issue-generator.service is WantedBy=default.target. Is default.target actually used during boot?
More often than not, no. Usually default is defined as graphical, but most boots are maintenance boots, so kernel cmdline includes a 3.
Which explains your problem.
Not really, since this is the situation with all openSUSE installations here, and only some of them fail to start issue-generator.service automatically.
I tried changing WantedBy from default to multi-user, but it didn't help.
Explain step by step what you did.
# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot What you didn't quote from my previous post indicates the resulting system state: Felix Miata composed on 2024-05-29 18:10 (UTC-0400):
# cat /etc/systemd/system/issue-generator.service.d/override.conf [Install] WantedBy=multi-user.target # systemctl cat issue-generator.service # /usr/lib/systemd/system/issue-generator.service [Unit] Description=Generate issue file for login session Before=systemd-user-sessions.service
[Service] Type=oneshot ExecStart=/usr/sbin/issue-generator
[Install] WantedBy=default.target
# /etc/systemd/system/issue-generator.service.d/override.conf [Install] WantedBy=multi-user.target
Given default.target for most installations is graphical.target, why is the default state WantedBy=default.target in the first place? Which users who rarely or never see a VT have any care whether issue-generator runs or not? It's value is in levels less than graphical.target. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 30.05.2024 17:44, Felix Miata wrote:
I tried changing WantedBy from default to multi-user, but it didn't help.
Explain step by step what you did.
# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot
I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.
Andrei Borzenkov composed on 2024-05-30 20:19 (UTC+0300):
Felix Miata wrote:
I tried changing WantedBy from default to multi-user, but it didn't help.
Explain step by step what you did.
# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot
I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.
Felix Miata composed on 2024-05-29 18:10 (UTC-0400):
# systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled
Looks enabled to me, whether on an installation where it works, or not. And, it works if I run systemctl start issue-generator.service on any where it doesn't. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-05-30 20:15, Felix Miata wrote:
Andrei Borzenkov composed on 2024-05-30 20:19 (UTC+0300):
Felix Miata wrote:
I tried changing WantedBy from default to multi-user, but it didn't help.
Explain step by step what you did.
# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot
I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.
Felix Miata composed on 2024-05-29 18:10 (UTC-0400):
# systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled
Looks enabled to me, whether on an installation where it works, or not. And, it works if I run
systemctl start issue-generator.service
on any where it doesn't.
He is saying that if you change the [install] section , you have to do a systemctl enable to activate that change. At least that is what I understand, it is news to me. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.5)
Carlos E. R. composed on 2024-05-30 23:25 (UTC+0200):
Felix Miata wrote:
Andrei Borzenkov composed on 2024-05-30 20:19 (UTC+0300):
Felix Miata wrote:
I tried changing WantedBy from default to multi-user, but it didn't help.
Explain step by step what you did.
# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot
I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.
Felix Miata composed on 2024-05-29 18:10 (UTC-0400):
# systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled
Looks enabled to me, whether on an installation where it works, or not. And, it works if I run
systemctl start issue-generator.service
on any where it doesn't.
He is saying that if you change the [install] section , you have to do a systemctl enable to activate that change. At least that is what I understand, it is news to me.
Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled; or issue-generator uninstalled, then installed? Restarting or rebooting I can understand, but not those pairs. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Op vrijdag 31 mei 2024 02:54:27 CEST schreef Felix Miata:
Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled; or issue-generator uninstalled, then installed? Restarting or rebooting I can understand, but not those pairs. systemctl daemon-reload systemctl restart whatever_service_you_added
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
Knurpht-openSUSE composed on 2024-05-31 02:58 (UTC+0200):
schreef Felix Miata:
Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled; or issue-generator uninstalled, then installed? Restarting or rebooting I can understand, but not those pairs.
systemctl daemon-reload systemctl restart whatever_service_you_added
Rebooting didn't/doesn't subsume those??? I know restart alone works for issue-generator, but expected behavior doesn't survive a reboot. Again, this is only on some systems, and I don't have any ideas where to look for responsible difference(s), unless cause is first found. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Fri, May 31, 2024 at 3:55 AM Felix Miata <mrmazda@earthlink.net> wrote:
Carlos E. R. composed on 2024-05-30 23:25 (UTC+0200):
Felix Miata wrote:
Andrei Borzenkov composed on 2024-05-30 20:19 (UTC+0300):
Felix Miata wrote:
> I tried changing WantedBy from default to multi-user, but it didn't help.
Explain step by step what you did.
# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot
I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.
Felix Miata composed on 2024-05-29 18:10 (UTC-0400):
# systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled
Looks enabled to me, whether on an installation where it works, or not.
That is a common misunderstanding. The "enable(d)" as used in systemd has nothing to do with the colloquial usage of the English word "enable(d)". "enable" in systemd means exactly that - create links defined by [Install] section. "enabled" in systemd means exactly that - links defined by [Install] section exist. Now you hit a case when some links are present and some links are missing. This unit is neither fully enabled nor completely disabled. systemctl apparently shows "enabled" if any link is present. Showing "disabled" in this case would be just as wrong. Maybe it should show "partially enabled" (or similar) to avoid confusion. That is something you need to bring up with upstream.
works if I run
systemctl start issue-generator.service
on any where it doesn't.
He is saying that if you change the [install] section , you have to do a systemctl enable to activate that change. At least that is what I understand, it is news to me.
Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled;
Quoting "man systemd.unit" Unit files may include an [Install] section, which carries installation information for the unit. This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1) You do not need to run "systemctl disable" if you just add an additional link. You obviously need to do it if you replace one link with another - and you need to do it *before* changing the [Install] section, otherwise "systemctl disable" will not know what old link to remove.
or issue-generator uninstalled, then installed?
In this case installing the issue-generator would run "systemctl enable".
On 2024-05-31 09:19, Andrei Borzenkov wrote:
On Fri, May 31, 2024 at 3:55 AM Felix Miata <mrmazda@earthlink.net> wrote:
Carlos E. R. composed on 2024-05-30 23:25 (UTC+0200):
Looks enabled to me, whether on an installation where it works, or not.
That is a common misunderstanding. The "enable(d)" as used in systemd has nothing to do with the colloquial usage of the English word "enable(d)".
"enable" in systemd means exactly that - create links defined by [Install] section. "enabled" in systemd means exactly that - links defined by [Install] section exist.
Thank you for this explanation. I was guessing something of the sort, but not all of it, by far. It is good to know. :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
Andrei Borzenkov composed on 2024-05-31 10:19 (UTC+0300):
On Fri, May 31, 2024 at 3:55 AM Felix Miata wrote:
Felix Miata composed on 2024-05-29 18:10 (UTC-0400):
> # systemctl list-unit-files | grep issue > issue-generator.path enabled enabled > issue-add-ssh-keys.service disabled disabled > issue-generator.service enabled enabled
Looks enabled to me, whether on an installation where it works, or not.
That is a common misunderstanding. The "enable(d)" as used in systemd has nothing to do with the colloquial usage of the English word "enable(d)".
"enable" in systemd means exactly that - create links defined by [Install] section. "enabled" in systemd means exactly that - links defined by [Install] section exist.
Now you hit a case when some links are present and some links are missing. This unit is neither fully enabled nor completely disabled. systemctl apparently shows "enabled" if any link is present. Showing "disabled" in this case would be just as wrong. Maybe it should show "partially enabled" (or similar) to avoid confusion. That is something you need to bring up with upstream.
Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled;
Quoting "man systemd.unit"
Unit files may include an [Install] section, which carries installation information for the unit. This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1)
You do not need to run "systemctl disable" if you just add an additional link. You obviously need to do it if you replace one link with another - and you need to do it *before* changing the [Install] section, otherwise "systemctl disable" will not know what old link to remove.
or issue-generator uninstalled, then installed?
In this case installing the issue-generator would run "systemctl enable".
On an obstinate host msi85 TW with graphical.target default, ultimately I: 1-changed default target from graphical to multi-user 2-rebooted without 3 on cmdline to find issue-generator started 3-changed default target from multi-user to graphical 4-rebooted 5-uninstalled issue-generator 6-removed /etc/issue 7-removed /etc/issue.d/ 8-removed /etc/sysconfig/issue-generator 9-rebooted 10-installed issue-generator 11-rebooted with 3 on cmdline to find issue-generator not started 12-rebooted without 3 on cmdline to find issue-generator started 13-created override to want multi-user instead of default 14-disabled issue-generator 15-enabled issue-generator 16-rebooted with 3 on cmdline to find issue-generator working as expected The question remains why necessary on this installation and not on most others with same default target graphical but 3 on grub's linu line? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Felix Miata -
Knurpht-openSUSE