[notabug?] unattended-upgrades will not run by default

johnraff · 2018-07-14 06:50:23

This is something that BunsenLabs users might run into if they install unattended-upgrades and expect it to run with the default config.

You should check over the Debian Wiki article anyway, and probably want to enable emails to "root", but what must be changed in /etc/apt/apt.conf.d/50unattended-upgrades is line 39

     "origin=Debian,codename=${distro_codename},label=Debian-Security";

because on BunsenLabs, ${distro_codename} will resolve to "helium". (No debian-security upgrades come from us, unfortunately. ) Change it to "stretch" and upgrades should start to work:

     "origin=Debian,codename=stretch,label=Debian-Security";

Run

sudo unattended-upgrades -v -d

before and after the change to see.

I've only just hit this, so I'll have to wait till the next security upgrades come in to be 100% sure.

A bug? The reason ${distro_codename} doesn't resolve to the Debian release "stretch" is presumably that 'lsb_release -sc' returns "helium" on BL Helium. That's as it should be, other things considered, but I'm not sure where else to report this.

brontosaurusrex · 2018-07-14 08:03:59

The possible (small) problem is that people might update to buster and forget about manual interventions like this. What is the procedure to assign this env variables and is it easily tweakable somehow? (If not easy i'd call this post a solution and not waste any sleep over it).

P.s. Personally i'd classifie unattended-upgrades as something that runs on server mostly. If that is true than this is a no problem.

Last edited by brontosaurusrex (2018-07-14 08:10:25)

johnraff · 2018-07-14 08:28:29

It's not an env variable as far as I can tell without digging deeply into the code - I'm guessing it's something apt or unattended-upgrades is generating, possibly from the output of 'lsb_release -sc', which on normal Debian systems would be the Debian codename.

lsb_release's info is configured by our bunsen-os-release package, according to standards, and necessary for some other things to work correctly, but nothing specifically BL in fact. Grub menu, software-properties-gtk...

If that package was removed then lsb_release would revert to reporting "stretch" or "buster", and this has been reported as the fix for another issue I now forget (printer driver?).

No, the situation is not quite optimal, but in fact most users of unattended-upgrades are expected to edit /etc/apt/apt.conf.d/50unattended-upgrades anyway.

brontosaurusrex · 2018-07-14 11:20:41

So that could be Debian/nodejs/etc related bug and has nothing to do with BL, however I can imagine a lot of people dealing with nodejs and that could be a problem.

johnraff · 2018-07-15 06:49:04

Well I'm not sure if this is a bug at all TBH:

If unattended-upgrades is installed on a system which is not pure Debian (as reported by 'lsb_release') then the default configuration will probably need adjusting.

As I mentioned above, users are really expected to check the configuration file anyway.

---
I did dig a bit further and found:

/usr/share/doc/unattended-upgrades/README.md.gz wrote:

Variable substitution is supported
for ${distro_id} that contains the output of `lsb_release -i` and
${distro_codename} that contains the output of `lsb_release -c`.

NB the below is not true:

/etc/apt/apt.conf.d/50unattended-upgrades wrote:

// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
// ${distro_id} Installed origin.
// ${distro_codename} Installed codename (eg, "jessie")

Anyway, indeed, on BL the default config would look for upgrades from 'helium' labelled 'Debian-Security'. Replace '${distro_codename}' with 'stretch' and all is well.

The behaviour of unattended-upgrades wrt config files changed between Jessie and Stretch, so Buster might be different again, but /etc/apt/apt.conf.d/50unattended-upgrades will likely need tweaking once more.

Last edited by johnraff (2018-10-13 02:48:05)

pgf · 2024-11-10 18:43:35

Long-tme linux user here, but Debian newbie: 6 years later, I assume that ${distro_codename} should be replaced with "bookworm", not "stretch". Correct? This, of course, is the problem with this solution. It will need editing in the future, right?

Since I'm a newbie, I'll ask a further question. Just below the lines in question in 50unattended-upgrades, I see this:
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
// "o=Debian,a=stable";
// "o=Debian,a=stable-updates";
// "o=Debian,a=proposed-updates";
// "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";

Wouldn't simply uncommenting the first two lines of that stanza (i.e., the "stable" and "stable-updates" lines also be sufficient? Or will that cause even more, or different, trouble sometime in the future?

paul

johnraff · 2024-11-11 05:40:07

pgf wrote:

I assume that ${distro_codename} should be replaced with "bookworm", not "stretch". Correct? This, of course, is the problem with this solution. It will need editing in the future, right?

Correct.

Since I'm a newbie, I'll ask a further question. Just below the lines in question in 50unattended-upgrades, I see this:
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
// "o=Debian,a=stable";
// "o=Debian,a=stable-updates";
// "o=Debian,a=proposed-updates";
// "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
Wouldn't simply uncommenting the first two lines of that stanza (i.e., the "stable" and "stable-updates" lines also be sufficient? Or will that cause even more, or different, trouble sometime in the future?

Matching against "stable" will mean that when Trixie becomes Stable, and Bookworm becomes Oldstable, upgrades will start coming from Trixie, regardless of whether your system has been upgraded from Bookworm to Trixie or not. So yes, some possible future trouble...

pgf · 2024-11-11 13:07:00

Thank you. Somehow that made it much clearer to me than the comments in the original file did.

One more question. The O.P. only recommends modifying the distributed 'label="Debian-Security"' line.

If I also want "normal" updates to Debian packages (i.e., important bug-fixes that don't qualify as security issues), will simply uncommenting the existing -updates line work? Or do I also need to replace ${distro_codename} there, as well? That line is:

"origin=Debian,codename=${distro_codename}-updates";

paul

johnraff · 2024-11-12 02:54:09

The most important use of unattended-upgrades is probably security upgrades.
Once a release has become "stable" there are usually few regular upgrades, except perhaps when there's a point release (as there was a couple of days ago).

<codename>-updates are a special path to get upgrades that are due to arrive eventually a bit before the point release time. The main thing I've noticed that they are useful for is, if you're using ClamAV it will pull in updates of the data base. Apart from that not much seems to come down that channel.

Anyway, security updates are sometimes urgent, so that's perhaps the main case where there's an argument for using unattended-upgrades. That and maybe servers. Most people with desktop computers prefer to do their upgrades by hand so they can keep an eye on things.

pgf · 2024-11-12 03:02:02

Thanks. I've been using Ubuntu until now, and I think there the -updates stream is much more active. I didn't realize it was used so differently by Debian.

#1 2018-07-14 06:50:23

[notabug?] unattended-upgrades will not run by default

#2 2018-07-14 08:03:59

Re: [notabug?] unattended-upgrades will not run by default

#3 2018-07-14 08:28:29

Re: [notabug?] unattended-upgrades will not run by default

#4 2018-07-14 11:20:41

Re: [notabug?] unattended-upgrades will not run by default

#5 2018-07-15 06:49:04

Re: [notabug?] unattended-upgrades will not run by default

#6 2024-11-10 18:43:35

Re: [notabug?] unattended-upgrades will not run by default

#7 2024-11-11 05:40:07

Re: [notabug?] unattended-upgrades will not run by default

#8 2024-11-11 13:07:00

Re: [notabug?] unattended-upgrades will not run by default

#9 2024-11-12 02:54:09

Re: [notabug?] unattended-upgrades will not run by default

#10 2024-11-12 03:02:02

Re: [notabug?] unattended-upgrades will not run by default

Board footer