slackware 12 fresh install

l33t_c0w · 10-22-2007, 11:43 PM

Hi. It's about that time again, when I decide to install Slackware on my laptop. It's going to stick one of these times.

Anyhow, on the first boot after installing Slackware 12, the screen goes blank in the middle of the boot sequence. Then it just sits there, with the CPU churning away. I was able to get it to boot by booting from the installation disk, and chmodding -x rc.udev. I'm pretty sure I want udev to run, though I don't know exactly why.

It seems like in release 10 or 11, I had to do something (don't remember what) to get it to not choke on my pcmcia card slot. Would the two be likely to be related? More generally, where should I start troubleshooting?

Sorry if this sort of thing has been discussed elsewhere. I'm having strange trouble getting onto some of this subforum's pages.

Alien_Hominid · 10-23-2007, 12:41 AM

Boot with option nopcmcia

Alien_Hominid · 10-23-2007, 02:02 AM

Hmmph, strange, there isn't such an option in /usr/src/linux/Documentation/kernel-parameters.txt, but try it nevertheless.

Bruce Hill · 10-23-2007, 02:51 AM

What is the make and model of your laptop? You could probably find more with that information in a search, and provided here.

l33t_c0w · 10-23-2007, 12:05 PM

Sorry for not mentioning it -- it's a Compal HEL80 (a whitebook). I already did a little searching, under that model number, and its Sager number, np2080. I didn't find anything. Will try nopcmcia when I get home tonight. Thanks for the replies so far.

onebuck · 10-23-2007, 02:28 PM

Quote:

Originally Posted by l33t_c0w

Sorry for not mentioning it -- it's a Compal HEL80 (a whitebook). I already did a little searching, under that model number, and its Sager number, np2080. I didn't find anything. Will try nopcmcia when I get home tonight. Thanks for the replies so far.

Hi,

What errors are you seeing on the stdout (display)?

Which kernel?

Try to pass the following to the kernel at boot; noapic and noacpi.

You could also try to force the pci to use the BIOS settings via boot by passing; pci=bios. This would be if your machine has a non-standard PCI host bridge that could cause the problem.

It could also be the other way, so try the 'pci= nobios'. To see if possibly the BIOS is causing the boot problem. This will cause direct hardware access for the pci instead of the BIOS settings.

BTW, there is no 'nopcmcia' that you can pass to the kernel.

digger95 · 10-23-2007, 02:39 PM

I was told the correct way to disable pcmcia is by editing /etc/rc.d/rc.m and simply commenting out the lines that load the pcmcia module (they're near the top). This worked for me. I have a desktop though and had no need for that module.

Alien_Hominid · 10-23-2007, 02:40 PM

Quote:

Originally Posted by onebuck

BTW, there is no 'nopcmcia' that you can pass to the kernel

There is nopcmcia, at least in rhel. Not sure why it isn't mentioned in linux docs, but that's not so strange keeping in mind that they weren't updated since 2003

nopcmcia worked for me on slax too.

l33t_c0w · 10-23-2007, 08:08 PM

Quote:

Originally Posted by onebuck

Hi,

What errors are you seeing on the stdout (display)?

Which kernel?

I'm not seeing any errors, just a black screen, with nothing on it. The kernel is the huge smp one that was installed by default (didn't the installer used to present you with a choice?). Passing nopcmcia at boot doesn't make a difference. I'll try some of the other things you mentioned.

Ok, I tried pci=bios, pci=nobios, noacpi, and noapic. The behavior was the same with all those options, except for pci=bios, which left me with a screen full of text and a kernel panic

onebuck · 10-24-2007, 07:34 AM

Hi,

You should use one of the generic kernels.

Code:

excerpt from CHANGES_AND_HINTS.TXT
It is recommended that you use one of the generic
kernels(either the plain kernel-generic or kernel-generic-smp)
for daily use. 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 12.0 are configured for SMP usage, so you won't have
to modify those to build external out-of-tree modules (such as
NVidia or ATI proprietary drivers) if you use the SMP kernel.

If you are using one of the non-SMP kernels (huge.s or
generic.s) and need to compile third-party modules (such as the
proprietary NVidia driver), have a look in 
extra/linux-2.6.21.5-nosmp-sdk/ for information on what is
needed to build them. As stated earlier, it is recommended that
you use one of the generic kernels rather than the huge kernels;
the huge kernel is primarily intended as an "installer" and
"emergency" kernel in case you forget to make an initrd.

However, if you do use one of the huge kernels, you will likely
encounter errors like this:
kobject_add failed for uhci_hcd with -EEXIST, don't try to
register. These occur because the respective drivers are
compiled statically into the huge kernels but udev tries to load
them anyway. These errors should be safe to ignore, but if you
really don't want them to appear, you can blacklist the modules
that try to load in /etc/modprobe.d/blacklist. However, make 
sure you remove them from the blacklist if you ever decide to 
use the (recommended) generic kernels.

If you choose to use the huge kernels then use a initrd. Read the '/boot/README.initrd' to see how.

digger95 · 10-24-2007, 08:27 AM

Hi,

Just to backup what onebuck posted, switching to the generic kernel will likely help you out a bunch. Slackware 12 installed fine for me using the huge kernel (as it was meant to), but for everyday use it was causing way too many conflicts on my machine. Switching to the generic kernel resolved a lot of headaches. Even the generic smp kernel runs great for me and I have an older Celeron P4.

I'm new to Slackware, but having just gone through this myself I thought I would speak up

Dig

digger95 · 10-24-2007, 08:37 AM

I also wanted to add that on my particular machine I was only able to successfully install and run Slackware 12 by using acpi=off at boot. Otherwise it stalled on me. Don't know if it's pertinent in your situation though. For some reason noacpi didn't work for me, but acpi=off did. I could very well have made a typing error though.

l33t_c0w · 10-24-2007, 12:09 PM

Well, I tried switching to the generic kernel, and creating the initrd, but it's still doing the same thing. There's got to be a fix for this besides turning off udev entirely. Are there bootlogs?

new development: acpi=off works.

This is a laptop though, so I'd rather have acpi turned on. What do I do next?

Bruce Hill · 10-24-2007, 01:56 PM

You should build a custom kernel for your laptop. During this process, you'll find which options will work for it. Kwan Lowe's Kernel Rebuild Guide is a great resource to learn HOW-TO rebuild the Linux kernel.

Also, search <Linux> Google Search for the option (acpi=off) which worked; as well as TuxMobil and Linux-on-Laptops for models similar to yours. You'll see what others have done with a similar buggy BIOS to get ACPI supported properly.