On 2010-09-20 14:48, Alexander Kurtz wrote:
Now we are getting somewhere! Here's what I suspect to be the problem:
[etc.]
Alexander, thank you so much: The system behaved exactly in the way you
had thought it would, and the problem is solved now. I had to map
/dev/md1 to vg md1_crypt, and
So after all this was just mdadm bug #583917 combined with the fact that
you used to wrong name (compared to /etc/cryptsetup) when unlocking the
crypto device manually. This of course caused the cryptsetup initramfs
hook to break when recreating the initramfs. As a consequence, your
cryptroot
reassign 594472 mdadm
forcemerge 583917 594472
thanks
Hi Toni,
Everybody else's problems were definitely caused[1][2] by mdadm bug
#583917[3]. Could you try upgrading to mdadm 3.1.4 (has reached squeeze
already), regenerate your initramfs and report whether this solves your
booting problems?
If
On 2010-09-24 11:50, Alexander Kurtz wrote:
So after all this was just mdadm bug #583917 combined with the fact that
you used to wrong name (compared to /etc/cryptsetup) when unlocking the
crypto device manually. This of course caused the cryptsetup initramfs
hook to break when recreating the
On 2010-09-18 23:46, Alexander Kurtz wrote:
Ehm... I suggested to change that line for *diagnosing only*. The fix
was that apparently you forgot the 2 part at the end
Sorry, what a stupid mistake I made. Corrected the diagnosis is:
# update-initramfs -u
update-initramfs: Generating
Now we are getting somewhere! Here's what I suspect to be the problem:
Am Montag, den 20.09.2010, 09:59 +0200 schrieb Andreas von Heydwolff:
* What exactly do you have to do to boot your system manually
after being thrown to a rescue shell (precise commands)?
# cryptsetup luksOpen
Hi Andreas,
let's try to keep this short, this bug report is already long enough:
Am Samstag, den 18.09.2010, 01:38 +0200 schrieb Andreas von Heydwolff:
ii cryptsetup2:1.1.3-3
ii lvm2 2.02.66-3
ii mdadm 3.1.4-1+8efb9d1
Good.
# update-initramfs -u
On 2010-09-18 18:33, Alexander Kurtz wrote:
-snip-
Ok, let me summarize:
* You did have[1] the problem that was caused by mdadm bug #583917[2].
However, after upgrading to mdadm 3.1.4 that is solved.
Yes
* You did have[3] some issue with cryptsetups initramfs hook.
However, for
Am Samstag, den 18.09.2010, 23:04 +0200 schrieb Andreas von Heydwolff:
It is gone because I replaced in line 185 of
/usr/share/initramfs-tools/hooks/cryptroot
echo cryptsetup: WARNING: invalid line in /etc/crypttab - $opt 2
with
echo cryptsetup: WARNING: invalid line in
Hi,
I think a little more information would be helpful. IMHO your problem
can be divided into three parts. Let's discuss them separately:
1. Just for the record: You do have mdadm 3.1.4-1+8efb9d1 installed (it
should migrate to squeeze today[1])?
Am Freitag, den 17.09.2010, 01:38 +0200
Hi everybody,
I spent the last hour re-reading the entire bug report, testing the new
mdadm version and testing a way to restore the system using a live CD.
Here's what I found:
* I am really sure that this is not a GRUB bug. You all get to the
initramfs. That's where problems start. GRUB
On 2010-09-17 14:17, Alexander Kurtz wrote:
IMHO your problem
can be divided into three parts. Let's discuss them separately:
Hello Alexander, thanks. Here goes:
1. Just for the record:
ii cryptsetup2:1.1.3-3
ii lvm2 2.02.66-3
ii mdadm 3.1.4-1+8efb9d1
On 2010-09-14 22:26, Alexander Kurtz wrote:
Am Dienstag, den 14.09.2010, 21:28 +0200 schrieb Andreas von Heydwolff:
My /etc/crypttab reads
md1_crypt UUID=3a10eb55-2dd8-4846-97e5-74649abf234f none luks
md2_crypt UUID=e78a6bea-cafb-41a7-89e9-03e999b38d6c none luks
Just some thoughts: What
After upgrading mdadm I had
[snip]
Generating udev events for MD arrays...done.
Verarbeite Trigger für man-db ...
Verarbeite Trigger für initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
cryptsetup: WARNING: invalid line in /etc/crypttab -
cryptsetup:
Am Dienstag, den 14.09.2010, 21:28 +0200 schrieb Andreas von Heydwolff:
My /etc/crypttab reads
md1_crypt UUID=3a10eb55-2dd8-4846-97e5-74649abf234f none luks
md2_crypt UUID=e78a6bea-cafb-41a7-89e9-03e999b38d6c none luks
Just some thoughts: What happens if you
* try `/dev/disk/by-uuid/'
Hi,
On Tue, 14.09.2010 at 21:28:17 +0200, Andreas von Heydwolff
106624@compuserve.com wrote:
After upgrading mdadm I had
since I really need my machine now, I didn't yet dare to reboot. I also
don't understand the issue too well, but simply want to contribute my
data for comparison.
Am Dienstag, den 14.09.2010, 23:01 +0200 schrieb Toni Mueller:
since I really need my machine now, I didn't yet dare to reboot. I also
don't understand the issue too well, but simply want to contribute my
data for comparison.
Explanation:
Andreas,
I had problems as well, but I used apt-get to upgrade and the
initramfs of ..-amd64 did not get updated. I could not see the
crypttab error message.
For me it helped to run a separate
# update-initramfs
after the upgrade.
If that does not help, how does your /etc/crypttab look like?
[stuff deleted]
Am Sonntag, den 29.08.2010, 02:35 +0200 schrieb Agustin Martin:
May this be related to #583917, mdadm: long delay (6-200 minutes)
during boot (root device detection) after upgrade on RAID/LVM/LUKS
setup?
Am Samstag, den 04.09.2010, 04:22 +0100 schrieb Darren:
upgrading to
Am Donnerstag, den 26.08.2010, 11:07 +0200 schrieb Toni Mueller:
After several (5?) minutes where the machine didn't do anything I was
able to see, the screen was suddenly flushed with a large number of
messages like:
/sys/devices/virtual/block/md0 (10715)
upgrading to mdadm 3.1.4-1+8efb9d1 from sid solved my boot problems.
That is for both, the VM I set up for testing, as well as my base PC.
Both are booting fine now.
Please note
* my system uses grub grub2/1.98+20100804-4 from sid, so your
mileage may vary ;)
* the normal install did not
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
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
Hi,
On Mon, 30.08.2010 at 08:55:23 +0100, Dh H dhh4...@googlemail.com wrote:
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
thanks
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
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-group.
But now I am dropped into a shell instead of getting these
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
Thanks a lot, Dh H. After downgrading mdadm to 3.1.1-1 I had the same
experience as you - unable to find LVM volume for root, ...does not
exist, timeout and busybox in initramfs.
Your workaround works for me as well (please find below my system and
grub config info which I could gather now
2010/8/26 Toni Mueller supp...@oeko.net:
Package: grub-pc
Version: 1.98+20100804-2
Severity: important
Hi,
my machine is a standard PC with two SATA disks, bundled as md0 and md1,
with /boot on md0, and everything else in a LUKS encrypted container on
md1 with LVM inside. So, booting
Hi,
On Sun, 29.08.2010 at 02:35:09 +0200, Agustin Martin agmar...@debian.org
wrote:
May this be related to #583917, mdadm: long delay (6-200 minutes)
during boot (root device detection) after upgrade on RAID/LVM/LUKS
setup?
after reading this bug report, I'm not convinced. Contrary to my
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
Package: grub-pc
Version: 1.98+20100804-2
Severity: important
Hi,
my machine is a standard PC with two SATA disks, bundled as md0 and md1,
with /boot on md0, and everything else in a LUKS encrypted container on
md1 with LVM inside. So, booting normally works by fetching the kernel
and initrd
34 matches
Mail list logo
