Unattended Upgrades Working in LM 18.1 or 18.2??

[asciiman]

Hi everyone-

I am planning on migrating a user from Mint 17 up to 18.1 and one of the features I am using in their Mint 17 is Unattended Upgrades.
I have it set up only for Mint and Ubuntu security upgrades.

I noticed that on my testing machine LM 18.1 Cinnamon has not included the Unattended Upgrades package.
I seem to remember in earlier versions Unattended Upgrades automatically came down from the Ubuntu repos (correct me if I am wrong).

I can certainly install it manually, but I wanted to inquire here first, just in case there is a known problem with Unattended Upgrades on 16.04 or Mint 18.1.

Can anyone advise me as to the status of this?

Thanks in advance,
Allen

[JoeFootball]

I seem to remember in earlier versions Unattended Upgrades automatically came down from the Ubuntu repos (correct me if I am wrong).

I agree, as I do see it in 17.3, but not in 18.1.

... just in case there is a known problem with Unattended Upgrades on 16.04 or Mint 18.1.

Being an Ubuntu package, I wonder how it could discern Linux Mint software upgrade levels, and therefore is incompatible on principle, and thus no longer included by default.

While I can't speak for everyone, I know that I have a personal problem with upgrading software unattended. I prefer to use the Update Manager, where I can evaluate what I want to upgrade, and when I want the upgrade to occur.

Joe

[MintBean]

I don't know anything about the unattended upgrades but if you were willing to upgrade to 18.2, it introduces a command-line method of accessing updates not just with apt, but with full access to the Mint level system.
The command is mintupdate-tool (type 'mintupdate-tool -h' (no quotes) in a terminal for more information). You could create a cron job to execute the command on a scheduled basis.

[asciiman]

Being an Ubuntu package, I wonder how it could discern Linux Mint software upgrade levels, and therefore is incompatible on principle, and thus no longer included by default.

Hi Joe!
Thanks for the reply.

You are correct in that Unattended Upgrades does not recognize the Mint upgrade level system.
However, I found that using it strictly for security upgrades, for both the Ubuntu core and for Mint itself, it worked very well in the LM 17.x series.
And this is for machines that pretty much run 24/7 and are never turned off other than to be rebooted every so often.

But I am just wondering if there were known issues with the 18.x series.

In my initial search here at the LM Forum, I did see one post where a LM 18 user was having problems with his machine taking forever to shut down as Unattended Upgrades was doing its upgrading at shutdown. But that might have been "pilot error" since "upgrade at shutdown" is a valid feature of the UU package. He might have accidently uncommented that line in the script.
But that is the only post I saw here and it was never stated what the actual issue was or how he resoved it.
Hence my post.

I would like to see the Mint Team develop something like UU that is an option within the regular Update Manager (Mintupdate) GUI.
Something that would in fact follow the levels selected by the user, or at minimum allow for the option to automatically install security updates like the official Ubuntus can do. At least give us the option in the Update Manager's GUI. The Ubuntu's will even upgrade kernels from time to time, usually leaving the two most recent kernels in the Grub2 loader. Mint now has something similar, but the install has to be done manually. It's not a big deal, but it might be nice to just have a simple check box to allow the Update Manager to auto-install a new security-level package (as differentiated from a new kernel).

Mint's Update Manager has continued to improve, and I have seen steady progress moving perhaps in this direction.
So I am certain the concept has at least been discussed. We shall see what the future brings.

But back to today, if anyone knows anything specific about Mint 18.x and how it is working with Unattended Upgrades, please chime in.
I suppose I could install and configure it and see what (if anything) breaks, but I would rather not have to do that, lol.

Allen

[JoeFootball]

I am just wondering if there were known issues with the 18.x series.

I am unaware of any technical issues with the package and 18.x, but I concede that I don't have any familiarity with it on any Linux Mint version.

Joe

[asciiman]

