Ubuntu
plymouth package

[details.so] No prompt for [S]kip or [M]anual recovery on server boot (or without "splash")

Bug #563916 reported by Thierry Carrez
174
This bug affects 29 people
Affects Status Importance Assigned to Milestone
Plymouth
Unknown
Medium
Release Notes for Ubuntu
Fix Released
High
Unassigned
plymouth (Ubuntu)
Fix Released
High
Colin Watson
Ubuntu ubuntu-10.10
Lucid
Fix Released
High
Colin Watson
Ubuntu ubuntu-10.04.2
Maverick
Fix Released
High
Colin Watson
Ubuntu ubuntu-10.10

Bug Description

Stable release update justification:

Impact: Mount failures of any kind on server installations (i.e. with the plymouth 'details' plugin) hang the boot process rather than producing a visible prompt. This is serious - you have no idea what's going on and no obvious way to fix it.
Development branch: plymouth 0.8.2-2ubuntu4 implemented the display_message method in the details plugin, fixing this.
Patch: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/563916/+attachment/1742442/+files/plymouth_0.8.2-2ubuntu2.2.debdiff
TEST CASE: Install an Ubuntu 10.04 server. Edit /etc/fstab to cause a mount to fail (a good way is to mount a nonexistent device, or you could deliberately break a filesystem in some way). When you next boot, you should see messages from mountall rather than silent inactivity.
Regression potential: Obviously test that normal boots still work. Desktop installations shouldn't have been changed by this, but I think it would be a good idea to double-check that.

Original report follows:

Binary package hint: mountall

On 10.04 servers, as of beta2, when for any reason mountall fails to mount some partition (for example because you created a snapshot on a LVM volume as in bug 563902), the boot will hang without a prompt for [s]kipping or [m]anually fix the situation. However pressing M or S still works...

See original description
Revision history for this message
Thierry Carrez (ttx) wrote :

As a sidenote, the prompt for passwords in encrypted partitions works perfectly.

