[FR] Allow Subiquity not to execute unattended-upgrades

[Pedro Principeza]

[Description]
A user may want to install Ubuntu Server and only rely on the package versions available at the installation media, and _not_ to use unattended-upgrades to get the latest package versions from the archives at the post-inst section of it.

The idea is to avoid the execution of:

 subiquity/Install/install/postinstall/run_unattended_upgrades

Today, there is no way to prevent that execution from happening.

[Use Cases]
There are cases in which the installation of Ubuntu _needs_ to bear an exact package version in all deployments of a fleet, for instance. Not reaching out to the archives to update whatever is at a certain version guarantees this requirement.

[Workarounds]
None. As of now, u-u is executed regardless.

[Michael Hudson-Doyle (mwhudson)]

IMO the way to do this is by either pointing the installation at a mirror you control the contents of (the better option) or by disabling network during install (and re-enabling it in a late-command or whatever).

Simply disabling the uu run is not enough to achieve the stated goal as the kernel is in general installed from the configured archive. Also we configure unattended upgrades to run automatically, so without further effort the installed system will get the updates fairly soon after boot anyway.

[Pedro Principeza (pprincipeza)]

Michael,

What if the sources in all squashes available are reduced to `file:///cdrom` (i.e. ditching the archive/security URLs)? Would that be a blocker on any part of the installation, to only use what's in the media?

Thanks.

[Michael Hudson-Doyle (mwhudson)]

Pedro, that's what happens when the network is disabled for the install. We could decouple that setting from the network I guess... but I'm not sure it's a good idea.

[Pedro Principeza (pprincipeza)]

Michael,

Network might be useful (even needed) for some other installation tasks; ideally, having a way to only disable the u-u would still leave the network part untouched.

I wonder if it would make sense to have a, say, a Kernel cmdline option to pass onto Subiquity to disable u-u, so that is not exposed as an option in the install screen. This would, IMHO, need some knowledge from whoever is installing the OS beforehand. Dunno.

Let me know what you think. Thanks.

[Yusuf Güngör (yusuf2)]

+1 for Pedro

[Kodiak Firesmith (kfiresmith-whoi)]

+1 from this UA customer. It's extremely annoying to not have any control over my workflow in this regard when it comes to the OS deployment.

We want certain things to happen via certain triggers. Part of that is a quick vSphere based VM deployment via autoinstall, then to have Ansible take over.

We also don't want intermittent failures in package availability to break an ongoing autoinstall, which is what just happened to me and brought this issue back to mind.

[Brendan Holmes (7-mc-d)]

Agreed should be a way of disabling updates without disabling network completely. Many people who auto-install need to iterate quickly during development. I expect a common pattern would be to re-enable updates prior to productionising/reaching master branch.

The way most people would expect updates to be disabled is using:
autoinstall.refresh-installer.update = no
But that doesn't work. I think the documentation on this should be clarified.

[Andreas Ntaflos (daff)]

As someone who deploys many, many machines every month I would also like to be able to skip unattended-upgrades, simply because it takes way too long. A regular installation takes almost 25 minutes, and a good 20 minutes of that is spent on unattended-upgrades. This is because unattended-upgrades is configured by default with the "minimal steps" option.

A useful alternative to skipping unattended-upgrades would be to allow configuring unattended-upgrades to *not* use minimal steps when running, i.e. set

    Unattended-Upgrades::MinimalSteps "false";

somewhere in /etc/apt/apt.conf.d/.

This would at least dramatically speed up the installation: without minimal steps unattended-upgrades is done in about 3 minutes. I have tested this by manually adding the above setting in /target/etc/apt/apt.conf.d/99zzz-unattended-non-minimal during installation, just before unattended-upgrades runs.

Unfortunately there is no way to set this option and have it persist until unattended-upgrades runs.

Using

    apt:
      conf: |
        Unattended-Upgrades::MinimalSteps "false";

sets the option in /target/etc/apt/apt.conf.d/94curtin-config but that file is deleted after curtin has set up the configured APT sources and before unattended-upgrades runs.

There would need to be a dedicated setting for subiquity that adds this option to (probably) https://github.com/canonical/subiquity/blob/main/subiquity/server/controllers/install.py#L472 .

[klausfiend (klausfiend)]

+1 for having more options with this behavior.

We have automated Ubuntu VM image building since U14, and up until U20, a full build for multiple distros in parallel took less than ten minutes front to back, including automated quality control checks. The unattended-upgrades step -- even with local mirrors, caching proxies, incredibly bare bones installs, etc., -- adds several minutes to build jobs, sometimes enough to cause a build to fail because the build worker spends too much time waiting for it to finish updating.

I think there's a balance to be struck here: when these images are deployed within our cloud, we have other tools and mechanisms in place to keep them up-to-date, and a given image may be used for a month or longer depending on circumstances, so all that time spent upgrading during the original image build is subject to rapidly diminishing returns. Disabling networking as a way to prevent this from happening is a complete non-starter, because every piece of all of our provisioning toolchains have explicit dependencies on other services on our internal network.

I think it's great to be able to do this within the install environment, but it can be a real nuisance if you're working on tight schedules in already controlled environments; having the flexibility to decide when and what to upgrade during provisioning would be very helpful.

[Stephen Collier (stephenc123)]

This is also affecting us. Once again we use ansible to add our own repos and update after installation. Servers do not have internet access, we are a regulated secure environment and we use foreman for provisioning.