More observance; I upgraded udev to 161-1 from SID and did not pay attention while I was booting the faulty VM. So the VM waited on passphrase input. When I came back, entered the password, nothing happend and the VM was completely stuck and consuming 100% processor. I killed it and rebooted and swiftly entered the passphrasae; Then the boot continued as described above. To make it short, udev Version 161-1 make no difference did not help neither worsened the behaviour.
Downgrading to 160-1 and check if 160-1 will show the same behaviour, if I do not enter the passphrase swiftly. Bingo, system went to Guru Meditation with udev 160-1 as well. Only if the passphrase is entered timely, booting will continue. Looking at CPU utilization, it is 100% until the the boot process actually starts after alls the sys/device/virtuals. This is even the case while Grub is waiting for input on the Boot menu, which I would not have expected. But maybe the latter is normal behaviour. In addition to the above, I added a spare drive to each md-device and tested failing disks and fail situations. These seemed to work all perfectly well. The spares kicked in and the mirror was restored as expected. Booting with one drive (either hda and hdb) worked fine as well, when I broke the other one before boot. BTW: I will be more than happy doing a few sensefull tests, if someone advises me of his needs. Cheers Darren -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
