>From time to time we hit

  https://bugzilla.redhat.com/show_bug.cgi?id=1741381

which result in 'dnf autoremove' failing. The suggested workaround
is to manually mark kernel packages as user-installed, so let's do
that every single time just in case.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 guests/playbooks/update/tasks/base.yml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/guests/playbooks/update/tasks/base.yml b/guests/playbooks/update/tasks/base.yml
index f085f19..97f365e 100644
--- a/guests/playbooks/update/tasks/base.yml
+++ b/guests/playbooks/update/tasks/base.yml
@@ -100,6 +100,13 @@
   when:
     - package_format == 'pkg'
 
+- name: Clean up packages after update
+  command: '{{ package_manager }} mark install "kernel*"'
+  args:
+    warn: no
+  when:
+    - os_name == 'Fedora'
+
 - name: Clean up packages after update
   shell: '{{ package_manager }} clean packages -y && {{ package_manager }} autoremove -y'
   args:
-- 
2.24.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Jan 10, 2020 at 05:03:35PM +0100, Andrea Bolognani wrote:
> >From time to time we hit
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1741381

FIY this has been fixed in both Fedora 30 and 31, so the workaround is no
longer necessary, IIUC it could have been any core package not just kernel, are
we going to adopt a similar workaround for systemd packages as well?

Erik

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Mon, 2020-01-13 at 12:18 +0100, Erik Skultety wrote:
> On Fri, Jan 10, 2020 at 05:03:35PM +0100, Andrea Bolognani wrote:
> > > From time to time we hit
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1741381
> 
> FIY this has been fixed in both Fedora 30 and 31, so the workaround is no
> longer necessary

Either me or Dan hit it very recently IIRC. I don't feel like
investing time into trying that again to prove that it was indeed
the case, sorry O:-)

Possibly what happened is that, even though the issue has been fixed
in a recent dnf version, when you perform a network-based install you
get the old dnf (which still has the issue) so at least the first
update round needs the workaround.

> IIUC it could have been any core package not just kernel, are
> we going to adopt a similar workaround for systemd packages as well?

I don't think anyone ever hit the issue with non-kernel packages, so
I see no reason to proactively expand the scope of the workaround.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Jan 10, 2020 at 05:03:35PM +0100, Andrea Bolognani wrote:
> >From time to time we hit
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1741381
> 
> which result in 'dnf autoremove' failing. The suggested workaround
> is to manually mark kernel packages as user-installed, so let's do
> that every single time just in case.
> 
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
>  guests/playbooks/update/tasks/base.yml | 7 +++++++
>  1 file changed, 7 insertions(+)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list