-   Slackware (
-   -   Slackware boots to "Verifying DMI Data Pool ........ L99 99 99 99 99 99 99 99 99..." (

Stragard 02-01-2011 12:24 AM

Slackware boots to "Verifying DMI Data Pool ........ L99 99 99 99 99 99 99 99 99..."
Hello, I have chosen to install Slackware Linux in order to make myself learn more about it. After the first install I rebooted, and the computer stopped at this message. I read on the Slackware installation FAQ that this was normal because the kernel used for installation was bare bones. I started up off of the install DVD and managed to boot into the system by typing

huge.s root=/dev/sda2 rdinit= ro at the boot: prompt

At that point I logged in as root and recompiled the kernal following the instructions here: Then I rebooted and still had the same results. I configured the kernel to not do anything with SMP as I thought that was the problem (and thus why huge.s worked).

I'm trying to install 13.1

The system I'm trying to do it with has an athlon xp 1600+ and 2 gigs of ram.

Should I switch the system to huge.s permanently (is that possible?) or should I look up how to configure the kernel the best way for this cpu (or would that information even exist for a cpu this old and a distro version this new?)

I'm kind of a newb at some of this stuff but really *really* want to pick it apart and know as much or more than anyone at work, its seems to be just a matter of finding a piece of thread to start unraveling the sweater with. I know how to use vi, chmod, and some other basic things. Anyway, thanks in advance for any help/advice.

allend 02-01-2011 12:44 AM

From 'man lilo':

99 invalid second stage index sector (LILO)
There is a problem with your lilo bootloader setup.

Here is a recent post describing how to fix this.
You may also have to edit /etc/lilo.conf so that lilo runs without error.

Stragard 02-02-2011 12:35 AM

Thank you for the reply.

I tried the first suggestion of running liloconfig, then I tried removing lilo and installing grub as suggested. Both left with me with the same results. In the thread you linked the guy says that he just ended up installing grub from another live cd. I have a few guesses

-1 This is something to do with the hardware being so old and not being supported or not supported without knowing how to really dial configurations in for such hardware.

-2 The 9s aren't from a LILO error but from something else since they still persist when LILO is gone and grub has been installed..unless grub has error codes that are exactly the same or those instructions do not really remove lilo and install grub all the way.

DonnieP 02-02-2011 06:26 AM


Originally Posted by Stragard (Post 4244261)
. . . After the first install I rebooted, and the computer stopped at this message. I read on the Slackware installation FAQ that this was normal because the kernel used for installation was bare bones . . . .

If you rebooted after installation then you weren't booting to the bare-bones install kernel but to the one newly installed on your hard disk which is not bare bones at all. This to me would indicate a lilo config problem before you ever went to recompiling kernel place. At this point, if it were me, I would just re-install anew and pay close attention to the lilo config during installation.

Stragard 02-02-2011 02:07 PM


Slackware uses stripped down kernels to do the actual installation -- in other words, the kernels don't have any more drivers than needed to control only the device needed to complete the installation. If you don't install the bootdisk kernel, it's possible to install with (for example) the bare.i IDE bootdisk, but install the SCSI kernel from the A series onto your hard drive. Since this kernel is has many SCSI drivers built-in, this can lead to hangs at boot time if the kernel misidentifies a piece of hardware that's unusual or at a non-standard port/IRQ.
This is what I was referring to though, I know I did not go out of my way to not install a specific kernel that only supported SCSI drives. Tonight I'll do a fresh install and then look at the expert installation options when the liloconfig part comes up. I can't remember what the options are off the top of my head right now, I've been trying to put it on the MBR I believe.

T3slider 02-02-2011 03:11 PM

That note is pretty old and doesn't really apply anymore. There are no SCSI-specific images in 13.1 (and haven't been since...11.0?). The only kernels you'll find (assuming you're using 32-bit Slackware) are huge.s and hugesmp.s on the install CD/DVD (and you should use hugesmp.s where possible even if you do not have an SMP-capable kernel), and huge/huge-smp/generic/generic-smp kernels on the installed system (assuming you installed all kernels). Again you should use an SMP-capable kernel wherever possible, and preferably the generic-smp kernel (which requires creating an initrd):

Originally Posted by CHANGES_AND_HINTS.TXT
Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock
generic kernels. You will need to create an initrd in order to boot
the generic kernels - see /boot/README.initrd for instructions.
The huge kernels are primarily intended as "installer" and "emergency"
kernels in case you forget to make an initrd. For most systems, you
should use the generic SMP kernel if it will run, even if your system is
not SMP-capable. Some newer hardware needs the local APIC enabled in the
SMP kernel, and theoretically there should not be a performance penalty
with using the SMP-capable kernel on a uniprocessor machine, as the SMP
kernel tests for this and makes necessary adjustments. Furthermore, the
kernel sources shipped with Slackware are configured for SMP usage, so you
won't have to modify those to build external modules (such as NVidia or
ATI proprietary drivers) if you use the SMP kernel.

If you decide to use one of the non-SMP kernels, you will need to follow the
instructions in /extra/linux- to modify your
kernel sources for non-SMP usage. Note that this only applies if you are
using the Slackware-provided non-SMP kernel - if you build a custom kernel,
the symlinks at /lib/modules/$(uname -r)/{build,source} will point to the
correct kernel source so long as you don't (re)move it.

You shouldn't need to reinstall the whole system if you can boot into it using the kernel on the LiveCD (but try using hugesmp.s instead of huge.s). You should post your lilo.conf and maybe the contents of /etc/fstab. If you can't boot with the SMP-enabled kernels then you may need to pass options to the kernel at bootup ('noioapic', 'noapic', 'nolapic', 'pci=nomsi', etc.) and hope it works then. You should probably strive to get the generic-smp kernel up and running, but it would be easier to try to get the huge-smp kernel running first since it doesn't require an initrd.

Stragard 02-03-2011 12:51 AM

Alright, so after booting up from the cd and configuring alpine with gmail (which is totally's the link if anyone wants here is my lilo.conf and fstab


# LILO configuration file
# generated by 'liloconfig'
# Start LILO global section
boot = /dev/sda2
#compact # faster, but won't work on all systems.
# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
bmp-timer = 65,27,0,255
# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt

# Append any additional kernel parameters:
append=" vt.default_utf8=0"
timeout = 300
# Normal VGA console
vga = normal
# VESA framebuffer console @ 1024x768x64k
# vga=791
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# VESA framebuffer console @ 800x600x64k
# vga=788
# VESA framebuffer console @ 800x600x32k
# vga=787
# VESA framebuffer console @ 800x600x256
# vga=771
# VESA framebuffer console @ 640x480x64k
# vga=785
# VESA framebuffer console @ 640x480x32k
# vga=784
# VESA framebuffer console @ 640x480x256
# vga=769
# ramdisk = 0 # paranoia setting
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
root = /dev/sda2
label = Slackware
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends


/dev/sda1 swap swap defaults 0 0
/dev/sda2 / ext4 defaults 1 1
#/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0

T3slider 02-03-2011 02:42 AM

You've installed LILO to the root partition of your Slackware install instead of to the MBR, so I *think* the problem is that it never gets to LILO in the first place. Unless you have a good reason not to, you should change the "boot = /dev/sda2" line near the top of your lilo.conf to "boot = /dev/sda" and rerun `lilo` as root to write to the MBR. If you really don't want to write to the MBR then you would have to mark sda2 as bootable (I think) so your BIOS will pass off to that partition by default.

Stragard 02-03-2011 08:41 AM

In the setup I've tried specifying to install on the slackware partition and on the MBR and it fails both ways. I'll change it manually tonight though like you suggest and see what happens.

All times are GMT -5. The time now is 04:48 AM.