Debian unattended-upgrades

Debian unattended-upgrades

[Chuck Lever]

Hi -

While testing with Debian 12 on AWS, I ran into this:

---
- name: Check if unattended-upgrades is installed
  command: dpkg-query -W -f='${Status}' unattended-upgrades
  register: unattended_upgrade_status
  ignore_errors: true
  changed_when: false

- name: Set fact if unattended-upgrades is installed
  set_fact:
    unattended_upgrades_installed: "{{ 'install ok installed' in
unattended_upgrade_status.stdout }}"

- name: Verify unattended-upgrades is not installed
  fail:
    msg: |
      The unattended-upgrades package is installed on the base image, this
      can cause tons of issues with CIs. Fix this by running the following
      commands:

      make cleancache
      make bringup
  when:
    - unattended_upgrades_installed|bool

The Debian 12 image on AWS has the unattended-upgrades package
installed. I haven't checked Debian 11 or Debian on other cloud
providers.

- I did a "dpkg --purge unattended-upgrades" on each of the
  instances, and this failure went away

- "make cleancache" might be appropriate for a libvirt installation,
  but it definitely won't do anything for cloud; a fresh OS image
  will always have that package (unless we make a custom image)

- Even so, if the libvirt OS image provider installs that package,
  "make cleancache" won't eliminate the failure

Noting that later steps in
playbooks/roles/devconfig/tasks/install-deps/debian/main.yml disable and
uninstall unattended-upgrades anyway, what
is the purpose for the above logic? Can it be removed?

-- 
Chuck Lever

Re: Debian unattended-upgrades

[Chuck Lever]

On 4/9/25 3:54 PM, Chuck Lever wrote:
> Hi -
> 
> While testing with Debian 12 on AWS, I ran into this:
> 
> ---
> - name: Check if unattended-upgrades is installed
>   command: dpkg-query -W -f='${Status}' unattended-upgrades
>   register: unattended_upgrade_status
>   ignore_errors: true
>   changed_when: false
> 
> - name: Set fact if unattended-upgrades is installed
>   set_fact:
>     unattended_upgrades_installed: "{{ 'install ok installed' in
> unattended_upgrade_status.stdout }}"
> 
> - name: Verify unattended-upgrades is not installed
>   fail:
>     msg: |
>       The unattended-upgrades package is installed on the base image, this
>       can cause tons of issues with CIs. Fix this by running the following
>       commands:
> 
>       make cleancache
>       make bringup
>   when:
>     - unattended_upgrades_installed|bool
> 
> The Debian 12 image on AWS has the unattended-upgrades package
> installed. I haven't checked Debian 11 or Debian on other cloud
> providers.
> 
> - I did a "dpkg --purge unattended-upgrades" on each of the
>   instances, and this failure went away
> 
> - "make cleancache" might be appropriate for a libvirt installation,
>   but it definitely won't do anything for cloud; a fresh OS image
>   will always have that package (unless we make a custom image)
> 
> - Even so, if the libvirt OS image provider installs that package,
>   "make cleancache" won't eliminate the failure
> 
> Noting that later steps in
> playbooks/roles/devconfig/tasks/install-deps/debian/main.yml disable and
> uninstall unattended-upgrades anyway, what
> is the purpose for the above logic? Can it be removed?
> 

This is a possible solution I found on StackOverflow:

https://stackoverflow.com/questions/45269225/ansible-playbook-fails-to-lock-apt/51919678#51919678

I see that bringup_guestfs.sh already attempts to uninstall
unattended-upgrades on new images. We'll want something that works
for cloud instances too.


-- 
Chuck Lever

Re: Debian unattended-upgrades

[Daniel Gomez]

On Wed, Apr 09, 2025 at 04:16:44PM +0100, Chuck Lever wrote:
> On 4/9/25 3:54 PM, Chuck Lever wrote:
> > 
> > - I did a "dpkg --purge unattended-upgrades" on each of the
> >   instances, and this failure went away
> > 
> > - "make cleancache" might be appropriate for a libvirt installation,
> >   but it definitely won't do anything for cloud; a fresh OS image
> >   will always have that package (unless we make a custom image)
> > 
> > - Even so, if the libvirt OS image provider installs that package,
> >   "make cleancache" won't eliminate the failure
> > 
> > Noting that later steps in
> > playbooks/roles/devconfig/tasks/install-deps/debian/main.yml disable and
> > uninstall unattended-upgrades anyway, what
> > is the purpose for the above logic? Can it be removed?

I was reviewing these tasks the other day with Swarna. My suggestion is to
reorganize the task order to the following:

- name: Check if unattended-upgrades is installed
- name: Set fact if unattended-upgrades is installed
- name: Stop and disable unattended-upgrades related services
- name: Remove unattended-upgrades package
- name: Remove optional unattended-upgrades configuration files if they exist
- name: Verify unattended-upgrades is not installed
- name: Upgrade Packages

I think the dpkg --purge should cleanup the unnatended-upgrades package files
as we do we do in "Remove optional...", right? In that case, we can replace this
task with the more appropiate dpkg command you have suggested above.

> > 
> 
> This is a possible solution I found on StackOverflow:
> 
> https://stackoverflow.com/questions/45269225/ansible-playbook-fails-to-lock-apt/51919678#51919678
> 
> I see that bringup_guestfs.sh already attempts to uninstall
> unattended-upgrades on new images. We'll want something that works
> for cloud instances too.

