During the section of text-only on the screen as it scrolls by, it's normally really fast (using 14.1). Then last week things started to get a little strange and now at bootup at a particular section it slows to a literal crawl.

When it gets to:

At each of those it now takes ~30 seconds, so now bootup takes about two minutes plus to get to a login screen. This has been going on for about three days now out of about a week+/- of using 14.1.

Anyone know if there's a way to fix this, and why it suddenly has decided to slow at those spots?

Pull up dmesg after it finishes and see if you get any disk errors reported.

I didn't find anything in dmesg about any errors with anything.

The modules, fonts, and database resync/rebuild commands always slow the boot process down for a few seconds, but it shouldn't slow down by huge time frames.

Can you post your system specs?

Did you add any X11-related packages recently?

FWIW, I roll all of those X11-related boot items from the rc scripts into a single script called "rc.xjunk". The script is never run on boot but is there in case I need to re-enable it or run it manually. If there's no reason to run the script--i.e., if nothing has changed in the configuration or installation of the X11 programs--the script doesn't get run.

As I said, at first it was booting nice and fast, then it just eventually got to this point that it's a forever wait at each of those points I listed.

Here's my system specs:

MOBO: ASUS M5A97LE R2.0

Video card: Nvidia GeForce GT520 1GB DDR3

CPU: AMD FX-6300

Sound card: Creative Labs SB Live!

4GB DDR3-1866 RAM

150GB HDD (sda with /boot and /home, WD1600AAJS sata 3Gb/s)

150GB HDD (sdb with / and swap, WD1600JS sata)

32 bit Slackware 14.1

Hmmmm...not that I can think of. Just apps like vlc and such and the libs it needs to build.

not sure if it'll help with your implementation

I asked about
gtk.immodules
gdk.pixbuf.loaders
pango-query modules
in rc.M last year and was told
Just comment it out, I always do and there's no problem.

see post here

I'm willing to give it a try...I can always open mc if I can't get to X and take out the comments.

Thanks, I'll let you know what happens.

Well, commenting those out didn't seem to help and though I'm not sure it was because of commenting those out, but the syetme boot got even slower, so I put rc.M back to original and it's back to booting slowly but not as slowly as when those were commented out. Back to square one <sigh>

Do you have a failing hard drive? Can you put some "echo"s in rc.M to track down the progress?

I checked it yesterday with SMART - short and long tests - and not one hiccup or error or problem reported with the drive.

Now that the SBo Slack packages is up (Thanks to you guys for all your hard work for that too!!), I think I'll reinstall next week and try this again (has to be next week as I'm on satellite internet and I accidentally ran over my limit this past week and until the next 'period' I'm stuck on only slightly-better-than-dialup speed). It's not just the slow boot now, but other things are happening that I'm not happy with at all, for example - When scrolling up or down on webpages, there's a 'line' of sorts that goes all the way across my screen but isn't there when not scrolling (I've tried all my NVIDIA's from 304 to 331...all the same, no difference). The problem with watching mkv files with vlc. kipi installs but doesn't show up on my right-click menu. Pacpl installs but also doesn't show up on my right-click menu. Maybe one or two other small things I can't think of at the moment but hopefully will be corrected with a better installation etc.

Thanks for the suggestion though, it's appreciated

Well, I do see one thing it might or might not be.

The fact that you're using a 64-bit CPU with a 32-bit OS might not be the case, but honestly, you aren't able to fully access your complete system resources so it might be limiting things to what 32-bit software can only access hardware-wise, so then it's kinda difficult to say it's a hardware accessibility resource issue, a hard drive issue, or even a software issue.

Let me ask these five questions, and please answer thoroughly and as much detail as possible:

1. What bus speed and data access rate is your hard disk?

2. What filing system are you using, and are you using multiple disk partitions?

3. Have you tried a 64-bit OS with 32-bit multilib in comparison against your current one?

4. Did you ever disable any service daemons in your previous install?

5. What is your exact boot time to Login: clock at with Runlevel 3?

It seems like a lot to ask, but this will help us work backwards through things and see if there is one minor or major issue, problem, or change you, or a software package presented into the system that changed something dramatically.

True, but 14.0 I didn't have these problems and used 32 bit with that also (same system/hardware)

Both of the hdd's are *supposed* to be sata 3 and mobo bus speed at "up to 4800 MT/s" (according to my mobo book), but when booting I don't think I've ever seen anything put the hdd's into sata speeds but I seem to mostly see udma 100 and 133 (which has been kind of depressing, and it was the same with 14.0)

I've use nothing but reiserfs since 2000 and never had a problem with it, even during a year+ without a UPS and out in the woods where powerouts and brownouts are the norm and not the strange, heh.

No. I don't want to simply *because* of the fact I have to futz around to get to much software to work in it and I'm not running/doing anything that needs the small improvement a 64 bit system will give me (just a plain Joe who can barely understand a bash script *if* someone else writes it, lol).

In 14.0? I honestly can't remember. I know I always *wanted* to rid myself of that troublesome akonadi and nepomuck things!

3 minutes and 21 seconds...that's to the login prompt in runlevel 3.

It's not a lot to ask, I'd always much rather work things out than re-install if at all possible and if I can follow along well enough to not screw things up worse than they already are, heh.

Check your Motherboard BIOS/EFI and see if you don't have legacy ATA mode enabled for your hard drive controllers. Look for the bus options for SATA(RAID), SATA(IDE), and SATA(AHCI), and set it to SATA-AHCI mode.

ReiserFS is actually showing it's problems on faster systems anymore. It actually was a file system meant for older systems that were under the 1.5 estimated GHz clock speed. It really does NOT scale well on modern CPUs. Modern file systems like EXT4 and JFS actually are known to work better with faster access speeds and scale better.

Well, whatever you do don't go more than 4GB of RAM or else you'll have issues. PAE works, but the true limit of resources in RAM a 32-bit system can access is only 4GB, but really you should be looking into using a 64-bit OS, even if just a pure 64-bit OS without Multilib.

You should always log what you do each system install in a notebook and duplicate it each install to make sure you can re-create the environment exactly as needed.

Even with my old Athlon64 X2 2.5GHz dual core and all scripts operating it should fully boot in less than 25 seconds.

Often at times a re-install is about the only way to fully reset and repair something.

More than likely it's a combination of a setting in the EFI/BIOS combined with ReiserFS.

Probably, and more than likely you should reset the hard drive controller to AHCI and then install using JFS as such for example:

sda1 - /boot - ext4
sda3 - /(root) - jfs
sda5 - swap - swap