[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Grub2 reinstall on raid1 system.

On Fri, 14 Jan 2011 05:25:45 -0700
Bob Proulx <bob@proulx.com> wrote:

> Jack Schneider wrote:
> > I have a raid1 based W/S running Debian Squeeze uptodate. (was
> > until ~7 days ago) There are 4 drives, 2 of which had never been
> > used or formatted. I configured a new array using Disk Utility from
> > a live Ubuntu CD. That's where I screwed up... The end result was
> > the names of the arrays were changed on the working 2 drives.
> > IE: /dev/md0 to /dev/126 and /dev/md1 became md127.
> Something else must have happened too.  Because normally just adding
> arrays will not rename the existing arrays.  I am not familiar with
> the "Disk Utility" that you mention.
Hi, Bob 
Thanks for your encouraging advice...

As I mentioned in a prior post,Grub was leaving me at a Grub rescue>prompt.  

I followed this procedure:
Booting now leaves me at a busy box: However the Grub menu is correct.
With the correct kernels. So it appears that grub is now finding the
root/boot partitions and files. 
> Next time instead you might just use mdadm directly.  It really is
> quite easy to create new arrays using it.  Here is an example that
> will create a new device /dev/md9 mirrored from two other devices
> /dev/sdy5 and /dev/sdz5.
>   mdadm --create /dev/md9 --level=mirror
> --raid-devices=2 /dev/sdy5 /dev/sdz5
> > Strangely the md2 array which I setup on the added drives remains as
> > /dev/md2. My root partition is/was on /dev/md0. The result is that
> > Grub2 fails to boot the / array.
> You may have to boot a rescue cd.  I recommend booting the Debian
> install disk in rescue mode.  Then you can inspect and fix the
> problem.  But as of yet you haven't said enough to let us know what
> the problem might be yet.
> > I have tried three REINSTALLING GRUB procedures from Sysresccd
> > online docs and many others GNU.org, Ubuntu etc.
> This isn't encouraging.  I can tell that you are grasping at straws.
> You have my sympathy.  But unfortunately that doesn't help diagnose
> the problem.  Remain calm.  And repeat exactly the problem that you
> are seeing and the steps you have taken to correct it.
> > The errors occur when I try to mount the partition with the /boot
> > directory. 'Complains about file system type 'linux_raid_member'
> I haven't seen that error before.  Maybe someone else will recognize
> it.
> I don't understand why you would get an error mounting /boot that
> would prevent the system from coming online.  Because by the time the
> system has booted enough to mount /boot it has already practically
> booted completely.  The system doesn't actually need /boot mounted to
> boot.  Grub reads the files from /boot and sets things in motion and
> then /etc/fstab instructs the system to mount /boot.
> Usually when the root device cannot be assembled the error I see is
> that the system is "Waiting for root filesystem" and can eventually
> get to a recovery shell prompt.
> > This machine has worked for 3 years flawlessly.. Can anyone help
> > with this? Or point me to a place or link to get this fixed. Google
> > doesn't help... I can't find a article/posting where it ended
> > successfully.  I have considered a full reinstall after Squeeze goes
> > stable, since this O/S is a crufty upgrade from sarge over time. But
> > useless now..
> The partitions for raid volumes should be 'autodetect' 0xFD.  This
> will enable mdadm to assemble then into raid at boot time.
> You can inspect the raid partitions with --detail and --examine.
>   mdadm --examine /dev/sda1
>   mdadm --detail /dev/md0

mdadm --examine /dev/sda1 & /dev/sda2  gives I think a clean result 
I have posted the output at : http://pastebin.com/pHpKjgK3
mdadm --detail /dev/md0 --> gives  mdadm: md device /dev/md0 does not
appear to be active. 

There is no /proc/mdstat  data output.  

> That will list information about the devices.  Replace with your own
> series of devices.
> I would boot a rescue image and then inspect the current configuration
> using the above commands.  Hopefully that will show something wrong
> that can be fixed after you know what it is.
> A couple of other hints: If you are not booting a rescue system but
> using something like a live boot then you may need to load the kernel
> modules manually.  You may need to load the dm_mod and md_mod modules.
>   modprobe md_mod
> You might get useful information from looking at the /proc/mdstat
> status.

>   cat /proc/mdstat
> There is a configuration file /etc/mdadm/mdadm.conf that holds the
> UUIDs of the configured devices.  If those have become corrupted then
> mdadm won't be able to assemble the /dev/md* devices.  Check that file
> and compare against what you see with the --detail output.
> The initrd contains a copy of the mdadm.conf file with the components
> needed to assemble the root filesystem.  If the UUIDs change over what
> is recorded in the initrd then the initrd will need to be rebuilt.  To
> do that make sure that the /etc/mdadm/mdadm.conf file is correct and
> then reconfigure the kernel with dpkg-reconfigure.
>   dpkg-reconfigure linux-image-2.6.32-5-i686
> Good luck!
> Bob

So it appears that I must rebuild my arrays.  I think I can munge thru
the mdadm man pages or Debian Reference to get the tasks.

Thanks for the help..  You need all the help you can get at 76yrs..


Reply to: