System bootup has decided to take forever...
 

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

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.

Okay, I did the first command you mentioned and read it with 'less'...unfortunately I haven't a clue about what I'm looking at. It turned out to be only 276 lines, but it might as well be written in mandarin Chinese :(

Anyway, I've decided to go back to 14.0 as one more problem reared its ugly head this evening and that was just one more than I needed (my printer, and all-in-one, prints fantastically, but this evening I needed to scan something and skanlite and xsane both, kept segfaulting on me), so I'm going to go back to what works for me well and maybe try 14.1 a little later if I can afford another hdd to try it on as a separate 'test' hdd on my system.

Thank you very much to everyone who has been trying to help. I honestly and truly do appreciate what you've all done and I'm sorry if I've wasted your time, but I just don't need this aggravation at this period in my life at the moment. You're all good people and I hope this doesn't stop you from helping me ever again if I happen to need it.

Oh, and, just because - I hope everyone had a great Thanksgiving (those who celebrate it, heh) and didn't gain too much weight yet, lol. Me, I've already had to let the belt out one notch and we still have half a turkey left and lots of trimmings.

No problem. I was hoping that one big number on the left was going to jump out, like this (from `strace -r sleep 30`):

The rest of it makes my eyes bleed. strace output is useful mostly when I want a fine-grained look at what a program is doing, but I don't want to fiddle with the source code or break out gdb.