Lilo Keytable/Checksum Error when using PCI-E SATA Card

bassmadrigal · 08-05-2012, 04:14 PM

So, in my desktop/server, I ended up needing more sata ports than my motherboard provided. Easy enough... picked up a PCI-E 2-port SATAIII card from Amazon and had it shipped over. Turned off the computer, hooked up the card and the new drives and off I went. BIOS went ok, and the card detected the new drives no problem. But when the BIOS finishes it checks and hands over control to LILO, LILO errors out and flashes the message about a keytable/checksum error. I thought I jacked something up, so I redid everything, and then I tried a whole bunch of other things, and the only way I could get the lilo process to proceed, is if I had the harddrives unplugged when starting the computer, and then I just plug them back in after Slack finishes loading. Definitely not the best way to have a server set up, since any reboot, planned or unplanned, would require me to be physically at the computer.

I did a ton of research about this, but pretty much all the stuff I have found seems to indicate that this problem points to hardware failure. Well, everything works perfectly when I plug them in after Slack has completed booting, so I have a hard time thinking that it is hardware failure. I even went as far as ordering another card from a different manufacturer (although, I found out afterward that they use the same SATA controller chip), but the problem occurs with either card. I currently have both cards in the computer, and as long as I hook up the drives after the bootup is complete, they work without issue.

Can anybody give me some insight as to why this happens? The only thing that comes to my mind is that maybe having the cards changes my device structure (/dev/sda is no longer /dev/sda), but if I remember right, when I first had this problem, I booted off the Slack CD and tried re-running lilo after getting my install drive mounted, and it stayed as /dev/sda5 (machine was set up as a dual-boot with Windows initially, although, it has been a long time since I booted into it).

As always, I'd appreciate any help that might help me fix this problem.

Didier Spaier · 08-05-2012, 04:56 PM

Probably adding the new drives changed their numbering by the kernel.

It I am right, naming it in /etc/fstab by their UUID (which never change) instead of /dev/something should solve the problem.

I would boot with hard drives unplugged, plug it all, then issue the "blkid" command to know all partitions' UUID, edit /etc/fstab to replace partitions names by UUID, edit /etc/lilo.conf to change the root partition(s) if needed, run 'lilo -t -v" and if goes well "lilo" and reboot.

In /etc/fstab just replace the /dev/something with UUID=number_given_by_the_blkid_command, see an example there steps 10 & 11

bassmadrigal · 08-05-2012, 05:26 PM

I actually had most of my drives already set up with the UUID in fstab just because I tend to fiddle a lot with the drives and upgrade older, lower capacity drives with newer larger capacity ones, and UUID made things so much easier. But I did leave out the swap, /, and /home partitions. With lilo, do I keep it listed as /dev/sda5 (my / partition) or use a UUID? Because if all my drives change their device block, wouldn't that prevent lilo from loading too?

I did just finish the swap from device blocks to UUIDs in the fstab, but I am worried about lilo and I want to make sure it is good before I reboot (I'd rather not have to fight redoing my fstab if this decides to not work like I think it will). So, currently, my fstab (at least the pertinent lines) is as follows:

Code:

/swap                                       swap                   swap            defaults         0   2
#/dev/sda3                                  swap                   swap            defaults         0   0
#/dev/sda5                                  /                      ext4            defaults         1   1
#/dev/sda6                                  /home                  ext4            defaults         1   2
UUID=26195a19-fccb-4848-9e35-05ebe471524c   swap                   swap            defaults         0   0
UUID=dcd4f9de-f5c5-4a79-b398-394cef03ceb3   /                      ext4            defaults         0   1
UUID=28469f68-24f8-494a-984c-6a13997a332a   /home                  ext4            defaults         0   3
devpts                                      /dev/pts               devpts          gid=5,mode=620   0   0
proc                                        /proc                  proc            defaults         0   0
tmpfs                                       /dev/shm               tmpfs           defaults         0   0

And the pertinent lines out of my lilo.conf are:

Code:

boot = /dev/sda
compact
LBA32
prompt
timeout = 120
change-rules
  reset
vga = 794

# Linux bootable partition config begins 
image = /boot/vmlinuz
  root = /dev/sda5
  label = Slack
  read-only
# Linux bootable partition config ends

# Windows bootable partition config begins
other = /dev/sda1
  label = Windows
  table = /dev/sda
# Windows bootable partition config ends

And other than some crap about my windows partition, it seems to accept it fine.

Code:

root@craven-moorhead:~# lilo -t -v
LILO version 23.2 (test mode)
  * Copyright (C) 1992-1998 Werner Almesberger  (until v20)
  * Copyright (C) 1999-2007 John Coffman  (until v22)
  * Copyright (C) 2009-2011 Joachim Wiedorn  (since v23)
This program comes with ABSOLUTELY NO WARRANTY. This is free software 
distributed under the BSD License (3-clause). Details can be found in 
the file COPYING, which is distributed with this software.
Compiled at 19:24:22 on Aug 11 2011

Reading boot sector from /dev/sda
Backup copy of master disk volume ID record in /boot/boot.0850 (test mode)
Using BITMAP secondary loader
Calling map_insert_data
Mapping bitmap file /boot/slack.bmp
Calling map_insert_file

Boot image: /boot/vmlinuz -> vmlinuz-huge-3.2.13
Added Slack  *

Boot other: /dev/sda1, on /dev/sda, loader CHAIN
Warning: Device 0x0800: Inconsistent partition table, 1st entry
  CHS address in PT:  0:32:33  -->  LBA (640)
  LBA address in PT:  2048  -->  CHS (0:107:16)
Warning: The partition table is *NOT* being adjusted.
Added Windows

The boot sector and the map file have *NOT* been altered.
2 warnings were issued.

Think this is good? I am still leery about having /dev/sda listed in lilo when that could very well be the issue that is preventing the computer from booting when drives are plugged into the sata card.

Didier Spaier · 08-05-2012, 05:40 PM

I don't know I didn't encounter this warning about partition table yet.

Anyhow I usually put the boot loader in Linux' root partition instead of the MBR, but this has probably nothing to do with your issue.

So I can't really say if this will work or not.