https://bugzilla.suse.com/show_bug.cgi?id=1189592 https://bugzilla.suse.com/show_bug.cgi?id=1189592#c4 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Stefan Hundhammer <shundhammer@suse.com> --- There is no way to know when systemd will be quiet; it (or even other processes) might decide to write to the system console at any time, even after the boot process is finished. Yes, this is annoying; I reported something even more severe many years ago as bug #941106 (which is STILL not fixed; it was only pushed aside). But if we are to use the YaST NCurses UI (the text mode), the only thing that makes sense to do it on the tty that is immediately visible after rebooting; and that is tty1, which is also the system console. If we tried to start YaST on, say, tty2 or tty3, how would a user sitting at the console know when and how to switch to that tty? Even if we'd write a message to the console ("Please switch to tty2 with Alt-F2"), that would easily get ignored, and if syslog messages keep flooding the screen, it would also just scroll away. Automatically switching to tty2 would be just as antisocial and user-unfriendly as what I experienced in bug #941106: A user trying to log in or just trying to read the messages would be just thrown off in the middle of what he is doing. Not a good alternative. Having said that, there aren't that many options. If your installation process requires a second stage or a firstboot workflow and the Qt (graphical) YaST UI which does not have this problem is not available, there is still manually refreshing the NCurses UI screen with Ctrl-L. If it's just one or two messages, that is a quick and easy fix. If a runaway process that keeps respawning keeps spamming the console, this obviously doesn't work; but in that case, that is a more serious problem than the firstboot workflow because that constant respawn will keep the machine very busy, so it should be fixed first. I don't think there is anything better than we can do here. Sorry. -- You are receiving this mail because: You are on the CC list for the bug.