I don't know anything about the unattended upgrades but if you were willing to upgrade to 18.2, it introduces a command-line method of accessing updates not just with apt, but with full access to the Mint level system.
The command is mintupdate-tool (type 'mintupdate-tool -h' (no quotes) in a terminal for more information). You could create a cron job to execute the command on a scheduled basis.

Hi Mint-
Thanks for that.
I just checked it out and it looks interesting.
Is there a place to go to read up on what the various command modifiers really do?
For example, when using the --install recommends, what does that really do?
Or say the --security option: does that differentiate between security updates and kernel updates?
That kind of stuff is what I am looking for.

Looks useful though!

[MintBean]

I don't have any further information. When the feature was announced, all the documentation said was to use the built in help for further information.

The 'install recommends' option treats recommended packages as dependencies and installs them. I enable that option in synaptic (which enables it system wide, including on the command line for apt). Obviously you would have to look at individual packages in synaptic to see what they 'recommend.' It's usually plugins and the like that enable the full feature set of an application.

[JoeFootball]

When the feature was announced, all the documentation said was to use the built in help for further information.

Yes, that help has some room for improvement. I predict some experience will enable some informative tutorials in the future.

Joe

[asciiman]

Just an observation:

On a "twice upgraded" version of LM 18.2 (original install LM 18.0), I noticed that Unattended Upgrades IS INSTALLED and is current (v. 0.9ubuntu0.6) and supported by Mint 18.2.

UU_in-LM18.2.png

I can't say if this is just left-over from the original LM 18.0 install, but I can say that LM 18.1 DID NOT have U.U. installed.

I may try setting UU up for security updates in 18.2 just to see how it goes.
Will report my findings.

[asciiman]

Hey something unexpected showed up:

NOTE:
Because I was unsure why 18.1 didn't seem to come with UU, and 18.2 did, I am experimenting with LM 18.2 here:

After I set up UU per the old method, I did the usual dry run to make sure my listed repo sources were OK.
When I opened the UU log file, there were a bunch of prior UU runs listed and a couple of UU archives as well.
So UU has been running all along! Never seen that before in Mint!
Of course, because there were no listed sources (until today), UU just came back empty handed.

So I started looking around and found the file 20AutoUpgrades...

20AutoUpgrades.jpg

It looks like APT is already checking package lists daily and running UU daily.

So my question is: Does this new routine render the old 10Periodic file superfluous?

I have more questions on this, but I will wait for now.

Thanks,
Allen

[asciiman]

Update:
Mint 18.2 Unattended Upgrades is working as it did in Mint 17.x.
It installed two security upgrades this morning.
However, I am still not sure what the 20AutoUpgrades file script is all about.

I am utilizing the 10Periodic file script to daily check repos, download, install and then run autoclean ever 30 days.

Just hoping there isn't a redundancy or conflict between the two scripts.

Any help on this greatly apprecicated!

Allen

[asciiman]

Here are a couple of links that speak to the question of the 20auto-upgrades files and its relationship to 10periodic:

https://help.ubuntu.com/lts/serverguide ... dates.html

https://www.hiroom2.com/2016/05/18/ubun ... t-upgrade/

These pertain to Ubuntu 16.04.
As I stated above, in LM 18.2 my 50unattended-upgrades file was being called by APT probably since the beginning.
The file had no specific sources, so it merely ran and created a log entry that there were no updates available.
(seems a waste of resources).

It seems as though 10periodic might be rather redundant (as I suspected) based on all the log files I had in /var/log/unattended-upgrades/ prior to me manually adding 10period (the old way of setting up U.U.)

Apparently, 20auto-upgrades can be set up to run APT:Periodic in the same way.
The writer (in the second link above) does suggest that if 10periodic is present its values will be applied to 20auto-upgrades.

I think I might try deleting my manually added 10periodic file and customizing the events in my "as-built" 20auto-updates file just to see how things run.

Will report back.