Boot time Slackware and Debian

noidea · 05-26-2008, 12:30 AM

i use slackware 12.1 at home using the generic smp kernel, it takes a while to boot up. at work i have a debian desktop that boots up extremely fast, i havent timed them but it would be under half the time. why is this so? the debian desktop boots up as fast as my xp desktop.

dugan · 05-26-2008, 02:27 AM

Any idea which part of Slackware's startup is the bottleneck?

If Slackware takes forever to print a row of dots on the screen before doing anything else, then add the COMPACT option to lilo.conf

If disk access continues to be slow after boot-up, then Slackware might be loading the wrong ATA driver. There's a note on this in CHANGES_AND_HINTS.TXT.

If it's something else then you need to give us more to work with.

reddazz · 05-26-2008, 02:39 AM

If I remember correctly Slackware used to run updatedb at boot up which sometimes could slow a system down. This is one of the things you could check and disable.

shadowsnipes · 05-26-2008, 12:43 PM

Quote:

Originally Posted by reddazz

If I remember correctly Slackware used to run updatedb at boot up which sometimes could slow a system down. This is one of the things you could check and disable.

I don't know if that was ever true, but I know it is not true now. A quick grep of the init scripts proves this. As far as I know, updatedb was always done as a cron job.

Slackware 12.1 does boot slower for me than 12.0. I think the additions of

gtk-update-icon-cache
gtk-query-immodules-2.0

is what makes it a little slower for me.

@noidea

The first thing you should check on your Slack box is if there are any errors. Check your logs and read the messages during boot up. Also, take note where things pause for a bit. Most likely it is during HAL/udev stuff, starting network services, and perhaps while updating the icon cache and gtk-query-immodules-2.0 that I mentioned earlier.

You may have more services turned on your Slack box than your Debian box. Turn off the ones you don't need (if they are from stock Slackware then removing the executable bit should be enough).

Also, if you are willing to hack the init scripts you can make Slackware boot very fast. I have a special boot up procedure that I can select from LILO that will boot my box (2GHz Celeron, 1.3GB RAM) in just a few seconds! In this particular case I'm booting my box into "mp3 mode" which basically boots into single user mode and runs a chrooted audio player (herrie) without needing to login. I hacked rc.S and rc.K to make it really fast, but you can hack the other scripts to speed things up. Don't do this unless you know what you are doing! It obviously is not supported by Slackware.

rg3 · 05-26-2008, 01:11 PM

You can also try to suspend to RAM or hibernate. Suspending to RAM is a bit trickier and uses power while the computer is suspended, but it will probably "boot" in less than 10 seconds. If you hibernate, you can boot in around 30 seconds and the computer will be completely turned off while hibernated.

Woodsman · 05-26-2008, 01:17 PM

Quote:

Slackware 12.1 does boot slower for me than 12.0. I think the additions of

gtk-update-icon-cache
gtk-query-immodules-2.0

is what makes it a little slower for me.

Indeed. Regarding those recent rc.M additions:
1) Update any existing icon cache files,
2) Update mime database,
3) SCIM and other GTK+ input methods like this file kept updated

I commented those items out of rc.M, copied the same text into a script called "house-cleaning" and placed the script in /etc/cron.daily.

This helps reduce boot time yet keeps my system updated and orderly.

I commented out and copied the sections for ldconfig and fc-cache to the same script.

I added update-desktop-database (from /var/log/setup) to this script.

However, the OP does not define fast. Some boot times would help better define that word.

shadowsnipes · 05-26-2008, 01:31 PM

Quote:

Originally Posted by Woodsman

Indeed. Regarding those recent rc.M additions:
1) Update any existing icon cache files,
2) Update mime database,
3) SCIM and other GTK+ input methods like this file kept updated

I commented those items out of rc.M, copied the same text into a script called "house-cleaning" and placed the script in /etc/cron.daily.

This helps reduce boot time yet keeps my system updated and orderly.

I commented out and copied the sections for ldconfig and fc-cache to the same script.

I added update-desktop-database (from /var/log/setup) to this script.

However, the OP does not define fast. Some boot times would help better define that word.

