[FR] Allow Subiquity not to execute unattended-upgrades

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.

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.

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.

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.

+1 for Pedro

+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.

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.

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 .

+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.

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.