# Boot time is slow

## aditya3098

I recently ran some tests and found my kernel takes 5-8 seconds to get from the "Parsing ELF" to the OpenRC stage.

I don't use an initramfs, but using one increases the time to about 9 seconds. 

Also, some times after a reboot, the kernel freezes, trying and failing to wake CPU1,2,3 and so on.

I have an AMD FX-6300 (Core), 8 gigs of ram and an NVIDIA GT 730 card on proprietary drivers, a fairly good machine. 

I have a mostly static kernel.

Is this an normal amount of time to boot the kernel?

Also, it takes 5 seconds at the "processing uevents". Is that normal, too?

Also, I tried searching for how to do this, but could not find out how I can start my less essential init scripts (sshd, libvirtd, samba, avahi) after my DM.

UPDATE: More details:

I used to get 12 seconds boot time (grub to login) when I was on an intel core i3 with integrated graphics. Now its 35 seconds.

----------

## Ant P.

 *Quote:*   

> Also, some times after a reboot, the kernel freezes, trying and failing to wake CPU1,2,3 and so on.

 

I have that on rare occasion with a Phenom II. Maybe it's a BIOS bug. I haven't bothered looking into it, hitting the reset button fixes it.

 *Quote:*   

> I have an AMD FX-6300 (Core), 8 gigs of ram and an NVIDIA GT 730 card on proprietary drivers, a fairly good machine. 
> 
> I have a mostly static kernel.
> 
> Is this an normal amount of time to boot the kernel?

 

Doesn't seem right. Mine only takes half that on lesser hardware.

 *Quote:*   

> Also, it takes 5 seconds at the "processing uevents". Is that normal, too?

 

That's udev's fault. It varies a lot depending on what hardware you have in the system, whether you have USE=kmod, what's in your /etc/udev/rules.d/, etc.

 *Quote:*   

> Also, I tried searching for how to do this, but could not find out how I can start my less essential init scripts (sshd, libvirtd, samba, avahi) after my DM.

 

Create a stacked runlevel (man rc-update), move all your unimportant stuff from default to that, then add an /etc/local.d/ script with "rc $yourrunlevel", which will be run after everything else in the default runlevel.

 *Quote:*   

> UPDATE: More details:
> 
> I used to get 12 seconds boot time (grub to login) when I was on an intel core i3 with integrated graphics. Now its 35 seconds.

 

Okay, that's not right. Have you tried using app-benchmarks/bootchart2?

----------

## aditya3098

Yeah, I tried bootchart.

The Stacked Runlevel thing got my boottime down to 25 seconds (that, slimming my kernel and also using lxdm instead of lightdm).

Kernel boot still about 5 seconds, another 5-10 for udev.

Did you ask me to add or remove the kmod flag?

----------

## aditya3098

Messed with the udev init scripts, removed unnesscary checks. Down to 20.

My kernel keeps saying something about raid6 for a few seconds. I have no raid on my computer and:

```

1 thangorodrim 17:33 ~ $ zcat /proc/config.gz | grep raid  

1 thangorodrim 17:33 ~ $ 

```

Anybody have any idea?

UPDATE: My bad, grep needed the -i flag

----------

## NeddySeagoon

aditya3098,

Pastebin  your dmesg output.  It needs to have timestamps on in so we can see what happens when.

uevent processing can create a pause, looking for firmware that is missing takes time, doing things that are not needed ....

----------

## ShanaXXII

 *aditya3098 wrote:*   

> Messed with the udev init scripts, removed unnesscary checks. Down to 20

 

Was wondering what you did by "messing with udev init scripts". I would like to speed up my uevent processing as well   :Smile: 

----------

## Ant P.

 *aditya3098 wrote:*   

> Yeah, I tried bootchart.
> 
> The Stacked Runlevel thing got my boottime down to 25 seconds (that, slimming my kernel and also using lxdm instead of lightdm).
> 
> Kernel boot still about 5 seconds, another 5-10 for udev.
> ...

 

I'm not really sure which is best for that, but I've heard developers who seem to know what they're talking about complain about kmod more often than not. With kmod all the module loading happens in a single process, without it /sbin/modprobe gets invoked a bunch of times in parallel, but that also costs the overhead of forking. Depends on whether some module has long delays or not.

Bootchart doesn't show everything by default btw - to figure out the root of problems like this (especially udev) you'd need to look at the output of pybootchargui --show-all.

----------

