Rant warning: Given how cross I am just now, first I want to set out my position clearly in case someone is going to say something that will really upset me. Please bear with me while I rant:

Opinions may differ, but mine is that in this day and age every operating system installation should be as close to self-service auto-updating of all of its applications as possible. One of Linux's killer strengths is the concept of a universal package manager or (co-operative collection of managers if you must) that can routinely keep the system up to date, unlike Windows, where every program has a different AA mechanism and most none at all. There should never be an occasion where any regularly used PC gathers digital dust, however lazy the user. Especially in a corporate environment: here every PC's updates should be the responsibility of the network managers. That's what they are paid for.

Old software puts a huge support burden on already overburdened open source developers that we cannot afford; worse still, it invites attack from the increasingly damaging community of cyber-criminals.
'But updates break stuff' you complain - this is patently true - I recently had cause to want to do something colourfully unconstitutional to members of the MySQL team for version 8.0.22 - an auto-update there broke my most important system, causing me several hours of bug-hunting and fixing. But blaming that on the use of auto-updates is missing the point - that is bit like blaming road traffic accidents that involve emergency ambulances on the concept of having ambulances. Better to let everyone drive themselves to A&E. But you don't get rid of ambulances - you make sure they are as safe and reliable and well-driven with as well-trained staff as possible. In the software world, you make sure your updates are as thoroughly tested as machinely possible. The world has changed: software changes, rapidly - the contract between the users and the small public software team is now something like 'we users agree not to pull out the nastiest prehistoric release of your product asking for a fix if you developers agree to make the latest version as bug free as you reasonably can'. So please don't start talking about 'but you can always manually update'. My Neon desktop has been without updates for just 12 days and there are 615 updates pending. Regular users don't care about updates and don't know what they are or why. They should just happen for them. Power-users like myself have better things to do than waste time running the updates every time we switch our computers on. Some actually like the idea of having the computer turn itself on at 1am (assuming we are not still working then), do it's updates without complaint and shut down automatically.

Rant over. Now the actual problem.

My apt is demon-possessed. No seriously.

My problem is that the one Linux system I cannot get to unattended upgrade reliably for more than five minutes is my Neon desktop daily driver. This nightmare started on 18.04 - every time I configured and turned on auto-updates, a few days or weeks later an update would turn them off - deleting one of the configuration files (20auto-upgrades IIRC). I never got the problem 100% resolved. Now I am seeing this on my new 20.04 Neon install. Every time I try to enable auto updates, this is what I get:

Code: Select all

~$ sudo dpkg-reconfigure -plow unattended-upgrades
Not replacing deleted config file /etc/apt/apt.conf.d/20auto-upgrades

I think this warning is new. The last update ran twelve days ago, going by the date stamp on the files in /var/log/unattended-upgrades/.

I have also tried several commands from posts here on the board, e.g. https://forum.kde.org/viewtopic.php?f=309&t=162783&p=427243&hilit=automatic+updates#p427243:

Code: Select all

 ~$ echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' | sudo debconf-set-selections
 ~$ sudo dpkg-reconfigure -f noninteractive unattended-upgrades
Not replacing deleted config file /etc/apt/apt.conf.d/20auto-upgrades
 ~$ debconf-show unattended-upgrades


The warning just kept appearing - the configuration file is not there. And no updates happen. Running:

Code: Select all

~$ sudo unattended-upgrade --dry-run


shows lots of potential upgrade activity, but the process never actually gets called. if I run:

Code: Select all

~$ sudo systemctl start apt-daily-upgrade.service
~$ sudo systemctl status apt-daily-upgrade.service


I get:

Code: Select all

● apt-daily-upgrade.service - Daily apt upgrade and clean activities
     Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.service; static; vendor preset: enabled)
     Active: inactive (dead) since Sat 2020-12-12 13:07:45 GMT; 8min ago
TriggeredBy: ● apt-daily-upgrade.timer
       Docs: man:apt(8)
    Process: 43356 ExecStartPre=/usr/lib/apt/apt-helper wait-online (code=exited, status=0/SUCCESS)
    Process: 43378 ExecStart=/usr/lib/apt/apt.systemd.daily install (code=exited, status=0/SUCCESS)
   Main PID: 43378 (code=exited, status=0/SUCCESS)

Dec 12 13:07:45 mainscreenlx07 systemd[1]: Starting Daily apt upgrade and clean activities...
Dec 12 13:07:45 mainscreenlx07 systemd[1]: apt-daily-upgrade.service: Succeeded.
Dec 12 13:07:45 mainscreenlx07 systemd[1]: Finished Daily apt upgrade and clean activities.


But no actual updates. I have looked into the config files. There is no 20auto-upgrades file and there clearly is another config file disabling the auto-updates, that no-one owns:

Code: Select all

~$ ls -l /etc/apt/apt.conf.d/20*
-rw-r--r-- 1 root root  202 Dec 22  2019 /etc/apt/apt.conf.d/20listchanges
-rw-r--r-- 1 root root 1040 Sep 23 11:55 /etc/apt/apt.conf.d/20packagekit
-rw-r--r-- 1 root root  114 Sep  4 16:42 /etc/apt/apt.conf.d/20snapd.conf
~$ find /etc/apt/ -type f -exec grep -H Periodic '{}' \;
/etc/apt/apt.conf.d/10periodic:APT::Periodic::Download-Upgradeable-Packages "0";
/etc/apt/apt.conf.d/10periodic:APT::Periodic::Unattended-Upgrade "0";
~$ dpkg-query -S 10periodic
dpkg-query: no path found matching pattern *10periodic*