Agree. And I think that was the intention of that part of the playbook.

> 
> 
> -- 
> Chuck Lever

Re: Debian unattended-upgrades

[Chuck Lever]

On 4/10/25 4:29 AM, Daniel Gomez wrote:
> On Wed, Apr 09, 2025 at 04:16:44PM +0100, Chuck Lever wrote:
>> On 4/9/25 3:54 PM, Chuck Lever wrote:
>>>
>>> - I did a "dpkg --purge unattended-upgrades" on each of the
>>>   instances, and this failure went away
>>>
>>> - "make cleancache" might be appropriate for a libvirt installation,
>>>   but it definitely won't do anything for cloud; a fresh OS image
>>>   will always have that package (unless we make a custom image)
>>>
>>> - Even so, if the libvirt OS image provider installs that package,
>>>   "make cleancache" won't eliminate the failure
>>>
>>> Noting that later steps in
>>> playbooks/roles/devconfig/tasks/install-deps/debian/main.yml disable and
>>> uninstall unattended-upgrades anyway, what
>>> is the purpose for the above logic? Can it be removed?
> 
> I was reviewing these tasks the other day with Swarna. My suggestion is to
> reorganize the task order to the following:
> 
> - name: Check if unattended-upgrades is installed
> - name: Set fact if unattended-upgrades is installed
> - name: Stop and disable unattended-upgrades related services
> - name: Remove unattended-upgrades package
> - name: Remove optional unattended-upgrades configuration files if they exist
> - name: Verify unattended-upgrades is not installed
> - name: Upgrade Packages
> 
> I think the dpkg --purge should cleanup the unnatended-upgrades package files
> as we do we do in "Remove optional...", right? In that case, we can replace this
> task with the more appropiate dpkg command you have suggested above.

I'm wondering about the repetition of "remove unattended-upgrades"
/after/ the full update in the current Ansible script. Is there a
possibility that the full update will reinstall unattended-upgrades? If
not, then your proposed order looks OK to me.


>> This is a possible solution I found on StackOverflow:
>>
>> https://stackoverflow.com/questions/45269225/ansible-playbook-fails-to-lock-apt/51919678#51919678
>>
>> I see that bringup_guestfs.sh already attempts to uninstall
>> unattended-upgrades on new images. We'll want something that works
>> for cloud instances too.
> 
> Agree. And I think that was the intention of that part of the playbook.
> 
>>
>>
>> -- 
>> Chuck Lever


-- 
Chuck Lever

Re: Debian unattended-upgrades

[Daniel Gomez]

On Thu, Apr 10, 2025 at 09:49:07AM +0100, Chuck Lever wrote:
> On 4/10/25 4:29 AM, Daniel Gomez wrote:
> > On Wed, Apr 09, 2025 at 04:16:44PM +0100, Chuck Lever wrote:
> >> On 4/9/25 3:54 PM, Chuck Lever wrote:
> >>>
> >>> - I did a "dpkg --purge unattended-upgrades" on each of the
> >>>   instances, and this failure went away
> >>>
> >>> - "make cleancache" might be appropriate for a libvirt installation,
> >>>   but it definitely won't do anything for cloud; a fresh OS image
> >>>   will always have that package (unless we make a custom image)
> >>>
> >>> - Even so, if the libvirt OS image provider installs that package,
> >>>   "make cleancache" won't eliminate the failure
> >>>
> >>> Noting that later steps in
> >>> playbooks/roles/devconfig/tasks/install-deps/debian/main.yml disable and
> >>> uninstall unattended-upgrades anyway, what
> >>> is the purpose for the above logic? Can it be removed?
> > 
> > I was reviewing these tasks the other day with Swarna. My suggestion is to
> > reorganize the task order to the following:
> > 
> > - name: Check if unattended-upgrades is installed
> > - name: Set fact if unattended-upgrades is installed
> > - name: Stop and disable unattended-upgrades related services
> > - name: Remove unattended-upgrades package
> > - name: Remove optional unattended-upgrades configuration files if they exist
> > - name: Verify unattended-upgrades is not installed
> > - name: Upgrade Packages
> > 
> > I think the dpkg --purge should cleanup the unnatended-upgrades package files
> > as we do we do in "Remove optional...", right? In that case, we can replace this
> > task with the more appropiate dpkg command you have suggested above.
> 
> I'm wondering about the repetition of "remove unattended-upgrades"
> /after/ the full update in the current Ansible script. Is there a

What repetition do you mean? These tasks?

- name: Remove unattended-upgrades package
- name: Remove optional unattended-upgrades configuration files if they exist

The first one removes the package. The second ensures that any remaining files
not cleaned up by the package removal task are also deleted. It'd simpler
enabling the purge option to the apt task.

> possibility that the full update will reinstall unattended-upgrades? If
> not, then your proposed order looks OK to me.

Not that I'm aware of.

Re: Debian unattended-upgrades

[Luis Chamberlain]

On Wed, Apr 09, 2025 at 03:54:22PM -0400, Chuck Lever wrote:
> what is the purpose for the above logic? Can it be removed?

guestfs images can be stale with the unattended-upgrades package still
installed, so we can just make this crap shoot check a guestfs specific
thing.

The actual removal is imprortant though, for cloud it makes sense to
still remove the package, and not bail out.

  Luis