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
