On Thu, 2017-04-27 at 11:34 +0200, Olav Seyfarth wrote: > Hi Ben, > > > [Reply to all, not just to me] > > sorry, using my mobile phone email client I did not notice that. > > > You cut too much. > > Below my message is what I did cut (running the older, stable kernel). > > Might any of the packages unattendedly installed tonight have any > influence on the "Soft lockup in KVM/QEMU virtual machine"?
Probably not. > tail -4 /var/log/apt/history.log > Start-Date: 2017-04-26 06:26:19 > Commandline: /usr/bin/unattended-upgrade > Upgrade: multiarch-support:amd64 (2.19-18+deb8u7, 2.19-18+deb8u8), > libc-bin:amd64 (2.19-18+deb8u7, 2.19-18+deb8u8), libc6:amd64 > (2.19-18+deb8u7, 2.19-18+deb8u8), minicom:amd64 (2.7-1, 2.7-1+deb8u1), > libxslt1.1:amd64 (1.1.28-2+deb8u2, 1.1.28-2+deb8u3) > End-Date: 2017-04-26 06:26:55 > > > > This indicates there was an earlier BUG logged; please send that too. > > Is that necessary for this bug? I ask since I hesitate to deliberately > break my production server (hosts all my internal und external services > like e-mail and file service). "Never touch a running system." ... Based on your original report, giving a kernel log from the guest (which has also been upgraded), I thought you were reporting an issue triggered by upgrading the guest kernel. Now I think what you're actually reporting is that upgrading the host kernel casues guests to crash. Is that correct? If so, can you check whether the host kernel logs anything when this happens, and send that? > I would like to do that once there is a newer kernel in proposed or > security that needs to be tested anyway. Would that be OK, too? [...] But I can't fix a bug if I don't understand what the bug is or how to reproduce it! Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure.
signature.asc
Description: This is a digitally signed message part
