You've hit the nail on the head. An mbr partition table can't handle drives of 2 TB or more. There just isn't enough room for the partition boundary addresses to be stored in it.

Large disks need a gpt partition table, but they don't need UEFI. Legacy boot with lilo or grub is enough. For proof, see post #11.

3 members found this post helpful.

I few thoughts on this, may need the boot flag set on the protective mbr partition, may need the lba32 as has already mentioned, or the boot partition files are to far from the beginning of the drive.

FWIW when installing LILO I do often do it twice, once to mbr (not often anymore since GPT) and once, always, to root. Whether one LILKO installed to MBR, one eLILO, one Grub, rEFInd or whatever bootloader twirls yer beanie, all of them AFAIK can hand off/chainload to a working, bootable partition/kernel.

From the various posts, I'm gleaning that for use of lilo, the boot drive must be 2T or less. I do have a 7TB RAID-5 system, but the boot RAID-1 (2TB) is separate from the larger RAID-5 and that works find.

Do we agree that this is true?

lba32 means 32-bit Logical Block Addresses. When the logical block size is 512 bytes, 32 bits are enough to address 2 TB.

In post #11 the boot drive is 4 TB. But the kernel is in the root file system in partition /dev/sda2 which is in the beginning of the disk, well under 2 TB. I guess that explains why it works.

Wow! This thread is wiping off the cobwebs of some very old triggers. If memory serves (and it might well not) there used to be a limit on partition size AND LOCATION, like before a certain cylinder. Shoot! I don't know if "cylinder" even applies anymore with SSDs.

As the person that posted comment 11, all I can say is that Petri may be on to something, but I don't remember what went on when I installed that disk and set it up with lilo. I generally keep most of the system files on a different partition from user space anyway. Maybe I planned to have the boot partition in the lower part of the disk. Maybe I just got lucky.

It is as it always has been. BIOS needs to be able to read boot sector/partition and whatever else up until the point control is passed off to something else (second-stage bootloader, UEFI, OS kernel, ...) but this does not necessarily constrain drive size. Way back when it was ~540MB / 1024 cylinders. Just locate the boot partition within this constraint and it generally worked.

BIOS booting and GPT partitioning should certainly be possible, but my go to source for such things hasn't concluded whether Lilo in particular handles it or not. But the way he tried it involved LVM. Maybe that complicates things:

"Despite GRUB 2's dominance of the Linux boot loader space, some people continue to use older boot loaders, such as the Linux Loader (LILO). Information on LILO's compatibility with GPT is contradictory. Most sources say the two won't get along, but I've read others who opine that the combination does (or at least should) work fine, since LILO uses sector maps to point to the kernel file. My one attempt at this combination proved inconclusive. LILO was able to load and run the kernel, but the boot then failed with the kernel message mount: could not find filesystem '/dev/root'. This message followed messages that indicated that the computer's LVM configuration was working fine, but somehow handing off to the LVM-based root filesystem was a problem. A GRUB boot of this system worked fine."

-- https://www.rodsbooks.com/gdisk/boot...ml#gpt_on_bios

I can confirm that my system which by accident booted a big GPT disk with lilo had a small root partition (about 1.5 GB) at the beginning of the disk.

If you for some reason don't like to have a small root partition you can create a small partition for /boot and place it at the beginning of the disk.

regards Henrik

Well, another thing that might be affecting this, my sda1 partition (at the beginning of the drive) is the swap partition. I started doing this because I could easily specify the size of the swap partition, then simply take the default start/end blocks offered by [fg]disk as the rest of the drive. In this case, I specified an 8G swap partition instead of my usual 4G. That would put the boot partition further in on the drive. Also, the larger the drive (this one is 8TB) the larger the allocation block, so that could move the boot partition in even further -- perhaps beyond the reach of LILO.

I use LILO because most of my systems are RAID-1s and supposedly formatting with meta-data 0.9 lets the system boot from the sdb raid member if the sda member fails, whereas grub (supposedly) does not. I say supposedly because I've never actually tried faulting/removing my sda partitions and trying a reboot. I should do that. I may have a chance to test that later this week. I'll have to find my reference on the "0.9" metadata thing.

That shouldn't cause any problems. When I bought my Lenovo, it had sda2 as the ESP because sda1 was some kind of Windows recovery toolbox. When I put in my ssd, I decided to keep sda2 as the boot partition and so I made sda1 my swap. I thought that keeping the ESP in the same place would make it easier for the UEFI chip to find it, which turned out not to be the case. UEFI's use guid partition ID's to register the ESP, not partition numbers.

Above it seems as if you only have a partition for swap and a partition for / , no separate partition for
/boot.

If you do not have any separate partition for /boot but put your boot files in the partition of your / those files can (at least in theory be placed anywhere within those 7.3 TB.)

This week I found the 8TB GPT-partitioned disk containing Slackware 14.2 and initially setup to boot with UEFI using syslinux/extlinux. By accident lilo was installed on that MBR and to my surprise was capable of booting that installation. I do not have any separate partition for /boot either, but my partition for / is rather small, less than 2 GB. Then I have separate partitions for /usr, /var, /tmp, /opt and /home. The small partition for / is /dev/sda1 and at the beginning of the disk.

regards Henrik