Thierry Carrez (ttx)
Changed in mountall (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

Well, this happens because all the logic for displaying those hints is in the ubuntu-logo / ubuntu-text themes, but the decision was made to boot without 'splash' on Server, so instead we're using the 'details' splash plugin which doesn't handle these messages. Reassigning to plymouth; I don't see any way for this to be resolved before release, unless you think we should revisit the decision to not use 'splash' on server.

affects: mountall (Ubuntu Lucid) → plymouth (Ubuntu Lucid)
summary: - [lucid] No prompt for [S]kip or [M]anual recovery on server boot
+ [details.so] No prompt for [S]kip or [M]anual recovery on server boot
Revision history for this message
Thierry Carrez (ttx) wrote : Re: [details.so] No prompt for [S]kip or [M]anual recovery on server boot

I wouldn't revisit the "splash" decision now over this missing prompt (especially since the keys still work). We should releasenote it if it can't be fixed before release.

We should also document the boot experience somewhere (if not already available), since hidden tricks are everywhere:

 * shift to get to grub2
 * add "splash" if you want the logo back
 * remove "quiet" if you like kernel messages
 * alt-f7 to see messages after boot

and now:
 * M/S to manualfix/skip in case the boot appears stuck after fsck

Till Ulen (tillulen)
Changed in plymouth:
status: New → Invalid
affects: plymouth → ubuntu-release-notes
Changed in ubuntu-release-notes:
status: Invalid → New
Steve Langasek (vorlon)
Changed in ubuntu-release-notes:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Alvin (alvind) wrote :

It's not only the prompt about the [S]kip and [M] that is missing, but also the information about what filesystem can not be mounted.

Revision history for this message
Steve Langasek (vorlon) wrote :

> * shift to get to grub2

Documented now at <https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#No%20delay%20for%20boot%20menu%20with%20GRUB%202>:

   When using the GRUB 2 bootloader included in Ubuntu 10.04 LTS, the first boot option will by default be loaded automatically without pausing for user input. To interrupt the boot, users can hold down the Shift key to bring up the boot menu, allowing them to select a different boot option or to configure kernel arguments. (https://help.ubuntu.com/community/Grub2#GRUB%20vs%20GRUB%202)

> * add "splash" if you want the logo back
> * remove "quiet" if you like kernel messages
> * alt-f7 to see messages after boot

Do you think these need to be listed in the release notes, or just in some sort of documentation of the boot experience (possibly linked /from/ the release notes)?

Revision history for this message
Thierry Carrez (ttx) wrote :

I think the alt-F7 trick definitely needs to go to the release notes... as it's a change in default behavior (people used to have them above the login prompt). I'm not sure if the kernel messages were flowing in karmic, but if they did we need to document that as well... For "splash" no need to document it in the release notes. If we do a generic boot experience/debug page, that could go there.

Revision history for this message
Thierry Carrez (ttx) wrote :

No kernel message flow in karmic, so only alt-F7 would need to be added to release notes.

Philip Muškovac (yofel)
tags: added: lucid
Revision history for this message
Steve Langasek (vorlon) wrote :

Documented at <https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Changes%20in%20boot-time%20output%20on%20Ubuntu%20Server>:

 With the introduction of plymouth, boot-time messages from startup scripts are no longer displayed above the login prompt on tty1. Instead, they are all output to tty7 and on Ubuntu Server, can be viewed after boot by pressing Alt+F7. On all systems the boot output can also be found in /var/log/boot.log.

 On new installs of Ubuntu 10.04 LTS Server, no boot splash screen is shown by default. While this provides server administrators with more immediate feedback about their system while booting, it also prevents prompts from reaching the user in the event of filesystem mounting failures. Users can add the splash option to /etc/default/grub if they prefer to always see the splash screen.Hotkeys for interacting with mountall will still work without the splash screen, but are not discoverable: C to cancel a running fsck; M to request a maintenance shell; S to skip an unavailable mount; and F to try to fix errors found by a fsck. (563916)

Changed in ubuntu-release-notes:
status: Triaged → Fix Released
Revision history for this message
Ian! D. Allen (idallen) wrote :

Ubuntu 10.04 LTS - Server x86-64

The system failed to boot. It was apparently hung and sitting on tty7
with the only messages on the tty7 screen being (approximately):

    fsck ...
    fsck ...
    /dev/md2: clean
    boot: clean
    init: ureadahead-other main process terminated with status 4

Though text boot messages had scrolled by during the boot, none of those
other consoles had any messages left when the screen switched to tty7
and the above few lines appeared. The keyboard didn't do anything useful.

ALT-SYSRQ and "E" killed the "plymouth" task but didn't bring up the system.
CTRL-ALT-DEL rebooted right back into the hung state.

Lots of Google work eventually led me to this bug (with a false start
directing me to the ureadahead bugs before coming here).

Some hints from other bugs suggested something was not mounting in
/etc/fstab and that was the cause of this unresponsive server hang.

I booted a live desktop CD, installed mdadm, assembled my RAID1 devices,
mounted my root, edited /etc/fstab to comment out a misbehaving DRBD
partition mount, unmounted, and rebooted successfully with no hang.

I'm inexperienced with Ubuntu Server releases. I find it hard to believe
that a misbehaving mount of a non-essential, auxilliary file system would
completely prevent the system from booting, but this is what is happening.

Steve's updated release notes (#8, above) suggest that "mountall" is
actually invisibly prompting me about what to do about the unavailable
mount in /etc/fstab, but I don't want any prompts at all (and neither
/usr/share/doc/mountall/ nor the mountall man page is unhelpful in telling
me how to change its unwanted interactive behaviour so as not to prompt).

How do I stop the interactive prompting, or at least limit the prompting
wait to a few tens of seconds before continuing with the boot?

I do not want the system to hang forever on an (invisible) prompt such
that I have to make a house call to the server to answer the (invisible)
question so that the system can boot and I can then go home and remote
login and fix the broken mount. Scott, Steve - where is the documentation
that tells me how to turn off the prompting so that my server *always*
tries to boot no matter what is wrong with /etc/fstab?

Revision history for this message
Erik Reuter (misc71) wrote :

A related bug is #571444.

https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/571444

I agree that it is totally unacceptable that a server distribution should stop with an invisible prompt just because an entry in /etc/fstab is not able to be mounted.

After a couple months, I do not understand why there seems to be no one assigned to fixing this bug or #571444.

Revision history for this message
In , Freedesktop-bugs-malc (freedesktop-bugs-malc) wrote :

Created an attachment (id=36984)
patch

The 'details' splash plugin (which Plymouth will fall back to in various situations, e.g. on a serial console) does not have a display_message function, and so any message display requests will be silently ignored.

On Ubuntu, messages sometimes include instructions on what key to press to continue boot (e.g. after filesystem mount failure); using the details splash plugin, these instructions are never displayed and the boot process simply appears to hang.

I attach a patch which adds support for message display to the 'details' plugin.

Revision history for this message
Malcolm Scott (malcscott) wrote : Re: [details.so] No prompt for [S]kip or [M]anual recovery on server boot

This bug arises because the 'details' plymouth splash plugin, which plymouth falls back to by default, is missing a display_message function -- plymouth tries to display the prompt informing the user about the filesystem mount problem but the message is silently discarded in the absence of this function.

This was also affecting any system using a 'console=...' kernel parameter, as plymouth falls back to the 'details' theme in this case (and probably in others too).

A patch to add the missing function is attached. I will publish fixed packages in a PPA shortly (I have verified that they fix the problem in the serial console case, in a Xen VM). I also reported this bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=29035

Revision history for this message
Malcolm Scott (malcscott) wrote :

My fixed plymouth packages are in a PPA at

   https://launchpad.net/~malcscott/+archive/plymouth/+packages

(currently queued for building -- give it an hour or so before attempting to use).

Revision history for this message
In , Rstrode (rstrode) wrote :

What is the keys: stuff about?

Revision history for this message
In , Freedesktop-bugs-malc (freedesktop-bugs-malc) wrote :

Ubuntu prepends "keys:" to messages which prompt the user with a list of possible keystrokes required to continue, so the graphical themes can display the message differently. The "keys:" tag itself is not intended to be displayed. I copied this behaviour from one of the Ubuntu themes.

If this behaviour is nonstandard, feel free to drop this part of the patch; Ubuntu can presumably re-add it locally.

Brian Murray (brian-murray)
tags: added: patch
David Stansby (dstansby-deactivatedaccount)
tags: added: patch-forwarded-upstream
removed: patch
Robbie Williamson (robbiew)
Changed in plymouth (Ubuntu Lucid):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Revision history for this message
Thierry Carrez (ttx) wrote : Re: [details.so] No prompt for [S]kip or [M]anual recovery on server boot

Would be great to have in 10.04.1 before we enable LTS to LTS release, feel free to unmilestone

Changed in plymouth (Ubuntu Lucid):
milestone: none → ubuntu-10.04.1
Revision history for this message
In , Colin Watson (cjwatson) wrote :

Scott pointed out that this code should probably use 'sizeof ("keys:") - 1' rather than 'strlen (keys)'.

Revision history for this message
In , Rstrode (rstrode) wrote :

So one bit I'm a little worried about is this part:

+ if (plugin->state != PLY_BOOT_SPLASH_DISPLAY_NORMAL)
+ display_normal (plugin);

That suggests we're going to move the details plugin out of "ask the user for a password" mode if we decide to print a message, even if the user hasn't answered the question yet.

In practice, this may work for the details plugin since it doesn't do a lot when switching modes (not sure), but I think it doesn't read well.

Colin Watson (cjwatson)
Changed in plymouth (Ubuntu Lucid):
milestone: ubuntu-10.04.1 → ubuntu-10.04.2
Thierry Carrez (ttx)
Changed in plymouth (Ubuntu Maverick):
milestone: none → ubuntu-10.10-beta
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Revision history for this message
Marius Gedminas (mgedmin) wrote : Re: [details.so] No prompt for [S]kip or [M]anual recovery on server boot

Incidentally, if Ctrl+C (in addition to just C) were to be accepted for cancelling a running fsck, that would be discoverable.

Revision history for this message
Colin Watson (cjwatson) wrote :

Malcolm, could you answer Ray Strode's question on the upstream bug, please?

"So one bit I'm a little worried about is this part:

+ if (plugin->state != PLY_BOOT_SPLASH_DISPLAY_NORMAL)
+ display_normal (plugin);

That suggests we're going to move the details plugin out of "ask the user for a
password" mode if we decide to print a message, even if the user hasn't
answered the question yet.

In practice, this may work for the details plugin since it doesn't do a lot
when switching modes (not sure), but I think it doesn't read well."

Revision history for this message
Bill Turner, wb4alm (wb4alm) wrote :

Recently, my system was upgraded "accidently" to Ubuntu 10.04 LTS. (I was unprepared to do the upgrade from 8.04LTS (had not finished my research), and I accidently pressed the upgrade button in error. By the time I realized what was happening, it was too late - and so had to finish the upgrade process.)

When the 10.04 LTS system finally restarted, it "hung" during the reboot.

In trying to discover what was going on, I pressed CTRL-C, thinking that at worst something would stop.
Nothing happened. I started to press CTRL-C again and hit the "F" key instead.

That is when I discovered that fsck had detected a filesystem error, and that I had just told it to "FIX" an unknown problem because a hidden prompt was waiting for input!

This is NOT a good way to do things...

(By the way, while I have only been using Linux for a couple of years, I have been in I.T. for over 45 years.)

Daniel Hahler (blueyed)
summary: [details.so] No prompt for [S]kip or [M]anual recovery on server boot
+ (or without "splash")
Thierry Carrez (ttx)
tags: added: server-mrs
Thierry Carrez (ttx)
tags: added: server-mro
removed: server-mrs
Colin Watson (cjwatson)
Changed in plymouth (Ubuntu Maverick):
milestone: ubuntu-10.10-beta → ubuntu-10.10
Revision history for this message
In , Colin Watson (cjwatson) wrote :

It looks to me as though it would work, but be confusing; you'd have a password prompt some distance up the screen with messages below it, and it wouldn't be obvious that the system was waiting for password entry. (Not to mention that, in Ubuntu's case, the message can be from mountall indicating that you're supposed to press one of certain keys to respond to fsck failures and the like, and plymouth won't pull keystroke triggers until the password entry is finished anyway!)

So, would the best approach be to queue up the messages until display_normal is called, and then display them all at once?

Revision history for this message
In , Ray Strode (halfline) wrote :

I think that's reasonable. Any time a message comes while the user is being asked for a password, hold off until the user answers before showing the message.

Note, we already keep a list of messages in main.c. Maybe we just need to "replay the list".

It does suggest we need a way to drain the list, too, but that's probably something that can be handled separately as demand arises.

Revision history for this message
In , Colin Watson (cjwatson) wrote :

Created an attachment (id=38522)
queue messages if necessary

This implements a local queue in details, pending work on a longer-term solution with decent lifetime support for messages (as discussed on IRC).

Revision history for this message
In , Colin Watson (cjwatson) wrote :

Created an attachment (id=38524)
this time without the special-case keys: hack

Revision history for this message
In , Rstrode (rstrode) wrote :

Thanks, pushed:

http://cgit.freedesktop.org/plymouth/commit/?id=e61e740e649bef341928b7b34e7950ecdb6c7126

One issue we may hit is distros may have been relying on details not displaying a message before. E.g., if they were doing a message

"Press escape to go to details mode"

It would look weird to see that message if the user is already in details mode. We may have to add some way to provide context to messages if that ends up being an issue.

Colin Watson (cjwatson)
Changed in plymouth (Ubuntu Maverick):
assignee: Canonical Foundations Team (canonical-foundations) → Colin Watson (cjwatson)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package plymouth - 0.8.2-2ubuntu4

---------------
plymouth (0.8.2-2ubuntu4) maverick; urgency=low

  * src/plugins/splash/details/plugin.c: Implement display_message, either
    by displaying it immediately or by queueing it for later display in the
    event that we're already waiting for user input (LP: #563916).
 -- Colin Watson <email address hidden> Wed, 08 Sep 2010 01:20:35 +0100

Changed in plymouth (Ubuntu Maverick):
status: Confirmed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in plymouth:
importance: Unknown → Medium
status: Unknown → Fix Released
Colin Watson (cjwatson)
Changed in plymouth (Ubuntu Lucid):
assignee: Canonical Foundations Team (canonical-foundations) → Colin Watson (cjwatson)
Revision history for this message
Colin Watson (cjwatson) wrote :

The patch for lucid as generated by debdiff unfortunately ends up being rather verbose, because the existing packages uses the 3.0 (quilt) source format with all the changes in a single patch, and the order of the files in the patch does not appear to be well-defined so they change around and generate enormous debdiffs. I don't think it would be a good idea to attempt to change the packaging in lucid. It comes out more readable if you unpack the packages before and after and run 'diff -ru old new | filterdiff -x \*/debian-changes'; I've attached the result of doing so.

Colin Watson (cjwatson)
description: updated
Changed in plymouth (Ubuntu Lucid):
status: Confirmed → In Progress
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted plymouth into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in plymouth (Ubuntu Lucid):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote :

Any testers of the lucid-proposed package? As this has been in -proposed for nearly three months, I'll remove the proposed package soon if there is no feedback. Thank you!

Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

Verified that there is now a prompt to press M/S in 10.04.1 Server Edition, using a fresh installation in VirtualBox, fully updated before enabling proposed.

tags: added: verification-done
removed: verification-needed
Bug Watch Updater (bug-watch-updater)
Changed in plymouth:
importance: Medium → Unknown
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package plymouth - 0.8.2-2ubuntu2.2

---------------
plymouth (0.8.2-2ubuntu2.2) lucid-proposed; urgency=low

  * src/plugins/splash/details/plugin.c: Implement display_message, either
    by displaying it immediately or by queueing it for later display in the
    event that we're already waiting for user input (LP: #563916).
 -- Colin Watson <email address hidden> Tue, 23 Nov 2010 11:05:04 +0000

Changed in plymouth (Ubuntu Lucid):
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in plymouth:
importance: Unknown → Medium
Revision history for this message
In , Rstrode (rstrode) wrote :

So i'm tempted to revert this (see below conversation about a system update utility that's using plymouth). We could add a --mode argument to show-message and complicate the plugins more, but probably easier to just fix the caller in comment 0 to write to /dev/console instead?

╍╍╍╍╍╍╍╍╍✂╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍

<halfline> plymouth doesn't show the journal on escape
[15:58:58] <halfline> it just shows /dev/console
[15:59:05] <wwoods> halfline: ideally, they'd see the stdout (i.e. we'd be using journal+console) and not the show-message calls
[15:59:28] <wwoods> right now IIUC they get the show-message calls and nothing else
[15:59:51] <halfline> well if that's the behavior you want, we need to fix plymouth
[16:00:18] <halfline> or you'll end up with duplicated messages
[16:00:44] <wwoods> heh. well, yeah, but I can't dictate what other people are doing with plymouth, so I don't know if that behavior would mess up other stuff
[16:01:01] <halfline> meh
[16:01:19] <halfline> can't be afraid to make fixes
[16:01:26] <wwoods> still, the behavior *I* would expect would be that hitting Esc shows you whatever was on the console, and that display-message is only shown on the graphical splash(es)
[16:01:49] <wwoods> halfline: heh - well gosh, if the maintainer(s) think that's a good idea, I'm all for it
[16:03:04] <wwoods> halfline: looks like your second patch would implement that behavior - i.e. normal display-message messages are ignored by the details view?
[16:03:55] <halfline> yea i think so
[16:05:40] <wwoods> heh if there are types other than PLY_BOOT_SPLASH_DISPLAY_NORMAL, the user could specify, like, "display-message --text="$text" --show-on-all" or something, and there'd be a different message type which *would* get displayed in the details view
[16:06:18] <wwoods> but I don't know if that's a use case anyone cares about
[16:06:27] <halfline> actually that patch isn't quite right anyway, if the mode isn't display_normal we queue the messages until the next time the mode is display_normal
[16:06:46] <halfline> see also https://bugs.freedesktop.org/show_bug.cgi?id=29035
[16:07:17] <wwoods> heh, I figured that this would be one of those bugs where there are arguments for both behaviors
[16:07:31] <halfline> my comment 9 is pretty awesome
[16:07:53] <wwoods> prescient!
[16:09:58] <halfline> nothing is ever simple
[16:15:56] <halfline> i'm kind of tempted to just revert the patch and tell them to send their message to /dev/console too
[16:17:33] <wwoods> I mean... it kind of makes sense that the "details" view just shows what was printed to the console, and "display-message" messages are out-of-band from the console

╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/plymouth/plymouth/issues/23.

Bug Watch Updater (bug-watch-updater)
Changed in plymouth:
status: Fix Released → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.