Bug#398312: INITRDSTART='none' doesn't work
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. update-initramfs -c -b . -k $(uname -r) 8.48s user 1.58s system 35% cpu 28.365 total piper:/tmp/cdt.d.Ns8889# zcat initrd.img-2.6.18-2-amd64| cpio -i 27018 blocks piper:/tmp/cdt.d.Ns8889# grep DEVS conf/md.conf MD_DEVS=none I get the same result whether I have arrays defined in /etc/mdadm/mdadm.conf or not. Also, if you look at /usr/share/initramfs-tools/hooks/mdadm, I cannot figure out how the behaviour you're seeing is even possible: [...] INITRDSTART=all [ -s $DEBIANCONFIG ] . $DEBIANCONFIG [ -z $INITRDSTART ] INITRDSTART=none [...] if [ $INITRDSTART != none ] [ -n $devpairs ]; then [...] else echo MD_DEVS=none $DESTCONFIG info no MD arrays will be started from the initial ramdisk. 2 fi [...] Please try again after sed -i 's,set -eu,x,' /usr/share/initramfs-tools/hooks/mdadm and post the output. 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. and starting all arrays is a bad one. if i built my initrd without an mdadm.conf i don't see why you would create one... maybe if you asked first unable to find root device, should i try to autodiscover and start arrays? or required an option on the kernel command line... My goal with mdadm was to make it a smooth upgrade from 1.9.x. I realise that it doesn't do everything it should, nor is it free of hacks, but there was only so much I could do with it in time for etch. I am willing to consider alternatives once etch is out. However, an interactive prompt during the startup sequence is not one of them. Instead, as per #398310, I would like to make mdadm deal with a matrix of devices and times when they should be assembled/stopped. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#398312: INITRDSTART='none' doesn't work
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.0 -0800
+++ /usr/share/initramfs-tools/hooks/mdadm 2006-11-13 01:51:37.0
-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]
Bug#398312: Re: Bug#398312: INITRDSTART='none' doesn't work
also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.1107 +0100]:
which causes the is_true() in info() to return 1 which causes the set -e
to terminate the script.
What shell are you using?
Does it work if you change info() to
info()
{
is_true ${VERBOSE:-false} write I $@ || :
}
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.
I do not see the problem with dash or zsh, so I guess you must be
using bash then. I wonder whether it isn't bash's fault, but I do
agree that the info function should not return false when
VERBOSE=false.
Fixed merged into 2.5.6-5.
is it really that hard to start only the root array?
What is the root array? What if you have LVM on two arrays providing
the root filesystem? Trust me, it's not that easy, and I cannot make
any drastic changes anymore due to the freeze.
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
Bug#398312: Re: Bug#398312: INITRDSTART='none' doesn't work
On Mon, 13 Nov 2006, martin f krafft wrote: also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.1107 +0100]: which causes the is_true() in info() to return 1 which causes the set -e to terminate the script. What shell are you using? my SHELL=/bin/zsh, but that won't affect the script... the script is #!/bin/sh ... and /bin/sh - bash. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398312: INITRDSTART='none' doesn't work
Package: mdadm Version: 2.5.5-1 Severity: grave 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. 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) here's my current setup: # grep -ve '^#' -e '^ *$' /etc/mdadm/mdadm.conf DEVICE partitions CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST system MAILADDR root # grep -ve '^#' -e '^ *$' /etc/default/mdadm INITRDSTART='none' AUTOSTART=false AUTOCHECK=false START_DAEMON=false VERBOSE=false USE_DEPRECATED_MDRUN=false notice i have no arrays defined. # dpkg-reconfigure linux-image-`uname -r` Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. W: mdadm: /etc/mdadm/mdadm.conf defines no arrays. Not updating initrd symbolic links since we are being updated/reinstalled (twinlark.1 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (twinlark.1 was configured last, according to dpkg) Running postinst hook script /sbin/update-grub. Searching for GRUB installation directory ... found: /boot/grub Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... Found kernel: /boot/vmlinuz-2.6.17.11 Found kernel: /boot/vmlinuz-2.6.17-2-amd64 Found kernel: /boot/vmlinuz-2.6.16-2-amd64-generic Found kernel: /boot/memtest86+.bin Updating /boot/grub/menu.lst ... done notice it complains that i have no arrays defined. # mkdir /tmp/initrd # cd /tmp/initrd # zcat /boot/initrd.img-`uname -r` | cpio -i 26975 blocks ok now i look at scripts/local-top/mdadm ... i note it sets MD_DEVS=all, which presumably should be overridden by /conf/md.conf... yet conf/md.conf contains: # cat conf/md.conf MD_HOMEHOST='groove242' missing MD_DEVS=none. also, scripts/local-top/mdadm goes on to test there's an /etc/mdadm/mdadm.conf, which isn't present in the initrd. because etc/mdadm/mdadm.conf isn't there, scripts/local-top/mdadm goes on to autodiscover all arrays... and then because of the missing MD_DEVS=none it assembles them all. as mentioned, this can result in data loss. while i think the root of the problem is that MD_DEVS=none wasn't copied from /etc/default/mdadm settings... i think this habit of discovering and starting all arrays is a bad one. if i built my initrd without an mdadm.conf i don't see why you would create one... maybe if you asked first unable to find root device, should i try to autodiscover and start arrays? or required an option on the kernel command line... anyhow, now to go see if this didn't ruin the drives i'm trying to recover (see #398310). -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
