well *I* think it's a bug

You can report problems, make suggestions, about the new BETA versions in this forum. For stuff related to final releases, please post a message in other forums
Post Reply
Posts: 12
Joined: 25 Jan 2011, 15:16

well *I* think it's a bug

Post by HansBKK » 28 Jan 2011, 19:17

First of all, SRCD's an *excellent* sysadmin tool, not just for rescue/recovery but also routine maintenance for servers whose production OSs are running outdated toolsets that can't be upgraded in situ. Thanks so much for all your hard work on this!!

And I'm probably not qualified to bring this up, but hey that doesn't stop me 8-)

Also the below is based on my experience with the shipping 2.0.0 rather than any beta (didn't seem a more appropriate forum to post in?)

I already mentioned this issue in a thread titled "stop messing with my raid", but since then I've done more thorough testing, and can't imagine the developers actually want SRCD to behave this way:

Vanilla boot, ls -l /dev/md*: my 0.90 raid1 arrays have been re-assigned new device numbers, almost but not quite randomly, with extra names symlinked to other ones (md0_0 ==> md124 etc, next time md124_0 ==>md129 etc), none of this usefully. Apparently the array's (components') superblocks are actually being written to and the "preferred minor" being changed, as the array's ability to boot in my production setup is now broken until I go re-write the GRUB scripts to use UUIDs. "Bad kernel! Bad!"

Boot with kernel option "nomdadm": the same arrays are now beautifully presented with their original intended device names md0, md1, md2 etc. (BTW I do have a backing store containing a carefully crafted mdadm.conf)

So two issues here - first of all is the default mangling going on without using the "nomdadm" option. The second is that this boot option **isn't in fact preventing** SRCD from auto-assembling the mdadm arrays!

What follows is just my uninformed speculation based on some googling around (see link below).

It seems the "nomdadm" option is just preventing the kernel itself from mangling the job, allowing udev to do it properly using mdadm later on. Apparently this is the current best practice, and should be the default, (again apparently) enabled with the kernel option "CONFIG_MD_AUTODETECT=n" which I'm guessing isn't the way SRCD's (nor upstream Gentoo?) is compiled, and that doing so would fix the first issue nicely.

Then I would suggest the "nomdadm" option be implemented to prevent any and all later init scripts from performing array auto-assembly (udev/mdadm?) or a differently named one if necessary, but I can't imagine anyone would actually want a "yesmdadm" (iow "yes kernel please buggily assemble my array without going through mdadm" 8-)

Probably related issue in Ubuntu:
https://bugs.launchpad.net/ubuntu/+sour ... bug/551719

PS just as a side note, Grml has apparently implemented these fixes already, and I personally prefer their philosophy - don't assemble the arrays by default - the boot screen tells the user to use "Start mdadm-raid" if he wants that, and there is a boot option to automate it if desired (same with LVM). But I'm sure you've all had debates back and forth on this, obviously a conscious choice.

Thanks for taking all this into consideration. . .

Post Reply