Mailinglist Archive: opensuse (1473 mails)

< Previous Next >
Re: [opensuse] grub no longer being maintained? so Suse drops support for XFS boot?
  • From: "Brian K. White" <brian@xxxxxxxxx>
  • Date: Tue, 16 Jun 2009 21:45:58 -0400
  • Message-id: <4A384AD6.101@xxxxxxxxx>


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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >