On Sat, 01 Sep 2012 16:32:39 -0600, Shane Johnson wrote:
I have a few machines with Raid 5 with LVM on top. Here is what I can
share with you. You must have grub2 installed ( I believe it is default
now but I always specify when installing.)
That means I'll have to start by upgrading grub from 1.98 to grub2.
Would it be safer to upgrade squeeze to wheezy first just to make sure I
have a really up-to-date grub?
your ARRAY info from mdadm
-D --scan must be in your /etc/mdadm/mdadm.conf file and be accurate.
When I change something, I make sure /boot/grub/device.map is accurate
and up to date. I make initrd is up to date. I then run update-grub2.
then I run : for i in a b c d e (for whatever drives you have); do
install-grub /dev/sd$(echo $i)
done
This makes sure the grub image file is installed and updated on whatever
drive is the boot drive.
By making sure it's on all of them.
I have run into problems with DOS compatible
partitions. To overcome this I don't use DOS compatibility in fdisk
anymore and use sectors for partitioning.
So far works wonderfully and I don't have to have /boot separate.
I have run into one instance where I couldn't boot that I haven't
figured out yet. It was on a 10 disk array I was hobbling together for
a SAN/NAS but just gave up and put the OS on a separate disk and now it
is booting. Before I put it on the seperate disk, I did discover that
some of the disk where not showing to grub from the grub emergency CL.
I think one or two of the disk controllers wasn't showing. Oh and one
instance that required a complete removal and install of grub for it to
boot properly. If you aren't hacking stuff together much and making a
lot of changes, you shouldn't have a problem.
Shane
On Sat, Sep 1, 2012 at 3:58 PM, Mark Allums <mark@allums.com> wrote:
On 9/1/2012 4:46 PM, Hendrik Boom wrote:
Thanks. Will try it in the next few days. Will also install grub to
the MBR of all my disks, so whichever gets picked at boot time will
work.
Is there an eaasy way to do this, so that they'll all get updated as
necessary when aptitude installs a new kernel? Or it this not
something that the MBR cares about?
And is the association of, say, /dev/sdb with a particular hard drive
consistent if there's no change in hardware, or does it depend on
random boot-tine timing issues?
- hendrik
As Tom H mentioned, on standard Squeeze, not partitioned RAID. Sorry
for the confusion.
You should use UUIDs or labels if you wand to reliably always boot or
mount a particular partition. The /dev/sdx designations are subject to
the winds of variability in a system, and it apparently has been deemed
unnecessary to sort this out, since UUIDs and labels are available.
Some distributions are smart enough to write the MBR to all disks in a
RAID 1, and others are not. I don't recall if Squeeze will or won't,
or or if Wheezy will, for that matter. I haven't installed either
recently enough to need to find out.
My RAID consists of two partitions, on on each of two physical drives.
Those physical drives have their own MBRs, partition tables, etc. The
RAID containe several file systems.
I don't expect the MBR to reside within the RAID.
It will be possible to place /boot on a partition on one of those two
drives outside the RAID if the squeeze boot process has difficulty with
finding /boot on LVM on RAID.
One thing I wonder about is how the boot process gets from the MBR to
reading enough of the file system to get to initrd and the kernel.
Presumably the MBR isn't big enough to contain the code for a file system.
And presumably the MBR does know where to read some file that does contian
the code for reading a file system to find the various configurations
sitting in /boot/grub. But how? And where?
-- hendrik