On Tue, 2004-11-30 at 10:16 -0700, Guy Fraser wrote:
Phil Schaffner wrote:
>On Sat, 2004-11-27 at 20:01 -0800, Vadim wrote:
>
>>On a similar note.
>>Why did we stop supporting LILO?
>
>Because GRUB is more powerful, has a shell, doesn't have to be
>reinstalled every time the config is changed?
>
No, but install a new drive and with no errors you may get nothing but a
blinking
cursor after selecting your entry.
I remember several instances of "LI" or "LI..." followed by repeated
numbers (like 02 02 02 ... IIRC) ad infinitum.
The documentation for grub does not seem explain how drives are
ordered or
how to list the order in which they are detected. Mapping drives seems like
driving in the dark without headlights on a moonless night.
But a least you can get a steering wheel (boot from a grub floppy) and
pick up a stick to probe around with ("find" command in grub shell).
Can you point me and the rest of the people suffering from this
problem
to some
enlightening information on how to configure grub from a rescue disk so
that it
will work after installing an SATA, SCSI or RAID drive. In bugzilla
there are
hundreds of bugs marked as "NOTABUG" with a variety of issues similar to
this. The "fixes" for this type of problem appear to be quite
mysterious, and
without reasonable explanation to why someone did what they did to make it
work.
There have been some extensive threads on getting grub configured, but
some better documentation would certainly help. It is difficult to
generalize the techniques one can use when grub is not working properly,
and to cover all the variations in possible drive mappings between BIOS,
CMOS setup options, and kernel device names.
I had to reinstall FC3 and reorder the drives in the advanced boot
config to
make it work. Bandwidth and time required to reinstall and get all the
updates
again aside, this is not a reasonable way to add SATA drives to a machine.
Probably could have saved the reinstall by spending the time figuring
out the required device.map using the grub shell and then fixing it in
rescue mode, but I haven't had to tackle that particular problem yet.
Expecting my first SATA machine this week. (Times have been lean of
late.)
Lilo may not have a shell, but it does not add ambiguity to which
drive is
which. I don't see how being able to mess around in your boot loader
during boot is of any more help. All I used to do was boot a rescue disk
edit lilo.conf, run lilo and reboot, no big deal. Three days of messing
around struggling through "info grub" and searching bugzilla, is not
intuitive.
So install LILO and away you go (until/unless it gets dropped as the
"depreciated" status indicates).
If grub was more intuitive, and not encumbered by "magic"
device mapping
your assessment might be correct. But with no apparent documentation on
how to properly modify "device.map", or even if it is the right file to
modify,
it is almost a futile effort to modify the grub config by hand.
Again, some better documentation might help. An example of debug
technique:
http://www.redhat.com/archives/fedora-list/2004-May/msg02647.html
>Good old LILO is still there in the base distribution if you want to use
>it. Quite a few people still seem to like it, or maybe old habits die
>hard.
>
>Phil
Forgot the smiley emoticon. :-)
Thought this might start a religious war.
>
Lilo is a good boot loader, and that is all it is good for, but thats
what it was
meant to do.
Used LILO [mostly] happily for years and was not an early adopter of
GRUB, but both have their good/bad points. I use GRUB now for its good
points, and because it is the default.
Most people don't need access to a shell that lets them muck
around before the system boots, most people just want to select an
option if
they have a multi boot system or different kernels for testing purposes.
Or perhaps many people have not taken the time to figure out how useful
the GRUB shell can be for debugging problems.
Too
bad lilo can't be installed as the default boot loader.
Doubt we're going to go back, but at least LILO should remain an option
for those who prefer it. Perhaps a Bugzilla RFE is in order?
According to bugzilla there are hundreds of complaints about grub
causing
problems that are not bugs, but can not be solved intuitively by modifying
a single file and running a simple command to update the boot configuration.
My opinion is that either GRUB is poorly designed, too complex for most
users, or needs good {not info based} documentation, that explains how to
map real devices to the logical devices used in the menu.lst file. Or grub
should not internally rearrange logical device maps when new devices are
added as it appears to be doing.
Would certainly be better if grub did a better job of "guessing" the
same device ordering at boot time that is seen under Linux kernel.
Info-based vs man page is likely to start another long discussion.
Phil