Graphical Ubuntu logo enabled on servers, no more login prompt

[Thierry Carrez]

Binary package hint: plymouth

Testing ubuntu-server 20100112 ISO

The server boot process, on my Intel-powered GPU, now shows a graphical Ubuntu logo. However, that logo doesn't go away at the end of the boot, and no login prompt appears. You have to manually switch VT (Alt-F1) to get to the login prompt.

This is quite confusing, as you end up with the impression that the server hangs during boot.

[stop (whoopwhoop)]

Just confirmed this with the ubuntu server lucid 64 bit Alpha 2 candidate...

[Mathias Gug (mathiaz)]

Marking as triaged. Booting on kvm doesn't show the graphical logo, however the boot process switches to VT7 - with no logging prompt available by default. Switching to VT1 shows a login prompt as mentioned Thierry.

IMO, at the end of the Ubuntu Server boot process, there should be a login prompt.

[Steve Langasek (vorlon)]

Since the current behavior of plymouth is there in response to other bugs, perhaps another solution here would be for the server to provide another upstart job that runs at the end of the boot to chvt over to VT1. I'm not sure if that job should run when plymouth itself stops, or if it should stop plymouth, but that seems a more reliable solution for this problem given that plymouth itself can't assume that chvt 1 is the desired behavior (since we may have gdm taking over at that point).

Whatever package shipped such a job should then Conflicts: gdm, kdm.

[Steve Langasek (vorlon)]

Can the folks affected by this drop the attached job in their /etc/init, and see whether it fixes the issue for you? If so, we can package this up in a 'plymouth-console' package or something that conflicts with x-display-manager, and have it pulled into the server seed.

[Igor Wawrzyniak (igor-tumus)]

Fixed it for me. Thanks

[Thierry Carrez (ttx)]

Works for me as well.

[Joel Ebel (jbebel)]

In case two confirmations wasn't enough, this fixes it for me as well.

[Steve Langasek (vorlon)]

Sorry, according to Scott this fix is wrong; plymouthd is correctly configured to exit on 'stopped rc RUNLEVEL=[2345]', but it's failing to restore the video state on shutdown and do the VT switch. Reverting the previous change.

[Etienne Goyer (etienne-goyer-outlands)]

Is there any good reason to have Plymouth in the Server Edition? It is fairly reasonable to assume that X will not be installed on the large majority of servers, so what's the benefit of installing plymouth in the first place?

[Steve Langasek (vorlon)]

Yes, plymouth is now the standard way for processes to interact with the user at boot time in Ubuntu. I think server users still care about being able to interact with mountall and cryptsetup at boot time.

[Paul Elliott (omahn)]

+1 for comment #9 from Etienne.

Unless Plymouth is absolutely required for the boot process on a server then I don't see what benefits it brings. Feel free to correct me though. I would much rather see every kernel/boot message on a plain text console for my servers. (The opposite applies of course for my desktops!) The old method of removing 'quiet' and 'splash' from the kernel parameters no longer seems to work either making debugging of slow booting machines difficult as nothing is printed to the screen unless an actual error occurs.

[Colin Watson (cjwatson)]

Paul, please refer to the previous comment from Steve. It's more robust in general for the init system to have a single way to interact with users (by which I mean prompt for input, not merely produce output) rather than needing to implement fallback mechanisms in every single package that requires interaction.

[Paul Elliott (omahn)]

Colin, that is fair enough but it seems the level of output is too low for server environments. Is it possible to configure the amount of output with plymouth or would that also require changes to packages?

[saghaulor (saghaulor)]

+1 The plymouth-console.conf worked for me too!

[Scott Evans (vk7hse)]

On both my servers here this has worked... +1 plymouth-console.conf

[Chris Jones (foxmulder881)]

So how come the proposed fix has not worked for me? I tried it several times with no results.

[Chris Jones (foxmulder881)]

Disregards my last comment. I realized I had the attached file set to an attributed executable txt file and not a conf file. Therefore, the system did not seem to pick up the fast the file was there upon boot. Fixed now though, nice work.

[Thierry Carrez (ttx)]

Please see comment 8 above: the fix you are testing is not likely to be the one that will be implemented.

[Patrick Goetz (pgoetz)]

+1 for comment #13. It would be nice to see a running console log of processes being started, even if this is only of psychological benefit.

[Mathieu Mitchell (mat128)]

I agree with #19. We need more verbose in a server environment in case things go wrong.

[Micheal Waltz (ecliptik)]

We're planning to run the server edition in our datacenters with serial console connections, having a way to completely disable any type of graphical boot and display console text only is essential to deploying on enterprise grade hardware.

[Steve Langasek (vorlon)]

Nothing here implies that serial consoles are unsupported or that you aren't able to boot without a graphical splash screen - removing the 'splash' boot option should accomplish the latter, setting the correct 'console' boot option achieves the former.

This bug is strictly about the fact that the splash screen, which is used by default, isn't cleared at the end of the boot sequence.

[Launchpad Janitor (janitor)]

This bug was fixed in the package plymouth - 0.8.0~-13

