You are not logged in.
If you install the new initscripts package, but don't have mdadm, then you'll get a message about mdadm.conf not being found on startup. It's nothing, really, but perhaps the initscripts should have something to bypass the software RAID stuff if mdadm.conf isn't found. Or maybe initscripts should have mdadm as a dependency.
Offline
You should probably post this in the bug tracker.
Offline
Interesting. I figured test would optimize an AND condition and not check the second qualifier if the first failed. Guess not.
Try this patch and see if the error goes away.
--- rc.sysinit 2005-11-10 14:06:31.000000000 -0800
+++ rc.sysinit.new 2005-11-10 14:07:10.000000000 -0800
@@ -41,7 +41,7 @@
fi
# If necessary, find md devices and manually assemble RAID arrays
-if [ -f /etc/mdadm.conf -a "`grep ^ARRAY /etc/mdadm.conf`" ]; then
+if [ -f /etc/mdadm.conf -a "`grep ^ARRAY /etc/mdadm.conf 2>/dev/null`" ]; then
if [ -d /initrd/dev ]; then
# udev won't create these md nodes, so we steal them from the initrd
for i in `grep ^ARRAY /etc/mdadm.conf | awk '{print $2}'`; do
Offline
Interesting. I figured bash would optimize an AND condition and not check the second qualifier if the first failed. Guess not.
bash does. [ -d /some/random/dir ] && mkdir /some/random/dir
however, the "[ x -a y ]" conditions aren't bash 'and's, they're params to 'test' (test x -a y).
Offline
hehe, you caught me. I clued in about 30 seconds after posting that it was test's fault.
Committed the fix.
Offline
If you install the new initscripts package, but don't have mdadm, then you'll get a message about mdadm.conf not being found on startup. It's nothing, really, but perhaps the initscripts should have something to bypass the software RAID stuff if mdadm.conf isn't found. Or maybe initscripts should have mdadm as a dependency.
i have this problem also how can i fix it ??? is there a way to do this ??? thanx
Offline
i have this problem also how can i fix it ??? is there a way to do this ??? thanx
/me points to the third post
Offline
Interesting. I figured test would optimize an AND condition and not check the second qualifier if the first failed. Guess not.
Try this patch and see if the error goes away.
--- rc.sysinit 2005-11-10 14:06:31.000000000 -0800 +++ rc.sysinit.new 2005-11-10 14:07:10.000000000 -0800 @@ -41,7 +41,7 @@ fi # If necessary, find md devices and manually assemble RAID arrays -if [ -f /etc/mdadm.conf -a "`grep ^ARRAY /etc/mdadm.conf`" ]; then +if [ -f /etc/mdadm.conf -a "`grep ^ARRAY /etc/mdadm.conf 2>/dev/null`" ]; then if [ -d /initrd/dev ]; then # udev won't create these md nodes, so we steal them from the initrd for i in `grep ^ARRAY /etc/mdadm.conf | awk '{print $2}'`; do
Committed the fix.
Sorry, but his is not a fix. It's just an ugly way to hide the error. You should really do
if [ -f /etc/mdadm.conf ] && grep -q ^ARRAY /etc/mdadm.conf; then
[...]
fi
or use a double if
if [ -f /etc/mdadm.conf ]; then
if grep -q ^ARRAY /etc/mdadm.conf; then
[...]
fi
fi
Offline
Yeah, I didn't understand that "fix" to be honest - your first correction seems sensible for me but maybe we are missing something subtle?
Offline
Sorry, but his is not a fix. It's just an ugly way to hide the error. You should really do<snip>
Sorry, wrong. Programs fail for a reason. They exit cleanly. There is no reason to test if a file exists before running cat, because cat will fail if the file does not exist. The same goes for grep.
By the same token, there are many *many* old unix programs (and most of plan9) which do no memory cleanup... they malloc a bunch of stuff and exit - the kernel cleans it up. No need to waste time if the kernel's going to do it anyway. In this regard, grep/cat/whatever already check if the file exists, so you're just repeatedly checking, instead of doing it once.
Call it ugly if you want, but it's exactly how the program works. The logic is 100% identical, this "fix" is just hiding the error message - because people freak out on simple messages (do a search for shpchp or whatever the hell it is - "ZOMG an errer massage, wut shud I dooz?!")
Offline
Mythoz wrote:Sorry, but his is not a fix. It's just an ugly way to hide the error. You should really do<snip>
Sorry, wrong. Programs fail for a reason. They exit cleanly. There is no reason to test if a file exists before running cat, because cat will fail if the file does not exist. The same goes for grep.
What?! If that's true phrak why have the first test command at all? All mythoz has suggested is a tidier test AND test command, i.e. a better version (IMHO) of what there is now - but from what you are saying it seems like the first test is point less and it should just be the grep command 2>/dev/null
So...I don't get your point - maybe I misunderstood tho
Offline
So...I don't get your point - maybe I misunderstood tho
For some reason, I read the patch as just removing the test and only having the grep >/dev/null chunk in there - not sure why.
That would be the most ideal situation.
Offline
Ahhh - so you were ranting somewhat unfairly then? Tho I agree with you with regard to best solution
Offline
Mythoz wrote:Sorry, but his is not a fix. It's just an ugly way to hide the error. You should really do<snip>
Sorry, wrong. Programs fail for a reason. They exit cleanly. There is no reason to test if a file exists before running cat, because cat will fail if the file does not exist. The same goes for grep.
Huh, this programming paradigm looks strage to me. Maybe because I am a C/C++ programmer. Accessing an invalid pointer is a very bad idea there. On the other hand I always keep performance aspects at the back of mine mind. A simple test for an exisiting file is much cheaper than a complete call of grep. But maybe this does not matter in shell script programming.
For some reason, I read the patch as just removing the test and only having the grep >/dev/null chunk in there - not sure why.
Yes, the first test is absolutly pointless because grep is executed anyway. If you really want to use it that way, there is an more elegant solution since grep has a special option for this:
if grep -q -s ^ARRAY /etc/mdadm.conf; then
[...]
fi
Offline