Bug 725913

You're free to use sysvinit for 12.1 and it will continue to delay getty till everything is started. but I don't see this as an improvement. systemd is just different.

Not being able to read the login prompt doesn't sound good from the usability point of view.

Neither the completely cleared screen in between.

Unfortunately, there is no easy way to delay startup of getty1 until everything is "started".

After installing sysvinit-init and switching back to systemd-sysvinit I'm no longer able to reproduce the issue.

reopening, upstream systemd has now a concept of "idle" service, which is used for agetty so they are only started once other services are running.

However, it is only available with systemd >= 184 and I don't plan to push it for 12.2. Keeping this bug opened until we have systemd >= 184 in Factory.

*** Bug 768054 has been marked as a duplicate of this bug. ***

Changing subject to make discoverable via Bugzilla search.

This needs to be fixed before 12.3 release.

This is happening with (default) systemd-init boot too.

@Felix: Why are you tweaking with the 'Found in Version' field and reassign the bug to a different bug owner (might be the side effect of modifying the version) without further arguments?

Please revert the former state.

If you consider this as a blocking issue for the openSUSE 12.3 release please modify the Severity accordingly.

I didn't see that the assignee got changed by Bugzilla, so I've reverted that. History isn't showing a QA change.

I don't see any way to change the "found in". I changed the product (that it can be fixed in).

I only change "priority" if I'm assigned the bug. Whether "importance" which is currently "major" should be something else isn't clear to me. Since it doesn't prevent use, I wouldn't call it a blocker or even critical. Since you filed it, maybe you want to change "severity".

The problem for me is I set tty1 to noclear, so messages following the login prompt obfuscate its existence so that I often can't even tell init is finished except by tapping <ENTER> to force a prompt redraw. Plus, if I switch to another tty as soon as it's possible, which is what I do on most boots so as to leave init messages on tty1 for the duration of uptime, the extra messages litter it instead. To me it's cosmetically repulsive, not a true blocker.

On a slow laptop, simply booting "init 3" in RC1+ puts over half a 48 row screen of messages following the tty1 login prompt, first "Started LSB...", ending "Reached target Multi-user."

Using 12.3RC2 on a P4 family 15 model 2 stepping 9 2.6GHz booting with 3 on cmdline puts 13 rows of messages (re: network, scheduler, LSB*) on tty1 following login prompt.

Using 12.3RC2 on host gx62b P4 family 15 model 4 stepping 3 3.0GHz booting with 3 on
cmdline puts 24 rows of messages (re: network, scheduler, samba, cups, sound card, LSB*) on tty1
following login prompt.

please attach output of "systemd-analyse plot > boot.svg" on one affected system.

But I doubt we will be able to do more than what is done upstream now.

Created attachment 529312 [details]
output of "systemd-analyse plot > boot.svg" on host gx62b

oops

if you are relying on network login, a dependency is missing (tracked on bnc#803471 )

if you aren't, because you don't have plymouth installed, there is no other dependency to start getty@tty1.service other than waiting for 5s max after all services needed for basic.target are started. 

Plymouth is adding another dependency (waiting for rc-local.service to be done, which is waiting for network.target) but there is no pro to enforce this when plymouth is not installed.

We can't improve this behaviour anymore. Sorry. Closing as FIXED.

Bug 803471 is NA here.

Can't some artificial depends be placed in rc-local.service or elsewhere to ensure long enough wait before getty@tty1.service starts, maybe agetty itself, or getty, or numlock? 

As a sort of workaround, what about a user configurable fixed length wait for tty1, but allowing tty[2-6] availability as soon as everything agetty requires has finished? I rarely log in on tty1 anyway, reserving it for the boot messages until such time as may come that I need more than 5 ttys doing something at once?

You may not want to or be able to fix it any time soon, but that doesn't make it resolved or fixed, much less unfixable. NAICT, Plymouth is not an essential element of the 12.3 init process[1], and so shouldn't be depended upon to provide function or user experience no worse than that of the init system it supplanted. If if won't be fixed while 12.3 remains supported, then leave it open for future attention. Don't indicate to potentially interested parties who might do what you can't or won't by closing as fixed.

http://lists.fedoraproject.org/pipermail/devel/2013-March/179848.html

(In reply to comment #19)
> Bug 803471 is NA here.
> 
> Can't some artificial depends be placed in rc-local.service or elsewhere to
> ensure long enough wait before getty@tty1.service starts, maybe agetty itself,
> or getty, or numlock? 

No, because it is artifical.

> As a sort of workaround, what about a user configurable fixed length wait for
> tty1, but allowing tty[2-6] availability as soon as everything agetty requires
> has finished? I rarely log in on tty1 anyway, reserving it for the boot
> messages until such time as may come that I need more than 5 ttys doing
> something at once?

No, there won't be a configuration for this.

Sorry again, but I'm closing it.

Feel free to open a bug upstream.

This is not fixed. Messages appear as described without installing any unneeded, unwanted non-mandatory packages.

I don't know enough about systemd workings to know if this is or is not exclusive to openSUSE, so won't be touching upstream unless somehow I stumble onto such knowledge. The other distros I've tested clear by default, and have some kind of difference to prevent noclear of tty1 from working reliably.

I don't plan to work on this anymore.

*** Bug 787610 has been marked as a duplicate of this bug. ***

I have this local job: /etc/systemd/system/helloworld.service

[Unit]
Name=Plays a welcome sound when target multi-user is reached
After=multi-user.target
# graphical.target - multi-user.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/usr/local/bin/helloworld

[Install]
WantedBy=multi-user.target


helloworld is a script that plays a sound. Till I hear that sound, I wait, booting has not finished and it is pointless to login. If you place a similar condition on the getty service, it will wait.

IMHO this bug is fixed. I'm booting a 12.3 as well as a 13.1 and both do show a normal agetty on tty1 *after* the boot is complete ... or should I say that the messaghes are not on tty1 but on an other tty ;)