search

mvo5 / unattended-upgrades

Automatic installation of security upgrades on apt based systems
GNU General Public License v2.0
278 stars 78 forks source link

unattended-upgrades not considering pin-priority #368

Open ryaeng opened 1 month ago

ryaeng commented 1 month ago

Hello everyone,

I've run into the issue a few times where unattended-upgrades doesn't take pin-priority into account. When looking through the codebase, I found the following:

That line indicates that it's possible for unattended-upgrades to consider pin-priority but it doesn't by default. Is this the desired effect or a bug?

We utilize pin-priority to tightly couple many nvidia packages together. This is necessary when dealing with a number of packages for AI/ML. When unattended-upgrades is run, it tends to break systems and drivers. Please advise.

ryaeng commented 2 weeks ago

Update regarding the aforementioned config. Added that to 52unattended-upgrade and set it to true. This did not work. When unattended-upgrade ran after making this change, it upgraded packages without taking pin-priority into account.

My recommendation going forward is to blacklist packages.

julian-klode commented 2 weeks ago

Pinning works within the confines of the requirements:

Pinning for sources that are not allowed are pinned to "never", overriding any pin configured for then.

If you want to pin a lower version, you also need to add that to the list of allowed origins, achieve the pin by pinning down the versions you don't want, or as you did block the package.

I've explained this in an older issue here that is open, feel free to find and read it for more details.

ryaeng commented 2 weeks ago

@julian-klode Thanks for the reply. Why is it setup this way? Since users typically use apt upgrade, my thought is that unattended-upgrade would run as close to this as possible.

That did work though. I added our repo to AllowedOrigins via 52unattended-upgrade-local. Running --debug proves that it holds back the proper packages. Thank you.