snaps not preseeded on Kinetic images

When the Lubuntu ISO is first booted, quite a bit of processing power is used. Opening htop reveals that a bunch of activity related to Snap is going on. It went by too fast for me to be sure that I captured everything, but the general order of CPU hogs is:

snapd
unsquashfs
ssh-keygen
/sbin/init/splash
snap ld-2.23.so (possibly two times?)
snapd
/sbin/init/splash
snapd
apparmor
/bin/sh firefox
apparmor
unsquashfs
apparmor
snapd

The ld-2.23.so process appears to hog a lot of power for a while, as if there's some linking process or similar going on behind the scenes. The sudden appearances of apparmor and the "/bin/sh firefox" bit also are interesting.

Once all of this CPU hogging finishes, then Firefox appears in the application menu. (It might show up before then, but I know it always shows up after that.)

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

This bug also manifests itself on the first boot of Lubuntu immediately after installation, however on the second boot the problem does not seem to occur. (This is on BTRFS installations of Lubuntu with UEFI+Secure Boot in a VM, I've not yet tested other filesystems but I intend to.)

Further to comment #4

I also tested full disk installs with xfs + UFI+secure and bug was present in all cases as described in above comment.

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

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

'snap-preseed' was failing to run during the ISO build, so it was removed from livecd-rootfs. This results in snaps now taking a couple of minutes to show up when the ISO is booted for the first time, or when a fresh install has been booted for the first time (as 'snap-preseed' would do some of the first boot snap tasks during the ISO build). So this is expected behavior for now.

I tested Lubuntu kinetic-desktop-amd64.iso dated 2022-09-27 persistent live via mkusb: dus-persistent from an SSD connected via USB in a Dell Precision M4800 in UEFI mode and BIOS mode. It works, also Firefox works.

I read about the delay of Firefox, but did not notice that it is much slower than before. I might notice a slow response in a slower computer or with less RAM or with a slower USB drive, for example a pendrive. If I check the time carefully I will probably also find that Firefox is slower the first time compared to before (but Firefox-snap in previous daily isos of Lubuntu was also slower than Firefox-apt).

Anyway, the current Lubuntu works when persistent live and this was the main purpose of my test today.

Comment #7 is correct and we expect to revert the change to livecd-rootfs before the final release of Ubuntu 22.10 (kinetic). For the record the changes can be found here:

https://launchpad.net/ubuntu/+source/livecd-rootfs/2.785

The snapd bug is being tracked separately in bug 1990884, so I'm closing that task but lets keep this bug open for the release notes and for tracking the revert of the "fix" to livecd-rootfs.

I tested the next Lubuntu kinetic-desktop-amd64.iso (dated 2022-09-27 21:11) persistent live via mkusb: dus-persistent from an SSD connected via USB in a Dell Precision M4800 in UEFI mode and BIOS mode. It works, also Firefox works.

This time I noticed the bug, but within 20 seconds after the first try, Firefox was there.

This bug was fixed in the package livecd-rootfs - 2.789

---------------
livecd-rootfs (2.789) kinetic; urgency=medium

  * re-enable snap preseed (LP: #1991011)

 -- jchittum <email address hidden> Thu, 13 Oct 2022 12:41:23 -0500

Just tested for this & looks good (lubuntu kinetic 20221017.1), thanks