Re: Grub2 reinstall on raid1 system.
On Fri, 14 Jan 2011 05:25:45 -0700
Bob Proulx <firstname.lastname@example.org> 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.
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
> 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
> 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!
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..