Problem Booting with LILO - Inconsistent partition table
 

Hi all:

I've recently completed installing LFS v. 7.4 on a Slackware host. I decided to not have LFS's GRUB do the booting but have the current LILO do the honors. Problem is, after configuring lilo.conf for the second OS, an error is thrown:

I tried the -P ignore option without success. In addition, the LILO manual does not directly address this issue. Also, while this error seems fairly common on the interwebz, the solutions are not; usually "use GRUB" or something similar.

Here's my block structure:

Not sure why there are verticle lines before /sda1 and /sda2 and a tick before /sda3 (/sda3 is where LFS is installed.) Possibly has to do with mounting, which shouldn't affect LILO at this point, should it?

Here's the relevant parts of lilo.conf:

Any help is greatly appreciated.

Are you using Lilo or eLilo? At truth Grub2 would be easier to help manage your booting though.

Thanks, ReaperX7. I'm using regular LILO installed during a regular install of Slackware - no EFI here.

I'm also not partial to LILO, but I have had problems in the past with GRUB2 properly "finding" other installed operating systems - especially in the configuration posted above, i.e., "original" OS on sda1, swap on sda2, then new OS on sda3. I just don't want to get locked out of my Slackware.

Grub2 requires os-prober to be installed to detect other systems. Did you install 14.0 or earlier or 14.1? 14.0 has packages for Grub2 on Slackbuilds.org that may be of assistance.

I'm using Slackware 14.1 - I installed it just for the purpose of building LFS, as I was having problems with using Arch and LMDE as hosts. The Slack worked fine for that purpose, but now I've found I really like the Slack (in fact, its all I use at this point), so I'd prefer not to lose it or have to re-install.

If I were to use GRUB, I would probably run it from the LFS partition, as it's already installed, and osprober is in /etc/grub.d. I suppose I may have to take the chance, but I'd really rather figure out what's wrong with LILO, if for no other reason than to solve the riddle.

I don't think lilo can boot from another partition. Grub is better for multiboot.
I think it's easier to edit /boot/grub/grub.cfg manually. It's really not that difficult, and you get better control. You can see an example here . (Don't worry about the stupid warning. The only reason it's not recommended to change directly in /boot/grub/grub.cfg in some distros is if they run 'update-grub' or similar automatically at updates. Not relevant in LFS or Slackware.)

Thanks, Lennie - I'm pretty much resigned to going with GRUB2. The problem with that, though, is I don't see where os-prober was installed. Without that, the LFS GRUB2 will not see my Slackware partition and I won't be able to boot it. (There is an os-prober script in /etc/grub.d, but that is apparently not enough. I just solved that issue on another box with an OS on /dev/sda1, swap on /dev/sda2, and Gentoo freshly installed on /dev/sda3 - the same set-up I have on the LFS box. Gentoo's GRUB2 did not see the OS on /sda1; I had to install os-prober on the /sda3 partition and reconfigure GRUB2, which then recognized the OS on /sda1. Apparently Gentoo does not ship with os-prober, even though the os-prober script is in /etc/grub.d.)

I haven't had time to check yet, but is anyone else having problems dual-booting from the GRUB2 installed on MBR from the LFS distro (i.e., following the LFS instructions for GRUB2 explicitly)?

Just add Slackware manually to /boot/grub/grub.cfg. You don't need os-prober for that.

If they use the same physical hard drive, then this do this?
image = /boot/vmlinuz
root = /dev/sda1
initrd = /boot/initrd.gz # added this line when changing from huge to generic
label = Slackware
read-only

image = /boot/<LFS Kernel>
root = /dev/sda3
initrd = /boot/initrd.gz # added this line when changing from huge to generic
label = LFS
read-only

Lennie - yes, that's what I'll try before messing with os-prober. Of course, given my luck (skills) so far in editing lilo.conf...

/dev/random, nice try, but the loader would get confused, as both kernels are symlinked vmlinuz, and to two different kernels, albeit on two different partitions. I'm sure that was what you were getting at by specifically naming the "second" kernel, but the format above is directly out of the LILO manual, and I'll assume they know more than me. At any rate, the problem seems to be some issue with the way the partitions are aligned or how the table is read.

Notice when the partition tables are measured by cylinders, the last cylinder of /dev/sda1 overlaps with the first cylinder of /dev/sda2. I don't think this is the problem, but I don't know what else is meant by "inconsistent partition table."

Thanks to both for your help and ideas.

Hey stoa,
That was the idea, here is what I had in mind, copy your LFS kernel to Slackware's boot directory (don't move it) but rename it so something like this lfs-vers-linux so now when you do what I told you to do in the previous post, it will load your LFS kernel from Slackware's boot partition, but use /sda3 as the root partition.

This works because that's how I have mine setup, the only issue to this is to update the bootloader you have to reboot into Slackware move over the new kernel and update it from Slackware.

EDIT:
I notice your lilo is using the older disk geometry, try turning it off. lba32 option will tell the BIOS to stop using the older MFM methiod and use Linear Block Addressing.

Also what size are your partitions? If they are +2TiB in size you are going to need to ditch the mbr and move you root as GPT doesn't have those limitations.

/dev/random:

I'd like to hear more about LBA - how exactly does one turn it on? And where are you finding the MFM info? Maybe its too late in the day, but I don't see how you determined that.

BTW - I think the copying of the kernel method is way beyond my pay grade (read: skills.)

Thanks.

I noticed this from the above: Warning: LBA32 addressing assumed

All recent BIOS's use LBA, however LILO sometimes unless you explicitly state to use lba32 can get confused about the geometry of the drive, by putting lba32 in the header of lilo.conf you are telling LILO to stop carring about cylinders and only look at the block level, by doing this you solve a bunch of problems, the biggest one is the whole 1024 above or below thing is thrown out the window because LILO no longer cares about cylinders or where they are mapped.

If LILO makes the mistake of thinking you want MFM addressing then any boot partition must be in the first 1024 cylinder range, which causes troubles specifically when your adding partitions to an existing partition table that are expected to be boot able.

If your hardware is not +10 years old assume it is using LBA as I have not seen a new motherboard or any add-on cards that still use the MFM method (cylinders, heads, sectors).

/dev/random:

Great! That's what I was loking for. Unfortunately, both enabling and unenabling lba32 in lilo.conf did not alter the output (error message.) I thought that was going to work. Somehow I need to decipher "CHS address in PT: 61:32:36 --> LBA (45149)
LBA address in PT: 50333696 --> CHS (68202:206:3)"; a gogle search turned up one result - mine.

So, at this point, I installed GRUB in Slackware (for some reason, it was already there; in true Slack fashion, the installation guide doesn't even mention GRUB, and I only found it was on the system by mistake) on my Slackware partition and was able to use it to boot LFS.

Thanks all for your help!

ELilo was included as the default as to why it's documented. Grub2 isn't documented but setting it up is really painless. If you need help with the /etc/default/grub file, feel free to ask. This should be the only file you edit for Grub2. I have a few LFS topics on it over in the LFS section to getting the most out of Grub2 including theme support, fonts, etc.