LILO [LWN.net]

LILO

Posted Jan 22, 2011 4:06 UTC (Sat) by ccurtis (guest, #49713)
In reply to: LILO by solardiz
Parent article: Openwall Linux 3.0: Linux for the security-conscious

Something to be aware of is that (unless something has changed recently) LILO doesn't support disks >2TB (using GPT tables). I ran into this problem a while back with a RAID-5 array I built; today I have a 2TB drive in my PC.

to post comments

LILO

Posted Jan 22, 2011 20:52 UTC (Sat) by solardiz (guest, #35993) [Link] (3 responses)

Thank you for your helpful comment. I did not experiment with this myself.

Yes, LILO lacks support for GPT tables. This does not prevent its use on boot devices of exactly 2 TB with MBR partition tables, though (we currently have many Owl installs with LILO on 2 TB devices, although we obviously tend to allocate just a small partition for the boot/root filesystem). My current understanding is that things should continue to work with MBR partitions for boot device size of up to 4 TB, but with individual partitions no larger than 2 TB each. (I have not tested this, though.) With larger RAID arrays (and eventually larger individual disks as well), the current workaround (while staying with LILO) would be to allocate a smaller device for booting from (e.g., put the first two disks into a RAID-1 array, put the rest into a RAID array bigger than 2 TB or 4 TB). Yes, this is a nasty limitation and a reason for us to move to a bootloader that is still being enhanced (or at least has been recently) rather than is merely maintained (like LILO mostly is, with occasional changes to its existing functionality but no new functionality being added).

LILO

Posted Jan 22, 2011 22:36 UTC (Sat) by ccurtis (guest, #49713) [Link] (2 responses)

It's been a while, but I don't think I had a capacity >4TB at the time.

But it is nasty as you said. I think you understand the problem, but just in case: if you do not use GPT tables, you cannot physically reach any storage beyond that 2 (or 4?) TB limit. It doesn't matter how you partition the drive (or array) - that extra space can simply not be accessed.

There may be some dirty hacks around now, but at the time it was quite an unpleasant surprise to me. Carving out a smaller virtual device for booting wasn't something I wanted to do at the time; on the upside, I learned to appreciate GRUB.

LILO

Posted Jan 23, 2011 2:45 UTC (Sun) by solardiz (guest, #35993) [Link] (1 responses)

We're in agreement on this.

Just to explain where I got the 4 TB figure from: my current understanding is that it is possible to have an almost-2 TB partition start at almost-2 TB into the device, thus it will end just below 4 TB (perhaps two sectors below 4 TiB, although I did not bother doing the math). That's with an MBR partition table. So on a 4 TB device, the first 2 TB may be partitioned arbitrarily (e.g., a few tiny partitions for the OS install, then an almost-2 TB partition for the machine's actual purpose), and the second 2 TB will have to be in one partition. Yes, this is a somewhat weird special case.

LILO

Posted Jan 24, 2011 2:34 UTC (Mon) by ccurtis (guest, #49713) [Link]

That's what I was thinking when I wrote "dirty hack" above. Not sure if there's any sign abuse going on in there or not.

But even that wouldn't have worked for my application (I don't think...), so GPT it was.

LILO

Posted Jan 24, 2011 7:37 UTC (Mon) by solardiz (guest, #35993) [Link]

Although LILO is indeed unaware of GPT tables (as of 23.1, the latest as of this writing), it appears that it might work on a system with GPT tables anyway. It doesn't really have to be aware. Here are some references sort of confirming this:

http://www.mail-archive.com/bug-parted@gnu.org/msg00993.html
http://www.justlinux.com/forum/showpost.php?s=a35ea34fa9a...
http://www.rodsbooks.com/gdisk/booting.html

Initially, I thought that it'd fail while being installed, but maybe not - or not always.