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
similar behaviour but the system may not boot at all.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472
the /sys/devices/virtual/block/... errors actually come from udev,
which times out in between those error messages flying by by 1000's.
--
To UNSUBSCRIBE, email to
Below is the complete log of the boot with the kvm commandline i use,
deleted by aprroximately 5K Lines, as noted inline between ### ###.
Should the full log be of interest I am happy to send, just let me know.
This is a vanilla install with the current alpha-installer,
installation was as stated
So this looks a bit like there are two erros:
1) mdadm is broken in 3.1.2 and brings up these errormessages.
2) Grub2 seems to be broken, as it does not start crypto,
consecutively failing to bring up LVM
The only thing I dont understand is why it is only us two experiencing this.
To test, I
thanks for the analysis. I'm under the impression that mdadm does
assemble the raids, but then fails to recognize the partition table.
But I don't know whether this is still in the realm of mdadm's
responsibility, or whether some other package (linux-image-*?) should
be responsible instead.
Downgrading MDADM helped for me, but not completely.
The behaviour at the beginning is still the same, such that it does
not find the volume-group.
But now I am dropped into a shell instead of getting these
/sys/devices/virtual/block/mdX
messages.
In that shell I can use lvm to bring the vg up
On Sun, Aug 29, 2010 at 9:38 AM, Toni Mueller supp...@oeko.net wrote:
Hi,
On Sun, 29.08.2010 at 07:18:36 +0200, Dh H dhh4...@googlemail.com wrote:
Downgrading MDADM helped for me, but not completely.
The behaviour at the beginning is still the same, such that it does
not find the volume
Downgrading MDADM helped for me, but not completely.
The behaviour at the beginning is still the same, such that it does
not find the volume-group.
But now I am dropped into a shell instead of getting these
/sys/devices/virtual/block/mdX
messages.
In that shell I can use lvm to bring the vg up
Here is some more information from me, as I had not much time this morning:
regardless of the passphrase I enter, any is accepted (also wrong
ones!!!) and the behaviour after that is the same.
Some I captured both standard and (recovery mode) below
(please note that the below was copied using an
I managed to get down to my data.
Using the Debian NetInstall CD I booted into rescue mode
Select language, territory and keyboard as applicable to you.
Cancel network autoconfig, if that does not work for you (for me that
is the case), and enter appropriate data.
Select any hostname and domain
when I add
insmod crypto
to the grub.cfg, my system goes directly to mode of flickering led.
Booting does not work at all.
Could it be that the culprit is within crypto.mod?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
My Laptop shows a very similar behaviour
It has 2x500G mirrored, two partitions set up
md0 acts as /boot
md1 is a encrypted lvm, which houses all other FS including root and swap.
While upgrading I had the question which arrays need starting at boot time.
I answered this with the default: All
Now
12 matches
Mail list logo
