On Tue, 2008-11-25 at 09:21 -0500, Lennart Sorensen wrote:
> Certainly in the past that didn't always work.  lilo would assume hda
> was 0x80 and if you had mixed ide and scsi you had to explitly teach
> lilo that 0x80 was in fact sda not hda on your system, or it wouldn't
> work.

As I _strongly_ made this point before (and will again for anyone who
missed it ;), _both_ GRUB _and_ LILO _require_ mapping lines.  _Neither_
can do it "automatically."

> And in some cases your drive names change between boots depending on
> driver load order, how does lilo deal with that?

It does not, and there is a false sense it will.  LILO can make some
"assumptions," but it still has trouble.  But this is a "great issue" in
general -- the remapping of BIOS disks to the boot loader mapping.  And
it can get even worse.

What about when the disk still shows up _after_ the BIOS has mapped it
first, but now that's the first device from the standpoint of the OS?
This has always been a major issue with software RAID and the multi-disk
driver, through no fault of its own (among other things).

FUTURE NOTE:  

I've long _avoided_ MD not because of MD, but because of things built
around MD, touch MD and -- in general -- sometimes look at a set of MD
slices (partitions) as individual Ext3.  Although newer MD meta-data
solves this, it's still a problem, and causes me to use hardware RAID
for the system disk (e.g., cheap 3Ware 8006-2LP PCI-X or 9690SE-2LP
PCIe).

So what is happening now, and will be supported in GRUB v2, is the
LVM2-DM approach to software RAID.  LVM _never_ looks like Ext3, and has
many other aspects.  Using the DeviceMapper (DM) facilities, RAID-1 and
other RAID levels are added.  That completely encapsulates everything.

Especially the boot-time ordering and "hand off" with device-mapping
details for software RAID.  Again, the current efforts are focused on
RAID-1 as part of LVM2-MD, and adding full LVM support to GRUB v2.
Personally, I cannot wait for that day.

In fact, I've _never_ had a problem with LVM/LVM2 _except_ when people
run it atop of MD, or use another distro's rescue disk.  Both are always
problematic, not because of any "bugs" in MD or the other distro's disk,
but because of differences.

> I wouldn't teach people about lilo personally.  I think it is an awful
> bootloader with an awful design (which happens to deal better with a few
> odd cases, but of well).  Nothing that big should be written in
> assembly.

I'm going to start another thread on this.

Despite all his argumentative comments (in addition to the "lack of
experience" with GRUB), there was one point I'd like to address.  I
hinted at it before.


-- 
Bryan J  Smith              Professional, Technical Annoyance
mailto:[EMAIL PROTECTED]  http://www.linkedin.com/in/bjsmith
-------------------------------------------------------------
           Fission Power:  An Inconvenient Solution

_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Reply via email to