On IRC we found out that this is related to mdadm not being able to deal when the device node referred to by mdadm.conf is a symlink:
/dev/md1 is not a block device
this seems to be a special case for devfs only.
In the case of the bug submitter, /dev/md1 is root, /dev/md2 is
swap, /dev/md3 is /home. /dev/md1 does not exist, /dev/md2 and
/dev/md3 are symlinks to /dev/md/X respectively. This seems to
suggest that these symlinks are created after the initrd assembled
the /dev/md/1 array (root-on-RAID).
The symlinks can be removed, but no hardlinks may be put in place
("Operation not permitted", exit code 1). However, mknod node
creation in /dev seems to work. Thus, we could just remove the
symlinks and let mdadm create them automatically. The following in
mdadm-raid should thus work okay:
if [ -e /dev/.devfsd ]; then
find /dev -type l -name md\* -maxdepth 1 \
| while read link; do
[ -b /dev/md/${link##/dev/md} ] && rm $link
done
fi
I am not sure whether the check for -b is necessary, but I feel
uneasy just killing all /dev/mdXX symlinks.
Moshe has tested this and confirmed it to work. Now I need to figure
out whether this is only devfs, or could happen in other cases too
(see debian-devel).
--
.''`. 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!
"i wish i hadn't slept all day, it's really lowered my productivity"
-- robert mcqueen
signature.asc
Description: Digital signature
