Yet another problem on the same virtualised host as in the other thread
a few weeks back.
As before, this is a presumably KVM virtualised host. With the
exception of a small boot partition, all storage volumes are encrypted
via cryptsetup‘s LUKS mode.
It looks like a race condition of some weird sort, and there’s no doubt
that the virtualisation is again playing tricks with me. If I type in
the password incorrectly, then it will most likely crash violently right
there. If typed in correctly, then in one of five it -might- boot. The
kernel panic is attached below.
The same thing happens if I boot the live CD and try to unlock the
volumes there, or if I sometimes later want to attach further dm_crypt
instances. The probability of a crash seems to rise rather quickly with
the number of CPU cores and the number of crypto volumes that need to be
unlocked.
At this point, I sometimes need the better part of an hour to finally
get the server to boot (the fiddlyness of virtual hoster‘s
administration console adds considerably to this). Any ideas, any
patches?
I lack the skill to interpret what the kernel panic is trying
to tell me. Are there some knobs that I could tweak in the meantime?
Heartfelt thanks for anyone who can help,
Stefan
--
Getting an inch of snow is like winning ten cents in the lottery!
-- Calvin; "Calvin & Hobbes"