Updating the mime db, ldconfig, and some of the others you mentioned really don't slow down (noticeably) the boot for me since they are forked off as a background process. ldconfig didn't use to be done this way (I think around Slackware 10.2 or 11.0).

gtk-update-icon-cache and gtk-query-immodules-2.0, on the other hand are not forked off, so you could potentially speed up the boot by adding an '&' to the line. Putting this stuff in a cron job works as well, and it is probably a good idea if the system is up for a long time anyways.

I agree that the OP should give some actual boot times (or at least estimates). It should also be noted what the hardware is for all of these machines.

C-Sniper · 05-26-2008, 01:38 PM

if you don't mind doing an rc.inet1 hack, you could change the DHCP time out settings which (since i have a laptop) use to take up most of the time. I have it set to 5sec and a reduce of 1sec and now it boots real fast.

reddazz · 05-26-2008, 02:45 PM

Quote:

I don't know if that was ever true, but I know it is not true now. A quick grep of the init scripts proves this. As far as I know, updatedb was always done as a cron job. ...

When I ran Slackware as my main distro a few years back, updatedb was ran at boot up and you had to edit one of the init script if you did not want this behaviour. I've not used Slack since 10.x, so obviously a lots changed since then. If I find an old article detailing this behaviour, I will post it back here.

slackb0t · 05-26-2008, 05:51 PM

Quote:

Originally Posted by Woodsman

Indeed. Regarding those recent rc.M additions:
1) Update any existing icon cache files,
2) Update mime database,
3) SCIM and other GTK+ input methods like this file kept updated

I commented those items out of rc.M, copied the same text into a script called "house-cleaning" and placed the script in /etc/cron.daily.

This helps reduce boot time yet keeps my system updated and orderly.

I commented out and copied the sections for ldconfig and fc-cache to the same script.

I added update-desktop-database (from /var/log/setup) to this script.

However, the OP does not define fast. Some boot times would help better define that word.

Could you post the script and the location where you placed it? If you would be so kind.

toni_N · 05-26-2008, 06:05 PM

hi for all

Code:

--- rc.M1	2008-05-24 15:47:04.000000000 +0200
+++ rc.M	2008-05-24 15:49:18.000000000 +0200
@@ -14,8 +14,8 @@
 # Tell the viewers what's going to happen.
 echo "Going multiuser..."
 
-# Update all the shared library links:
-if [ -x /sbin/ldconfig ]; then
+# Update all the shared library links: hack_T
+if [ -x /sbin/ldconfig -a -x /etc/rc.d/upgradeboot  ]; then
   echo "Updating shared library links:  /sbin/ldconfig &"
   /sbin/ldconfig &
 fi
@@ -67,7 +67,7 @@
 fi
 
 # Update the X font indexes:
-if [ -x /usr/bin/fc-cache ]; then
+if [ -x /usr/bin/fc-cache -a -x /etc/rc.d/upgradeboot ]; then
   echo "Updating X font indexes:  /usr/bin/fc-cache -f &"
   /usr/bin/fc-cache -f &
 fi
@@ -129,28 +129,32 @@
   . /etc/rc.d/rc.acpid start
 fi
 
