I've had several systems over the last several years hang after Slackware installations. The latest is a P23G motherboard, which was
running Slackware 11.

I backed up the /dev/hda1 partition and then installed Slackware 12.1 there.

Upon booting, the last thing printed on the console was

Freeing unused kernel memory...

So I figured I did something wrong, wiped the partition, and started all over again. Same results. Meanwhile I've googled for two days.

The system comes up when booted with the kernel on the DVD, but if booted from /dev/hda1, it dies at the same spot.

Apparently rc.sysvinit is the next thing to run after the message, and
the system stops activity. ENTER keys cause a CRLF to go to the
video, and everything scrolls up one line. But nothing is happening.

I have one hypothesis, which I am digging on...and that is whether the physical location of the booted kernel on the harddrive makes any difference.

Any ideas?

Hi,

Maybe try a different kernel (since dvd works and the hd doesn't, it might be a config flag in the kernel you're booting)
Since slack 11 worked, maybe you can check the configs of your old(working) kernel with the one you're installing now.


Hope it works out,

Ben

Have you tried booting the huge.s instead of hugesmp.s ?

Actually, the other way around. I was using huge.s, since the processor is a single core. When I tried the hugesmp.s it finished booting.

Parts of the boot are low, and I need to investigate why.

Meanwhile I've built a leaner kernel to try, to see if I can a.) lean it up, and b.) improve speed.

Ok, good, so it did work with the other kernel.

Yeah, if you experience slow booting, either building your own kernel or using the generic kernel (* with initrd) will speed things up.

Also, try to disable starting services you do not need by making files unexecutable in '/etc/rc.d', for example if you don't want GPM to run at boot make 'rc.gpm' unexecutable:

I also edit rc.M to add an '&' after things that take a long time to start and can be backgrounded (that's what the & does).

For example:
However, this cannot be done for rc.messagebus because HAL needs this running in order to start.

One thing you can do is add noquiet to the kernel boot command line, it'll give you more verbose output as the kernel is coming up and might provide more information as to where it was actually hanging.

I have not done that in YEARS, and forgot about that parameter. Thanks for the suggestion.

Meanwhile I have that system running, apparently it just doesn't work on the Slackware 12.1 huge.s, but works OK on hugesmp.s. Go figure.

Thanks for the other suggestions. One trick I have done on a large server system is to bring the system up, but spawn fscks and mounts from rc.local. It's kind of a kludge, but prior to journaling filesystems, it was a timesaver!