Felix Miata wrote:

On 2009/06/15 16:55 (GMT+0200) Per Jessen composed:

...

jdd wrote:

...

...

2) lilo don't have the boot editor. It's very usefull for advanced users when changing some hardware and the computer don't boot anymore.

...

I consider myself an advanced user, but I have no idea what the "boot editor" is - is it a special grub feature?

Probably what he means is the Grub shell. If boot fails due to some system change the bootloader doesn't know about or understand, one can use the Grub shell to interactively locate & load a kernel & initrd to get booted, then via that virtually normal boot find and fix whatever went wrong, all without hunting down some media to perform a rescue boot, or needing to figure out why rescue and/or chroot doesn't work right.

I find the Grub shell indispensable, and never use any Grub scripts for anything at all any more. I usually use the shell to setup Grub whenever setup is necessary (on RAID systems so far I've been letting YaST2 do it).

I never learned anything about lilo except how difficult it can be compared to Grub, particularly if boot fails and lilo needs fixing.

Thanks for the explanation, Felix - very helpful actually. /Per -- Per Jessen, Zürich (23.5°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2009/06/16 00:33 (GMT+0200) Carlos E. R. composed:

When boot fails and I get to the grub shell, I have to boot something else to read grub instructions, as I can't do anything.

I committed the few necessary Grub instructions to memory early on. The Grub shell has built in help for its built in commands. It's pretty simple and easy if only you take a little time sometime to use it without any mental pressure and discover how easy and simple it really is.

I end by booting the system somehow and reconstructing grub - which is more or less the same I did with lilo, with the difference that lilo I can understand and memorize, grub not.

I never learned Lilo, so I didn't have any significant recollection of how it works to interfere with learning how Grub works. The main thing I remember about Lilo is how frustrating it always was to figure out how to fix it on a rescue boot, particularly with Xandros, the last significant distro I ever used to abandon Lilo as its default (if in fact it ever did - v4+ was never released for free download AFAIK, so I never tried it). FWIW, most of my systems are multiboot. Very few of them use Lilo. On those few that do where anything made Lilo unusable, I usually found it easier to fix Lilo by booting that distro's partition using the Grub from another distro and loading the kernel/initrd from the Lilo partition manually. Also FWIW, I have many times made various Grubs and Lilos unusable through my proclivity to clone and resize partitions. That's given me a lot of opportunity to exercise my skill in "rescuing" via Grub. Like learning to drive a stick, it becomes second nature before too long. Grub really can be that easy, which may be why the devs decided "supporting Lilo" was pointless. -- "Cast but a glance at riches, and they are gone, for they will surely sprout wings and fly off to the sky like an eagle." Proverbs 23:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2009/06/16 08:04 (GMT+0200) Per Jessen composed:

Felix Miata wrote:

...

Like learning to drive a stick, it becomes second nature before too long. Grub really can be that easy, which may be why the devs decided "supporting Lilo" was pointless.

Felix, using the same argument, when lilo really is that easy, why wasn't it kept? No, that argument doesn't hold water.

"Lilo is that easy"? I never found anything easy about Lilo except shooting yourself in the foot by forgetting or not knowing to _run_ lilo after _any_ configuration change, intentional or otherwise. Grub has an easy shell. Lilo has no shell at all. Thus Lilo can't be easy when what needs doing can't be done at all. I have nothing against Lilo for those who like it, but take offense to those who think Grub is hard. Grub is not hard. It's just different, and more powerful, from Lilo. The extra power is what makes it no contest which should be default. "Support" or not for the non-default is just a question of resource budgeting by the dev drivers. If Lilo is "not supported" in SLES and SLED, it's understandable that they would not want to devote resources in the free openSUSE on which they are built. -- "Cast but a glance at riches, and they are gone, for they will surely sprout wings and fly off to the sky like an eagle." Proverbs 23:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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. -- "Cast but a glance at riches, and they are gone, for they will surely sprout wings and fly off to the sky like an eagle." Proverbs 23:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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

Brian K. White wrote:

But, how do you know all those things in lilo?

There aren't many of "all those things" in lilo. There's 9-10 common parameters that hardly ever change (from system to system) and you don't need to know much about them in any detail. Then there is 6 lines of parameters per bootable image, which also don't vary much. The vga setting does occasionally, but I tend to use the 80x25 on all production systems anyway :-)

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.

No I don't - not as long as the only argument is "lilo is not supported by openSUSE".

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

I don't make mistakes in lilo.conf :-) There's so little to fiddle with. When it _does_ happen, I boot up a rescue system, quite often Knoppix. Seriously, how often does one fiddle with the bootloader config and how often does one make mistakes such that the grub "advantage" is actually advantageous?

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.

At some point there was an issue with booting from RAID1? I haven't looked into it, so I could be way wrong.

software? What is so special about the boot loader that it must stay frozen in 1994?

2007 you mean. The last lilo release was 2007. /Per -- Per Jessen, Zürich (17.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Brian K. White wrote:

Per Jessen wrote:

...

Felix Miata wrote:

...

Like learning to drive a stick, it becomes second nature before too long. Grub really can be that easy, which may be why the devs decided "supporting Lilo" was pointless.

Felix, using the same argument, when lilo really is that easy, why wasn't it kept? No, that argument doesn't hold water.

Because lilo simply can not do things grub can do.

I don't think that's a good reason for dropping support and I don't think that was the reason either. It was a fairly simple product management decision about how best to spend limited developer time.

lilo is valuable primarily because options are valuable even if they are inferior options. Not because it works better or is simpler or has any advantages over grub.

Agree - I wasn't trying to argue lilo or grub either way. I use lilo and intend to stick with it because I (IMHO) wouldn't gain anything but a learning curve by switching to grub. /Per -- Per Jessen, Zürich (21.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

But lilo has some uses, it works on some instances where grub does not, and thus, I see it as an alternative for those cases where the primary booter (grub) does not work. It is sound engineering redundance to have two valid solutions.

One example I can think of - I manage a number of remote servers where I have no console access. A grub shell would be of no use here, and to me(!) it's no big deal to boot the rescue system (via pxeboot) and correct lilo.conf. /Per -- Per Jessen, Zürich (18.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday, 2009-06-17 at 12:06 +0200, Per Jessen wrote:

...

Carlos E. R. wrote:

...

But lilo has some uses, it works on some instances where grub does not, and thus, I see it as an alternative for those cases where the primary booter (grub) does not work. It is sound engineering redundance to have two valid solutions.

One example I can think of - I manage a number of remote servers where I have no console access. A grub shell would be of no use here, and to me(!) it's no big deal to boot the rescue system (via pxeboot) and correct lilo.conf.

Doesn't grub manage the serial port? Tsk, tsk, too bad... :-P

It doesn't matter - the only access I have is over IP. But I'm sure grub can boot with a serial console too. /Per -- Per Jessen, Zürich (20.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Per Jessen wrote:

Carlos E. R. wrote:

...

But lilo has some uses, it works on some instances where grub does not, and thus, I see it as an alternative for those cases where the primary booter (grub) does not work. It is sound engineering redundance to have two valid solutions.

One example I can think of - I manage a number of remote servers where I have no console access. A grub shell would be of no use here, and to me(!) it's no big deal to boot the rescue system (via pxeboot) and correct lilo.conf.

I agree that for any machine that's unimportant enough that you didn't invest $75 to $300 for serial console or ip-kvm access the advantages of grub are likewise unimportant. That's not any of my machines. I'd be embarrassed to have to call a data center and have someone hook up a crash cart and do stuff on one of my boxes. I'd also be embarassed to have to tell the customer their box is down while I wait for said on-site staff, or that they just lost a half days work by switching them to their backup server, instead of me being able to deal with the unexpected immediately for lack of a $200 part (that supports up to 16 servers so it could even be $200/16) -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org