"Remove media" message is not displayed after installation

Well there are two types of messages......

.... if it is a pretty one, it will able to reboot

.... if it is the ugly one, it tells the user to reboot - meaning manual hard reset.

.... if there is no message, that's bad.

I'm curious what needs to be done, when no message is shown? bios or uefi boot? straight to installation or try-ubuntu first?

I speculate that this is a race between plymouth-reboot.service and casper.service, which does not declare itself to be ordered after plymouth-reboot.service.

 - the casper service is racing plymouth; it doesn't wait for plymouth-reboot.service to have started before it checks to see if plymouth is available, so if plymouth is slow to start up, casper may write its message only to the console.
 - casper is writing to a different tty than the one plymouth runs on, because plymouth in shutdown mode defaults to running on tty63 - not tty1 which was used for everything at boot, and which casper writes its 'backup' message to.
 - if you do change VTs to tty1 and see the 'fallback' message telling you to reboot, you can't just press enter, because we're only listening to plymouth in this case, and not the tty. This is why a different message is displayed (as Dimitri mentions).
 - because we're calling plymouth --ping at two different times, we can actually get two different answers, especially since we're currently racing. So you can wind up with casper only writing the message to the console, and then listening for an answer via plymouth, and nobody's happy.

I think it is important that we fix the race by ensuring the casper service always starts after plymouth-reboot.service. I've raised an MP for this.

But I don't know if that's actually going to fix the bug reported here (which seems to actually be a metabug, describing different symptoms on UEFI vs BIOS).

Jean-Baptiste, can you please clarify:
 - what environment you see this behavior in (KVM? VirtualBox? Bare metal? UEFI or BIOS?)
 - what is the exact message you see on the console when you press alt-right 5 times

- I see this behaviour on bare metal in BIOS and UEFI mode when installing from the live session.
- when pressing alt-arrow 5 times, I see the purple screen with the Ubuntu logo and the message "Please remove the installation medium, then press ENTER:"

This bug was fixed in the package casper - 1.397

---------------
casper (1.397) cosmic; urgency=medium

  [ Steve Langasek ]
  * debian/casper.service: order this after plymouth on shutdown, so that if
    plymouth is present we are reliably talking to it, rather than possibly
    racing by writing to console and then having plymouth start behind our
    back. LP: #1795882.

 -- Dimitri John Ledkov <email address hidden> Wed, 10 Oct 2018 16:47:59 +0100

This issue still exists on Cosmic Desktop 20181011 with casper 1.397. I reproduced it on bare metal in legacy mode with an installation from the live session.

I just reproduced on KVM (w/QXL), just doing a standard installation with today's ISO 20181012.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1795882

I've still been unable to reproduce this locally.

$ cat /cdrom/.disk/info
Ubuntu 18.10 "Cosmic Cuttlefish" - Beta amd64 (20181012)$

Selected 'Install Ubuntu' at BIOS boot screen. Installed a full disk install. Clicked button to restart; was shown the plymouth splash screen, with the message to remove media and press enter.

VM is booted under virt-manager using the attached libvirt definition.

Resulting horrible qemu commandline is below.

qemu-system-x86_64 -enable-kvm -name guest=lp.1795882,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-20-lp.1795882/master-key.aes -machine pc-i440fx-wily,accel=kvm,usb=off,dump-guest-core=off -cpu IvyBridge -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ae4754f7-56af-4617-b07e-436c1c3ff1da -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-20-lp.1795882/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/dev/virgil_nocrypt/xenial-test,format=raw,if=none,id=drive-ide0-0-0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive file=/dev/sr0,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:99:c8:1a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

For some reason launchpad is not letting me attach the libvirt xml, so please find it inline below instead.

<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit lp.1795882
or other application using the libvirt API.
-->

<domain type='kvm'>
  <name>lp.1795882</name>
  <uuid>ae4754f7-56af-4617-b07e-436c1c3ff1da</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-wily'>hvm</type>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='custom' match='exact' check='partial'>
    <model fallback='allow'>IvyBridge</model>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/virgil_nocrypt/xenial-test'/>
      <target dev='hda' bus='ide'/>
      <boot order='2'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/home/vorlon/devel/iso/cosmic-desktop-amd64.iso'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:99:c8:1a'/>
      <source network='default'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-...

So https://launchpad.net/ubuntu/+source/casper/1.399 this upload should make things better and drop the user to the plymouth splash more often.

There is a race between casper script and show-splash, as show-splash command is an ExecStartPost command.

Please confirm if existing machines that used to land on an `empty` tty with just `_` or things that landed on tty1 still do not show shutdown ubiquity, eventually.

Dimitri, that sounds like it should only be a race between show-splash and plymouth message, which could cause the splash screen to show up but not have text displayed. That was not the symptom reported. Have you in fact been able to reproduce the reported black screen?

Believed fixed with:

casper (1.399) cosmic; urgency=medium

  * Switch vt to where plymouth-shutdown will show-splash, if not
    already have.