So here is a new one for me. I've installed Slackware a hundred times, next month is my ten year anniversary as a member of linuxquestions. I have a LOT to learn, but I though I had install issues pretty much down...

So...I did a clean install of Slackware 14.1 32 bit. The box has an Asus m4a89gtd board with two IDE drives. I have Windows 7 on sda1, so I put Slackware on sda5. I've done this many many times. Finish install, reboot:

Seven seconds into the boot I get:

BUG: unable to handle kernel NULL pointer dereference at 00000001
IP: [<00000001>] 0x0
Oops: 0020 [#1] SMP
...
then it gives me registers, stack, call trace.
...
Code: Bad EIP value

I'm not sure what is relevant that it is showing me, nor do I know exactly what it is saying is the problem. I'm typing this by hand while looking at the screen. And at this point it locks.

I tried to boot from install CD, giving it the appropriate parameters, and it does the exact same thing.

I've seen the Bad EIP value here and there, and the only solution I saw was to use an older kernel, which I'm in the process of doing right now, I'll post here if that actually works.

Anyone seen this before? I can give more information from the onscreen display if there is anything you want to see, just didn't want to type the entire mess.

Slackware 14.0: same problem.

Slackware 13.37 with the 2.6.37 kernel. Works!

I've found posts where others encountered this problem, and the solution was to use an older kernel. For reasons unknown to me, that worked in this case. I'd be very interested in hearing any ideas why this is so. I can use 13.37 on this box, as that was an excellent release, but I'd like to know why 14.0/14.1 would not boot without a kernel panic.

I know some older hardware might have problems with 3.x kernels. I know you can install an older slack version then upgrade one at a time to the latest version. But don't forget to skip kernel upgrades or all that time spent would have gone to waste!

Without the stack trace it is impossible to know what is going wrong.

If you're unable to capture it you can take a picture and post that.

--mancha

Yeah, sorry I didn't post the entire stack trace. The first line was something like start_kernel, and the last line was idle-something. That probably doesn't help much. I've since removed 14.1 and 14.0. and am successful running 13.37. So far ...

Since you can boot with the install CD can you just mount and chroot to your system, compile and run the latest revision (Linux 3.10.32 or 3.12.13 for now) with the configs from your install CD, and see if it works?

EDIT:
That probably does help much.
.

Let me get this straight. You were able to effectively boot the hugesmp.s kernel to complete the install but not to boot the installed system with the same kernel? Did you install Lilo to MBR or to "/" and use some other bootloader?

And in all cases, the hugesmp.s kernel on the boot CD loaded just fine, and the installer ran just fine. I installed Lilo to the MBR, it's how I always do it. I was able to install and run Slackware 13.37 with no problem (13.37 uses the 2.6.x kernel). Neither 14.0 nor 14.1 would boot without kernel panic, even though they installed just fine.

The only time I've seen this before was when I was mixing IDE and SATA drives together, but that error is usually related to not being able to mount the file systems. This error was different.

I loaded Slackware 13.37 successfully, and I've had a render job running on it for over 12 hours that maxes out both cpu cores, and hammers the hard drive, and it is running just fine. No errors, no overheat problems, it is running just fine under full load. I was suspecting hardware issues, but the fact that 13.37 boots and has run under full load for the last 12 hours makes me wonder now if that is the case or not. Or if there is something in the 3.x kernels that the 2.6.x kernels don't do that is the cause of the problem?

I don't what, if any differences, there are in the "install kernel" and the "installed kernel", either by design or in error but there obviously are some. Hopefully someone with deeper knowledge on this subject than I spots this and comments.

I can attest that there is indeed a difference between the install kernel on the CD/DVD/USB image, and the installed kernel that runs from the hard drive. I had two laptops, HP Pavilion g7-2069wm, and dv7-7227cl, that could run the 14.0 install routine just fine, but as soon as I booted from the hard drive, kernel panic time! My solution, as others have stated above, was to run an older kernel; in my case, that was the 2.6.x series. It was a kludge to say the least, but it ran nevertheless.

If the install completed, but the reboot failed, I'm guessing that the issue is with a kernel module that's not loaded by the installer. I've seen a few Intel motherboards fall over when a watchdog module is loaded. Not the case here, but it still seems likely that it's a module issue since the installer carries fewer modules. Perhaps replacing the modules on the system with the ones from the installer could prove this?

The install kernels are identical to the ones that the system boots from later.

1 members found this post helpful.