No web browser installed in the canary image

Triage suggests a bug in image building, snap:firefox is still seeded in desktop-minimal. Suggest to analyse bugs to see what happens to seeded snap.

The reason for this is that we now 'seed' the snaps on the livefs via the installer model assertion, and currently we only seem to have the most required snaps seeded there: core22, snapd, ubuntu-desktop-installer. The snaps that come from seeds are now moved to the classic layer, which is not the layer used for the livefs. This feels like a bug, since we should make sure to pull in all the snaps as we have in the seeds right now, possibly. I don't think there's other options?

Okay, addressed with https://github.com/snapcore/models/commit/3898c5cbea9123600ae77955ca14cf185b546a55 .

Since I think I have all the model info that I need, I'll send these to signing and after that I'll update livecd-rootfs to use the new models.

I don't see all the printing snaps which are included in this manifest:

https://cdimage.ubuntu.com/ubuntu/daily-live/20230818.1/mantic-desktop-amd64.manifest

Was their omission deliberate?

...I think we need a better way of dealing with this. Since what I did right now is make sure that the livefs and the 'FDE target' model have the same set of snaps. But apparently the set of snaps we install on the canary target are... limited?
This warrants figuring a better way of dealing with snaps. Adding new snaps to the model assertion is problematic, requires a signing round and updates to livecd-rootfs. This is suboptimal. I think we need to somehow make the livefs layer use the seeded snaps that we basically 'rip out' to the classic layer right now.

I don't have the brain power to figure that out right now. Maybe mwhudson would have an idea for this already?

On Sat, 19 Aug 2023 at 08:02, Łukasz Zemczak <email address hidden>
wrote:

> ...I think we need a better way of dealing with this.

Yes.

> Since what I did right now is make sure that the livefs and the 'FDE
> target' model have the same set of snaps. But apparently the set of snaps
> we install on the canary target are... limited?
>

Yeah I don't know quite why that's the way it is.

> This warrants figuring a better way of dealing with snaps.

No kidding.

> Adding new snaps to the model assertion is problematic, requires a signing
> round and updates to livecd-rootfs.

However, I don't think there is a way around it (irrelevant correction: it
requires either an update to livecd-rootfs or an upload to the store via
APIs only store admins have access to).

> This is suboptimal. I think we need to somehow make the livefs layer use
> the seeded snaps that we basically 'rip out' to the classic layer right now.
>

I don't think we can do this. When seeding a system with a uc20 style model
assertion, snapd will only seed

> I don't have the brain power to figure that out right now. Maybe
> mwhudson would have an idea for this already?

I have a few ideas for some things we should do but there's no way around
the signing round bit aiui.

Here's what we should do IMO:

1. make a decision about a source of truth for which snaps are part of a
default Ubuntu desktop install (probably the seed definition)
2. Write some tooling to update the list of snaps in the pre-signing model
JSON for the classic desktop model definition
 (Note that these snaps should have "presence: optional" so they can be
removed after install)
3. Same for the model assertion for the live installer environmnet
(4. Set up something in the spirit of component mismatches to yell at us
when these sets of snaps get out of sync)
5. Change the code in livecd-rootfs to make sure that all snaps in the
model are included in the seed (by default, snapd does not include
"presence: optional" snaps in the seed)

separately, on the isos we used to run /usr/lib/snapd/snap-preseed to speed up first boot and snap startup.
Ideally we should still run that for the canary image with asserted-signed classic model.
The questions are if this is possible and how to do it specifically:

1) can we run /usr/lib/snapd/snap-preseed on the asserted-signed classic model system?
2) will that generate something else (like a tarball?) rather than lots of files in /var/lib/snapd like it was with legacy style unsigned classic models?
3) does the result of /usr/lib/snapd/snap-presseed require signing? If yes, how, and can it be done post-build? (i.e. livefs builder will not currently have access to the signing key)

See also bug 2032647 where we are waiting for snapd during the live session.

Right, this bug, bug 2031675 and bug 2032647 are likely different symptoms of the same issue.

In the 20230825.2 canary image, firefox is confirmed available in the live session.

I think any remaining questions of preseeding and performance should be taken to a separate bug.