Description of problem: Boot log messages are shown after the login prompt in text mode How reproducible: Mageia-2-beta2-i586-DVD instaled in virtual box 4.1.10 r76836 running on Windows 7 ultimate 64 Bits. Steps to Reproduce: 1. Install with lxde but do not enable automatic X start, LSB and mariadb. 2. Boot 3. See the result: http://dutheil.dyndns-server.com/mageia-2B-01.html Hit enter and the login prompt shows up again.
I don't see why this is a bug, you boot whithout, so you don't after X, or do you want the plymouth splash ?
Keywords: (none) => NEEDINFO
I agree that it's an annoyance. When using run level three, you get the login prompt, and as you are typing in the user name, the remaining messages make it difficult to see what you're doing. However, as the only way I can think of to fix this, is to delay the startup of the getty until after everything else, I'd rather have the annoyance, as the messages can be ignored.
CC: (none) => davidwhodgins
sorry for my very bad sentence :s
I think the point is that whatever is writing to tty1 ought to claim that device until it is finished, in the same way that getty does. That way, getty can start early and just claim tty2 without conflict. Way back when, the startup stuff used to go to tty12 for exactly this reason, to get it out of the way.
CC: (none) => ftg
(In reply to comment #4) > I think the point is that whatever is writing to tty1 ought to claim that > device until it is finished, in the same way that getty does. That way, getty > can start early and just claim tty2 without conflict. Way back when, the > startup stuff used to go to tty12 for exactly this reason, to get it out of the > way. Although it's pretty difficult to test, I'm pretty sure that if you press alt+ctrl+f2 after the login prompt appears on tty1, but before the other messages show up, then those messages will show up on tty2. I.E. whatever the currently active text tty is.
(In reply to comment #5) > (In reply to comment #4) > > I think the point is that whatever is writing to tty1 ought to claim that > > device until it is finished, in the same way that getty does. That way, getty > > can start early and just claim tty2 without conflict. Way back when, the > > startup stuff used to go to tty12 for exactly this reason, to get it out of the > > way. > > Although it's pretty difficult to test, I'm pretty sure that > if you press alt+ctrl+f2 after the login prompt appears on > tty1, but before the other messages show up, then those messages > will show up on tty2. I.E. whatever the currently active > text tty is. You are right. Tested with alt+ctrl+f12 and some more messages were shown: See result: http://dutheil.dyndns-server.com/mageia-2B-01.html tty1 login remains clean.
The correct link is http://dutheil.dyndns-server.com/mageia-2B-02.html
Reviewing the last image I just found that the messages are mixed portuguese and english. Install was done choosing brazilian portuguese language.
The mixed language is a different issue, for the messages of some programs there is no Brazilian Portuguese translation available, so they are given in English. Reading the comments about the cause of the messages at the login prompt, the solution that will give more delay and the good workaround, I think this bug should be closed as WONTFIX Do you agree?
Keywords: NEEDINFO => (none)CC: (none) => marja11
(In reply to comment #9) > I think this bug should be closed as WONTFIX > Do you agree? No. Login prompt on tty1 should be delayed until init process is done writing there.
CC: (none) => mrmazda
We don't have a maintainer for the package, so cc'ing two committers.
CC: (none) => mageia, tmbSource RPM: (none) => initscripts
(In reply to comment #10) > (In reply to comment #9) > > I think this bug should be closed as WONTFIX > > > Do you agree? > > No. Login prompt on tty1 should be delayed until init process is done writing > there. I strongly disagree.
(In reply to comment #12) > (In reply to comment #10) > > (In reply to comment #9) > > > I think this bug should be closed as WONTFIX > > > > > Do you agree? > > > > No. Login prompt on tty1 should be delayed until init process is done writing > > there. > > I strongly disagree. Is initscripts the correct package, btw? If it should be systemd or sysvinit or even something else, please change it.
It should really be systemd. Corrected that. FWIW, I'm now somewhat split regarding this issue. Part of me would like a login prompt ASAP and thus delaying until after all default target jobs are complete would be in many ways unnecessary (we currently delay them until a specific service (systemd-user-sessions) is ready, thus ensuring that e.g. NSS is available for remote user lookup, NFS mounts are available for $HOME etc. but there is typically no real reason to wait for e.g. httpd to finish starting before logging in. However, on reflection, I'm actually not that bothered about tty login availability speed. Sure it's "nice", but it's certainly not a requirement per-se. Arguably it's also a nice indicator to know that when the TTY is ready, the system has finished booting. Obviously this does NOT apply to graphical logins which should be shown as soon as possible. Here perceived speed really does matter. Anyway, upstream have now added support for "idle" units are are using them for getty's which solve this problem: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f2b6878955b1f77ea1fa87b502b13d5dbefc57f6 I see no specific reason not to follow that and sysadmins are welcome to create their own getty@.service file and place it in /etc/systemd/system if they prefer a different approach (e.g. adding "ExecStartPre=-/bin/kill -53 1" to the current getty@.target should tell systemd to stop outputting status messages to the console and thus prevent leakage over the login prompts). So there are fixes for both problems. I prefer to take the upstream approach whenever necessary, but I'm not sure I'll be able to backport it easily due to upstream tree changes and without pulling in a lot of other commits that I'd rather not have to test etc. at this stage in the game. So I think the kill approach is maybe the better one for mga2 with a transition to whatever upstream provides later. As sysadmins will ultimately have control, I think this is the most sensible compromise. Does everyone agree?
Source RPM: initscripts => systemd
(In reply to comment #14) > Does everyone agree? Sounds like a reasonable way to go.
CC: (none) => sander.lepik
In that case can someone affected please try adding: ExecStartPre=-/bin/kill -55 1 to their: /lib/systemd/system/getty@.service file and rebooting to see if the problem is solved? Cheers
I've tested with the kill, and it works. Looks like a good approach to me.
OK, I've added this fix to the latest systemd package.
Status: NEW => RESOLVEDResolution: (none) => FIXED