Add an installer option to enable/skip unattended upgrades?

[suplero]

I just installed Kubuntu 20.04 on a test machine, and was booting it after the install.

It was working fine, but when I went to try to install new packages, and update the 400+ updates with synaptic, it gave me the "locked by another process" warning.

I waited a few minutes and tried the taskbar updater, and that also said, "locked by another process"

I did apt-get updates, and that worked, so I wasn't sure what the issues was.

Finally realized that unattended-updates is a thing now, and tried to kill it, etc, finally sudo rm lock to get me control of MY machine back.

Did my updates (all 400+ updates were still marked in synaptic, so no idea what unattended-updates was trying to do.)
Nuked unattended-updates from my machine, did some work. Of course a kernel update was installed, so did a reboot. The actual update with synaptic took about 5 minutes, which is way less than the time I waited for unattended updates to actually try to finish.

Upon shutting down, the computer actually said "Installing updates, do not turn off your computer." What? Not cool! I waited a little while, but finally nuked that as well with the power button, because I want to use MY computer.

Unattended-updates is way too window-esque for me, and I hate it. I want to control the updates myself, I want to know what the updates are, and what the status is. None of that is possible with unattended-updates.

Some suggestions:
1) put a check box on the installer for installing or not installing unattended-update packages. If I wanted to hand total control of my pc over to somebody else, I would use blasted windows. I don't care if it is enabled or not by default, I just want control.

2) put a slide screen on the install that "unattended updates" is a thing, and an instruction of how to remove it.

3) if, by all that is holy, unattended updates actually MUST be installed (for some bizarre reason), provide an informational widget and window that shows the status and what is being updates. What happens if unattended updates hangs? (which is what I suspect with my machine) How long do I lose the ability to update and INSTALL packages? Not having any indication that a major process is running is a huge flaw for me.

Unattended updates in the present form is a completely hidden package - there is no way to figure out what is happening and how it is running. Only by nuking it from the machine after install does the update process work properly, with information and status.

[jlittle]

(I presume a fresh install from an iso, and that you unchecked "download updates during the installation.)

When I installed 20.04, in April, I think I did not get unattended-upgrades, if only because I did the same as you, and immediately used apt to update and do a full-upgrade, which proceeded normally and took a while. What is the date on the iso you used?

[suplero]

I would guess I downloaded around mid-May.
Base 20.04 x-64 iso.

If there is any option that is checked during install which sets up unattended-updates, that should be clearly labeled. That is the one program that wrests control of your pc away from you, even though it is tiny.

[jlittle]

Having checked the APT configuration, I now think I was just lucky, in that there were few or not large security upgrades when I installed. Muon->Settings->configure software sources, updates tab, showed "Install security updates without confirmation" selected. I've now changed it to "only notify about available updates".

That caused /etc/apt/apt.conf.d/20auto-upgrades to read:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "0";
APT::Periodic::Download-Upgradeable-Packages "0";

We could edit that before booting into the new install, from a live session. I always run the installer from a live session anyway, so that I can run ubiquity with the -b flag to stop it from installing a boot loader, so it'll be easy to do the edit, if I can remember. The documentation about that is in the comments in /usr/lib/apt/apt.systemd.daily.

I might give that a try on a test install...

I don't mean at all to dismiss your irritation (if that's the right word, "anger" seems too much, or slightly critical) at Windows-like behaviour. But, we're in a world where turning on automatic security updates by default is generally a good idea.

[jlittle]

What is the date on the iso you used?

That was a pointless question, sorry. The Kubuntu 20.04 iso hasn't changed since the release date, and I expect it won't unless there's a 20.04.1 release.

[jlittle]

... /etc/apt/apt.conf.d/20auto-upgrades ...
We could edit that before booting into the new install...

I might give that a try on a test install...

I tried it, and it worked, as far as I could tell. On logging in, Discover immediately said there were lots of upgrades available, and upon listing them with apt list --upgradable, I could see some were security updates, and then I was able to run apt full-grade, which took over half an hour, much longer than the install.

[suplero]

I honestly don't know when or how unattended-updates triggers, and that is part of the problem.

For me, it triggered on the boot after x amount of time - probably at least 2 weeks, based on the number of upgrades.

unattended-updates installing might be based on either time of last update or criticality of the updates that are found. In either case, I will stick to my statement that doing anything without the user's permission - that potentially takes control of my machine away - is a very dirty microsoft tactic, and should be prominently displayed somewhere - during install and especially when the program is running.

All those reports of windows rebooting during presentations or in the middle of writing a college essay - don't copy that behavior in Kubuntu (or any Linux for that matter).

[jglen490]

Open Muon and look in Settings -> Software Source -> Updates tab.

[suplero]

Not to attack you - but where is this documented?

That is the issue - these "unattended-upgrades" (which is an actual package that is installed!) are not documented.

Unless the user knows what is going on, there is no way for them to know what has hijacked their machine!

And I never use Muon, so even though it is installed, I would never think to look there, as I feel that is a package (like everything else unless specifically started) that should say dormant until I start it. There should be no system level settings in any package. And settings of any individual package should be for that package only.

I know windows abuses the hell out of this, but Linux should not copy windows in any way.

System settings is where system level changes should be made.

It could be that I am the only one that seems to be affected by this, and if that is the case, i'm sure this whole soapbox seems like just a complaint. Guess I'll just make a sticky that says "NUKE unattended-updates" so any time I reinstall I know what needs to be done to fix it.

How many non-aware users are suffering because of zero documentation? I only heard of unattended-updates from a blog post complaining about it the same way I am, and that is how I figured out how to kill the lock when I actually WANTED TO USE MY machine. Very sad.

[jlittle]

System settings is where system level changes should be made.

I agree, and I have a vague memory that it once was in system settings. But, it was just an invocation of /usr/bin/software-properties-kde. You can get to it in Discover, too.

but where is this documented?

Alas, IMO this is a general problem with KDE, and Ubuntu, and it seems to me to be getting worse. There's lots of wikis last updated years ago. The best place for documentation is the Arch wiki. In my digging for documentation about this stuff, I got into the weeds of systemd, and found that there can be a random jitter applied to systemd services, and for the apt daily service it's "60m". So, the bit in my post #4 about being lucky might have have been on the nail.

[jglen490]

Not to attack you - but where is this documented?

That is the issue - these "unattended-upgrades" (which is an actual package that is installed!) are not documented.

Unless the user knows what is going on, there is no way for them to know what has hijacked their machine!

And I never use Muon, so even though it is installed, I would never think to look there, as I feel that is a package (like everything else unless specifically started) that should say dormant until I start it. There should be no system level settings in any package. And settings of any individual package should be for that package only.

I know windows abuses the hell out of this, but Linux should not copy windows in any way.

System settings is where system level changes should be made.

It could be that I am the only one that seems to be affected by this, and if that is the case, i'm sure this whole soapbox seems like just a complaint. Guess I'll just make a sticky that says "NUKE unattended-updates" so any time I reinstall I know what needs to be done to fix it.

How many non-aware users are suffering because of zero documentation? I only heard of unattended-updates from a blog post complaining about it the same way I am, and that is how I figured out how to kill the lock when I actually WANTED TO USE MY machine. Very sad.

I appreciate that. And as for me, understanding that Linux is not always documented completely, and knowing that Linux devs - while very devoted people - are not always inclined to document what they have built, I just have curiosity about things. I used Muon long before using Synaptic, and while I have investigated Discover, I don't use it for much. So stuff sticks to my brain. Sometimes its incorrect stuff, sometimes not, but the only reason I refer to Muon these days is because it's the one GUI program that best shows the configuration of the apt packaging system - without having to dig through the command line swamp all the time. I love the command line, but there are limits.