[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse
Subject:    Re: [opensuse] grub no longer being maintained? so Suse drops support
From:       "Brian K. White" <brian () aljex ! com>
Date:       2009-06-17 1:45:58
Message-ID: 4A384AD6.101 () aljex ! com
[Download RAW message or body]



Carlos E. R. wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On Tuesday, 2009-06-16 at 16:09 -0400, Felix Miata wrote:
>
>> On 2009/06/16 21:47 (GMT+0200) Carlos E. R. composed:
>>
>>> I find that shell impossible to use without printed instructions by the
>>> side. The first dificulty being that I have to translate linux names 
>>> like
>>> hdc5 to the equivalent grub name.
>>
>> One who has not taken the trouble to learn this translation scheme would
>> obviously need a cheat sheet of some kind, but that learning is 
>> something I
>> would expect an average 9 year old to be able to pick up and remember 
>> in less
>> than 30 minutes of instruction, self-taught or otherwise. Maybe I'm 
>> giving
>> the 9 year old too much credit, and maybe it is different for those 
>> whose
>> native language is not English, but remembering /dev device c == Grub 
>> device
>> 2 and /dev partition 5 == Grub partition 4 is just not a problem for me.
>
> Maybe for you it is no problem, but for me, with many years of 
> experience in computing, it is a problem. It is a developer system, 
> not a user system, because the index is zero based, not 1 - for 
> starters. Partition 5 should be #5, no "maths".
>
> If I were setting up systems often, I'd remember. But I'm not. When I 
> have to do it, a year after the last time, I don't remember if it is 
> zero based or one based, or how do I differentiate the MBR from the 
> partition, or what is the path for the kernel, the image, or what 
> magic options do I have to feed the kernel so that it boots correctly. 
> Or which of the dozens of partitions I have is root or boot, and for 
> which of the several systems I have.
>
> If instead of the shell it presented me with the menu.lst file so that 
> I could edit it, then _that_ would be way more useful, because almost 
> always I know what change is not working before hand. And if not, in 
> the file I have my notes to guide me.
>
> So, no, the grub shell is useless to me. I have to boot a rescue 
> system and edit the config file instead.
>

But, how do you know all those things in lilo? The zero vs one based 
thing is a single trivial detail among the many others you must know and 
understand regardless what bootloader you use. You still have to know 
where your kernel is, where your bootloader is, the difference between 
the bootloader, the kernel, and the root filesystem which may be in 
still a third location unrelated to either the bootloader or the kernel. 
True an ignorant desktop user may have a problem with being aware that 
one part of the system counts from 0 and another part counts from 1. But 
that user will also have the same problem knowing that he has a kernel, 
on a filesystem, which is on /dev/hda2, and that depending on which 
kernel he booted, and/or depending on certain motherboard bios settings, 
that same physical location may be /dev/sda2, or /dev/sdb2 or any other 
letter for that matter. If you know all that other stuff, then you have 
no basis for claiming that remembering the zero vs one thing is a 
problem. That's just being a baby. You learned 10 things 10 years ago 
and they haven't changed since then, and don't want to replace 5 of 
those things with 6 others today. If they made completely new and 
completely different bootloaders every year that  might  be a valid 
argument, but they don't and it's not.

How do you address mistakes in lilo at boot time? You can't.

And, you CAN edit menu.lst at boot time so that argument is just plain 
false with no even partial merit.
It's only the in-memory copy, which is perfect, as it means you can 
trial & error as many times as you want harmlessly.
In fact, there is no magical difference between the grub shell and 
menu.lst. All menu.lst IS is grub shell commands written down in a file. 
It's a grub shell script.

There are probably freaky fluke cases where lilo performs some task that 
grub fails at, but I have not heard a single one so far. (and probably 
there are an equal number of fluke cases where lilo can't function and 
grub can) All I've heard is that yast often fails to configure grub 
properly, and users that have used lilo do not know how to use grub.

The latter is no ones fault but their own and warrants no sympathy or 
apology. If you don't want to learn how to operate your bootloader then 
I guess you don't want to boot your system, simple as that. If you don't 
mind learning how to operate your boot loader but only want to learn one 
thing one time, then why doesn't the same apply to every other part of 
the system and every other thing that has undergone advancement and/or 
replacement with something new and different? You should simply keep 
using the same version of the old system that had lilo on it if you 
can't tolerate the change. Why is it ok to deal with the many changes to 
the linux kernel and every other piece of software? What is so special 
about the boot loader that it must stay frozen in 1994?

The former is a real problem but would almost certainly be no better if 
suse still used lilo instead of grub, and would certainly be even worse 
if suse split it's resources to keep supporting two or more bootloaders. 
The bootloader configurator in yast has certainly gotten less useful for 
me at least since 10.0, so I definitely agree that yast too often fails 
to set up grub. But that is the fault of yast or possibly the fault of 
newer systems offering more and morer strange and unpredictable paths 
and methods to boot that simply didn't exist in the past or were so 
uncommon no one cared, and it's pretty hard to try to write that much 
brains into any script or program to analyze a system and determin what 
should be done correctly. For my part I can almost never even use the 
yast bootloader module even for fresh installs. I must always break out 
and configure grub completely manually myself.

I don't know but I wouldn't be surprised if one part of the problem was 
that it's impossible for run-time software to actually know what bios 
boot time code is going to do for sure. To the running kernel it may 
look like some partition on some device must be the boot partition on 
the boot device, but I bet it really can't know for sure. If that's true 
then it's always a cross-your-fingers and hope moment when a mere 
program takes it's best guess at creating the boot loader and reboots.. 
Whatever the reason, I have machines and configurations that 10.0 or 
10.1 created a working bootloader for just fine, and then 10.3 fails to 
create a working boot loader on the same hardware configured the same 
way. Then other machines where the same is true from 10.3 to 11.x, 10.3 
handled it ok, 11.x fails to. Obviously that's yast failing to correctly 
analyze the system or at least failing to know how to do what I asked 
with it. If the loader was lilo, or syslinux, or anything else, none of 
that fixes the problem which is yast.

I'm not especially a fan of any particular bootloader just for the 
record. I used GAG on laptops for a few years, I even used sco open 
servers boot code for a long time just to be perverse and because it 
amused me that it could multi-boot sco, dos/win, and linux a long long 
time ago. Like, Xenix long ago before linux existed. It even has 
boot-time controllability somewhere between syslinux and grub. I used 
freebsd's bootloader  now and then, including as the primary boot loader 
on multiboot boxes. And of course I used lilo a lot and for years just 
like you and every other linux user. Currently I do use grub on all my 
production boxes because of the value of the boot-time shell which can 
save your a-- once in a while. And I use syslinux on usb sticks and for 
PXE, which is usually how I install new systems, repair broken ones, and 
run dos flash utilities for bios, raid card, & disk firmware updates. I 
just point out that people are making arguments and complains about 
things that aren't true.

-- 
bkw
-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse+help@opensuse.org


[prev in list] [next in list] [prev in thread] [next in thread]