startup messages continue on screen after first login prompt appears

As you can see from line "a" above, the login prompt actually is displayed, however it is displayed before the initscripts are run. If you press enter, the login prompt should reappear.

I am experiencing the same problems with Feisty (Server edition).

I tried changing the setting "DELAYLOGIN" in /etc/default/rcS but it has no effect. Is this an upstart bug for not adhering to this setting?

I confirm this bug on a custom Feisty desktop installation from alternate CD.

Assigning to upstart.

Occurs because the getty is started at the beginning of rc2 rather than the end; easy fix would be to start the getty at the end of the runlevel (after the script is finished) or to fix the messaging in the first place

Boot messages dicussion scheduled (again) for UDS

a guy named steve made the following comment about our server distro on slashdot :

"A boot screen that doesn't look like vomited output. Why does the
login prompt appear before services have finished loading? I support
being able to use the machine before services have stopped. I do not
need "Starting PostgreSQL" appearing as I'm entering my login
credentials locally."

I know this is cosmetic, but it seems to be really annoying some people.

Perhaps not just annoying, but confusing as well.

We have received feedback from users who were confused there was no login prompt. Pressing <ENTER> will display a prompt, but it is seemingly non-intuitive to new users.

And then there is the argument that other dists don't have this "problem".

Still present in Ubuntu Server 7.10 - no GUI installed here.

It is *quite* annoying, not worth throwing the toys out of the pram for though.

Does anyone have a workaround for this? Other than inserting -q into rc2: "exec /etc/init.d/rc -q 2"

Ideally one that allows the info to be captured to a log. I've tried "console none" and "console logged" in rc2 but they didn't seem to have any effect.

My not elegant solution was the creation of a script named /etc/init.d/restart-tty1 with the following content:

#!/bin/sh

stop tty1
clear
start tty1 > /dev/null

And, then, a symbolic link to it at /etc/rc2.d named S99zrestart-tty1. I have chosen the prefix S99z to be sure that it will be the last script to be called.

Thanks Jakson... incidentally my workaround of adding "-q" after rc does NOT work. Some or all of the scripts in /etc/rc2.d did not get executed when I did that. Then Gnome started complaining that it failed to initialize HAL and such.

Here's a workaround that's a bit more upstartish, I think.

* In /etc/event.d/tty1, comment out "start on runlevel 2".

* Then change /etc/event.d/rc2 as follows, removing the first "exec" and adding the line that says "exec start tty1":

 /etc/init.d/rc 2
        exec start tty1
end script

Thanks, Joshua! Your workaround worked flawlessly here.

