the chromium snap takes a long time to install without visible user feedback, seems stuck

ok i found 'snap changes' and did snap abort.

Now stuck on 20% again...

antheperson@danski:~$ snap changes
ID Status Spawn Ready Summary
1 Done today at 23:24 NZST today at 23:26 NZST Initialize system state
2 Done today at 23:24 NZST today at 23:24 NZST Initialize device
3 Done today at 23:26 NZST today at 23:35 NZST Install "canonical-livepatch" snap
4 Doing today at 23:28 NZST - Install "pycharm-community" snap from "latest/stable" channel
5 Doing today at 23:32 NZST - Install "chromium" snap

dantheperson@danski:~$ sudo snap abort 5
dantheperson@danski:~$ sudo snap abort 4
dantheperson@danski:~$ sudo apt install chromium-browser
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  chromium-browser
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0 B/48.4 kB of archives.
After this operation, 164 kB of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 185728 files and directories currently installed.)
Preparing to unpack .../chromium-browser_81.0.4044.129-0ubuntu0.20.04.1_amd64.deb ...
=> Installing the chromium snap
==> Checking connectivity with the snap store
==> Installing the chromium snap

Progress: [ 20%] [#####################################....................................................................................................................................................]

ok after 20 mins i abort again. snap reports the following

==> Installing the chromium snap
error: cannot perform the following tasks:
- Download snap "chromium" (1213) from channel "stable" (context canceled)
dpkg: error processing archive /var/cache/apt/archives/chromium-browser_81.0.4044.129-0ubuntu0.20.04.1_amd64.deb (--unpack):
 new chromium-browser package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/chromium-browser_81.0.4044.129-0ubuntu0.20.04.1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
W: Operation was interrupted before it could finish

Can you try installing the snap using the "snap install chromium" command?
Please let us know how this goes, and if it succeeds you should be able to safely install the deb wrapper ("apt install chromium-browser").

ok thanks that worked a treat.

Running snap directly there was a progress indicator so i could see that snap downloads are very very very slow. 200kb/s. I'm on a a basic residential 100Mbits fibre line, so apt downloading deps from the ubuntu mirror is usually quick, 10MB/s. So the snap download is 50x slower than what i am used to.

So download 50x slower than usual, and no progress indicator, made me think it was hung when i probably should have just waited half an hour.

Normal download speed from apt upgrade straight after the snap install:

The following packages will be upgraded:
  libnss3 snapd
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 28.4 MB of archives.
After this operation, 15.2 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://nz.archive.ubuntu.com/ubuntu focal-updates/main amd64 libnss3 amd64 2:3.49.1-1ubuntu1.2 [1,171 kB]
Get:2 http://nz.archive.ubuntu.com/ubuntu focal-updates/main amd64 snapd amd64 2.45.1+20.04 [27.3 MB]
Fetched 28.4 MB in 3s (10.9 MB/s)

I'm glad this worked, and thanks for the feedback.
I know that the snap store uses a CDN to serve snaps, it could be that NZ isn't favoured with the current setup. This is just a blind guess, I suggest you ask about it on https://forum.snapcraft.io/.

Have a feeling this will crop up a lot. I too am in NZ and was doing a routine apt upgrade of chromium-browser on Ubuntu 20.04 LTS.

First time, it decided to install the chromium snap and appeared stuck at 14%. (There was a bug, reporting identical symptoms, back in May. It's been expired because it's more than 60 days old but I'd bet that people will still be having the same problem.)

Next attempt - after much fixing-up having bombed out of what appeared to be a hung install - is showing exactly what the OP here describes: it's chosen first to install the chromium snap, with the progress bar appearing stuck at 20% for ages.

I'm prepared to wait ... and wait, as it appears from comments above that eventually this will complete and normal apt upgrades will be restored. Doesn't change my opinion: regardless of whether this works in the end, it's badly broken.

I agree this isn't a good user experience. I'll look into what can be done to report more detailed progress.

Please raise the issue with NZ being poorly served by the snap store CDN separately at https://forum.snapcraft.io/, this is something I cannot address myself but I'm sure the store team will be interested in hearing of the problem.

Please put TNT on snap... This was a machine of stress on the most easy thing to do on any Linux OS, installing software.

Sorry, I'm not sure what you mean with that last comment. Can you please elaborate?

I reckon he means get rid of snap caused it turned a trivial task into a
difficult one.

On Fri, 7 Aug 2020, 08:10 Olivier Tilloy, <email address hidden>
wrote:

> Sorry, I'm not sure what you mean with that last comment. Can you please
> elaborate?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1886414
>
> Title:
> the chromium snap takes a long time to install without visible user
> feedback, seems stuck
>
> Status in chromium-browser package in Ubuntu:
> Confirmed
>
> Bug description:
> after an initial attemp to install where the progress got stuck at
> 20%, i rebooted as there were a bunch of other system updates that had
> been applied after a fresh isntall.
>
> Now chromium wont install
>
> dantheperson@danski:~$ sudo apt install chromium-browser
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be upgraded:
> chromium-browser
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> Need to get 48.4 kB of archives.
> After this operation, 164 kB of additional disk space will be used.
> Get:1 http://nz.archive.ubuntu.com/ubuntu focal-updates/universe amd64
> chromium-browser amd64 81.0.4044.129-0ubuntu0.20.04.1 [48.4 kB]
> Fetched 48.4 kB in 0s (1,527 kB/s)
> Preconfiguring packages ...
> (Reading database ... 185728 files and directories currently installed.)
> Preparing to unpack
> .../chromium-browser_81.0.4044.129-0ubuntu0.20.04.1_amd64.deb ...
> => Installing the chromium snap
> ==> Checking connectivity with the snap store
> ==> Installing the chromium snap
> error: snap "chromium" has "install-snap" change in progress
> dpkg: error processing archive
> /var/cache/apt/archives/chromium-browser_81.0.4044.129-0ubuntu0.20.04.1_amd64.deb
> (--unpack):
> new chromium-browser package pre-installation script subprocess
> returned error exit status 10
> Errors were encountered while processing:
>
> /var/cache/apt/archives/chromium-browser_81.0.4044.129-0ubuntu0.20.04.1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> ProblemType: Package
> DistroRelease: Ubuntu 20.04
> Package: chromium-browser 81.0.4044.129-0ubuntu0.20.04.1
> ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
> Uname: Linux 5.4.0-40-generic x86_64
> ApportVersion: 2.20.11-0ubuntu27.3
> AptOrdering:
> chromium-browser:amd64: Install
> NULL: ConfigurePending
> Architecture: amd64
> CasperMD5CheckResult: skip
> Date: Mon Jul 6 23:39:11 2020
> Dependencies:
>
> ErrorMessage: new chromium-browser package pre-installation script
> subprocess returned error exit status 10
> InstallationDate: Installed on 2020-07-06 (0 days ago)
> InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64
> (20200423)
> Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal,
> 3.8.2-0ubuntu2
> PythonDetails: N/A
> RelatedPackageVersions:
> dpkg 1.19.7ubuntu3
> apt 2.0.2ubuntu0.1
> SourcePackage: chromium-browser
> Title: package chrom...

If so that kind of feedback isn't constructive, and this bug report isn't the right place for it.

Hi,

I just wanted to say that I am facing the same/similar problem (from Berlin/Germany).

error: cannot perform the following tasks:
- Download snap "chromium" (1691) from channel "stable" (download too slow: 0.00 bytes/sec)
- Download snap "gnome-3-28-1804" (161) from channel "stable" (download too slow: 0.00 bytes/sec)<

So the process auto-aborted after about 20 minutes.

My laptop has good internet connectivity. So I assume it is an issue with the snap CDN.

The most easyest thin in linux is installing, except chromium

I've confirmed this is still an issue on 24.04LTS and 24.10. It's not a good experience and this really could do with being fixed!

Enough was said about this being bad user experience, can I get a suggestion of what a good one would be? Of course the constant of the connection to the store being slow can't be wished away.

Is "Installing" the keyword that is throwing people off? If we instead wrote

"=> Downloading the chromium snap and its dependencies"

would this be any better?

For the specific case this bug is about (error: snap "chromium" has "install-snap" change in progress), I'm considering adding a notice clarifying the situation and giving option for manual intervention.

                echo "=> Snap installation is already in progress. You can wait some more minutes, but it might be stuck, in which case you could try the following:"
                echo "1. Open a terminal."
                echo "2. Enter 'snap changes', note the ID number of the stuck operation."
                echo "3. Enter 'sudo snap abort <id>', replacing '<id>' by the ID number of the stuck operation."
                echo "4. Enter 'sudo snap install chromium' and wait for it to complete."

I'd be glad to hear your impressions on the subject.

Thank you for taking this bug on. If it was just a case of the snap taking a long time it would be tolerable, but in some scenarios it just hangs with the snap partially installed. This means the application isn't installed, and now installing it isn't possible without resetting snap to a consistent state.

So to answer your question of what a good user experience would be:

1. Ideally, the snap would just install regardless of whether apt or snap initiated it. If I do `snap install chromium-browser` it works, but `apt install chromium-browser` is hit and miss and takes considerably longer to the point of timing out after 20 minutes. It's unclear why this is so different when it appears that apt is just calling the snap installation?

2. If the apt installation of chromium-browser fails, it should do so in a way that the system doesn't now believe that it is installed, even though the snap isn't available to run. As a result, the user could simply try the installation again with the hope it succeeds the next time, without needing to figure out how to get their system back into a state where the installation can be reattempted.

I haven't tested the proposed solution, but if it works then I feel giving the user prompts to deal with the issue appropriately is helpful, but really is just a workaround. Ideally users shouldn't need to take the steps mentioned and the package should handle it's own failure scenarios appropriately.

Thank you for your response.

> It's unclear why
> this is so different when it appears that apt is just calling the snap
> installation?

Indeed, the deb hook is just calling snap install chromium, so it is also
beyond me why this problem occurs and so I assumed this wasn't part of the
issue. But given you report of it being a consistent and recurring issue with a
specific 20 min timeout, I'll ask around, maybe it is a dpkg thing.

> 2. If the apt installation of chromium-browser fails, it should do so in
> a way that the system doesn't now believe that it is installed,

From the bug description, the system does not believe the package is installed:

> Errors were encountered while processing:
> /var/cache/apt/archives/chromium-browser_81.0.4044.129-0ubuntu0.20.04.1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Can you clarify what leads you to conclude that the system thinks the package
is installed? The commands

  dpkg -l chromium-browser
  snap info chromium-browser

are one way to find out whether that is correct.

> the package should handle it's own failure
> scenarios appropriately.

I'm not sure about that. Suppose the snap really can't be downloaded right now,
let's say, store is down. Then the installation failing is the only right
outcome as far as I can see.

Am 06/11/2024 um 13:51 schrieb <email address hidden>:
> Thank you for taking this bug on. If it was just a case of the snap
> taking a long time it would be tolerable, but in some scenarios it just
> hangs with the snap partially installed. This means the application
> isn't installed, and now installing it isn't possible without resetting
> snap to a consistent state.
>
> So to answer your question of what a good user experience would be:
>
> 1. Ideally, the snap would just install regardless of whether apt or
> snap initiated it. If I do `snap install chromium-browser` it works, but
> `apt install chromium-browser` is hit and miss and takes considerably
> longer to the point of timing out after 20 minutes. It's unclear why
> this is so different when it appears that apt is just calling the snap
> installation?
>
> 2. If the apt installation of chromium-browser fails, it should do so in
> a way that the system doesn't now believe that it is installed, even
> though the snap isn't available to run. As a result, the user could
> simply try the installation again with the hope it succeeds the next
> time, without needing to figure out how to get their system back into a
> state where the installation can be reattempted.
>
> I haven't tested the proposed solution, but if it works then I feel
> giving the user prompts to deal with the issue appropriately is helpful,
> but really is just a workaround. Ideally users shouldn't need to take
> the steps mentioned and the package should handle it's own failure
> scenarios appropriately.
>

I've tested this again just now and in typically I cannot get it to fail again on my computer. I've asked someone else to test and although it took about 10 minutes compared to the 10 seconds it took me, it did complete. This is despite us being sat next to each other on the same network and their device being a higher specification than mine.

After replicating this bug during the Ubuntu Summit, then me replicating the failure on a Canonical employees device in the same way, I'm certain in some scenarios it fails and leaves the device with a partially installed snap. Perhaps this is down to the snap taking a long time to download then hitting a timeout whilst the install is occurring? You can see a report of this in the linked bug #1891373.

To clarify when I say the package should handle its own failure scenarios, I don't mean that it shouldn't fail, just that it should put the system back into the state it was in before the failure rather than leave something behind that could cause problems with future installations. I appreciate that it may be difficult to do this if

I appreciate that this may be a difficult one to get to the bottom of and appreciate your patience.

In my case it failed to install because i killed apt thinking it had hung.
Apt normally downloads very fast, and provides feedback of the download
progress. So when apt just sat there for 20 minutes with no indication
that it was doing something, i killed it, i think that's quite a natural
reaction. Once the snap install was interrupted, you couldn't install it
via apt anymore. It wasn't obvious that it was calling snap, and it took a
bit of digging to discover the snap error and clear it.

The solution to me is that there should be some user feedback that it is
doing something and that we should just wait 30 mins because its taking a
hundred times longer than usual to download, but it is downloading
nonetheless.

On Thu, 7 Nov 2024 at 05:16, Daniel Walker <email address hidden>
wrote:

> I've tested this again just now and in typically I cannot get it to fail
> again on my computer. I've asked someone else to test and although it
> took about 10 minutes compared to the 10 seconds it took me, it did
> complete. This is despite us being sat next to each other on the same
> network and their device being a higher specification than mine.
>
> After replicating this bug during the Ubuntu Summit, then me replicating
> the failure on a Canonical employees device in the same way, I'm certain
> in some scenarios it fails and leaves the device with a partially
> installed snap. Perhaps this is down to the snap taking a long time to
> download then hitting a timeout whilst the install is occurring? You can
> see a report of this in the linked bug #1891373.
>
> To clarify when I say the package should handle its own failure
> scenarios, I don't mean that it shouldn't fail, just that it should put
> the system back into the state it was in before the failure rather than
> leave something behind that could cause problems with future
> installations. I appreciate that it may be difficult to do this if
>
> I appreciate that this may be a difficult one to get to the bottom of
> and appreciate your patience.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1886414
>
> Title:
> the chromium snap takes a long time to install without visible user
> feedback, seems stuck
>
> Status in chromium-browser package in Ubuntu:
> In Progress
>
> Bug description:
> after an initial attemp to install where the progress got stuck at
> 20%, i rebooted as there were a bunch of other system updates that had
> been applied after a fresh isntall.
>
> Now chromium wont install
>
> dantheperson@danski:~$ sudo apt install chromium-browser
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be upgraded:
> chromium-browser
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> Need to get 48.4 kB of archives.
> After this operation, 164 kB of additional disk space will be used.
> Get:1 http://nz.archive.ubuntu.com/ubuntu focal-updates/universe amd64
> chromium-browser amd64 81.0.4044.129-0ubuntu0.20.04.1 [48.4 kB]
> Fetched 48.4 kB in 0s (1...

The only outcomes that could occur are

apt ------ snap
error ---- not installed (1)
success -- installed (2)
error ---- installed (3)

Of course there is a period where the snap installation could be
in progress, but it should be a transitional state.

> leaves the device with a partially installed snap.

If the installation fails with the error reported in this bug ("snap
installation in progress" — exit status 10), then indeed the deb can be left in
some non-installed state[1]. The snap, however, will never be partially
installed. It will be either installed or in the process of being installed.
All that would be a correct outcome in my opinion, although I do not argue that
it is confusing that Apt says "I give up, the package installation fail"
whereas Snapd is nonetheless chugging along, installing Chromium albeit slowly
(outcome 3 above). I searched and asked around but could find no evidence for a
time-out in Dpkg's maintainer scripts.

If you ever get that again and can gather evidence of a partially installed
snap, please do correct me. I fail to see such evidence in LP:1891373 either;
There, the *deb* is partially installed, but then the user forced the Apt
process to end, which is usually indeed a bad idea.

> To clarify when I say the package should handle its own failure
scenarios, I don't mean that it shouldn't fail, just that it should put
the system back into the state it was in before the failure rather than
leave something behind that could cause problems with future
installations.

I agree there. There is a denominator problem that Apt does not handle
interruption well.

> I appreciate that this may be a difficult one to get to the bottom of
> and appreciate your patience.

I likewise appreciate your constructive comments and please let me know if
anything was unclear or if you disagree or if you have a suggestion to
reproduce the issue etc..

[1] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

Am 06/11/2024 um 16:07 schrieb <email address hidden>:
> I've tested this again just now and in typically I cannot get it to fail
> again on my computer. I've asked someone else to test and although it
> took about 10 minutes compared to the 10 seconds it took me, it did
> complete. This is despite us being sat next to each other on the same
> network and their device being a higher specification than mine.
>
> After replicating this bug during the Ubuntu Summit, then me replicating
> the failure on a Canonical employees device in the same way, I'm certain
> in some scenarios it fails and leaves the device with a partially
> installed snap. Perhaps this is down to the snap taking a long time to
> download then hitting a timeout whilst the install is occurring? You can
> see a report of this in the linked bug #1891373.
>
> To clarify when I say the package should handle its own failure
> scenarios, I don't mean that it shouldn't fail, just that it should put
> the system back into the state it was in before the failure rather than
> leave something behind that could cause problems with future
> installations. I appreciate that it may be difficult to do thi...

On the user feedback side, I found that the

        . /usr/share/debconf/confmodule

in the hook is causing the later 'snap install chromium' output to be
supressed. It is very weird because the "echo '==> ...'" is working.

Even getting rid of the carriage returns with

            snap install chromium | tr '\r' '\n'

does not help, no output.

After some hours I finally found that this is neither buffering nor carriage returns consumption nor changed behavior if stdout is not a terminal, but rather if *stdin* is not a terminal: https://forum.snapcraft.io/t/is-it-possible-to-get-the-installation-progress-or-removal-of-a-snap-with-the-process-running-in-backgroud/10538/2.

Reseting the stdin

  exec 0> /dev/tty

solves the lack of feedback problem as recorded.

Thank you for your explanation, I agree with your assessment of the situation, and your proposed fix. I can see you've posted a patch which looks like it should do what is needed.

Thanks again!

Not related to this bug but I wonder whether this problem also affects the Firefox snap?

Indeed, Firefox deb is doing essentially the same.

Why we haven't heard of it? Firefox is a seeded package (jargon for "installed
in a default install") so the number of explicit installations of the firefox
deb is certainly tiny compared to the chromium-browser one.

@Nathan Teodosio (nteodosio)

Thanks for the confirmation! I was wondering this as installing Firefox in a Vagrant VM that previous has no Ubuntu Desktop installed seemingly stuck in an unrelated progress reporting message:

Snap installation hangs at "Waiting for automatic snapd restart..." - snapd - snapcraft.io
https://forum.snapcraft.io/t/snap-installation-hangs-at-waiting-for-automatic-snapd-restart/43651

Hi brlin, while the attached patches will solve the lack of feedback, Snapd itself hides the pulling of depedencies behind a "connecting eligible plugs for $SNAP", so maybe that bit will still look stuck, but for that we already have the correct tree to bark at: LP:2052683 (:.

Hi Nathan,

To be clear, are you asking for sponsorship for your debdiffs? The sponsorship report flags you as someone with upload permissions on the packages in question?!

Cheers,
Simon

Hi Simon, indeed I got upload permissions meanwhile so let me remove ubuntu-sponsors from the subscribers list.

Also from 2024-12-02@#ubuntu-devel at least one modification to the patch is due:

--->
<cjwatson> (a) should probably be 0</dev/tty rather than 0>/dev/tty (b) needs somebody to explicitly test it in an environment without a controlling terminal to see what happens, since I'm not sure
<---

For me Gnome Software is not working, so I tried Synaptic and it works fine, but it does have a some sort of embedded terminal.

This bug was fixed in the package chromium-browser - 2:1snap1-0ubuntu3

---------------
chromium-browser (2:1snap1-0ubuntu3) plucky; urgency=medium

  * d/chromium-browser.preinst: Force stdin to be a tty so that snap install
    reports progress (LP: #1886414).

 -- Nathan Pratta Teodosio <email address hidden> Thu, 07 Nov 2024 12:42:26 +0100

This bug was fixed in the package firefox - 1:1snap1-0ubuntu7

---------------
firefox (1:1snap1-0ubuntu7) plucky; urgency=medium

  * d/firefox.preinst: Force stdin to be a tty so that snap install
    reports progress (LP: #1886414).

 -- Nathan Pratta Teodosio <email address hidden> Fri, 17 Jan 2025 13:49:08 +0100