last-minute surprise /var/cache/swcatalog/cache/C-os-catalog.xb in mantic images

[Steve Langasek]

Our last respin of the Ubuntu Desktop ISO for mantic to pick up a new version of the ubuntu-desktop-installer snap also unexpectedly increased the total image size by 50MiB.

Tracked this down to the addition of a new file under /var/cache:

$ du -sh /mnt/*/var/cache/swcatalog/cache/C-os-catalog.xb
8.4M /mnt/2/var/cache/swcatalog/cache/C-os-catalog.xb
$

This file gets compressed, but we get a SEPARATE copy of it in each of the per-language squashfs layers on the system.

Previously, this file WAS present in the minimal.enhanced-secureboot.squashfs, however something has changed to cause this file to be different in each of the per-language layers on top of this.

A copy also ended up in casper/minimal.standard.live.squashfs that had not been there before.

I think the image builds should enforce an allowlist of files allowed under /var/cache and fail the build for unexpected contents for each given squashfs layer.

[Steve Langasek (vorlon)]

Note that the actual content likely came from /etc/apt/apt.conf.d/50appstream:

# Refresh AppStream cache when APT's cache is updated (i.e. apt update)
APT::Update::Post-Invoke-Success {
    "if /usr/bin/test -w /var/cache/swcatalog -a -e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || true; fi";
};

[Steve Langasek (vorlon)]

> APT::Update::Post-Invoke-Success {

This also implies that the hook is only run because we're doing a fresh 'apt-get update' in each squashfs layer, which we really shouldn't do; if the archive we're building against changes during the build, we should ignore it anyway and keep a single coherent view of the archive for all layers as part of a given build.

the actual call to apt-get update is buried deep in the live-build abstraction, of course.

[Launchpad Janitor (janitor)]

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