I tried the new Slackware 12 version just these days. I find Slackware 12 boots much slower than the previous Slackware 11, both from the installation CD 1 and from the hard drive when installed. I just want to know why this happens. Thanks for your help.

Another question: Slackware 12 on Virtual PC 2004 SP1 after an installation didn't seem to set the video mode successfully. During the boot after rc.udev (exactly after udev events are enabled), the screen becomes strange, with many horizontal lines and showing only the upper half. It looks like a graphic mode but contains only plain text information, and the text looks very unclear. Did I install it incorrectly, or any configuration went wrong in /etc/rc.d/ ? Thanks again.

On my computer the Linux kernel takes some time to scan the SATA devices plugged to the IC7R southbridge of my motherboard. Even if there is none. Then the kernel takes almost one minute to load itself where it could have done it in 5 seconds with my old computer.
So it may be a bug or some strange behaviour with your hardware.

in my desktop, it tried to scan the RAID, even though i don't use RAID
this behavior doesn't occur on my laptop which is using -Current

I've noticed that udev seems to slow down the boot process in 12 for some reason. I haven't yet had time to investigate it as I just bought and moved into a new house last week and have been busy setting up housekeeping in the new place.

Hi,

I'm not sure about your hardware but mine seems to boot the kernel a lot faster. You possibly have a probing problem! You devices and rules may cause the slower boot

I would first look at the output of your logs. Look at the dmesg.

Reading this could show the possible slow boot. Look at the video as a possible error.

How is your lilo.conf setup? What video mode did you choose? I would suggest that you start with a standard video 'vga = normal'. Then write the lilo.conf via the 'lilo' command to update the 'MBR'.

I would capture the dmesg for each session for debug reasons. Just redirect it by; 'dmesg >dmesg.debug.1' for session 1 and do for each after unique by incrementing the number. That way you can trace through to find the problem.

Reboot to see what happens during the boot. Compare output of dmesg errors between the boots. If you don't save the dmesg between session then you will not have a means to trace.

edit: sorry about the redundant post but my network was down do to a severe storm.

I've noticed Slackware 12 is slower to boot also; I believe the culprits are udev, hald, and hplip (that HP print driver program written in Python). Just my perception as I watch my PC boot...

IMHO, Slack 12.0 with UDEV, HAL, hplip etc boots about the same speed as 11.0 with UDEV and hplip. This is really a extremely subjective area though and is heavily influenced by factors like hardware and what you have running at boot.

Booting is slower in 12 for me, but at a particular point. At the udevtrigger --reply-failed step of rc.udev, the boot process seems to completely stop. The cursor stops flashing for about 90 seconds, then the cursor starts flashing again and the LED indicator on my laptop's Wifi button flickers a couple of times. Then booting continues. I've learned that the udevtrigger --reply-failed option is retrying to create kernel device events for devices that failed in a previous run. I haven't figured out why it takes so long or appears to hang the boot process. My /dev/.udev/failed directory has entries for what looks like every PCI Bus ID listed by lspci.

Remember also, that the default kernel is called huge because it contains support for most stuff built-in. If you want faster booting, change to generic as stated on CHANGES_AND_HINTS.txt or compile your own.
Dhcp could be causing some delay too...

Hi,

That's not true! The speed of the kernel would not necessarily be controlled by the built in drivers just the kernel size. The trigger and identifying would take care of this since the kernel matches to the irq, device names and device tables assignments within the kernel device driver layer.

The device identification would not be a linear search through the kernel. The event for the device during polling within the kernel device driver layer of the init cycle would be how this is done. Then the device would be handled by the kernel via the assignments.

No where in the CHANGES_AND_HINTS.TXT
is there a statement about faster booting and compiling.

Now there is a statement for performance but for another reason.

I don't think I've missed anything in the text nor read between the lines. Correct me if I'm wrong.

Sorry, I meant to said that's stated there how to change the kernel, no that one is faster than other. However, the huge will try to probe for RAID stuff (as a example). I'm not a racer, but when I saw this thread I measured the difference between huge and my compiled kernel and saw a 2 seconds difference, mostly because I enabled some resolution stuff that takes 5 seconds to setup.
Anyway, another glitch that I saw is that "compact" option in lilo isn't still default, that speeds up kernel loading too (the dots when loading a kernel with lilo).

Hi,

You can speed up by decrease of time if you do remove irrelevant probes. Especially something link RAID. If the hardware is not there then why attempt to probe. That is part of the problem when you must have a kernel to cover everything. There you can change the boot processes then the kernel will still use the device driver layer. If you look at 'accelerated knoppix' in how they use the cloop to decrease the boot time by this very method. It's just that the process technique they use isn't always reliable and not all devices are recognized.

Yes, if you trim for non-existent probe equipment then the amount of time will decrease. The kernel process is still the same. Just that you are changing the manner or what is probed.

Thanks. I'll try this.

For the display problem in Virtual PC, I looked at the dmesg output. I found the following line:

...
Console: switching to colour frame buffer device 80x30
fb0: S3 Trio32 on 0000:00:08.0, 4 MB RAM, 14 MHz MCLK
...

May this be the problem? How can I disable the switching?

I encountered some severe performance issues on my pc. The whole system responsiveness plunged down to a low. My old notebook (200MHz) is 10 times faster than this machine (2,5GHz). It is no matter what kernel I use (generic or huge) although I think it's somehow related to the kernel, but I couldn't find the relevant option causing it.
However, it is not only the boot process being slow, it's everything (KDE startup, startup of akregator takes about 4 Minutes!!!!; make, which is causing kernel recompilation to be a real pain).
Please HEEEEEEELP!!!!!!!