RE: Temporarily Disable Array

* RE: Temporarily Disable Array
       [not found] <AANLkTiktOdqq5Y3OWvU5dusDy+t_guEo88jm=DN-HnR8@mail.gmail.com>
@ 2011-02-08  0:14 ` Leslie Rhorer
  2011-02-09 19:08   ` hansbkk
  0 siblings, 1 reply; 4+ messages in thread
From: Leslie Rhorer @ 2011-02-08  0:14 UTC (permalink / raw)
  To: hansbkk; +Cc: 'Linux RAID'


> -----Original Message-----
> From: hansbkk@gmail.com [mailto:hansbkk@gmail.com]
> Sent: Sunday, February 06, 2011 9:07 AM
> To: lrhorer@satx.rr.com
> Subject: Re: Temporarily Disable Array
> 
> I assume no one every replied (and I can't comment other than "sounds
> good to me" 8-)
> 
> FFR did you do this and did it work?

	I did, but it didn't work as I had planned.  About a year ago, I ran
across a bug that had caused the homehost field on the arrays to gave a pair
of single quote marks in it.  Upon upgrade of mdadm, this causes the
automatic assembly of the RAID arrays to fail.  I thought I had fixed the
issue on all the arrays, but evidently not.  When I tried the upgrade, it
failed to boot.  I never even thought about the problem with the quote marks
until I finally ran it to ground.  If I had thought of the issue, it would
have been fine, and I would have fixed it in a matter of minutes.  As it
was, it took me two days to find the problem, because every time I would
move down one avenue for recovery, something else would prohibit me from
getting the system into a state where troubleshooting was practical.  In the
mean time, all four arrays on the system suffered some fairly dastardly
abuse.  They all survived, however, if not entirely intact, then at least
with no more damage than could easily be fixed.  Most importantly, there was
no loss of data, other than a couple of battered superblocks and one small
array that had to be rebuilt.

	There was also one small issue with the boot array.  GRUB2 was able
to assemble it just fine so as to get through the boot, but then the array
would not assemble for the kernel.  It turned out the newer mdadm was
insisting the metadata statement say, "0.90", instead of "0.9" in
mdadm.conf.
 
> On Sat, Feb 5, 2011 at 11:44 AM, Leslie Rhorer <lrhorer@satx.rr.com>
> wrote:
> >
> >        In a few days, I am going to be upgrading Linux on one of my
> servers
> > from Debian "Lenny" to "Squeeze".  I've gone through this upgrade a
> handful
> > of times, and it can be pretty tricky.  It would be best if the data
> array
> > were not assembled over and over again during the process.  I know it
> really
> > shouldn't make a difference, but in the real world stability issues have
> > raised their ugly heads more than once causing additional time and
> heartache
> > associated with the array to be required to complete the task.  With
> this in
> > mind, I would like to temporarily disable the assembly of the array
> until
> > the upgrade is complete and the system stable.  Do I have the following
> > checklist correct, or is there something wrong or missing?  Are there
> better
> > alternatives?  I'm not missing something about the "homehost" utility,
> am I?
> >
> > 1.  Edit /etc/mdadm/mdadm.conf and comment out the line specifying the
> > array.  Also comment out the line "HOMEHOST <system>"
> >
> > 2.  Edit /etc/fstab and comment out the line specifying the mount point
> for
> > the array.
> >
> > 3.  Issue the command `update-initramfs -u`
> >
> > 4.  Reboot the system, making sure the array does not assemble.
> >
> > 5.  Perform the OS upgrade.
> >
> > 6.  Edit mdadm.conf and fstab, removing the comment markers placed in
> steps
> > 1 and 2.
> >
> > 7.  Issue the command `update-initramfs -u`
> >
> > 8.  Reboot the system, making sure the array assembles and mounts.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread