On Sat, 26 May 2012, Michael Tokarev wrote: > On 26.05.2012 16:06, Cristian Ionescu-Idbohrn wrote: > > hi mdadm 3.2.5-1 tool to administer Linux MD arrays > > ..because it is sid, and this is mdadm version I uploaded to > unstable/sid just a few HOURS ago, and you already have it > installed. This means you had a few upgrades of it already, > each overwrote your changes, and your system is still bootable. > > In the initramfs/conf.d/md, only alternative device names are > listed, -- this also confirms that your change does not work > anymore, since after your change there should be both variants > of the naming.
True. All that stuff vanished when I replaced the discs. > And now the whole thing looks pretty much okay, AND we can > be sure that at least the boot array is assembled automatically > from within initramfs, -- you still have your root filesystem > in /dev/md0 (or /dev/md/0). Yes. > Note the package is placed on hold, yet it is of very latest > unstable version.. you may want to inspect your system > configuration more closesly... ;) Yes. The package is placed on hold, intentionally. > Note also that you still have the same inconsistency -- you list > /dev/md/0 in mdadm.conf, but use /dev/md0 as root filesystem. I > can't say it works by design, more by a chance, it is better to > use consistent naming there. Alright. You possibly mean changing /etc/fstab? Is /dev/md/0 the preferred device name (and /dev/md0 an alias) or the other way around? > As far as I can see, the original problem was due to the fact > that mdadm initramfs script did not assemble any arrays at all, > but it worked when using `mdadm --assemble --scan' manually. Sounds like that was the case. > That can happen if it weren't able to find running arrays to > start with, when generating initramfs. The diffs from > update-initramfs you provided sort of confirm this. > > But note this change: > > commit debb4be5b5bdf2819699fd2a65e19632d98a1c5c > Author: martin f. krafft <[email protected]> > Date: Fri Jan 29 18:37:03 2010 +1300 > > translate between /dev/mdX and /dev/md/X > > Signed-off-by: martin f. krafft <[email protected]> > > diff --git a/debian/changelog b/debian/changelog > index 6cd1eb8..a0e79bd 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -5,6 +5,7 @@ mdadm (3.1.1-2) UNRELEASED; urgency=low > bugscript output. > * Check active devices against configuration file based on UUID, not device > name. > + * When preparing the list of devices, treat /dev/mdX and /dev/md/X equally. > > -- martin f. krafft <[email protected]> Wed, 27 Jan 2010 14:42:16 +1300 > > diff --git a/debian/initramfs/hook b/debian/initramfs/hook > index 9b73055..b9c619a 100644 > --- a/debian/initramfs/hook > +++ b/debian/initramfs/hook > @@ -195,6 +195,21 @@ else > esac > done > [ -n "${dev:-}" ] || continue > + > + # /dev/mdX and /dev/md/X are the same, really > + case "$dev" in > + (/dev/md/*) alt=/dev/md${dev##*/};; > + (/dev/md*) alt=/dev/md/${dev#/dev/md};; > + (*) > + err "unknown device encountered: $dev" > + warn_emergency > + exit 0 > + ;; > + esac > + if [ ! -b "$dev" ] && [ -b "$alt" ]; then > + dev="$alt" > + fi > + > echo -n "${dev}:" > if [ -n "${level:-}" ]; then > echo -n "$level" > > (which has been made before reported version 3.1.4-1+8efb9d1) Well, as I said, I don't recall much about the circumstances but it would seem the problems I had were related to: * When preparing the list of devices, treat /dev/mdX and /dev/md/X equally. in one way or another. > This change should make the script to recgnize either form > when generating the image. The only possible case I can think > of is when you listed > > INITRDSTART=/dev/md0 Many moons later, but yes, it sounds reasonable. > (the same as for root filesystem in fstab), but using /dev/md/0 > in mdadm.conf -- in this case, mkinitramfs reports: > > W: mdadm: I am supposed to start /dev/md0 from the initial ramdisk, > W: mdadm: yet I cannot find the array in the configuration file. > W: mdadm: I am thus reverting to starting all arrays. Yes, I do recall those messages ;) > But actually it does not start anything during initramfs, in the > way you observed. > > Is (was) that the case, can you remember/comment ? Sorry. Parts of my memory were wiped out at some point ;) Maybe the bug#632401 submitter can remember more? Cheers, -- Cristian -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
