lubuntu noble - full (inc. 3rd party) install is kinda slow

[Chris Guiver]

This is NOT a bug that can be fixed with code.

At most a fix maybe a line in the release notes, that selecting all 3rd party software for inclusion can be SLOW IF you're using 3rd-world, some aussie NBN or other older/slower internet connections (or just infrastructure at canonical end anyway).

This report has been filed ONLY for timing purposes; so I can look, and have record of how long install actually took (with calamares running)...

A watched kettle always appears to take longer to boil... I was sitting watching this install & for a long time is stayed at 90% with slideshow repeating... I switched to show all messages and it didn't scroll up for maybe 10 mins there either..

I actually CTRL+ALT+T and opened a terminal, made it full screen on this boxes other display & `sudo apt install iotop` and let that run... From there I could see downloads taking place (thru write) & eventually notice `snap download` progress to next package (krita, kf5 etc)... but the installer window remained at 90%.. eventually 92%... |

Many users may assume the installer is 'looping' or dead...

2024-04-16 - 02:17:35 (start of calamares)
2024-04-16 - 12:17:43 (calamares switched to local time I assume)
2024-04-16 - 12:48:06 (end calamares)

So ~thirty minutes to install, I didn't let it sit at any dialog.. just selected items & continued...

This box may not be quick... but I believe issue is mostly internet speed & what is required to be downloaded.. something we can't do much about it..

Is a release note worth including??

Could a end-user think the install has failed is looping, when in fact it isn't....

I don't see how we can change anything, as even viewing the messages calamares provides I didn't see progress for near 10 mins... thus why I opened terminal & starting watching progress via `iotop`

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: calamares 3.3.5-0ubuntu3
ProcVersionSignature: Ubuntu 6.8.0-22.22-generic 6.8.1
Uname: Linux 6.8.0-22-generic x86_64
.etc.calamares.modules.after_bootloader_context.conf:
 ---
 dontChroot: false
 timeout: 120
 firmwareType:
     "*": "-rm ${ROOT}/home/${USER}/Desktop/lubuntu-calamares.desktop"
.etc.calamares.modules.finished.conf:
 ---
 restartNowMode: user-checked
 restartNowCommand: "systemctl -i reboot"
.etc.calamares.modules.fstab.conf:
 crypttabOptions: luks,keyscript=/bin/cat
 efiMountOptions: umask=0077
.etc.calamares.modules.shellprocess_logs.conf:
 ---
 dontChroot: true
 timeout: 30
 script:
     - calamares-logs-helper ${ROOT}
.etc.calamares.modules.unpackfs.conf:
 ---
 unpack:
     - source: "/cdrom/casper/filesystem.squashfs"
         sourcefs: "squashfs"
         destination: ""
ApportVersion: 2.28.0-0ubuntu1
Architecture: amd64
CasperMD5CheckResult: pass
CasperVersion: 1.496
CurrentDesktop: LXQt
Date: Tue Apr 16 12:48:16 2024
LiveMediaBuild: Lubuntu 24.04 LTS "Noble Numbat" - Beta amd64 (20240415)
RelatedPackageVersions:
 calamares-settings-ubuntu-common 1:24.04.28
 calamares-settings-lubuntu 1:24.04.28
 xfsprogs 6.6.0-1ubuntu2
 btrfs-progs 6.6.3-1.1build2
SourcePackage: calamares
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/2061711

[Erich Eickmeyer (eeickmeyer)]

Hey Chris,

If this isn't something that can be fixed with code or with a package update, and while I don't feel like it is something that *can't* be fixed, I think the status needs to be "Opinion" because it's certainly worthy of discussion.

[Chris Guiver (guiverc)]

Of no importance.. but the 10 mins nothing will likely be

2024-04-16 - 12:32:43 [6]: .. Running ("/bin/sh", "-c", "snap-seed-glue --seed /tmp/calamares-root-hazyaxmi/var/lib/snapd/seed krita")
2024-04-16 - 12:45:09 [6]: .. Running ("/bin/sh", "-c", "snap-seed-glue --seed /tmp/calamares-root-hazyaxmi/var/lib/snapd/seed thunderbird")

after krita I noticed (& mentioned) a kf5 snap.. but that detail would have come from my viewing `iotop` and the `snap download` command that showed there.

[Simon Quigley (tsimonq2)]

This bug is certainly worth noting, but I do not believe anything can really be done about it.

The problem comes down to, how do we get the software the user is willing to install? We could put it in a layered or separately-mounted squashfs, but that is unfair to users who just want a normal install, especially if we want to be able to extend these options next cycle. Also, if no network access is available at all, these options are completely hidden anyway.