LILO can also be booted off of software RAID-1. Hardware RAID is not required.

That's how I use it. Disconnect all of the RAID disks except any one of them and it boots fine.

1 members found this post helpful.

RAID-1 is not striped, its mirrored, that is the only reason why LILO can boot it. try booting a RAID-5 software (mdadm based raid) and you will find out it cant boot raid (mirror doesn't count because I can unplug one drive and it will boot anyways because the dta is not striped.

I wasn't disagreeing with any of the previous posts. I was just pointing out that LILO works with software RAID-1. Someone reading this thread may have not understood that.

The immediate previous posts mentioned booting from a non-RAID ext2 partition (saulgoode) and the fact that hardware RAID works for LILO & GRUB (/dev/random). I just wanted to clarify that it works okay with software RAID-1. saulgoode had mentioned that LILO's disk sector based design doesn't work for "striped filesystems".

@/dev/random - I don't understand why you say that "mirror doesn't count". Doesn't RAID type 1 qualify as a "Redundant Array"?

When GRUB legacy (the old version) was out, I kind of like it, as I frequently update my kernel, and it does no need to rewrite the MBR each time. But GRUB 2 is almost growing into its own OS, and I don't like the way it does configuration, no more simple configure file will do the work, and the documentation is really lacking. So for BIOS machine, I used lilo, for EFI capable machine I used rEFInd with EFI stub in kernel.

Booting from fully encrypted systems often requires a sort of bootstrap system to mount the drive and then load the modules for the encrypted system. That's why Grub almost feels like a miniature OS. This isn't necessarily a bad thing. Plus the configuration isn't really a simple configuration. It's really more of an interactive shell script for Grub to use.

Mirror doesn't count in my books because it is no different then cloning the hard drive (lilo and all) and setting it as JBOD#2, if JBOD#1 fails, the BIOS will automatically attempt to boot JBOD#2 in which case is an exact replica of JBOD#1 this is not redudent in the least, nor do you gain any advantages... RAID10 yes because your striping an mirroring, RAID5, striping with 1 redudent drive (not really a good idea and speed sucks), RAID6 2 redudent drives requires 3 drives total but you get better writes then RAID5, my personal favirote is RAID60 all the redudency you could ask for and hardly any speed penitly for it at the cost of 8 drives.

More or less I beleave in the spinning rust myth that mirroring should be for non-sensitive data because if you went out and bought 2 drives and pluged those drives in at the same time, there is a higher probability that both drives die at the same or near the same time, which is bad because if one drive dies thats fine, but what happends when the other drive dies while you are recovering? simple, your data is gone... with raid 6 or higher is it very unlikly that all 2 in every 4 pairings of 5 die, that would mean that 10 drives would have to fail in a raid60 out of 20 drives... simply not really realistic comapared to raid 1 because the propiblity that two drives came from the same bad batch is very likley...

At the most I would only use raid 1 for the OS where if I lose the OS I can get it back within 30min, restoring 8TiB of data from tape because I desided to mirror the drives is not very smart.

As long as Slackware includes lilo, I will use lilo.
Just to keep from learning something new...... llllooooooooolllll

It's easy and I understand it especially for dual booting windows for gaming.
Even if it's no longer maintained it is still a good, simple boot loader.

I've been using SLack since 1995 and used lilo the whole time. Although
in the old days learning new software was fun, at my age (65) learning new
software is getting a little tougher as time goes by especially since I
build everything from source before installing so It's built specifically
for my computer. I never install pre-built packages except in a new OS install.
These days I delve into new software when it's forced on me. lol

I have, until now, been using a GRUB 0.97 version that I compiled from source, with a few patches, as my “Master Boot Loader.”

Whenever I install an operating system, I install its default Boot Loader on the Superblock of its system partition.

To boot one of the installed operating systems, I let my Master Boot Loader chainload the boot loader of the selected operating system. The configuration of my Master Boot Loader is simple enough that I can maintain it manually—it simply has entries like the followng:
...and so on. The required maintenance is minimal: Only when I remove, add, or replace an operating system do I have to modify my Master Boot Loader configuration file.

Anyway, for Slackware, I have, thus, been using LILO up to now.

The problem that I’m having now is that LILO doesn't understand GPT (“GUID Partition Table”).

I have just installed Slackware onto a new laptop; the laptop is configured to run a traditional BIOS, not EFI, but even so, I partitioned its hard disk using GPT. Since there wasn’t any operating system installed on the laptop just yet, I (temporarily) installed LILO onto the Master Boot Record; even though LILO cannot make sense of GPT, that wasn't a problem, since LILO records the Logical Block Addresses of the kernel and whichever other files that it may need.

Next, I tried to install LILO on the superblock of the third GPT partition (which is where Slackware now sits), but LILO told me that partition 3 was marked as “empty” (i.e., type 0x00)—which is true, if you look at the MBR partition table. (On a GPT disk, the MBR partition table shows just one partition, which begins at logical block address 1 and ends at the very last sector of the disk—or at the last sector that the MBR can support, if the disk has more than 2^32 sectors.)

Thus, chainloading to LILO is no longer an option under the GPT partitioning scheme, and consequently, I will be forced to stop using it. I’ll be installing GRUB 2 on the superblock of my Slackware partition instead.

While I’m at it, I’m dropping by ageing GRUB legacy copy, and I’m about to replace it with a GRUB 2 version that I’m working on compiling from source.

You'll need a bios boot partition.
http://en.m.wikipedia.org/wiki/BIOS_boot_partition

Yes, I know. The first partition on the disk is a 960-KiB BIOS boot partition (type code EF02). The second partition is a 127-MiB Linux partition, onto which I will install the GRUB software that I am about to compile. That is why my Slackware system sits on the third partition.

I still don't have a need for an alternative boot loader. But will consider them when I switch to UEFI motherboard (might be soon). Although I don't like GRUB2 and will probably try to find something else. I actually prefer a manual configuration and don't have trust in automatized boot loaders.

For what it's worth, SYSLINUX has some (albeit threadbare) support for UEFI targets.

https://wiki.archlinux.org/index.php...x#UEFI_Systems

Additional limitation: syslinux can't boot on UEFI firmware off optical disks, only off hard disks or USB flash drives.

1 members found this post helpful.

I have found the same. For dual booting EFI machines I have found rEFInd the easiest and most flexible solution. I prefer it with the EFI stub but it works fine in combination with LILO as well. I did try grub when I first got my EFI machine and it works but is was much more complicated to get working than rEFInd.

rEFInd isn't necessary now since EFI is included in some of the newer installers. Debian Jessie, Ubuntu, Fedora all have support for Efi.