Now, I could just re-instate 20auto-upgrades and/or change 10periodic, but I am none the wiser to what the cuplrit was, and judging by past experience, it won't take - something will undo the changes. Something in the system is fighting me and I want to know what and why, and I want to know who thinks it's such a great idea to break auto-updates.

Can anybody help me with this madness?

Hi!
I don't want to go into your rant because I have different opinions, thats why I am running arch

I've read about KDE neon, that they do not support the full-apt-compatibility and you should upgrade with `pkcon update && pkcon refresh` which would be like `apt update && apt full-upgrade` but I couldn't find the topic in a hurry. As the apt update-part is not supported, you could check the unattended-upgrades-logs ( /var/log/unattended-upgrades/unattended-upgrades.log*)

Besides this, the unattended-upgrades are nothing you can rely on, as they cannot catch every possible situation. You have to manually update your system from time to time or in situations unattended-upgrades cannot do it: see https://wiki.ubuntu.com/AutomaticUpdates for explanations.

Minimum entries for /etc/apt/apt.conf.d/10periodic:

Code: Select all

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


APT::Periodic::Unattended-Upgrade set to 0 would disable the whole unattended-upgrades-stuff.

@koffeinfriedhof thank you for your reply.
I fully expect to have to manually intervene now and then - just not every day. I am aware of pkcon, but If pkcon is going to replace apt, it needs to do the unattended stuff too. Yes, I can place / replace the entries in 10periodic and or 20periodic and I am sure it will work - for a while. My problems is this, something disabled unattended updates in a way that invalidates much of the technical advice on this forum and others, and in a way that means you have to hack the config files rather than using either the standard dpkg-reconfigure or debconf commands, or the GUI to get them back. What did that and why? How do I stop it from doing it again? From experience it will do so at some point soon.

pkcon does not replace apt, it actually uses it to update and install/remove things, so it is not a factor in this issue.

This is not a Neon-specific issue, and may be worth investigating in other places that may have more Ubuntu-specific knowledge, in addition to what turns up here.

As claydoh mentioned, pkcon does not replace anything. It is just a wrapper which could be configured to use underlying tools like apt/apt-get/dpkg on debian based, pacman on arch and dnf on centos, etc.
Perhaps you get the answers you're looking for from the debian maintainers / developers themselves at [https://github.com/mvo5/unattended-upgrades], after investigating what exactly did disable unattended-ugrades. I do only use some virtual machines running Kubuntu and KDE neon and always disable this feature as I do updates my own way. The state never changed, neither after upgrading from 18.04 to 20.04, nor after removing all python2-stuff after its end of service.

Thank you all for your help.
I have a number of different Ubuntu systems, both at work and at home and have had for many years, all with unattended upgrades fully enabled. The only system that has given me this much grief is this one running Neon. I get the usual problems with all the others, stalled updates due to incomplete upgrades; packages that need user interaction; services who's repos go away or move without warning, out-of-date keys etc. This system is the only one where it seems to want to actively fight me, by turning unattended upgrades off eriodically. When I installed 20.04, I clean installed it, but experienced exactly the same issue as 18.04.
The pattern from previous experience is that there is a core Neon package somewhere that, when upgraded, triggers some kind of configuration refresh. That process then overwrites my apt config changes from some KDE-specific 'master source', in which auto-updates are notionally turned off. I thought debconf might be that source, but apparently not. It feels very much like a typical layered configuration problem, similar to such as has plagued network and Wifi configuration on Linux in the past. In that case, you have various competing hidden management programs at different levels, all vying for control, and if you follow a guide that predates those tools, things just get worse. As a similar example, I had lots of fun just working out unattended-upgrades no longer runs under cron, but systemd.
Can anyone suggest anywhere in the system to look please?

I don't know where to look at, as I am not a developer or interested in how Ubuntu/Debian really works. But why mess around with it? Just disable the apt-daily-upgrade.service and create a custom systemd-unit with another name, running the command you want to, e.g trigger `unattended-upgrade --no-minimal-upgrade-steps` via this unit.

I am using a simple Alias in my shell configuration

Code: Select all

alias upd='sudo apt update && sudo apt full-upgrade && sudo apt autoremove'

and start it opening a terminal window, like e.g. in Yakuake and just type upd. So there is no GUI hiding sutff, I can decide when to upgrade and see what to upgrade. You can start the full-upgrade and autoremove with the --yes - flag too, but I would not recommend it. As a workaround and if you know how to fix minor dpkg-errors, you could just use these commands to automatically upgrade your system. I've used this for years on a ubuntu homeserver instance with only some minor issues. Again: not recommended

Can anyone suggest anywhere in the system to look please?

I think that the file /etc/apt/apt.conf.d/50unattended-upgrades could be overwritten by upgrades which is the apt-configuration file. Perhaps you just can copy it to /etc/apt/apt.conf.d/90-my-unattended-upgrades to be sure that the apt config itself stays stable.