Re: Grub2 reinstall on raid1 system.
On Tue, 18 Jan 2011 17:31:29 -0700
Bob Proulx <bob@proulx.com> wrote:
> Jack Schneider wrote:
> > It booted to the correct grub menu then to Busy Box. I am thinking
> > it goes to BB because it can't find /var and or /usr on the
> > md1/sda5 LVM partition.
>
> Very likely.
>
> > I checked /proc/mdstat and lo & behold there was md1:active
> > with correct partitions and md0: active also correct partitions...
>
> That is good news to hear. Becuase it should mean that all of your
> data is okay on those disks. That is always a comfort to know.
>
> > So here I sit with a root prompt from Busy Box.... I checked mdadm
> > --examine for all known partitions and mdadm --detail /mdo & /md1
> > and all seems normal and correct. No Errors.
>
> Yeah! :-)
>
> > Both /etc/fstab and /etc/mtab show entries for /dev/md126..
> > What the ... ?
>
> That does seem strange. Could the tool you used previously have
> edited that file?
>
> You said you were using /dev/md1 as an lvm volume for /var, /home,
> swap and other. As I read this it means you would only have /dev/md0
> for /boot in your /etc/fstab. Right? Something like this from my
> system:
>
> /dev/md0 /boot ext2 defaults 0 2
>
> You /var, /home and swap would use the lvm, right? So from my system
> I have the following:
>
> /dev/mapper/v1-var /var ext3 defaults 0 2
> /dev/mapper/v1-home /home ext3 defaults 0 2
>
> Those don't mention /dev/md1 (which showed up for you as /dev/md126)
> at all. They would only show up in the volume group display.
>
> If you are seeing /dev/md126 in /etc/fstab then it is conflicting
> information. You will have to sort out the information conflict. Do
> you really have LVM in there?
>
> Certainly if the "/dev/md0 /boot" boot line is incorrect then you
> should correct it. Edit the file and fix it. If your filesystem is
> mounted read-only at that point you will need to remount it
> read-write.
>
> mount -n -o remount,rw /
>
> Bob
Hi, Bob Back at it...8-(
I think I found a significant glitch.. I appears that mdadm is
confused. I think it happened when I created the /dev/md2 array from
the new disks. It looks like the metadata 1.2 vs 0.90 configs is the
culprit...
Here's the output of:
mdadm --detail --scan:
ARRAY /dev/md0 metadata=0.90 UUID=e45b34d8:50614884:1f1d6a6a:d9c6914c
ARRAY /dev/md1 metadata=0.90 UUID=c06c0ea6:5780b170:ea2fd86a:09558bd1
Here's the output of /etc/mdadm/mdadm.conf:
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=f6de5584:d9dbce39:090f16ff:f795e54c name=hetzner:0
ARRAY /dev/md/1 metadata=1.2 UUID=0e065fee:15dea43e:f4ed7183:70d519bd name=hetzner:1
ARRAY /dev/md/2 metadata=1.2 UUID=ce4dd5a8:d8c2fdf4:4612713e:06047473 name=hetzner:2
# This file was auto-generated on Mon, 10 Jan 2011 00:32:59 +0000
# by mkconf 3.1.4-1+8efb9d1
Given that the metadata from 0.90 & 1.2 cannot be on each md0 and md1
at the same time. Although they are on different places on the disks
IIRC. Something needs to change... I am thinking of an mdadm.conf
edit. But there maybe an alternative tool or approach... ????
This was obtained using my Debian-live amd64 rescue disk.
TIA
Jack
Reply to: