Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
is there some inherent limitation of LILO that prevents the 'automatic' MBR writing that grub spoils us with? I miss 'lilo' because it is not called 'grub'.
"I forgot to run LILO"
Posted Dec 9, 2010 11:30 UTC (Thu) by nix (subscriber, #2304)
Disclaimer: I'm still using LILO because, well, it still works perfectly well for my purposes and I have better things to do than mess with bootloaders. Also, last I encountered it, all the GRUBs required deep magic to dump its bootloader on both disks of an md-raid-1 set and to boot from kernels on such an array. This may well have changed, as that was years ago.
I have never once forgotten to rerun LILO because my kernel building script does it for me automatically (and, no, this doesn't mean I compile the kernel as root). Doesn't everyone's?
Posted Dec 9, 2010 21:07 UTC (Thu) by dlang (✭ supporter ✭, #313)
If you have a simple desktop with a single drive, grub 'just works', but if you have multiple drives of different types, and your boot drive is something like /dev/sdm, grub won't even look at the drive.
Posted Dec 10, 2010 11:44 UTC (Fri) by stevem (subscriber, #1512)
Grub 1 broke too many times for me; when I looked at the source to try and fix a bug I was so scared that I deleted the source and switched back to lilo for all my systems.
Grub 2 is slightly better, but still *far* too complex for my liking.
There are now new maintainers for lilo, so I'm hopeful for continuing maintenance. Otherwise, extlinux looks like a good simple replacement.
Posted Dec 10, 2010 12:27 UTC (Fri) by etienne (subscriber, #25256)
Ever tried Gujin (at sourceforge)?
Either the full blown interface you get when installing the whole package, or the new "boot the newest vmlinuz/initrd you found in /boot and do not ask any question" mode?
In short, to test, install the precompiled package associated with your distribution, and reboot: you are running the main Gujin bootloader.
Once rebooted, desinstall the package, it restores the previous bootloader automatically.
To test the new "do not ask any question mode" (and if you only have a single Linux distribution on your PC), before uninstalling the package, type on a terminal as root:
/sbin/gujin -t tinyext4.bin /boot/minigujin.ebios
and reboot, it will loads Linux without any question.
To remove that new simplified mode, just type as root:
/sbin/gujin --remove /boot/minigujin.ebios
That will bring you back to the previous bootloader, i.e. full Gujin interface, that you can remove if you want to by uninstalling the package.
Gujin do not work if your kernels are on a LVM slice, and it only recognises few filesystems, but ext*fs, vfat or iso9660 are fine.
Posted Dec 11, 2010 9:03 UTC (Sat) by dlang (✭ supporter ✭, #313)
this is where grub falls down and the simplicity of lilo makes it still usable.
lilo may not be simple to setup in such a situation, but it's simple enough that it's failures are simple and so you can fairly easily work your way through the issues to get a working system. With Grub it's hard enough to figure out what grub is really having problems with (what's it trying to do exactly??) that the result is (on a complex configuration) it crosses over to the unusable category.
Posted Dec 13, 2010 13:10 UTC (Mon) by etienne (subscriber, #25256)
There is for instance no problem having Fedora, Ubuntu and debian distributions in both 32 and 64 bits installed on the same PC (i.e. 6 distributions in 6+ different partitions), plus kind of 10-20 iso images of live CD distributions.
One problem with other bootloaders is that when you boot from a USB key, some PC shift all BIOS drives numbers, so that number cannot be safely written in a static configuration file.
For instance, if you have a distribution on a USB disk, distribution containing it own /boot/gujin.cmd to supply its own command line to its own kernel, you can boot your PC with or without this disk connected; Gujin will automatically recognise that way to boot and display a line in the menu.
It doesn't matter if Gujin came from the hard disks or the USB disk.
Posted Dec 15, 2010 4:44 UTC (Wed) by dlang (✭ supporter ✭, #313)
your description of the many-OS system can still be done with very few drives
Posted Dec 15, 2010 10:39 UTC (Wed) by etienne (subscriber, #25256)
Well, the 15 disks limit was done because it is said that some BIOS would have a problem - and BIOS disk 0x90 was the same as BIOS disk 0x80...
But as long as your vmlinuz/initrd pair is located in one of the first 15 disks Gujin should still work.
Moreover, I assume that you start your system with some disk in "power on standby mode" - or else you have a massive power supply; those disks will not contain the /boot partition.
Gujin has been tested with disks in "power on standby mode".
With such a system, if your main MBR is corrupted and you try to boot from a USB key, and that key is mapped by the BIOS as disk 0x80 (shifting all other disks numbers by one), your preconfigured mapping in either Grub or LILO will be wrong (trying to load from the wrong disk).
Increasing the default number of disk supported in Gujin is a single "#define NB_DISK" change, maybe I'll increase the default.
> your description of the many-OS system can still be done with very few drives
One drive is enough, but the complexity to manage the six Grub configurations in six partitions is a nightmare...
Posted Dec 15, 2010 19:53 UTC (Wed) by dlang (✭ supporter ✭, #313)
the IDE drives are connected to 3-ware raid cards (but not using the raid features of the cards), not directly to the motherboard.
Posted Dec 20, 2010 13:58 UTC (Mon) by nix (subscriber, #2304)
Posted Dec 13, 2010 15:26 UTC (Mon) by nix (subscriber, #2304)
Not being able to boot off LVM might be annoying, as LILO can boot off LVM as long as it's not also RAIDed, but not being able to boot off any live RAID-1 partition would be a killer.
(disclaimer: horrible flu so have not even looked at gujin, preferring to randomly pontificate: this *is* the internet).
Posted Dec 15, 2010 10:45 UTC (Wed) by etienne (subscriber, #25256)
Posted Dec 17, 2010 16:56 UTC (Fri) by Duncan (guest, #6647)
Understood. I continued for quite some time with LILO for that reason, tho I eventually switched to GRUB... at the same time I switched to md/RAID, FWIW.
> Also, last I encountered it, all the GRUBs required deep magic to dump its bootloader on both disks of an md-raid-1 set and to boot from kernels on such an array. This may well have changed, as that was years ago.
As hinted above, that has indeed changed. FWIW this is still grub-1 (0.97 with various distribution patches) I'm discussing here as I've not upgraded to grub2 yet.
Basically, it's a simple matter of first copying the stage-X and filesystem module files to /boot/grub if necessary (that's done using normal copy procedures, so if it's an md/RAID-1, just make sure it's mounted and cp to it as normal), then for each physical device, start the interactive grub session (the grub-install script isn't smart enough to figure it out), tell grub where to point the mbr install at when you install it using the root directive, do that actual install using the setup directive, and exit the interactive shell. So something like this:
(grub1 is zero-based and uses hd notation for drives other than floppies regardless of sata/scsi/ide/usb-thumb/whatever so for that example, /boot is on an md/RAID-1 composed of, assuming we're not dealing with legacy non-libata ide) /dev/sda3 and /dev/sdb3.)
Then you ensure your emergency boot disk is available just in case, and reboot, disabling all drives but the one you want to test. By disabling all drives instead of simply changing the BIOS boot selector, you catch any mistakes such as root (hd0,2) setup (hd1), pointing the mbr of the second BIOS drive at the third partition of the first BIOS drive, instead of its own third partition.
While that might be "deep magic" for the point-n-click types not comfortable at the command line, it should be fine for an admin comfortable with typical admin tasks such as installing their own kernels and editing their own bootloader configs.
Posted Dec 21, 2010 18:30 UTC (Tue) by nix (subscriber, #2304)
boot = /dev/md0
in lilo.conf, that is pretty bloody hideous. It is plain that GRUB has no actual support for this use-case at all, so you're having to in effect reimplement it by installing multiple GRUBs by hand, one in each boot sector. And if you typo you have a silent failure you won't notice until it's too late, while with LILO the stanza above always works (assuming your boot RAID-1 array is /dev/md0 that is).
I'll give it a miss.
Posted Dec 27, 2010 11:25 UTC (Mon) by mfedyk (guest, #55303)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds