I can't choose LILO as boot loader anymore in the install process? And what is the advantages in GRUP vs. LILO that are so great that LILO has been deleted all together?
One big disadvantages when forced to use GRUB is that it is a hassle to make the disks in a RAID1 bootable. https://www.redhat.com/archives/fedora-list/2005-March/msg05935.html
and RAID1 seems pretty useless when it is the only bootable disk that fails.
can someone come up with a nice one-liner that will make GRUB "global" like LILO is out-of-the-box ? or is ther a parameter you can give?
I don't know about you but when one of my disks fails I really don't need too many new check marks to worry about on my to do list.
best regards Ulrik
Ulrik S. Kofod wrote:
I can't choose LILO as boot loader anymore in the install process? And what is the advantages in GRUP vs. LILO that are so great that LILO has been deleted all together?
lilo is included in the distro, when booting the installer add 'lilo' to the boot options list.
- K
Quoting "Ulrik S. Kofod" usk@cybersite.dk:
I can't choose LILO as boot loader anymore in the install process? And what is the advantages in GRUP vs. LILO that are so great that LILO has been deleted all together?
It is still there, but not selectable from GUI. Most likely it is going to be removed in future versions of RH distributions (and therefore from CentOS too). You can still use "bootloader --useLilo" option in ks.cfg file (for automated KickStart installations). Other option is to install LILO RPM (hm, 3rd CD I think) after the GUI installation finishes, delete Grub RPM, create /etc/lilo.conf and run /sbin/lilo.
Do note that there is no LILO in x86_64 distribution. Only in i386 distribution. I'm affraid for x86_64 you'll have to use Grub. I haven't attempted installing LILO RPM from i386 distribution onto x86_64. It *might* work...
One big disadvantages when forced to use GRUB is that it is a hassle to make the disks in a RAID1 bootable. https://www.redhat.com/archives/fedora-list/2005-March/msg05935.html
Hmmm... that article sounds familiar ;-)
and RAID1 seems pretty useless when it is the only bootable disk that fails.
can someone come up with a nice one-liner that will make GRUB "global" like LILO is out-of-the-box ? or is ther a parameter you can give?
No one-liners here. But there's that two-liner in the above referenced article ;-)
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Aleksandar Milivojevic sagde:
Quoting "Ulrik S. Kofod" usk@cybersite.dk:
It is still there, but not selectable from GUI. Most likely it is going to be removed in future versions of RH distributions (and therefore from CentOS too).
Will groub ever be able to boot RAID1 (from any disk in the array by default) ? I hate when something that works get's replaced with something "smart". And I still havent seen an answer to why grub is so great, to me it seems like it doesn't really work as booting pretty much is the main attaction in boot loaders.
No one-liners here. But there's that two-liner in the above referenced article ;-)
Well a two-liner for each disk that has to be typed into the grub thingy, no fun when running RAID1 with 2 spares, can't this be put into a script?
On Wed, 2005-11-30 at 09:51, Ulrik S. Kofod wrote:
Will groub ever be able to boot RAID1 (from any disk in the array by default) ? I hate when something that works get's replaced with something "smart". And I still havent seen an answer to why grub is so great, to me it seems like it doesn't really work as booting pretty much is the main attaction in boot loaders.
It will boot RAID1 - or more accurately it will boot from an underlying partition. You just have to do the install command manually because it doesn't figure out the underlying devices that make up up the md device.
No one-liners here. But there's that two-liner in the above referenced article ;-)
Well a two-liner for each disk that has to be typed into the grub thingy, no fun when running RAID1 with 2 spares, can't this be put into a script?
I agree that it would be nice if this were automatic, but with grub at least you only have to do it once so it's not a real showstopper. With lilo you had to repeat the install at every change to the config, kernel or initrd. There is also an issue in automating this regarding where the alternates appear in case the boot disk(s) fail. With scsi and most failure modes, the subsequent drives shift up as far as bios and the /dev/sd? devices are concerned. With IDE, they keep their original bios and /dev/hd? names but most failures will also take out any drives sharing the same controller and prevent booting until you physically remove the bad one anyway. I'm not sure what to expect with SATA.
Les Mikesell wrote:
With lilo you had to repeat the install at every change to the config, kernel or initrd.
This is a weak point. With either grub or lilo, you have to edit configuration file. After editing, you run /sbin/lilo, and lilo does the right thing. This is completely automated from kernel postinstall script and requires no user intervention. For the vast majority of users, the only differences between grub and lilo they will ever encounter/notice are:
- grub has "fancier" boot-time interface - grub doesn't work out-of-the-box on RAID1 configuration
Nothing more and nothing less. Most users will never use any of grub features other than selecting which image to boot (same as in lilo).
Aleksandar Milivojevic alex@milivojevic.org wrote:
Nothing more and nothing less. Most users will never use any of grub features other than selecting which image to
boot
(same as in lilo).
Umm, GRUB does _dynamic_ boot resolution. LILO does _not_, it says "blindly boot this sector offset." That's why you have to re-install LILO everytime you change something.
That's the _key_ difference between the two.
Hence why GRUB is highly recommended over LILO, because you can resolve issues at boot-time -- including helping users over the phone without their having to have a rescue disk. GRUB is adding more and more disk label and filesystem support all-the-time.
Now if they'd only get LDM (Dynamic Disk) support, we'd be set!
-- Bryan
P.S. You _can_ give LILO a "pretty GUI" just like GRUB.
On Thu, 2005-12-01 at 01:08, Bryan J. Smith wrote:
P.S. You _can_ give LILO a "pretty GUI" just like GRUB.
Is there any way to give grub a live command line like lilo so you don't have to do a dozen extra steps to boot single user mode or add some other simple option?
On Thu, 2005-12-01 at 09:01 -0600, Les Mikesell wrote:
Is there any way to give grub a live command line like lilo so you don't have to do a dozen extra steps to boot single user mode or add some other simple option?
How is selecting the kernel and pressing "a" a dozen extra steps?
On Thu, 2005-12-01 at 09:05, Ignacio Vazquez-Abrams wrote:
On Thu, 2005-12-01 at 09:01 -0600, Les Mikesell wrote:
Is there any way to give grub a live command line like lilo so you don't have to do a dozen extra steps to boot single user mode or add some other simple option?
How is selecting the kernel and pressing "a" a dozen extra steps?
I count the arrow keypresses as steps along with the 'b' needed to boot and round up. Just typing what you want and hitting enter is much simpler.
Quoting "Bryan J. Smith" thebs413@earthlink.net:
Aleksandar Milivojevic alex@milivojevic.org wrote:
Nothing more and nothing less. Most users will never use any of grub features other than selecting which image to
boot
(same as in lilo).
Umm, GRUB does _dynamic_ boot resolution. LILO does _not_, it says "blindly boot this sector offset." That's why you have to re-install LILO everytime you change something.
That's the _key_ difference between the two.
Hence why GRUB is highly recommended over LILO, because you can resolve issues at boot-time -- including helping users over the phone without their having to have a rescue disk. GRUB is adding more and more disk label and filesystem support all-the-time.
Incidentally, the *only* time ever that I needed those extra features of Grub was a case where LILO would have simply worked ;-)
Or at least warned me about the problem right away right there pointing to the real underlying problem with very clear message.
What happened was that I had a laptop whose BIOS could address only around 8GB. So I made sure that Windows partition was almost 8GB with partition for /boot filled the rest of the disk up to 8GB mark. Well, the thing was the BIOS could really address a little bit less than 8GB (heads*sectors*1024 was really just under 8GB), so the part of my /boot partition ended up above BIOS limit. It happened that kernel and initrd ended up in addressable space. Grub's configuration file grub.conf ended up in non-addressable space, so Grub couldn't read it during boot, and it would throw me to command line with some non-intuitive error message (took me some time to figure out what was really the problem). Obviously, if I had LILO on that machine, it would just work. Of course, it might have failed on kernel updates (if new kernel or initrd ended up in non-addressable space, which would happen sooner or later).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Ulrik S. Kofod wrote on Wed, 30 Nov 2005 16:51:44 +0100 (CET):
And I still havent seen an answer to why grub is so great, to me it seems like it doesn't really work as booting pretty much is the main attaction in boot loaders.
The latest grub (which is *not* part of CentoS 4.2) has some pretty interesting features, f.i. recovering from boot failures. Don't know if lilo provides the same. Also, you have to run lilo after each kernel upgrade which isn't necessary for grub. I agree that grub should handle RAID better and do the installation on all disks for you automatically.
Kai
On Wed, Nov 30, 2005 at 04:06:08PM +0100, Ulrik S. Kofod wrote:
One big disadvantages when forced to use GRUB is that it is a hassle to make the disks in a RAID1 bootable. https://www.redhat.com/archives/fedora-list/2005-March/msg05935.html
This should be fixed in recent anaconda.
On Wed, Nov 30, 2005 at 04:53:36PM +0100, Ulrik S. Kofod wrote:
This should be fixed in recent anaconda.
so grub will eventually be able to do the trick?
It can now; it just needed a little manual work. (I have it set up on my FC3-based system at home.) But yeah -- in future releases, it should Just Work.
-
Aleksandar Milivojevic -
Bryan J. Smith -
Ignacio Vazquez-Abrams -
Kai Schaetzl -
Karanbir Singh -
Les Mikesell -
Matthew Miller -
Ulrik S. Kofod