[Bug 563916]

Wed Aug 8 05:41:04 UTC 2018

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to plymouth in Ubuntu.
https://bugs.launchpad.net/bugs/563916

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

Status in Plymouth:
  Unknown
Status in Release Notes for Ubuntu:
  Fix Released
Status in plymouth package in Ubuntu:
  Fix Released
Status in plymouth source package in Lucid:
  Fix Released
Status in plymouth source package in Maverick:
  Fix Released

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...

To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/563916/+subscriptions