-# Update any existing icon cache files:
-if find /usr/share/icons 2> /dev/null | grep -q icon-theme.cache ; then
-  for theme_dir in /usr/share/icons/* ; do
-    if [ -r ${theme_dir}/icon-theme.cache ]; then
-      echo "Updating icon-theme.cache in ${theme_dir}..."
-      /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} 1> /dev/null 2> /dev/null
-    fi
-  done
-  # This would be a large file and probably shouldn't be there, but if it is
-  # then it must be kept updated, too:
-  if [ -r /usr/share/icons/icon-theme.cache ]; then
-    echo "Updating icon-theme.cache in /usr/share/icons..."
-    /usr/bin/gtk-update-icon-cache -t -f /usr/share/icons 1> /dev/null 2> /dev/null
-  fi
-fi
+#hack_T
 
-# Update mime database:
-if [ -x /usr/bin/update-mime-database -a -d /usr/share/mime ]; then
-  echo "Updating MIME database:  /usr/bin/update-mime-database /usr/share/mime &"
-  /usr/bin/update-mime-database /usr/share/mime &
+if [ -x /etc/rc.d/upgradeboot ]; then
+   # Update any existing icon cache files:
+   if find /usr/share/icons 2> /dev/null | grep -q icon-theme.cache ; then
+     for theme_dir in /usr/share/icons/* ; do
+       if [ -r ${theme_dir}/icon-theme.cache  ]; then
+         echo "Updating icon-theme.cache in ${theme_dir}..."
+         /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} 1> /dev/null 2> /dev/null
+       fi
+     done
+     # This would be a large file and probably shouldn't be there, but if it is
+     # then it must be kept updated, too:
+     if [ -r /usr/share/icons/icon-theme.cache ]; then
+       echo "Updating icon-theme.cache in /usr/share/icons..."
+       /usr/bin/gtk-update-icon-cache -t -f /usr/share/icons 1> /dev/null 2> /dev/null
+     fi
+   fi
+   
+
+   # Update mime database:
+   if [ -x /usr/bin/update-mime-database -a -d /usr/share/mime ]; then
+     echo "Updating MIME database:  /usr/bin/update-mime-database /usr/share/mime &"
+     /usr/bin/update-mime-database /usr/share/mime &
+   fi
 fi
-
 # Start D-Bus:
 if [ -x /etc/rc.d/rc.messagebus ]; then
   sh /etc/rc.d/rc.messagebus start
@@ -166,8 +170,8 @@
   sh /etc/rc.d/rc.bluetooth start
 fi
 
-# SCIM and other GTK+ input methods like this file kept updated:
-if [ -x /usr/bin/gtk-query-immodules-2.0 ]; then
+# SCIM and other GTK+ input methods like this file kept updated: hack_T
+if [ -x /usr/bin/gtk-query-immodules-2.0 -a -x /etc/rc.d/upgradeboot  ]; then
   echo "Updating gtk.immodules:  gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules"
   /usr/bin/gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules 2> /dev/null
 fi

save this patch in a file , patch-rc.M-fastboot.diff

copy in

/etc/rc.d

then make a backup
#cp rc.M rc.M.backup

patch rc.M
#patch -p0 <patch-rc.M-fastboot.diff

then create upgradeboot
#touch upgradeboot

if you want a fastboot without upgrade:
#chmod -x upgradeboot

if you want a slowboot with upgrade:
#chmod +x upgradeboot

shadowsnipes · 05-26-2008, 06:32 PM

Quote:

Originally Posted by slackb0t

Could you post the script and the location where you placed it? If you would be so kind.

Woodsman did not post the script, but it is just bits taken out from the original scripts, which you would have to do to make it useful anyways. The location was specified and the name does not matter (it only matters that it is executable).

Quote:

Originally Posted by toni_N

save this patch in a file , patch-rc.M-fastboot.diff

copy in

/etc/rc.d

then make a backup
#cp rc.M rc.M.backup

patch rc.M
#patch -p0 <patch-rc.M-fastboot.diff

then create upgradeboot
#touch upgradeboot

if you want a fastboot without upgrade:
#chmod -x upgradeboot

if you want a slowboot with upgrade:
#chmod +x upgradeboot

This is similar to the /etc/forcefsck file. As such, I recommend that it would be better to check if the file is readable and not if it is executable, since the file itself is not used to actually run anything directly. This would also help distinguish it from the other executable scripts. Just 'touch' the file when you want to use it next time and delete when you don't.

Personally I like to use boot time variables. Simply set one in lilo.conf for your kernel image by adding an append line with the variable and its value (eg. append="bootFast=yes"). Then you can decide to use your fast or slow boot during boot time instead of having to touch/change perms on a file during the last boot. Just keep in mind that this variable is active until you reboot. For my hacked scripts, for instance, I check what runlevel I came from before doing some things. This is useful, for instance, when wanting to skip waiting for processes to die when going into runlevel 1, but only doing this if coming from no prior runlevel.

Woodsman · 05-26-2008, 10:19 PM

Quote:

Could you post the script and the location where you placed it? If you would be so kind.

There is not much to post. As I mentioned in my previous post, the script is located in /etc/cron.daily and is executable. But here goes:

Code:

#!/bin/sh
# /etc/cron.daily/house-cleaning

# Update all the shared library links:
if [ -x /sbin/ldconfig ]; then
  /sbin/ldconfig
fi

# Update the X font indexes:
if [ -x /usr/bin/fc-cache ]; then
  /usr/bin/fc-cache -f
fi

# Update any existing icon cache files:
if find /usr/share/icons 2> /dev/null | grep -q icon-theme.cache ; then
  for theme_dir in /usr/share/icons/* ; do
    if [ -r ${theme_dir}/icon-theme.cache ]; then
      /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} 1> /dev/null 2> /dev/null
    fi
  done
  # This would be a large file and probably shouldn't be there, but if it is
  # then it must be kept updated, too:
  if [ -r /usr/share/icons/icon-theme.cache ]; then
    /usr/bin/gtk-update-icon-cache -t -f /usr/share/icons 1> /dev/null 2> /dev/null
  fi
fi

# Update mime database:
if [ -x /usr/bin/update-mime-database -a -d /usr/share/mime ]; then
  /usr/bin/update-mime-database /usr/share/mime &
fi

# SCIM and other GTK+ input methods like this file kept updated:
if [ -x /usr/bin/gtk-query-immodules-2.0 ]; then
  /usr/bin/gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules 2> /dev/null
fi

# Run update-desktop-database:
if [ -x /usr/bin/update-desktop-database ]; then
  /usr/bin/update-desktop-database /usr/share/applications 1> /dev/null 2> /dev/null
fi

storkus · 09-08-2008, 09:10 AM

I've been reading this with fascination since I've been thinking about this ever since 12.1 came out. I was looking for something else that also happens on an old distro with a work computer, though. Maybe you can answer that as well.

So wrt 12.0 to 12.1, the biggest difference is the gtk and mime database updates, and my first question is: why is it necessary, exactly, to do it with every boot? For instance, Woodsman says, "3) SCIM and other GTK+ input methods like this file kept updated", but if that's true, why isn't it run as a cron job the same way updatedb is? Ditto for the mime crap. Another related question: why can't we put these, along with ldconfig and other stuff, in that same daily cron job and then nice it to death so it doesn't slow the system to a crawl--updatedb is no fun when it starts to run. (No, I haven't done this nicing yet, I just now thought of it.)

Another problem: I can only vaguely understand why the "udevtrigger --retry-failed" line (I'm typing by memory from work on a windoze machine) needs to be there. The man page is plain enough about what that does (and why Pat will have to change the command name soon) but not why this needs to be called in the init scripts at that location. What I *DO* know is that, if commented out, the system will not finish booting!

Finally, the ever-so-annoying "regular fsck" problem, and the one I alluded to above with the work server (running a VERY OLD Caldera distro) as well as with current Slackware 12.1 and who knows what else: why, if I'm running ext3, and it's supposedly the most stable thing available, do I need to fsck every partition every n boots? I thought that's what a journal was for, for starters! On a server, this may be nice, but waiting around for my laptop or desktop to boot as it goes about fsck'ing every partition (but one, always but one, and that one gets done the next time!) can be a little maddening. In this morning's case, I had a customer waiting while the server decided THIS reboot would be the one to fsck everything. Can anyone answer this at all?

Thanks, Mike

gnashley · 09-08-2008, 10:52 AM

Nearly all those checks are quite important and leaving them out should be done with caution. The udev stuff has to run or you get no devices, ldconfig should really be run at startup -otherwise it makes no sense to run it -except when libraries are installed or removed.
The database updates are mostly in the same category. What I'm getting at is that these are all sanity checks which are done on each boot in case you or some installer forgot to do these things the last time the machine was running. You could probably do away with 80% of the boot-time procedures and still be able to boot, but sooner or later you'll get bitten by not doing one of them. Just be sure you understand the workings and relative importance of each item before moving or disabling it.