211167 2008-02-23 11:47 0000 sys-fs/mdadm-2.6.4 should not create /dev/dev 2008-02-26 19:14:19 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified x86 Linux RESOLVED FIXED P2 normal --- 1 RonnyPeine@gmx.de base-system@gentoo.org gentoo-bugs.f@umsar.org robbat2@gentoo.org RonnyPeine@gmx.de 2008-02-23 11:47:54 0000 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 vapier@gentoo.org 2008-02-23 20:50:08 0000 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 RonnyPeine@gmx.de 2008-02-24 11:15:41 0000 (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. vapier@gentoo.org 2008-02-24 11:27:48 0000 looks like robbat2 broke it ... i was testing the last version i wrote, and it works fine ;) vapier@gentoo.org 2008-02-24 19:10:05 0000 Created an attachment (id=144526) raid-start.sh-2.6.3-r4 please test this for me RonnyPeine@gmx.de 2008-02-25 20:36:28 0000 (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. vapier@gentoo.org 2008-02-25 22:12:41 0000 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. RonnyPeine@gmx.de 2008-02-26 07:04:01 0000 (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. vapier@gentoo.org 2008-02-26 07:17:07 0000 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 RonnyPeine@gmx.de 2008-02-26 19:13:33 0000 (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? RonnyPeine@gmx.de 2008-02-26 19:14:19 0000 (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 :) 144526 2008-02-24 19:10 0000 raid-start.sh-2.6.3-r4 raid-start.sh-2.6.3-r4 text/plain IyAvbGliL3Jjc2NyaXB0cy9hZGRvbnMvcmFpZC1zdGFydC5zaDogIFNldHVwIHJhaWQgdm9sdW1l cyBhdCBib290CiMgQ29weXJpZ2h0IDE5OTktMjAwOCBHZW50b28gRm91bmRhdGlvbgojIERpc3Ry aWJ1dGVkIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug djIKIyAkSGVhZGVyOiAvdmFyL2N2c3Jvb3QvZ2VudG9vLXg4Ni9zeXMtZnMvbWRhZG0vZmlsZXMv cmFpZC1zdGFydC5zaC0yLjYuMy1yNCx2IDEuMSAyMDA3LzEwLzA4IDIxOjA3OjA3IHJvYmJhdDIg RXhwICQKClsgLWYgL3Byb2MvbWRzdGF0IF0gfHwgZXhpdCAwCgojIFdlIGNvdWxkIG1ha2UgdGhp cyBkeW5hbWljLCBidXQgZWgKI1sgLXogJHtNQUpPUn0gXSAmJiBleHBvcnQgTUFKT1I9JChhd2sg JyQyID09ICJtZCIgeyBwcmludCAkMSB9JyAvcHJvYy9kZXZpY2VzKQpNQUpPUj05CgojIFRyeSB0 byBtYWtlIHN1cmUgdGhlIGRldmljZXMgZXhpc3QgYmVmb3JlIHdlIHVzZSB0aGVtCmNyZWF0ZV9k ZXZzKCkgewoJbG9jYWwgbm9kZSBkaXIgbWlub3IKCWZvciBub2RlIGluICIkQCIgOyBkbwoJCVsg IiR7bm9kZSMvZGV2fSIgPSAiJHtub2RlfSIgXSAmJiBub2RlPSIvZGV2LyR7bm9kZX0iCgkJWyAt ZSAiJHtub2RlfSIgXSAmJiBjb250aW51ZQoKCQlkaXI9JHtub2RlJS8qfQoJCVsgISAtZCAiJHtk aXJ9IiBdICYmIG1rZGlyIC1wICIke2Rpcn0iCgoJCW1pbm9yPSR7bm9kZSMjKi99CgkJbWtub2Qg IiR7bm9kZX0iIGIgJHtNQUpPUn0gIiR7bWlub3IjIyptZH0iCglkb25lCn0KCiMgU3RhcnQgc29m dHdhcmUgcmFpZCB3aXRoIG1kYWRtIChuZXcgc2Nob29sKQptZGFkbV9jb25mPSIvZXRjL21kYWRt L21kYWRtLmNvbmYiClsgLWUgL2V0Yy9tZGFkbS5jb25mIF0gJiYgbWRhZG1fY29uZj0iL2V0Yy9t ZGFkbS5jb25mIgppZiBbIC14IC9zYmluL21kYWRtIC1hIC1mICIke21kYWRtX2NvbmZ9IiBdIDsg dGhlbgoJZGV2cz0kKGF3ayAnL15bWzpzcGFjZTpdXSpBUlJBWS8geyBwcmludCAkMiB9JyAiJHtt ZGFkbV9jb25mfSIpCglpZiBbIC1uICIke2RldnN9IiBdOyB0aGVuCgkJZWJlZ2luICJTdGFydGlu ZyB1cCBSQUlEIGRldmljZXMiCgkJY3JlYXRlX2RldnMgJHtkZXZzfQoJCW91dHB1dD0kKG1kYWRt IC1BcyAyPiYxKQoJCXJldD0kPwoJCVsgJHtyZXR9IC1uZSAwIF0gJiYgZWNobyAiJHtvdXRwdXR9 IgoJCWVlbmQgJHtyZXR9CglmaQpmaQoKcGFydGl0aW9uZWRfZGV2cz0kKGxzIC9kZXYvbWRfZCog Mj4vZGV2L251bGwpCmlmIFsgLW4gIiR7cGFydGl0aW9uZWRfZGV2c30iIF07IHRoZW4KCWViZWdp biAiQ3JlYXRpbmcgUkFJRCBkZXZpY2UgcGFydGl0aW9ucyIKCS9zYmluL2Jsb2NrZGV2ICR7cGFy dGl0aW9uZWRfZGV2c30KCWVlbmQgMAoJIyB3YWl0IGJlY2F1c2UgdmdzY2FuIHJ1bnMgbmV4dCwg YW5kIHdlIHdhbnQgdWRldiB0byBmaXJlCglzbGVlcCAxCmZpCgojIHZpbTp0cz00Cg==