Been quite a while since I fiddled with Slack, but it looks like there's a package for bootchart. Maybe try that to get some idea of where the time is going.

systemd offers some tools, but I'm guessing not too many have taken up bartgymnast on his offer.

systemd is not a part of Slackware officially, and Bart is far from having his SlackBuilds completed. There are still many problems with resource and dependency loading with systemd that have yet to be officially addressed, and currently the only solution is a rather complicated one.

Bootchart should work well enough if needed, but in all honesty, he did say his drive was acting as a UDMA ATA-100/133 drive, and he's using ReiserFS on an AMD FX series CPU. That alone should answer some questions and point to a problem at hand, as well as a solution.

Doesn't answer in any why why it used to work, and now apparently doesn't. Need some hard data.

@ReaperX7 - I appreciate the help, but syg00 is right...in 14.0 things were fine *and* fast, and at first with 14.1 they were the same. It was almost like a sudden, overnight thing that happened and now my boot time has gone through the roof and *mainly* with those three things at/near the end of the boot process - gtk.immodules, gdk.pixbuf.loaders, pango-query modules.

@syg00 - I looked at that 'bootchart' thing, and since I use the huge.smp where in lilo do/how I "append" it like it says to do (it just doesn't say *where* or how to do it in lilo, heh)?

Try touching the file /etc/forcefsck and rebooting.

@Richard - The system had actually done that just the other day since it had been 31 reboots in about a week, and it was clean.

Every partition? Or do you only have one?

Actually as software changes, so do the requirements. Sometimes subtley, and sometimes dramatically.

To be honest, yes the cache refreshers do slow down the boot times, and you can move them into cron jobs to ease up things if you are on long up times, but you honestly should take a review of your system overall and start with the most common sense checks. Those cache refreshers work off access times for your disk and the speed of the CPU. This is why I said you need to research ReiserFS against modern hardware, and check your motherboard UEFI's SATA mode setup.

Just because in 14.0 it worked doesn't mean the same software is at work in 14.1 in the same way. Changes have happened since 14.0's software packages are out, and those same packages may not work exactly the same way.

Oops...forgot to let you know that the BIOS is still (and apparently I did it with 14.0) set at ahci.

As for the fs thing, it still doesn't explain why it (14.1) worked fine for about a week and then of a sudden decided to take its time on those cache update parts at boot.

Is there a way to check what speed my system is using on these hdd's? They're sata 3's, but I always see 'udma' settings during boot, but I can't be sure if that's just something that's seen but not used and they're getting sata speed.

Just the one, sdb, since my / partition and swap are on the sdb drive and /boot and /home are on sda.

These other folks may be on the right track, but you might try something like (as root) `strace -r -o ./output update-gtk-immodules`, then open the file ./output to see where things are hanging up.

You'd have to research into a Benchmark program probably.

Try using Stress here: http://slackbuilds.org/repository/14.1/system/stress/

If it's set to AHCI then that's saying that there are other system issues possibly.

I have other questions now:

1. How old is your hard drive?

2. What brand and model is it?

3. When you installed 14.1 in place of 14.0, did you perform a complete full clean installation with a reformat of the ReiserFS partition, or did you simply install over the existing software in an upgrade method of installation without repartitioning?

The problems with the ReiserFS are addressed here in this article:

http://lwn.net/Articles/202780/

Be warned it can get a bit technical, but in a nutshell it says that there are issues with it scaling effectively on multi-core CPUs due to a kernel locking feature that prevents certain multi-core CPU functions during read-write phases which can actually make access and read times on modern systems slower than filesystems like EXT3, EXT4, and JFS.

Okay, I tried this, but where is './output' at so I can look at it?

The sdb which holds / and swap, is about 4 years old (S.M.A.R.T. and fsck both say it's in good shape) and the sda which holds /boot and /home, is only two and also in good shape.

Both Western Digitals. (which since ~'95 have worked well for me whereas I've always had bad luck with Seagate's).

The installation was a fresh install, formatting of both drives etc. I've never done an 'upgrade' installation as IMO it's just 'better' (and far easier) to do a clean, fresh install.

strace creates a lot of output, so I had "-o ./output" in the command. If this was done, then you should be able to stay in the same directory and type `less ./output` to view the output. Otherwise, you can trim the command down to something like `strace -r update-gtk-immodules` and scroll backwards to see the output. Double-check the name though. It looks like the name of these update scripts have version numbers on the end of them now. Oops.

Start with `strace -r sleep 1` or `strace -r true` to see the output from a short command.