On Mon, 13 Nov 2006, martin f krafft wrote:
> severity 398312 important
> tags 398312 unreproducible moreinfo
> thanks
>
> > even though i have INITRDSTART='none' in my /etc/default/mdadm and rebuilt >
> the initrd, it still goes and does array discovery at boot time.
>
> piper:/tmp/cdt.d.Ns8889# grep '^INITRD' /etc/default/mdadm
> INITRDSTART='none'
> piper:/tmp/cdt.d.Ns8889# update-initramfs -c -b . -k $(uname -r)
> update-initramfs: Generating ./initrd.img-2.6.18-2-amd64
> W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
> I: mdadm: using configuration file: /etc/mdadm/mdadm.conf
> I: mdadm: no MD arrays will be started from the initial ramdisk.
> I: mdadm: use `dpkg-reconfigure --priority=low mdadm` to change this.
try again with VERBOSE=false...
which causes the is_true() in info() to return 1 which causes the set -e
to terminate the script.
perhaps this bug report should be titled "set -e considered harmful" :)
set -e would be better if it actually caused sh to complain when the
error occured... instead it's the worst of both worlds: scripts exit
due to programming errors and then you have no idea they exited early.
> > this is marked grave because it can cause dataloss if drives with
> > stale superblocks are put together in an unexpected manner
> > resulting in an array rebuild. (i.e. same reasoning as #398310)
>
> Again, I don't see this as a grave bug but human error. I agree that
> mdadm should do something against it, but it's not a grave problem
> every time that it fails to prevent human error.
i dunno, it's not really a human error to not know anything at all about
the superblocks.
with the default settings of INITRDSTART='all' it's impossible for a
person to stick some old PATA disks (which happen to be part of an old
array) into their box. because it requires a reboot and then initrd
will make an array and md might start trying to rebuild the disks. i
can't even stick them in to do --zero-superblock...
unless i change INITRDSTART setting and rebuild initrd.
is it really that hard to start only the root array? i suppose it is a
challenge on an upgrade... because you don't have the helpful sysfs
features that newer 2.6.x kernels provide for finding dependencies.
blah.
-dean
--- /var/tmp/mdadm.orig 2006-11-13 01:28:46.000000000 -0800
+++ /usr/share/initramfs-tools/hooks/mdadm 2006-11-13 01:51:37.000000000
-0800
@@ -23,14 +23,6 @@
;;
esac
-is_true()
-{
- case "${1:-}" in
- [Yy]es|[Yy]|1|[Tt]rue|[Tt]) return 0;;
- *) return 1;
- esac
-}
-
write()
{
local PREFIX; PREFIX=$1; shift
@@ -39,7 +31,9 @@
info()
{
- is_true ${VERBOSE:-false} && write I "$@"
+ if [ "$VERBOSE" = "true" ]; then
+ write I "$@"
+ fi
}
warn()
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
