also sprach Frans Pop <elendil@planet.nl> [2006.07.07.2330 +0200]:
> I have applied your patches (with minor modifications) and they
> are pending upload.
Thanks.
> I have tested the changes for rescue mode with the both with
> current (unstable) and new (experimental) mdadm-udeb with an
> existing RAID0 array (containing root) present. In both cases
> there were errors.
Ouch.
> Current unstable mdadm-udeb
> ---------------------------
> The array was _not_ listed as availble for mounting:
> Log says:
> mdadm: --auto=yes requires a 'standard' md device name,
> not /dev/.tmp.md0
This is an upstream limitation or feature, I have not yet found out.
:)
We could use --auto=md, but the result may not be what we want:
mdadm:~# mdadm -Aamd /dev/.tmp.md5 /dev/sd[abc]1
mdadm: /dev/.tmp.md5 has been started with 3 drives.
mdadm:~# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sda1[0] sdc1[2] sdb1[1]
46976 blocks [3/3] [UUU]
unused devices: <none>
mdadm:~# ls -l /dev/.tmp.md5
brw-rw---- 1 root disk 9, 127 2006-06-27 23:15 /dev/.tmp.md5
This is about assembly of existing arrays, right? Then it should not
matter and you can use --auto=md instead of --auto=yes to make it
work.
Anyway, I've contacted upstream about this. I've run up against this
a bunch of times and would like to get to the root of it.
> New experimental mdadm-udeb
> ---------------------------
> The array was _not_ listed as availble for mounting:
> Log says:
> mdadm: failed to create /dev/md/0
> # cat /tmp/mdadm.conf
> ARRAY /dev/md/0 level=raid0 num-devices=2 UUID=...
>
> Doing the following manually and restarting the rescue option, the RAID
> array _was_ started normally:
> # mkdir /dev/md
Okay, as said, I'll get to the root of this, but that's another
reason why I should try to get mdadm/experimental into testing! It's
almost ready...
> Question is: is this an mdadm error or should we make sure that /dev/md
> exists before calling mdadm?
I do the latter in the initramfs script, where I've had the same
problem.
> That the changes fail with current mdadm-udeb makes implementing the
> changes in d-i a bit harder than I'd have liked.
I won't remove mdrun until after etch, so if we can't reliably
resolve this, just keep on using mdrun. Although I can foresee
problems relating to #354705.
> > I would appreciate if someone could whack together an image with
> > this patch and mdadm-udeb from experimental. I'll give it a spin,
> > and anyone else would be very welcome.
>
> An image for i386 that has the mdadm-udeb from experimental and the
> modified rescue udebs is available for testing from:
> http://people.debian.org/~fjp/d-i/mini_mdadm.iso
>
> If you'd also like an image with current mdadm-udeb, I can provide that.
I'd prefer if people focused on 2.5.2 (= experimental) instead.
Thanks for your time, and sorry for the trouble. mdadm is quite
complex. Had I known when I adopted the package...
well,^W^W^W^W^W^W^W^W^W^W^W^W We'll get this working!
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
"i like .net for the same reason i like gentoo. it keeps all the
people with no clue from writing c code, which is much harder for me
to identify and eliminate from my systems. in the same way that
gentoo gives those people a place to be that isn't in debian"
-- andrew suffield
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)