also sprach Paul Check <[EMAIL PROTECTED]> [2005.05.25.1045 +0200]: > md0: /dev/sda1 /dev/sdb1 --> /boot > md1: /dev/sda3 /dev/sdb3 --> / > md2: /dev/sda4 /dev/sdb4 --> lvm, for other partitions. > > Note, I also have disks sdc through sdg, no raid, but using lvm. > > Problem: Yesterday after re-booting the system, the md1 and md2 devices were > not getting created properly on boot. However, if I boot into the 2.4 kernel
The /dev/md0 device was created though? What's the output of
ls -l /dev/md*
?
> everything worked fine. After reading the bug report, I tried creating the
> /etc
> /mdadm/mdadm.conf file (I never had one before..my backup system shows that).
> With the mdadm.conf file created, I am now able to boot into my system in the
> 2.6 kernels: The md1 and md2 devices get created.
Okay, so the problem is likely to be with mdrun, which is
deprecated. Nevertheless, I would like to find out just why it
fails...
Could you move your mdadm.conf out of the way, apply the following
patch to /sbin/mdrun and see if that solves it?
--- mdadm-1.9.0/debian/mdrun
+++ mdadm-1.9.0/debian/mdrun
@@ -67,7 +67,7 @@
test -d $BASE && BASE=$BASE/
next_free_md() {
- for raidnr in `seq 0 24` ; do
+ for raidnr in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
24; do
if ! mdadm -D $BASE$raidnr >/dev/null 2>&1 ; then
echo $BASE$raidnr
return 0
Rationale: since your /usr seems to be on RAID, you may be tripping
over #310671.
If that's not the case, please drop the following file onto your
system, reboot, and then run the commands afterwards:
cat <<_eof > /etc/rcS.d/S01RAID-HACK
#!/bin/sh
cd /dev && ./MAKEDEV md
_eof
chmod 755 /etc/rcS.d/S01RAID-HACK
reboot
Now /dev/md1 should be created, but /dev/md2 not.
So now, please run
sh -x /sbin/mdrun
and provide us with the output.
Thanks,
> However, for some reason, / dev/sda4 now won't get added to md2
> (either automatically or manually). Again, if I boot into the 2.4
> kernel, I can create everything, no problem.
>
> If I try to add /dev/sda4 to /dev/md2 I get:
>
> mdadm /dev/md2 -a /dev/sda4:
>
> mdadm: hot add failed for /dev/sda4: Invalid argument
>
> in dmesg:
>
> md: could not bd_claim sda4.
> md: error, md_import_device() returned -16
Weird. Does /dev/sda4 exist?
> Note: I may have switched over to 2.4 and done some raid work
> after this problem arose in an attempt to fix it, but I presume
> that this shouldn't (?) damage the raid on the 2.6 kernels? On the
This should not be a problem.
> other hand, I have had problems several months ago running lvm
> across the different kernels. This problem disappeared, but
> perhaps it's back and interferring with the sda4 partition
> somehow? (I doubt it...).
LVM is a different story.
> Observation: The differences between my 2.6 kernels (raid not
> working) and 2.4 kernel (raid working) are: udev vs. non-udev and
> initrd vs none. I have had problems with udev in the past. I've
> also seen an old post regarding a bug with mdadm and the use of
> initrd's.
Does the root filesystem get mounted at all? If so, then initrd
works fine and the problem is with udev. If that's not the case, we
have an issue with initrd.
Could you make sure to recreate your initrd after the above tests,
and try them again?
dpkg-reconfigure kernel-image-$(uname -r)
> Any thoughts on what this might be?
Another thing you could do is to figure out the previous version of
mdadm: You can check the versions by saving /var/lib/dpkg/status to
somewhere, fetching the last one from /var/backup and putting it
into place, running dpkg -l to get the version info, and then
restoring the original /var/lib/dpkg/status file.
Cheers,
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
time wounds all heels.
-- groucho marx
signature.asc
Description: Digital signature
