Bugzilla Bug 211167

sys-fs/mdadm-2.6.4 creates the directory /dev/dev, which i have found by
accident because rkhunter barks about it. In this directory it has created an
md0 block-device-file which is also created in /dev/md (the correct place for
this). I have a software raid so this is expected but not the entry in
/dev/dev. This is a regression compared to sys-fs/mdadm-2.6.2 which doesn't
create /dev/dev.

Reproducible: Always

works fine on my server

you'll need to trace the code and find out who is creating it ... look at the
addon in /lib/rcscripts/addons/raid-start.sh

also, post your mdadm.conf file as an attachment

(In reply to comment #1)
> works fine on my server
> 
> you'll need to trace the code and find out who is creating it ... look at the
> addon in /lib/rcscripts/addons/raid-start.sh
> 
> also, post your mdadm.conf file as an attachment
> 

Hello SpanKY,

i have found the bug. Here is the trace:
+ '[' -f /proc/mdstat ']'
+ MAJOR=9
+ mdadm_conf=/etc/mdadm/mdadm.conf
+ '[' -e /etc/mdadm.conf ']'
+ mdadm_conf=/etc/mdadm.conf
+ '[' -x /sbin/mdadm -a -f /etc/mdadm.conf ']'
++ awk '/^[[:space:]]*ARRAY/ { print $2 }' /etc/mdadm.conf
+ devs=/dev/md0
+ '[' -n /dev/md0 ']'
+ create_devs /dev/md0
+ local node dir minor
+ for node in '$@'
+ '[' /md0 '!=' /dev/md0 ']'
+ node=/dev//dev/md0
+ '[' -e /dev//dev/md0 ']'
+ dir=/dev//dev
+ '[' '!' -d /dev//dev ']'
+ mkdir -p /dev//dev
+ minor=md0
+ mknod /dev//dev/md0 b 9 0
+ ebegin 'Starting up RAID devices (mdadm)'
/lib/rcscripts/addons/raid-start-real.sh: line 34: ebegin: command not found
++ mdadm -As
+ output='mdadm: /dev/md0 has been started with 2 drives.'
+ ret=0
+ '[' 0 -ne 0 ']'
+ eend 0
/lib/rcscripts/addons/raid-start-real.sh: line 38: eend: command not found
++ ls '/dev/md_d*'
+ partitioned_devs=
+ '[' -n '' ']'

The problem lies in the line
[ "${node#/dev}" != "${node}" ] && node="/dev/${node}"
in create_devs().
It evaluates for node="/dev/md0" which is the value in my mdadm.conf for the
raiddevice to node="/dev//dev/md0".
It should not be "!=", it should be "=". Tested here and works fine.
I think the line should test if the node already inhibits the /dev, if not it
should put it as prefix in it. I'm wondering why you can't reproduce it. Maybe
you haven't rebooted since the update or you are using just "md0" in mdadm.conf
as devicename.
For tracing i have renamed raid-start.sh to raid-start-real.sh and written a
wrapper raid-start.sh which invokes raid-start-real.sh with bash -x, therefor
the ebegin error.

looks like robbat2 broke it ... i was testing the last version i wrote, and it
works fine ;)

Created an attachment (id=144526) [edit]
raid-start.sh-2.6.3-r4

please test this for me

(In reply to comment #4)
> Created an attachment (id=144526) [edit]
> raid-start.sh-2.6.3-r4
> 
> please test this for me
> 

Well, i have just read your script and your quoting seems to be not so well.
The quotes are better in robbat2's script, he uses '"' with care where it
should be. I prefer robbat2's script with just my small "="-fix.
Be careful with using "" in a for loop like 'for node in "$@"'. This works for
this variable but can be wrong in other ways like FOO="a b c d"; for i in
"${FOO}"; do echo $i; done. It's better to omit these '"' in most cases.
The other quotes are better solved in robbat2's which would also allow spaces
and things like that in devicenames even if this won't ever occur.

are you saying that without testing/knowing for real ?  i removed quotes where
they were not actually needed

if you know of a specific place where quotes are missing, state them now

you also dont know the difference between "$@" and "$*".  mine is correct,
robbat2's is not.  consult the bash man page.

(In reply to comment #6)
> are you saying that without testing/knowing for real ?  i removed quotes where
> they were not actually needed
> 
> if you know of a specific place where quotes are missing, state them now
> 
> you also dont know the difference between "$@" and "$*".  mine is correct,
> robbat2's is not.  consult the bash man page.
> 

Ok, you are right with the "$@" as stated before, but i like more to quote with
'"' for variable initialization like devs="$(awk '/^[[:space:]]*ARRAY/ { print
$2 }' ${mdadm_conf})" instead of omitting '"' here, it's more about taste here.
Your script will work, i don't need to test it. Changes are minor and mostly
only quoting.

pointless quoting around assignments like:
var="$(command)"
leads to ugliness when you need to quote inside of the $(...):
var="$(command "${arg}")"

added to 2.6.4-r1

(In reply to comment #8)
> pointless quoting around assignments like:
> var="$(command)"
> leads to ugliness when you need to quote inside of the $(...):
> var="$(command "${arg}")"
> 
> added to 2.6.4-r1
> 

Let's summarize it as different tastes :) Your script works, maybe inclusion in
a sys-fs/mdadm-2.6.4-r1 possible?

(In reply to comment #9)
> (In reply to comment #8)
> > pointless quoting around assignments like:
> > var="$(command)"
> > leads to ugliness when you need to quote inside of the $(...):
> > var="$(command "${arg}")"
> > 
> > added to 2.6.4-r1
> > 
> 
> Let's summarize it as different tastes :) Your script works, maybe inclusion in
> a sys-fs/mdadm-2.6.4-r1 possible?
> 

Hmm i should have read your comment more deeply :)