[Pkg-xen-devel] Bug#932759: Bug#932759: After upgrade from stretch to buster, removal of obsolete xen 4.8 packages seems to trigger shutdown of xenconsoled
Hans van Kranenburg
hans at knorrie.org
Mon Jul 22 23:57:43 BST 2019
Hi niek,
Thanks for the report!
On 7/22/19 8:32 PM, niek wrote:
> Package: xen-hypervisor-4.11-amd64
> Version: 4.11.1+92-g6c33308a8d-2
>
> What happened:
> - upgraded Debian Xen Dom0 from stretch to buster and rebooted, as
> described in
> https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html
>
> - started some Linux pv domu without problems
>
> - removed obsolete packages with 'apt autoremove'. This removed (among
> others)
> xen-hypervisor-4.8-amd64:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11),
> libxen-4.8:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11),
> xen-utils-4.8:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11)
>
> [...]
> - xenconsoled was not running
>
> - searching system logs revealed that xenconsoled seemed to have stopped
> when 'apt autoremove' removed the obsolete xen 4.8
> packages after upgrading to xen 4.11.
Well, there it is again. We tried to make a fix, exactly for this...
https://salsa.debian.org/xen-team/debian-xen/commit/ef242a700765a971a6afc12d25ee19944dd3a27a
...and apparently there's another scenario in which even this doesn't work?
Can you show the lines from /var/log/dpkg.log from that moment, the
seconds around 07:38:40? It tells exactly what got removed, in what
second, just to confirm?
I'm pretty sure I tried to reproduce this after we added the fix I just
referenced, and I was unable to. So, I'm very interested in finding out
what's still going on here.
Usually being able to reproduce a problem is one of the biggest steps
towards finding a solution. (since it can be done over and over again,
finding out what exactly causes it). So, finding the right sequence of
steps to make it happen again is crucial here.
Do you think the systemd reload has anything to do with it? Maybe the
whole systemd init-script-wrapper-trickery is misbehaving in some way?
Can you reproduce this by manually grabbing the
xen-hypervisor-4.8-amd64, libxen-4.8 and xen-utils-4.8 from stretch
again, installing them and removing them again? Do you have any other idea?
Thanks,
Hans
More information about the Pkg-xen-devel
mailing list