Doug Ledford wrote:
On Fri, 2007-10-26 at 10:18 -0400, Bill Davidsen wrote:
[___snip___]
Actually, after doing some research, here's what I've found:
* When using lilo to boot from a raid device, it automatically installs
itself to the mbr, not to the partition. This can not be changed. Only
0.90 and 1.0 superblock types are supported because lilo doesn't
understand the offset to the beginning of the fs otherwise.
I'm reasonably sure that's wrong, I used to set up dual boot machines by
putting LILO in the partition and making that the boot partition, by
changing the active partition flag I could just have the machine boot
Windows, to keep people from getting confused.
* When using grub to boot from a raid device, only 0.90 and 1.0
superblocks are supported[1] (because grub is ignorant of the raid and
it requires the fs to start at the start of the partition). You can use
either MBR or partition based installs of grub. However, partition
based installs require that all bootable partitions be in exactly the
same logical block address across all devices. This limitation can be
an extremely hazardous limitation in the event a drive dies and you have
to replace it with a new drive as newer drives may not share the older
drive's geometry and will require starting your boot partition in an odd
location to make the logical block addresses match.
* When using grub2, there is supposedly already support for raid/lvm
devices. However, I do not know if this includes version 1.0, 1.1, or
1.2 superblocks. I intend to find that out today. If you tell grub2 to
install to an md device, it searches out all constituent devices and
installs to the MBR on each device[2]. This can't be changed (at least
right now, probably not ever though).
That sounds like a good reason to avoid grub2, frankly. Software which
decides that it knows what to do better than the user isn't my
preference. If I wanted software which fores me to do things "their way"
I'd be running Windows.
So, given the above situations, really, superblock format 1.2 is likely
to never be needed. None of the shipping boot loaders work with 1.2
regardless, and the boot loader under development won't install to the
partition in the event of an md device and therefore doesn't need that
4k buffer that 1.2 provides.
Sounds right, although it may have other uses for clever people.
[1] Grub won't work with either 1.1 or 1.2 superblocks at the moment. A
person could probably hack it to work, but since grub development has
stopped in preference to the still under development grub2, they won't
take the patches upstream unless they are bug fixes, not new features.
If the patches were available, "doesn't work with existing raid formats"
would probably qualify as a bug.
[2] There are two ways to install to a master boot record. The first is
to use the first 512 bytes *only* and hardcode the location of the
remainder of the boot loader into those 512 bytes. The second way is to
use the free space between the MBR and the start of the first partition
to embed the remainder of the boot loader. When you point grub2 at an
md device, they automatically only use the second method of boot loader
installation. This gives them the freedom to be able to modify the
second stage boot loader on a boot disk by boot disk basis. The
downside to this is that they need lots of room after the MBR and before
the first partition in order to put their core.img file in place. I
*think*, and I'll know for sure later today, that the core.img file is
generated during grub install from the list of optional modules you
specify during setup. Eg., the pc module gives partition table support,
the lvm module lvm support, etc. You list the modules you need, and
grub then builds a core.img out of all those modules. The normal amount
of space between the MBR and the first partition is (sectors_per_track -
1). For standard disk geometries, that basically leaves 254 sectors, or
127k of space. This might not be enough for your particular needs if
you have a complex boot environment. In that case, you would need to
bump at least the starting track of your first partition to make room
for your boot loader. Unfortunately, how is a person to know how much
room their setup needs until after they've installed and it's too late
to bump the partition table start? They can't. So, that's another
thing I think I will check out today, what the maximum size of grub2
might be with all modules included, and what a common size might be.
Based on your description, it sounds as if grub2 may not have given
adequate thought to what users other than the authors might need (that
may be a premature conclusion). I have multiple installs on several of
my machines, and I assume that the grub2 for 32 and 64 bit will be
different. Thanks for the research.
--
bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
