Ubiquity failure - Error while installing packages Ubuntu Jammy

[Leó Kolbeinsson]

Testing Ubuntu Jammy daily ISO 21.03.2022
The test was run on 2 seperate machines see: http://iso.qa.ubuntu.com/qatracker/milestones/429/builds/245913/testcases/1300/results/
1. Lenovo V14 II - barebone
2. InWin BL641 i5-10400 - run in VirtualBox VM
When the installation terminates the following message appears (see also attached screenshot)
"Error while installing packages: "
Then follows large text and refers to broken "firefox-locale-en" package
When the system reboots no boot media is found on the install machine.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: ubiquity 22.04.7
ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
Uname: Linux 5.15.0-23-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu79
Architecture: amd64
CasperMD5CheckResult: pass
CasperVersion: 1.467
CurrentDesktop: ubuntu:GNOME
Date: Mon Mar 21 17:44:01 2022
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---
LiveMediaBuild: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220321)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu QA Website (ubuntuqa)]

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/1965805

[Leó Kolbeinsson (leok)]

Tested 3rd machine = AWOW NY41 – Int.Cel. J4125
with the same ISO (21.03.22) and this also failed.

[cesar (paschubu)]

HI, today i try to reinstall 22.04 in a vm, and almost get the same problem, except the installer get stuck and no move on, trying installing firefox from snap store. btw, the licecd is from today.

[Launchpad Janitor (janitor)]

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

[Mike Pontillo (mpontillo)]

I'm seeing what might be the same issue with the Jammy live image. Before I got the error, I saw that it was trying to install the Firefox snap and was not able to reach the snap store. (For the record, the machine _did_ have a network connection.)

[Mike Pontillo (mpontillo)]

FYI: I was able to work around this by asking Ubiquity to do a minimal install, not to download packages during install, and turning off WiFi (just to be sure).

[cesar (paschubu)]

interesting... i going to try that setting to see if work, as expected.

[Cristina (fcloud400)]

Same problem here

[cesar (paschubu)]

confirmed, with ubiquity in no download update and minimal install, and no network... install as expected!.

[Brian Murray (brian-murray)]

The screenshot from the bug report does not match the screenshot of the other people commenting on the bug report. Leo's screenshot indicates a problem with the firefox-locale-en package while the other ones are about contacting the snap store (which was down for a bit in the past 24 hours). If you continue to see an issue contacting the snap store when installing please open a new bug report.

@Leo I don't see anything in your ubiquity syslog about firefox-locale-en. Could you try recreating the problem again and also look in /var/log/apt/ for a log file with a more detailed error message? Thanks in advance

[Mike Pontillo (mpontillo)]

Thanks for your attention.

For the record, I saw the same errors mentioned in this bug after the Firefox install timed out, which is why I posted the screenshot. (I thought it might provide additional detail about the root cause.)

After the snap install timed out, the entire install process aborted and I had to manually revert the changes to the partition table.

(Also, I would personally consider it a bug if the installer cannot gracefully handle the case where "the network is connected but the snap store cannot be contacted".)

[Leó Kolbeinsson (leok)]

@brian-murray Brian - re comment # 11

Re tested same machine and same ISO also same results - here are the log files from /var/log/apt

[Leó Kolbeinsson (leok)]

And one further log file re above comment

[Leó Kolbeinsson (leok)]

It looks like the problem is with unpacking .../firefox-locale-en as the history and term logs show.

Ran another test this time with no Internet and minimum install and no errors were encountered.
Ran yet another test with Internet connection and no downloading and again the problem with Firefox.

As far as I could determine what happens is that the installer fails to connect/contact the snap store and waits/retries 3 times for 10 minutes (toatl 30) and then the crash occurs as in my initial report.
This results in no boot device available after the incomplete install.

[cesar (paschubu)]

exactly my problems.... the installer stuck before trying install firefox... like @leo say and @mike say...

[Brian Murray (brian-murray)]

Part of this was likely due to the fact that the firefox-locate-* packages were still in the supported seed for Ubuntu. I've removed that today and tomorrow's daily builds on or after 2022-03-24 should include that change.

[James Henstridge (jamesh)]

I tried to do a clean install in a VM with the current daily install media and managed to reproduce the problem.

The Firefox preinst script was stuck in its loop calling "snap info firefox", so I opened a shell with "sudo chroot /proc/$pid/root" and ran the same command. That led to a panic that I've attached below.

The panic occurs when it is trying to get the caller's home directory, picking the sudo user in preference:

https://github.com/snapcore/snapd/blob/6541efe9d6daad221447a2220c6de544b1741f46/client/login.go#L97-L100

The called function checks the SUDO_USER environment variable:

https://github.com/snapcore/snapd/blob/6541efe9d6daad221447a2220c6de544b1741f46/osutil/user.go#L309-L347

The /proc/$pid/environ file shows that the preinst script is being run with SUDO_USER=ubuntu, which is essentially the same environment I happened to create with "sudo chroot". The user lookup fails because there is no user by that name in the file system being set up for the install.

[James Henstridge (jamesh)]

Looking further, it seems this is a problem that has already been fixed in snapd:

https://github.com/snapcore/snapd/pull/11275

The change was included in snapd 2.55. The ENOENT check is not present in 2.54.4, as is being used in the installer environment:

https://github.com/snapcore/snapd/blob/5d1db242a82a8e3b2460a0877c9890ec99cd9b60/osutil/user.go#L306-L317

I can see that an upload of snapd 2.55.2 was made to jammy 2 days ago, so I suspect that would likely correct the problem when the next image is spun.

[cesar (paschubu)]

i try the build of today... and NO problem with the installer of ubuntu.. and no problem installing firefox on the installer.

[jeremyszu (os369510)]

remove debian packages firefox-locale-* and seeding firefox snap in the image could fix this issue.
Verified on 3/24 Jiayi OEM base image.

[James Henstridge (jamesh)]

I just tried installing a system using the 20220324.3 daily image (which includes the new snapd). The installation completed successfully, and the /usr/bin/snap panic I'd previously observed when run under "sudo chroot /target" was now gone.