Bug 731594

Workaround: Hand-typing the following in a root console works:

systemctl reload-or-restart getty@tty2.service
systemctl reload-or-restart getty@tty3.service
systemctl reload-or-restart getty@tty4.service
systemctl reload-or-restart getty@tty5.service
systemctl reload-or-restart getty@tty6.service

Before that, "systemctl status" for one of these services gives the following reply:

getty@tty3.service - Getty on tty3
          Loaded: loaded (/lib/systemd/system/getty@.service; enabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/getty@.service/tty3   

<rant>
I see sysvinit has been made "obsolete" in favour of this new-fangled systemctl procedure. It weren't broke, ye shoudna fixt it.
</rant>

P.S. Of course there is no workaround for the missing --noclear switch in getty@tty1.service

/etc/inittab is not used under systemd.

ttys are started on demand by systemd, (based on /lib/systemd/systemd/getty@.service), unless you create symlinks in /etc/systemd/system/getty.target.wants/ to /lib/systemd/systemd/getty@.service

to get --noclear, we would need to replace /etc/systemd/system/getty.target.wants/getty@tty1.service symlink with a copy of the file and add --noclear to it

(In reply to comment #3)
> /etc/inittab is not used under systemd.
> 
> ttys are started on demand by systemd, (based on
> /lib/systemd/systemd/getty@.service), unless you create symlinks in
> /etc/systemd/system/getty.target.wants/ to /lib/systemd/systemd/getty@.service

What do you mean by "on demand"? AFAICT, unless I start them manually as shown in comment #1, in runlevel 5 (i.e. graphical multiuser) tty 2-6 don't react to the keyboard and don't display a login prompt.

Is this "load on demand" the reason why system messages will appear "spontaneously" on any text console, possibly overwriting the output of a curses-based program like yast or vim being used there?

I suppose the aliases in the [Install] section of getty@.service would have to be modified too.

> 
> to get --noclear, we would need to replace
> /etc/systemd/system/getty.target.wants/getty@tty1.service symlink with a copy
> of the file and add --noclear to it

OK, I made an edited copy as /lib/systemd/system/getty@tty1.service and linked it from /etc/systemd/system/getty.target/ -- we'll see how it works at next boot.

It works, so let's recap.

1. copy /lib/systemd/system/getty@.service to getty@tty1.service in the same directory
2. edit getty@tty1.service adding --noclear on the agetty command-line
3. in getty@.service, replace the [Install] section by the following:

[Install]
Alias=getty.target.wants/getty@tty2.service
Alias=getty.target.wants/getty@tty3.service
Alias=getty.target.wants/getty@tty4.service
Alias=getty.target.wants/getty@tty5.service
Alias=getty.target.wants/getty@tty6.service

4. cd /etc/systemd/system/getty.target.wants
   ln -svf /lib/systemd/system/getty@tty1.service
   ln -sv /lib/systemd/system/getty@.service getty@tty2.service
   ln -sv /lib/systemd/system/getty@.service getty@tty3.service
   ln -sv /lib/systemd/system/getty@.service getty@tty4.service
   ln -sv /lib/systemd/system/getty@.service getty@tty5.service
   ln -sv /lib/systemd/system/getty@.service getty@tty6.service

sorry, I forgot to comment.

"on demand", means tty should be started when you switch to vt2 => vt6 by systemd. If it doesn't, there is a bug somewhere.

fixing what your proposed :
don't copy /lib/systemd/system/getty@.service as /lib/systemd/system/getty@tt1.service but put the file directly to /etc/systemd/system/getty.target.wants

you shouldn't store anything in /lib but use /etc

(In reply to comment #6)
> sorry, I forgot to comment.
[...]
> don't copy /lib/systemd/system/getty@.service as
> /lib/systemd/system/getty@tt1.service but put the file directly to
> /etc/systemd/system/getty.target.wants
> 
> you shouldn't store anything in /lib but use /etc

What about the last two lines:

[Install]
Alias=getty.target.wants/getty@tty1.service

Keep them? Remove them? Keep one and remove the other? Don't care?

[Install] is only used if you run "systemctl enable getty@.service", so you don't need them since you did the symlink yourself.

In reply to comment #8: I meant after moving getty@tty1.service to /etc/systemd/system/getty.target.wants/ (overwriting the symlink) but IIUC is is not needed (maybe even harmful?) there.

it is not harmfull, since systemctl should not touch non-symlink files.

The workaround in comment #5 (but with the modified files in /etc rather than /lib per comment #6 sqq.) is still working for me in openSUSE 12.2. I haven't yet upgraded to openSUSE 13 because of busy schedule and also of bug 773058 but I keep reminding me to find some time to try it.

Please re-test on openSUSE 13.1 and provide results - Thanks.

(In reply to comment #12)
> Please re-test on openSUSE 13.1 and provide results - Thanks.

OK; but that will of course have to wait until I find time to upgrade to openSUSE 13.1 (or later) and have it succeed. If anyone else (already running openSUSE 13) is willing to do the same test, feel free to do so.

(In reply to comment #13)
> OK; but that will of course have to wait until I find time to upgrade to
> openSUSE 13.1 (or later) and have it succeed. If anyone else (already running
> openSUSE 13) is willing to do the same test, feel free to do so.

Sure, I think this issue is gone a while ago. I cannot reproduce it myself on openSUSE 13.1. 
It would be good to hear it from the reporter though ;-).

No response

I see that this bug has now been RESOLVED NORESPONSE. The reason I didn't answer comment #14 is that there was nothing new to report: I still haven't found the time to put a weekend aside for trying to update. Comment #11 still describes my current state of affairs.

If and when I upgrade to 13.1 or later, I'll remind myself to turn this bug to either RESOLVED WORKSFORME or REOPENED depending on results.

You may give the latest util-linux[1] package from openSUSE Factory a try (compare with bug #774126).  There I've added a workaround for a slow plymouth which may lead to a broken termios structure in the kernel.

Beside this I never had seen the reported behaviour with 12.3 and 13.1.  Only on 12.3 and if the dependency chain of systemd had been corrupted it had happen sometimes that the agetty on e.g. tty2 might not been started on demand. But this had been correct.

[1] The default getty is agetty from util-linux, also I had ported and submitted all mingetty feature to the agetty of upstream of util-linux which had been accepted (compare with upstream changelog).

(In reply to comment #17)
> You may give the latest util-linux[1] package from openSUSE Factory a try
> (compare with bug #774126).  There I've added a workaround for a slow plymouth
> which may lead to a broken termios structure in the kernel.
[…]

OK I'm adding this to my TODO list. I'll also have to reread the above comments: after a little more than 2 years the details of the problem aren't very fresh in my memory. Maybe there was a misunderstanding on my part at some point, trying to understand that (then) new systemctl software.

Could you please enlighten me on what "Plymouth" is? (probably by private mail to avoid spamming the bug). I notice that during boot there is a "Plymouth Boot Screen" which diverts startup messages to tty7 for a time, where they later get hidden by the X11 screen, but only the first time: if I log out of X11 the graphical login screen reappears on tty8 rather than on tty7, making the last page of boot text visible again on tty7, with "Starting Wait for Plymouth Boot Screen to Quit..." a few lines up from the bottom; and if I log out from X11 a second time the graphical screen remains on tty8. Unrelated to this, I suppose, but it has puzzled me.

I am now on openSUSE 13.1 and the bug is not present. I had other (unrelated) problems but the system is still booting mingetty on tty1 to tty6, and with no clear-screen action on tty1, possibly due to the changes I made while at some earlier release, see bug 808871 comment #17. I did NOT have to make them again. In addition, and unlike what happened at release 12.2, the login prompt appears on tty1 at the very bottom. I notice I'll have to change the heading which still says "Welcome to openSUSE 12.2 (but with the correct kernel version and tty number).

The only thing I don't like overmuch is that the Plymouth screen appears on tty7, which means it cannot be seen once X11 has been started the first time. If I exit the display manager, the graphical login screen will reappear (strangely enough) on tty8 rather than tty7 (and the last screen of Plymouth will be visible again on tty7) but now that I know it it's OK. (I already mentioned this as the last paragraph of comment #18 above.)

The util-linux presently installed is version 2.23.2-6.1-x86_64 from vendor openSUSE; AFAICT it comes from the normal 13.1 "Update" repository. I have the impression that the bootup process is faster than under 12.2 (except after a power failure or other unexpected reboot, where the reiserfs journal is handled at exactly the same speed); but this is a subjective impression, I have taken no "scientific" measures.

P.S. (to para 1 of comment #19): I have a customized /etc/issue, which I have just changed so that it now says

Welcome to openSUSE 13.1 (\m) - Kernel \r (\l).
\U logged in on \d \t

followed by one empty line.

Use agetty not mingetty as the last one is not supported anymore. All features from the old mingetty had been ported to agetty at upstram util-linux by my self.

(In reply to comment #21)
> Use agetty not mingetty as the last one is not supported anymore. All features
> from the old mingetty had been ported to agetty at upstram util-linux by my
> self.

Including its small footstep (aka size) ?

P.S. Here are some of the "features" of mingetty which I regard as useful:
- It is minimal (VSZ=4516 when running, according to the ps utility).
- It cannot log in from remote or serial lines, but only from local (virtual) consoles.
- It accepts and obeys the --noclear switch
- It recognises in /etc/issue all the slash-escaped sequences mentioned in comment #20.

agetty isn't that large and it can log on both serial lines and virtual consoles, it also accepts and obeys the --noclear and it can handle the escape sequences of you /etc/issue

In fact the discussion was done several years ago and mingetty was kicked out.

(In reply to comment #24)
> agetty isn't that large and it can log on both serial lines and virtual
> consoles, it also accepts and obeys the --noclear and it can handle the escape
> sequences of you /etc/issue
> 
> In fact the discussion was done several years ago and mingetty was kicked out.

So I note that mingetty isn't "officially supported" anymore. If I decide to use it (like I use the Sunbird selfstanding calendar, whose latest Linux64 nightly is dated 2010-01-11 AFAIK, and for which I haven't found a replacement that satisfies me), it will be under my own responsibility. If I have specific problems with mingetty (as opposed to systemd or login, which _are_ supported), part or all of the answer will always be "mingetty is obsolete; use agetty instead".

The point of serial lines might be moot since AFAIK I don't have any (though I'm not sure); but I regard being able to listen to logins from them as a security liability unless they are really known in advance to be needed as login devices. I don't know how big agetty is when running; its binary executable is only slightly larger than that of mingetty and vastly smaller than that of mgetty so you might have a point there. My other two points, apparently, make no difference between agetty and mingetty.

I have a fresh install of 13.1. So far I could not get systemd give me any VT. I can start a VT by entering 'aboot tty1' from a xterm, with the penalty that in that xterm bash will crash.
So for each VT I have to start a Konsole in X, su and enter the root password, type 'aboot ttyx &' close the Konsole. Both work and around.

Simply do as root

     chvt 1

or use press the Crtl, the Alt, and the F1 keys all together

Beside this: bugs are not allot for teaching how to use the system.