---------------
plymouth (0.8.0~-13) lucid; urgency=low

  [ Steve Langasek ]
  * Don't attach /proc/cmdline to apport reports, this is already in the
    standard info that gets collected...

  [ Alberto Milone ]
  * ubuntu_logo theme:
    - New logo from Otto Greenslade.
    - Switch off dots starting from the ones on the left instead of
      switching them off all at once.

  [ Scott James Remnant ]
  * Move the Ubuntu logo up as discussed with Otto, this makes the mouse
    cursor appear between the logo and dots and solves the optical illusion
    of the logo being too low. LP: #535014.
  * Don't include message about disk checks, which can come from mountall.
  * Drop the rc script splash functions, we don't want the SysV-rc compat
    stuff messing around with the splash screen - this can be entirely
    managed by Upstart now. LP: #528787, #537262.

  * Plymouth Fix Mega Patch:
    - This hasn't yet been broken up into enough bits to send upstream, and
      doesn't *quite* address all the issues yet, but it's a major step.

    - Rewrite the VT handling, rather than abusing /dev/tty0 keep all VT
      operations on the actual VT (tty7), this avoids issues where we set
      the graphics mode of the wrong VT or put the wrong VT into VT_PROCESS
      mode. LP: #520460, #522598, #526321, #533135
    - Don't attempt VT switch when using non-VT consoles.
    - Make VT mandatory for renderer plugins, so we fallback gracefully to
      text when the console is not a VT. LP: #516825, #527083.
    - Restore VT when finished displaying the splash unless plymouth quit
      is called with --retain-splash. LP: #506297.
    - Activate VT from text and details plugins, rather than haphardly in
      the main code, this means the textual boot is also on VT7.
      LP: #518352, #520122.
    - Add a --has-active-vt command that can let gdm inquire whether it
      should reuse Plymouth's VT; fixes the issue where Plymouth has no
      visible splash screen and X ends up on VT1. LP: #519641, #533572.

    - Don't open terminal device in X11, fixes the issue where X will crash
      when debugging plugins using the X11 renderer.
    - Add --tty option to plymouthd for debugging when X is running and
      thus using an alternate VT.

    - Improve deactivate command so that the terminal is no longer watched
      for keyboard input, session is closed, etc. LP: #528787, #531650.
    - Ignore mode changes while deactivated, otherwise we can end up
      resetting the VT back into text mode while X is starting up.
      LP: #523788, #502509.

    - Fix races with simultaneous quit and deactivate commands, or multiples
      of those commands.
    - Ignore --show-splash, --hide-splash, etc. commands while deactivated.
    - Add reactivate command for testing purposes.

    - Don't scan out drm buffer contents to fbcon when not called with
      quit --retain-splash. LP: #527180.

    - Avoid resetting the terminal to unbuffered mode on every write, this
      results in setting X's VT into raw mode and results in the X server
      crashing on key presses. LP: #532047, #534861, #519460, #520...

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2010-02-12 at 20:13 +0000, Paul Elliott wrote:

> Colin, that is fair enough but it seems the level of output is too low
> for server environments. Is it possible to configure the amount of
> output with plymouth or would that also require changes to packages?
>
The lack of output isn't anything to do with Plymouth; without "splash"
on the command-line Plymouth uses a backend that passes through all
console messages.

We simply don't have many console messages anymore during boot!

Scott
--
Scott James Remnant
<email address hidden>

[Ricardo Duarte (rjtd21)]

This does not look like a good decision on a server installation.
Even without "quiet" and with "--verbose", all the info on screen is still lacking for a server.
I think that it would be much better to show the "Starting web server [OK]" (like on Karmic) than not showing anything at all.
Is it even possible to get this information on any log? /var/log/boot is empty.

[Ricardo Duarte (rjtd21)]

Btw, if I start the scripts on the tty I can see the verbose output.
So, it's not like the scripts don't print the information anymore.
It looks more like upstart/plymouth/other is deliberately hiding this output.

[Thierry Carrez (ttx)]

Ricardo: I think you have a good point, could you please file a separate bug about server boot process verbosity when it comes to init script output ? And subscribe me to it.

[Thierry Carrez (ttx)]

And now I see you did that already, bug 542666 :)

[Norberto Bensa (nbensa)]

who is the genius that came with the superb idea of putting a boot splash on a server edition!?

I'm sorry, but this is ridiculous.

Please, revert the server edition to NOT USE ANY KIND OF GRAPHICAL BOOT.

That, or maybe it is time for me to go back to Debian on servers.

[cdmiller (cdmiller)]

Here is how we got a text only console for Lucid server, and upgrade from Karmic on a VM:

Enable the text console:
http://staff.adams.edu/~cdmiller/posts/Ubuntu-Lucid-server-text-console/

Disable Plymouth:
http://staff.adams.edu/~cdmiller/posts/Ubuntu-Lucid-server-disable-plymouth/

Verbose Upstart for boot messages:
http://staff.adams.edu/~cdmiller/posts/Ubuntu-Lucid-server-upstart/

[Tom Ellis (tellis)]

@cdmillier, try the 'noplymouth' boot option

[cdmiller (cdmiller)]

@Tom Ellis,

Thanks! The 'noplymouth' option worked great with all plymouth upstart scripts back in place. Definitely a more civilized approach. Boot options of:

ro nosplash noplymouth INIT_VERBOSE=yes init=/sbin/init -v

give "nice" output on a VM server text console.

[Christian Kujau (christiank)]

@Maintainers, please reconsider.

I just had a real usecase here where some box just hung and the last message I was seeing came from "plymouth". I booted with
"ro nosplash noplymouth INIT_VERBOSE=yes init=/sbin/init -v", but it still hung. See plymouth-1.png under:

   http://nerdbynature.de/bits/LP-506297/

So I removed plymouth via equivs (control file & installable .deb on URL above) and it turned out it wasn't plymouth-related at all. As a bonus, the screen does not "clear" any more after boot, so I can see all the boot messages (if one had to plugin a display device :))

Again, please tell what plymouth would be good for in a Ubuntu _server_ installation. Last I checked, Ubuntu still supports server installations, does it not? Options:

1) remove plymouth altogether on Ubuntu server (until it does something useful)
2) make plymouth "Recommends", not "Depends"
3) ?

Thanks for listening,
C.