Joshua, sadly your solution does not work for me: I mean, getty is not started at the BEGINNING of runlevel 2, but neither at the end, even with "exec start tty1" in /etc/init.d/rc (I really don't know why). However, I found a better solution: since upstart is event-based, you simply need to tell it to start getty when runlevel 2 has finished loading.

To accomplish this task, edit /etc/event.d/tty1 and replace:

  start on runlevel 2

with:

  start on stopped rc2

With trivial modifications, it also works for runlevels other than 2 and for tty's other than 1. Note that those modifications should SOLVE the bug and should't be a workaround.

Cheers!

I like your solution Dario (I have not tested it yet). However, I'm not sure it should be considered a fix. Before applying this workaround, tty1 was being started earlier. We were forced to delay tty1, and therefore the appearance of the login prompt, due to rc2's output messages. But if the logger were working, we could instruct rc2 to output its messages to the logger only and not to the console. tty1 could be started at the same time as rc2.

We have lengthened the time to the appearance of the prompt, when a proper solution (a working logger) would not require that sacrifice.

This seems to affect the (still alpha) version of Hardy.
The "fix" you propose still works though.

Suggest consideration of the order you actually want the events to happen.
Is it a good idea to allow users to login before the standard daemons have been started?

I think the most appropriate solution is to delay tt1 only.
This way the boot messages will be displayed in a proper fashion:
- Boot messages
- (All daemons started)
- Show the login prompt

Login via ssh is not affected in any way, and most probably this is how system admins will login to a headless server, so the cosmetic change will only be a change for the better.
In my particular case (I'm building virtual appliances), the cosmetic change makes all the difference in the world in the eyes of my clients (having a tidy login prompt looks more "professional").

I believe the change should be what Dario Berzano suggested:

In /etc/event.d/tty1:
Replace
"start on runlevel 2"
with
"start on stopped rc2"

I think it actually SOLVES the bug, not just works around it: it's the proper way to make sure an upsart daemon starts on the end of rc2.
I really hope this will make it into hardy.

- Trib'

Here is a patch file that takes care of the change.

- Trib'

Raising the priority so that we put some attention to it.

@ Trib' and others:

I'm running Ubuntu server edition 7.10. I was having this problem and found this site. I downloaded and applied the patch (and checked tty1 to make sure it was applied correctly), and it's not working for me. Instead, it's now impossible to login using a keyboard. (Fortunately, SSH still works.)

Here's what happens for me:
First of all, I still see a prompt that says "mutedroar login: " up before a lot of the services start. When they're done, I see the same prompt, repeated. Here's a sample of what happens:

mutedroar login: [my user name]
Password:
[first letter of my password]
Login incorrect
mutedroar login: [my user name]
Password: [first letter of my user name; shows up along with the prompt, before I actually type my password]

Login incorrect
mutedroar login:

...and so on and so forth. Sometimes it does weird things where it will give me another login prompt immediately following the first (rather than a password prompt), and this second prompt will be tabbed over on the screen. It will sometimes echo my password after I type it in. Sometimes I get the normal login messages and a user prompt, but when I try to type anything (e.g. ls), it immediately prompts me to login in again. It's all rather frustrating, and I can only gain access using SSH from another computer. (That works the same as always.) Any ideas on why this patch isn't working?

Could you please attach the output of "cat /etc/event.d/tty1"?
There should be no reason why it wouldn't work after applying my patch :(

Did you try making the changes by hand instead of using my patch?

- Trib'

Whew, after some very puzzling results I finally figured out what the problem was.

When I ran the patch, I included the -b option to create a backup of the original file; I had never used patch before, so I wanted to make sure I could get the original back in case I messed things up somehow. This created a file called tty1.orig in /etc/event.d, along with the patched version of tty1. After much fun and games, I finally figured out something that you guys probably already know: the computer was reading anything that started with "tty1", regardless of its ending. (I realized this after I accidentally applied the patch to an already-patched version of tty1 and it created a file called tty1.rej, consisting of the parts it couldn't insert; on the next boot I saw an error message about not being able to interpret tty1.rej.)

So once I renamed my backup version of tty1 to something else that didn't start with tty1, and deleted tty1.rej, the patched version worked flawlessly. The bootup looks good, and the login doesn't appear until after all the scripts are run. Thanks for coming up with this patch!

Actually,

I just got through installing 7.04 server ppc version, I can confirm that
this behaviour exists
within the ppc version.

However, I did not install X or any components thereof.

Michael

On Feb 19, 2008 1:26 PM, Nick Barcet <email address hidden> wrote:

> ** Changed in: upstart (Ubuntu)
> Assignee: (unassigned) => Ubuntu Server Team (ubuntu-server)
>
> --
> startup messages continue on screen after first login prompt appears
> https://bugs.launchpad.net/bugs/65230
> You received this bug notification because you are a member of Ubuntu
> Server Team, which is a direct subscriber.
>
> Status in Source Package "upstart" in Ubuntu: Triaged
>
> Bug description:
> To reproduce:
> 1-install type "server"
> 2-boot new installation
> 3-reconfigure /boot/grub/menu.lst with a vga=0x122 or vga=0x314 on kernel
> line
> 4-install an X desktop and its deps (I do kubuntu-desktop)
> 5-apt-get remove usplash, or set up to boot using an alternate boot loader
> (I use SUSE's grub), or otherwise reconfigure so that init has no splash and
> all normal init messages display in text big enough to see and read on tty1
> 6-reboot
> 7-Ctrl-Alt-F1
>
> Actual results:
> 1-normal init messages display on tty1
> 2-video switches from native text mode to text emulated graphics mode (as
> installer uses)
> 3-login prompt appears
> 4-init messages continue:
> a-ubuntu login: * Starting system log...
> b-* Starting kernel log...
> c-* Starting Common Unix Printing System: cupsd
>
> Expected results:
> 1-normal init messages display on tty1
> 2-login prompt appears
> 3-nothing more appears on tty1 until logging in
> 4-video stays in native text mode
>
> This is edgy network installation on old ATI video card.
>

@ faulkes:

Same here as well. I installed 7.10 server edition, and selected the LAMP and Samba options, but never installed a GUI. Still, I had this bug from the first boot.

Is this not a feature and not a bug?

http://upstart.ubuntu.com/

System-V init was sequential and if one of the scripts got stuck, you
never got to a login.

There are some race conditions such as ntp and networking.

At least you have a chance of fixing a problem instead of rebooting
into single user.

Jim Tarvid

On 2/19/08, peppergrower <email address hidden> wrote:
> @ faulkes:
>
> Same here as well. I installed 7.10 server edition, and selected the
> LAMP and Samba options, but never installed a GUI. Still, I had this
> bug from the first boot.
>
> --
> startup messages continue on screen after first login prompt appears
> https://bugs.launchpad.net/bugs/65230
> You received this bug notification because you are a member of Ubuntu
> Server Team, which is a direct subscriber.
>

See the attachment for why the implementation, at least, is a bug.

Look at the top of that screen dump. When you look at the actual screen after bootup, the login up top is just barely still on the screen. It shows up and the system doesn't even pause--it keeps plowing on through the other scripts. (Notice that MySQL even has its output on the same line.) The cursor ends up at the far right edge of the screen (to the right of the last [OK]). It's rather odd, and definitely confusing for an inexperienced Linux user. I daresay that it's not what an experienced user expects either. And if I had just one more script running starting up, there wouldn't even be a buried login on the screen. If you want a login available earlier, then there has to be a better way to do it.

On Tue, Feb 19, 2008 at 9:46 PM, peppergrower <email address hidden> wrote:
> If you want a login available earlier, then there has to be a
> better way to do it.

You can swap over to tty2+ and get a login there.

Perhaps it should avoid printing the login prompt on *tty1* until all
init scripts have finished, but go ahead and display them on the rest
of the tty's as soon as login is ready.

:-Dustin

As a server owner, I want a login as soon as the system is capable of
handling my requests. In fact, I would like a BIOS that would give me
"busybox" like access on a crashed machine.

Think of the bad days and what it takes to make them less bad.

Jim

On 2/20/08, Dustin Kirkland <email address hidden> wrote:
> On Tue, Feb 19, 2008 at 9:46 PM, peppergrower <email address hidden> wrote:
> > If you want a login available earlier, then there has to be a
> > better way to do it.
>
>
> You can swap over to tty2+ and get a login there.
>
> Perhaps it should avoid printing the login prompt on *tty1* until all
> init scripts have finished, but go ahead and display them on the rest
> of the tty's as soon as login is ready.
>
>
>
> :-Dustin
>
>
> --
> startup messages continue on screen after first login prompt appears
> https://bugs.launchpad.net/bugs/65230
> You received this bug notification because you are a member of Ubuntu
> Server Team, which is a direct subscriber.
>

Like Dustin said, you can always switch to tty2 to fix stuff to make bad days more bearable...
And tty1 can be "pretty" for thoses of us who package appliances.

Best of both worlds?

Hi, just wanted to still confirm this for the daily build of Hardy, pr 15. march 2008. The attached patch fix the problem

Petter

Scott, do you have any comments on the proposed fix for this bug? It seems to me like a straightforward solution to defer starting the getty on tty1 until after the rest of rc2 has finished. Perhaps the proposed patch isn't future-proof against other services being migrated to use upstart events instead of sysv init scripts (?), but that doesn't seem to me like a reason to avoid a partial fix that could get us through hardy.

Sounds reasonable

This bug was fixed in the package upstart - 0.3.9-2

---------------
upstart (0.3.9-2) hardy; urgency=low

  * Start the getty on tty1 after the rc script has stopped rather then
    at the same time it starts to avoid overwriting by console messages.
    tty2..6 will still be active if you want an early login. LP: #65230.
  * If the recovery menu is available start that instead of sulogin when
    entering single-user-mode.

 -- Scott James Remnant <email address hidden> Fri, 11 Apr 2008 13:38:50 +0100

The login prompt being held until last on tty1 has been very nice,
Scott, thanks.

However, I have occasionally seen the following, where a seemingly
delayed SSH message pops up:
myhostname login: * Reloading OpenBSD Secure Shell server's configuration sshd

Ideas?

:-Dustin

Something reloaded SSH? :)

This will always pop up over your active console until we completely redo the way we do such messages.

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Jim

Jim Tarvid
Internet Engineer at LSNet
Johnson City, Tennessee Area

Confirm that you know Jim Tarvid
https://www.linkedin.com/e/-8tyzhs-goaoxml7-3y/isd/3040027673/YxtpbwbD/

--
(c) 2011, LinkedIn Corporation