Unfortunately, I did not think of making a foto of the messages. I've tried that new kernel on my "real" machines at home, there it booted without problems. Both machines are using luks and lvm. One is unlocked manually, the other via mandos in my LAN. Both machines booted the 3.16-1 kernel without problems. It seems that this specific VM setup might somehow play into this. All I know it is a ganeti/kvm setup running with -cpu host. Thus I'm not seeing the "qemu" cpu in /proc/cpu info but the real one. Unfortunately, I cannot contact the admin of the vm's host computer 24/7. I'll BCC'ed him this email and perhaps he has an idea what might be causing this. We might be able to retry this in a few days. Then I'll try to get a screenshot of the messages. Regards, Dominik Am 09.09.2014 um 20:10 schrieb Ben Hutchings: > Control: severity -1 import > Control: tag -1 moreinfo > > On Tue, 2014-09-09 at 19:43 +0200, C. Dominik Bodi wrote: >> Package: src:linux >> Version: 3.16.2-2 >> Severity: critical >> Justification: breaks the whole system >> >> I've got a debian unstable system running in a ganeti/kvm vm that runs >> with lvm. The physical volume the root file system resides on is >> encrypted with luks. I've installed dropbear to unlock the luks volume >> via ssh, using a kernel cmdline ip=... in /etc/grub/default >> >> Up and including linux-image-3.14-2-amd64 this worked flawlessly. >> >> However, having installed and booted from 3.16-1, the kernel panics >> after unlocking the luks volume. There were some error messages about >> /dev/pts and/or /dev not being mounted successfully, but as the kernel >> panicked, the busybox console (accessed via spice) was frozen and I had to ask the admin >> admin to hard-reset the machine for me. >> >> The 3.14-2 kernel continues to boot normally, >> >> I'm a bit at loss what might cause 3.16 to panic but 3.14 to boot >> successfully. Unfortunately I cannot hard-reset the machine myself >> (spice remote-viewer does not to support hard-reset signals to the vm) >> and I wasn't able to deduce anything from the few kernel panic lines >> on the console. > [...] > > But we might be able to. > > Ben. >
Attachment:
signature.asc
Description: OpenPGP digital signature