Re: Can squeeze boot into a LVM over RAID?
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
Reply to: