The prompt asking for media removal is not shown at the end of the installation

Bug #966480 reported by Alessandro Menti on 2012-03-27
208
This bug affects 33 people
Affects Status Importance Assigned to Milestone
Plymouth
Won't Fix
Medium
casper (Ubuntu)
High
Stéphane Graber
Precise
High
Stéphane Graber
plymouth (Ubuntu)
High
Mathieu Trudel-Lapierre
Precise
High
Unassigned

Bug Description

*** Edit ***
This bug affects Ubuntu and other flavours as well and yes, it is alive and doing well with Saucy as well.

See: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/966480/comments/22

*** End of Edit ***

At the end of the installation, just after clicking on "Reboot Now" to restart the computer, the graphical environment is shut down and the TERM signal is sent, asking all processes to terminate. However, the prompt asking the user to remove the CD and press Enter is not shown (the CD is ejected, then the system hangs).

Tested on today's (27 March 2012) KUbuntu Precise daily ISO in a VirtualBox VM (using VirtualBox 4.1.8, 1 GiB of RAM, 16 GiB HD, 4 CPUs, EFI disabled).
---
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
DistroRelease: Ubuntu 12.04
InstallCmdLine: file=/cdrom/preseed/kubuntu.seed boot=casper maybe-ubiquity initrd=/casper/initrd.lz quiet splash -- debian-installer/language=it keyboard-configuration/layoutcode?=it
InstallationMedia: Kubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120327)
Package: ubiquity (not installed)
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Tags: precise ubiquity-2.10.3
Uname: Linux 3.2.0-20-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

apport information

tags: added: apport-collected ubiquity-2.10.3
description: updated

apport information

apport information

description: updated
summary: - The prompt asking for media remotion is not shown at the end of the
+ The prompt asking for media removal is not shown at the end of the
installation
affects: ubiquity (Ubuntu) → casper (Ubuntu)
Changed in casper (Ubuntu):
importance: Undecided → High
Steve Langasek (vorlon) on 2012-03-29
tags: added: rls-mgr-p-tracking
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in casper (Ubuntu):
status: New → Confirmed
tags: added: qa-daily-testing
Kate Stewart (kate.stewart) wrote :

Making sure this is targetted properly to precise, so it gets looked at. Seems to be stalled out.

Changed in casper (Ubuntu Precise):
status: New → Confirmed
importance: Undecided → High
milestone: none → ubuntu-12.04.1
tags: added: rls-p-tracking
removed: rls-mgr-p-tracking
Changed in casper (Ubuntu):
assignee: nobody → Stéphane Graber (stgraber)
Changed in casper (Ubuntu Precise):
assignee: nobody → Stéphane Graber (stgraber)
Changed in casper (Ubuntu):
status: Confirmed → Incomplete
Changed in casper (Ubuntu Precise):
status: Confirmed → Incomplete
Changed in casper (Ubuntu):
status: Incomplete → Triaged
Changed in casper (Ubuntu Precise):
status: Incomplete → Triaged
Stéphane Graber (stgraber) wrote :

Can someone still reproduce this on Quantal?

I don't see any reason why it'd be fixed (no change in casper that'd explain it), but I'm clearly unable to reproduce here.
I tried around 15 reboots, all of whom showed the message and rebooted fine when pressing enter.

If someone can reproduce this reliably, please comment so I can try and get more debug information.

Changed in casper (Ubuntu):
status: Triaged → Incomplete
Stéphane Graber (stgraber) wrote :

Untargeting from the point release as there's no reliable reproducer and no idea of where the bug actually is.

Changed in casper (Ubuntu Precise):
milestone: ubuntu-12.04.1 → none
Stéphane Graber (stgraber) wrote :

Ok, we had an idea of what might go wrong and I'm now preparing an upload that tries to address that.

On 2013-04-23 19:38, Stéphane Graber wrote:
> Ok, we had an idea of what might go wrong and I'm now preparing an
> upload that tries to address that.
>
Great, let's hope it will fix the bug for the different instances where
it appears :-)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package casper - 1.331

---------------
casper (1.331) raring; urgency=low

  * Re-order the eject code so that the message is rendered before the eject
    which should fix the case where fonts or other bits are missing and the
    message can't be rendered. (LP: #966480)
  * Also detect swap space on virtio.
 -- Stephane Graber <email address hidden> Tue, 23 Apr 2013 19:46:18 +0200

Changed in casper (Ubuntu):
status: Incomplete → Fix Released
Nightfall (someoneelse) wrote :

Kubuntu raring final iso, Samsung NC10:

Running as live system for testing (from flash drive):
First try: Splash (kubuntu-logo) is displayed during shutdown, but no "Please remove media..." message;
second try: no splash is displayed (and no message on the terminal which is visible instead).
Shutdown completes after pressing Return (if I remember correctly).

After installation (from flash drive):
No splash is displayed (blank, black screen if I remember correctly) - shutdown completes after pressing Return.

(Also see bug #1170421 for testing with pre-release isos - maybe it's not (only) a casper bug.)

sudodus (nio-wiklund) wrote :

I think this bug still affects Lubuntu Saucy i686, when running a live session (without installing).

I would expect a prompt to remove the live media and press ENTER. I think it exists, but is 'hidden behind' the graphics screen with the dots, because it is shown in text mode (as seen for example in Lubuntu Raring running in VirtualBox).

sudodus (nio-wiklund) wrote :

This bug is still alive in Lubuntu Saucy Alpha 2 desktop 32-bit

Erick Brunzell (lbsolost) wrote :

This also effects Ubuntu GNOME Saucy Beta 2 images. I personally find that it's more likely to occur if running the installation from the main menu than running the installation from the live DE.

Erick Brunzell (lbsolost) wrote :

Could someone please change the status of this bug to reflect that it effects Saucy images?

I can't figure out how to do that :^/

sudodus (nio-wiklund) wrote :

I was happy to report that I did *not* find it in Lubuntu Saucy Beta 2 :-)

@Lance: Where and how do you see this bug in a current version of Saucy? Did it come back again, or is it only in Ubuntu Gnome? What do you mean by 'running the installation from the main menu'?

Erick Brunzell (lbsolost) wrote :

@nio,

Simply start by choosing "install" rather than booting to the live DE. At the end of the installation when asked to restart and clicking on "restart" the CD/DVD ejects as expected but no message is displayed.

With no message being displayed it leaves one wondering what to do, possibly leading to a hard reset when not needed.

Erick Brunzell (lbsolost) wrote :

BTW I'm testing on bare metal so this may not appear in a VM.

sudodus (nio-wiklund) wrote :

I see. I have tested on bare metal as well as in a VM, but I have used dd-cloned USB pendrives, not CDs, so that is a difference. And I have only tested Lubuntu.

Have you seen the problem with Lubuntu or only Ubuntu Gnome?

Erick Brunzell (lbsolost) wrote :

I've seen it with Lubuntu, Ubuntu, Ubuntu GNOME, and Edubuntu.

sudodus (nio-wiklund) wrote :

Obviously the bug is still alive, although I haven't seen it lately. I'll keep looking for it.

amjjawad  (amjjawad) wrote :

Long story short:

1- Bug is still alive
2- Happens with LiveCD/LiveDVD
3- It is NOT happening with LiveUSB - whenever you use LiveUSB, once you click on "Restart" after the installation is done, it will reboot your machine without any message at all. Which is, different behaviour.
4- I think this bug: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1194895 is a duplicate of this one.

Thanks!

P.S.
This is NOT flavour specific, this is Ubuntu + other flavours bug.

amjjawad  (amjjawad) on 2013-10-02
tags: added: sacuy
description: updated
description: updated
Daniel Manrique (roadmr) on 2013-10-02
tags: added: saucy
removed: sacuy
Erick Brunzell (lbsolost) wrote :

In Ubuntu GNOME Saucy 20131017 the proper text seems to display OK if installation is started from the live DE but not if choosing Install directly from either boot menu option.

Colin Watson (cjwatson) wrote :

Reopening as we've had a number of reports with saucy.

Changed in casper (Ubuntu):
status: Fix Released → Triaged
Erick Brunzell (lbsolost) wrote :

ATM I can't reproduce this on Lubuntu so it may be limited to Ubuntu GNOME only, and my test hardware is not playing well with Ubuntu itself so I can't be quite sure :^(

sudodus (nio-wiklund) wrote :

I had this issue with the Lubuntu release candidate today, reported in: 'Install (manual partitioning) in Lubuntu Desktop i386 for Saucy Daily ', so it affects Lubuntu too.

Erick Brunzell (lbsolost) wrote :

@ sudodus,

I had seen bug #1238836 while testing Lubuntu live images circa 20131015, but I don't think it's an actual duplicate???

But maybe they're related in some way?

This can be reproduced in VirtualBox with xubuntu-14.04-desktop-amd64.iso. Create VM, attach CD image, boot, "Try Xubuntu without installing", "Try Xubuntu", choose Shutdown from desktop, and it hangs immediately after "Stopping early crypto disks... [OK]"

tags: added: trusty
Marius Gedminas (mgedmin) wrote :

I can reliably reproduce this with KVM:

    kvm -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus -cdrom ubuntugnome_utopic-desktop-amd64.iso -m 2048

See bug 1384095 for more details.

Confirmed in Ubuntu 14.04.1. There seems to be caused by a race condition or undefined behaviour.

"/etc/rc0.d/casper stop" does "plymouth --ping" to test whether plymouth is running, then does "plymouth message" to print the message to the screen , then "plymouth watch-keystroke" to read the enter key press. But at this point, "plymouthd --mode=shutdown" is already running. This results in a hang with the following processes running:

root 3527 0.0 0.0 4444 652 ? Ss 21:28 0:00 /bin/sh -e /proc/self/fd/9
root 3625 0.0 0.0 18072 368 ? S 21:28 0:00 @sbin/plymouthd --mode=shutdown
root 3629 0.0 0.0 4444 804 ? S 21:28 0:00 /bin/sh /etc/init.d/rc 0
root 3863 0.1 0.0 4444 804 ? S 21:28 0:00 /bin/sh -x /etc/rc0.d/S89casper stop
root 4089 0.0 0.0 4444 388 ? S 21:28 0:00 /bin/sh -x /etc/rc0.d/S89casper stop
root 4096 0.0 0.0 12808 448 ? S 21:28 0:00 plymouth watch-keystroke

There could be a race condition between the "plymouth --ping" test and the action, or between plymouthd being shutdown and the casper script running plymouth, or it could be that the plymouth commands just don't work when plymouthd is in shutdown mode. Either way, this can be fixed by removing the use of plymouth from casper and reverting to the alternative actions which read and write /dev/console. Patch attached.

It looks like the casper plymouth code that introduced this problem was intended to fix bug #506418 ("live cd does not shutdown").

The attachment "casper_rm_plymouth.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Steve Langasek (vorlon) wrote :

That's not a correct fix. The prompting is supposed to be done via plymouth, not via direct writes to the console.

tags: removed: patch
Erick Brunzell (lbsolost) wrote :

I have a dumb question; is a different mechanism used to display the restart dialog when the install is started from the live DE rather than started from the boot menu?

I ask because based on recent testing I seem to get the restart prompt properly (at least more often) if installation is started from the live DE, but I'm much less likely to see the restart prompt if "Install" is selected either from the normal boot menu or the advanced boot menu.

I'll be testing the 14.04.2 candidates over the next few days so I'll watch more closely to verify if I'm correct about that behavior.

> That's not a correct fix. The prompting is supposed to be done via plymouth,
> not via direct writes to the console.

Okay, I didn't know whether plymouth is meant to still be in use at this late stage.

The problem is the race condition in plymouth-shutdown.conf:

         /sbin/plymouthd --mode=shutdown
        /bin/plymouth show-splash

"plymouth show-splash" can be executed before the plymouthd daemon is up and running. The subsequent message from casper then fails because the splash is not shown:

        [main.c] on_display_message:not displaying message Please remove installation media and close the tray (if any) then press ENTER: as no splash

To fix this just requires making sure that plymouthd is ready before the call to show-splash. Patch attached.

tags: added: patch
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in plymouth (Ubuntu Precise):
status: New → Confirmed
Changed in plymouth (Ubuntu):
status: New → Confirmed
Kalle Tuulos (kalle-tuulos) wrote :

This error exists still in 14.10. Tested with media lubuntu-14.10-desktop-i386.iso, installed under VirtualBox 4.3.22 r98236, host OS is 64bit MS Windows 7 Pro SP1.

Tim (darkxst) wrote :

Kalle, This can't be fixed for 14.10, its not possible to update released images. It is therefore more interesting if it affects 14.04.2 or 15.04 images, have you tried testing those?

Erick Brunzell (lbsolost) wrote :

Tim, I haven't seen this happen with 14.04.2 when starting the installation from the live desktop, but it does occur (possibly only sometimes) if the installation is started from either the Try/Install screen or from the advanced boot menu.

This problem has popped up from time to time for a very long time.

Changed in plymouth (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
status: Confirmed → Triaged
importance: Undecided → High
Changed in plymouth (Ubuntu Precise):
importance: Undecided → High
status: Confirmed → Triaged
Erick Brunzell (lbsolost) wrote :

I've performed a lot of tests over the past week or so and finally had this happen with Ubuntu GNOME Vivid 20150223 having chosen Install from the Try or Install screen, so I grabbed a picture. Sorry it's a bit blurry but since the Install was not started from the live DE I couldn't take an actual screenshot.

BTW I think this should be marked Won't fix for Precise because no new Precise images will be built, and probably milestoned for 14.04.3 and Vivid.

Regarding this bug: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/966480

The problem is that the Ubuntu plymouthd init script does the equivalent of:

        /sbin/plymouthd --mode=shutdown
        /bin/plymouth show-splash

The second command would fail because of the race condition where plymouthd forks and returns, but isn't actually ready to answer connection requests.

The simple fix would be to modify the init script to wait until plymouthd is ready:

        /sbin/plymouthd --mode=shutdown
        while ! plymouth --ping; do sleep 1; done
        /bin/plymouth show-splash

But does this make sense?
Should plymouthd really be returning before it is ready to answer requests?
It seems like this behaviour could cause bugs on other non-Ubuntu distributions too (e.g. bug #39774 looks the same)

Changed in plymouth:
importance: Unknown → Medium
status: Unknown → Confirmed

So this bug report doesn't seem right to me. The code doesn't call ply_detach_daemon (which exits the parent) until after ply_boot_server_listen. Are you sure you've pegged the problem right? If so, can you explain the race to me in more detail?

Upstart doesn't wait for the call to plymouthd to exit, it just waits for it to fork.

The upstart script is like:

    expect fork
    exec /sbin/plymouthd --mode=shutdown
    post-start exec /bin/plymouth show-splash

afaics upstart starts plymouthd, and when plymouthd forks, upstart then immediately executes "plymouth show-splash". At this point plymouthd isn't ready - race condition - which causes the splash screen to fail.

"The daemon should ensure that when it completes the (second) fork that it is fully initialized, since Upstart uses the fork count to determine service readiness" http://upstart.ubuntu.com/cookbook/#daemon-behaviour

This is probably more the fault of the upstart script than of plymouthd. It seems like it will be easier to just fix the script.

Changed in plymouth:
status: Confirmed → Won't Fix
Steve Langasek (vorlon) wrote :

Chris, this analysis is unlikely to be correct. Certainly at the time the plymouth upstart jobs were written, plymouthd was only forking once - and correctly opening its socket before detaching from the foreground. If plymouthd behavior has since changed to double fork, and to not start accepting connections until after the first fork, then not only would there be a race condition, but upstart would completely lose all ability to sanely track the plymouthd process - it would consider the plymouth service 'stopped' as soon as the first child had exited.

And considering we're discussing a problem that occurs only on shutdown - there have been no problems with reliability of plymouth splash appearing on boot due to a corresponding race condition - I don't think this is at all a likely explanation for the behavior.

Historically the problems with plymouth not displaying on shutdown from an install image have been due to a race between the plymouth jobs loading the required files into memory, and the casper jobs unmounting the filesystem that these files live on (which is a prerequisite for ejecting a DVD). This bug is almost certainly an instance of this general problem.

> at the time the plymouth upstart jobs were written, plymouthd was only forking
> once - and correctly opening its socket before detaching from the foreground.

This is not correct. main.c:main calls ply_create_daemon before start_boot_server, so the process does fork before binding the port.

When the error occurs the plymouthd log states:

        [main.c] on_display_message:not displaying message Please remove installation media and close the tray (if any) then press ENTER: as no splash

Note "not displaying message... as no splash". That error message only occurs when the splash screen is not being shown. It is not related to unmounting the filesystem.

> And considering we're discussing a problem that occurs only on shutdown -
> there have been no problems with reliability of plymouth splash appearing on
> boot due to a corresponding race condition - I don't think this is at all a
> likely explanation for the behavior.

Boot and shutdown are different. On boot, plymouth.conf executes plymouthd, then plymouth-splash.conf executes plymouth show-splash. On shutdown, plymouth-shutdown.conf executes both plymouthd and plymouth. Since one script executes both, the timing is tighter.

I have tested the patch and it works.

main.c forks before opening the listening port (calls ply_create_daemon before start_boot_server). Is this intentional? Would you consider it a bug in plymouthd?

Hi,

(In reply to Chris Bainbridge from comment #3)
> main.c forks before opening the listening port (calls ply_create_daemon
> before start_boot_server). Is this intentional?
Yes.

> Would you consider it a bug in plymouthd?
No.

Upstart should wait until the parent exits. We exit the parent when plymouthd is ready. It must have a way of coping with this situation, since it's not a novel or exotic way to daemonize.

> at the time the plymouth upstart jobs were written, plymouthd was
...
> correctly opening its socket before detaching from the foreground.

The fork-before-open-socket behaviour goes back to the first tag of plymouth (0.1.0). It has always been that way.

Probably the reason this problem was not noticed earlier is that the time period between execution of plymouthd and execution of plymouth was longer. Older hardware was slower, the time to start plymouth would include the time to load the executable from the CDROM or USB drive. Even on a VM it would be slower if the VM were on a harddrive. But now systems are faster, often physical PCs are booted from USB3 drives, or VMs are on SSD drives, so plymouth gets launched faster, and the race condition is more likely to be hit.

Comment from plymouth upstream:

> Comment # 4 on bug 89503 from Ray Strode [halfline]
>
> > main.c forks before opening the listening port (calls ply_create_daemon
> > before start_boot_server). Is this intentional?
> Yes.
>
> > Would you consider it a bug in plymouthd?
> No.
>
> Upstart should wait until the parent exits. We exit the parent when plymouthd
> is ready. It must have a way of coping with this situation, since it's not a
> novel or exotic way to daemonize.

Thanks for clarifying.

Phillip Susi (psusi) wrote :

So upstart considers the job started the moment the process forks, rather than waiting for it to exit? If so then I agree with plymouth upstream: the bug is in upstart.

On Fri, Mar 13, 2015 at 08:55:24PM -0000, Phillip Susi wrote:
> So upstart considers the job started the moment the process forks,
> rather than waiting for it to exit? If so then I agree with plymouth
> upstream: the bug is in upstart.

Yes, it turns out this is bug #530779 which remains unfixed in upstart.

Closing the vivid tasks since we've fixed that in systemd / casper.

Changed in casper (Ubuntu):
status: Triaged → Fix Released
Changed in plymouth (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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