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

[Alessandro Menti]

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

[Alessandro Menti (elgaton)]

apport information

[Alessandro Menti (elgaton)]

apport information

[Alessandro Menti (elgaton)]

apport information

[Launchpad Janitor (janitor)]

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

[Kate Stewart (kate.stewart)]

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

[Stéphane Graber (stgraber)]

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.

[Stéphane Graber (stgraber)]

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

[Stéphane Graber (stgraber)]

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

[sudodus (nio-wiklund)]

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)]

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

[Nightfall (someoneelse)]

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)]

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)]

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

[Erick Brunzell (lbsolost)]

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)]

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)]

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)]

@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)]

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

[sudodus (nio-wiklund)]

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)]

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

[sudodus (nio-wiklund)]

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

[amjjawad  (amjjawad)]

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.

[Erick Brunzell (lbsolost)]

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)]

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

[Erick Brunzell (lbsolost)]

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)]

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)]

@ 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?

[Chris Bainbridge (chris-bainbridge)]

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]"

[Marius Gedminas (mgedmin)]

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.

[Chris Bainbridge (chris-bainbridge)]

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.

[Chris Bainbridge (chris-bainbridge)]

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

[Ubuntu Foundations Team Bug Bot (crichton)]

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

[Steve Langasek (vorlon)]

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

[Erick Brunzell (lbsolost)]

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.

[Chris Bainbridge (chris-bainbridge)]

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

[Launchpad Janitor (janitor)]

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

[Kalle Tuulos (kalle-tuulos)]

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 Lunn (darkxst)]

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)]

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.

[Erick Brunzell (lbsolost)]

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.

[Chris Bainbridge (chris-bainbridge)]

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)

[Rstrode (rstrode)]

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?

[Chris Bainbridge (chris-bainbridge)]

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.

[Steve Langasek (vorlon)]

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.

[Chris Bainbridge (chris-bainbridge)]

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

[Chris Bainbridge (chris-bainbridge)]

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?

[Rstrode (rstrode)]

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.

[Chris Bainbridge (chris-bainbridge)]

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

[Chris Bainbridge (chris-bainbridge)]

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.

[Chris Bainbridge (chris-bainbridge)]

Thanks for clarifying.

[Phillip Susi (psusi)]

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.

[Steve Langasek (vorlon)]

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.

[Mathieu Trudel-Lapierre (cyphermox)]

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

[Phill Whiteside (phillw)]

This is back in 14.04.4 lubuntu 64 bit (Entire Disk) with the build dated 15th Feb 2016 (It was not present in the build dated 14th Feb)

[Lyn Perrine (walterorlin)]

This does not happen on 14.04.4 on real harware.

[sudodus (nio-wiklund)]

Den 2016-02-16 kl. 02:19, skrev Brendan Perrine:
> This does not happen on 14.04.4 on real harware.
>

It works like it should in my Toshiba too.

[Chris Bainbridge (chris-bainbridge)]

On 16 February 2016 at 01:19, Brendan Perrine <email address hidden> wrote:
> This does not happen on 14.04.4 on real harware.

It's a race condition so it will happen on some hardware and not
others. On some hardware it will happen rarely and on other hardware
more often. afaik The underlying bug (see fix comment #35) was not
fixed in 14.04, but fixed by moving to systemd for Vivid (15.04)
onwards.

[Phill Whiteside (phillw)]

I see this bug on http://phillw.net/hardware/aDU4RVzY with the new Xenial respin for Lubuntu Desktop ... http://cdimage.ubuntu.com/lubuntu/daily/20160224/xenial-alternate-i386.iso
So, it is alive and thriving on xenial... having been here since saucy... As we approach another LTS..... Can it be squished?

[Phill Whiteside (phillw)]

My apologies for the incorrect iso link... it does not appear in alternate, but can be seen at http://cdimage.ubuntu.com/lubuntu/daily-live/20160224/xenial-desktop-amd64.iso

What can I say? ... oops...

[sudodus (nio-wiklund)]

This bug seldom affects me, but it happens. It seems to develop resistance like bacteria get resistent to antibiotics :-P

[amjjawad  (amjjawad)]

Hi, I must confirm that I am seeing this bug with Oracle VirtualBox since very very long time. I can see the bug has been reported on 2012-03-27 which explains a lot and I am seeing it with:

Ubuntu GNOME Desktop i386 build: 20160224.3

I've seen it too with the previous releases.

However, weird enough, I never faced it with ToriOS even though ToriOS is based on Ubuntu 12.04.5 and maybe that's why? not really sure.

Also, I'd like to double-confirm that I always test using Oracle VirtualBox so I have no idea how it is with real hardware. I have no spare hardware to test real installation on. I only test Ubuntu GNOME (due to very very limited time) and the spare old machine I have can't handle Ubuntu GNOME AFAIK and it's a broken laptop connected to a TV I use it as media player with ToriOS installed.

While this bug is not very serious/critical, IMHO it would be great if we could fix it at least with 16.04 :)

Thanks!

[sudodus (nio-wiklund)]

Now it happened to me in Lubuntu Xenial desktop i386 ;-)

[bakaniko (baka-niko)]

Hi,

I have this bug with OSGeo-Live 9.5 beta 1 based on Lubuntu 14.04.2 amd64 build in february 2016.
It is not critical but really annoying.

Nicolas

[SamInside (sam-inside-89)]

Same problem here.
On real hardware (Phenom II) it works fine.
In VirtualBox the prompt asking for CD removal is not shown and pressing Enter does nothing. You have to hard shutdown the machine.
A bug living 4 years and beyond, lol.

[sudodus (nio-wiklund)]

It seems to me that this bug affects systems booted via syslinux, but not systems booted via grub.

See this comment to a related bug report,

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1552985/comments/17

[sudodus (nio-wiklund)]

This problem is affecting Lubuntu Xenial final, and I was adviced to create a new bug report. The symptoms are the same or similar as in

Bug #1572378: The prompt asking for media removal is neither shown at the end of the installation nor at 'normal' reboot nor poweroff.

It affects the live session, when booted from a USB drive, when cloned (with mkusb, usb-creator-gtk, gnome-disks, dd, Win32 Disk Imager).

Workaround: remove the boot option 'splash'. It works in real computers and in VirtualBox.

If you know about it, you can press Enter to continue (rebooting or shutting down) with seeing the prompt. This works in real computers, but not in VirtualBox.

This might also be a symptom of the same problem in the program code as reported in

Bug #1359689: cryptsetup password prompt not shown and/or
Bug #1370707: Plymouth does not display the graphical boot splash

[sudodus (nio-wiklund)]

This problem is affecting Lubuntu Xenial final in UEFI mode, which boots from grub, when booting from a cloned USB drive (as described earlier). But it does not affect grub-n-iso boot systems. In that case there is no prompting, it just reboots or shuts down.

[Bernard Stafford (bernard010)]

This problem is minor. After install of Ubuntu 20.04 daily build 3/14/2020.
Missing: Remove media and press Enter Prompt.
Other wise just sits idle waiting for user to press enter.
To do initial first restart after installation.
Had no other problems.
Install (entire disk) in Ubuntu Desktop amd64 in Focal Daily
Testcase Reporting

[MarkF (az2008)]

I've been seeing this for the past 4-6 days. I've also noticed that the new media check (during startup) doesn't appear on the screen. It seemed to me the shutdown msg becoming unseen happened at the same time the media check became unseen.

In both cases, what I see is my bios's splash screen. It's like that's being invoked and kept on the screen. (I've seen this on an old Toshiba, and a new Acer.).

[MarkF (az2008)]

This may be related. I've noticed the past few days that the Ubuntu desktop daily image is being generated even though nothing has changed. For example, today the QA Tracker says 03-14 is available. But, zsynch says no data is downloaded (compared to the last one I had). When I run: strings focal-desktop-amd64.iso | grep "Ubuntu 20.04" it shows the ISO is still 03-09.

That's about when I noticed something with startup and shutdown changed (the media-check msgs are hidden, as is the "press ENTER" message). I think we're testing the same ISO every day.

Yesterday the QA tracker's date was 0313.4 (appearing to have been regenerated 4 times?). But, it took was unchanged from the last one. So, something funny is happening in this regard. And, it seems to have begun about the same time as what Bernard reported.

[corrado venturini (corradoventu)]

Same problem installing from Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200329)

[sudodus (nio-wiklund)]

Yes, this bug has returned after several years. I suspect that there is a race condition.

[Béné (bene-d)]

For me this is fixed since the Focal beta.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release