# Bootprozess beschleunigen

## flammenflitzer

Hallo

Ich will den Bootprozess beschleunigen. Ich bin wie folgt vorgegangen.

aus rc default entfernt:

acpid

cpufrequtils

cupsd 

lircd

vixie-cron

aus /etc/conf.d/local.start entfernt:

```
#ebegin "Cleaning Distfiles - Distfiles werden gelöscht"                  

#rm -r -f /usr/portage/distfiles/*                                        

#eend $?                                                                  

#                                                                         

#ebegin "Zeitabgleich Systemzeit mit Atomuhr"                             

#/usr/local/bin/Zeitabgleich                                              

#eend $? 
```

Angelegt:/etc/eigeneStartscripte

acpid_verzögert_starten

```
#!/bin/bash

sleep 25

/etc/init.d/acpid start
```

cpufrequtils_verzögert_starten

```
#!/bin/bash

sleep 30

/etc/init.d/cpufrequtils start
```

cupsd_verzögert_starten

```
#!/bin/bash

sleep 35

/etc/init.d/cupsd start
```

Distfiles-löschen_verzögert_starten

```
#!/bin/bash

sleep 300

/usr/local/bin/Distfiles_leeren
```

lircd_verzögert_starten

```
#!/bin/bash

sleep 45

/etc/init.d/lircd start
```

vixie-cron_verzögert_starten

```
#!/bin/bash

sleep 50

/etc/init.d/vixie-cron start
```

Zeitabgleich_mit_Internet_verzögert_starten

```
#!/bin/bash

sleep 20

/usr/local/bin/Zeitabgleich
```

/usr/local/bin

Zeitabgleich

```
#!/bin/sh

rdate -s time.fu-berlin.de

hwclock --systohc

rm /etc/adjtime
```

Distfiles_leeren

```
#!/bin/bash

rm -r -f /tmp/*

rm -r -f /usr/tmp/portage/*

rm -r -f /var/tmp/portage/*
```

So sieht die local.start aus

```
cat /etc/conf.d/local.start                    

# /etc/conf.d/local.start                                                          

# This is a good place to load any misc programs

# on startup (use &>/dev/null to hide output)   

ebegin "Cleaning Tmp - Temporäre Verzeichnisse werden geleert"             

rm -r -f /tmp/*                                                           

rm -r -f /usr/tmp/portage/*                                               

rm -r -f /var/tmp/portage/*                                               

eend $?                                                                   

/usr/bin/kdm

/etc/eigeneStartscripte/acpid_verzögert_starten

/etc/eigeneStartscripte/cpufrequtils_verzögert_starten

/etc/eigeneStartscripte/cupsd_verzögert_starten

/etc/eigeneStartscripte/lircd_verzögert_starten

/etc/eigeneStartscripte/vixie-cron_verzögert_starten

/etc/eigeneStartscripte/Zeitabgleich_mit_Internet_verzögert_starten

/etc/eigeneStartscripte/Distfiles-löschen_verzögert_starten
```

Wie kann man das besser machen?

MfG

----------

## SvenFischer

Nur der lieben Vollständigkeit halber frage ich, ob "openrc" nicht das richtige für Dich wäre?

----------

## obrut<-

man könnte auch z.b. einit oder init-ng nehmen.

----------

## doedel

Man kann aber auch ohne ein anderes init-System das Zeug flotter machen.

In der /etc/rc.conf oder so (weiss nicht mehr genau) RC_PARALLEL_STARTUP setzen.

----------

## Anarcho

Ich habe das auch gerade durch.

Ich habe folgendes gemacht:

1. mir eine SSD gekauft

2. Den Kernel optimiert (Zeitinfo für dmesg einschalten und gucken welcher Treiber beim initialisieren am längsten braucht). Ich habe hier EHCI und OHCI als Modul kompiliert und lasse diese erst während des bootens parallel laden. Da ich ne SATA Platte habe und somit IDE nur für den Brenner brauche habe ich das IDE Modul ebenfalls als Modul. Kernel übergibt jetzt nach ca. 3 Sekunden an init. (Kernel 2.6.28 ist etwas schneller als die vorherigen).

Wichtig hier: Coldplug ausschalten und die Module in autoload eintragen. Sonst werden die Module nicht parallel zum Rest geladen und man hat nichts gewonnen.

3. OpenRC/Baselayout 2 verwendet und parallel startup an

4. Mittels bootchart überprüfen was man noch machen kann

Bei mir werden einige Dienste gestartet und mein Rechner zeigt mir jetzt nach ca. 19 Sekunden (von grub->xdm) den grafischen Login.

----------

## Knieper

 *doedel wrote:*   

> Man kann aber auch ohne ein anderes init-System das Zeug flotter machen.
> 
> In der /etc/rc.conf oder so (weiss nicht mehr genau) RC_PARALLEL_STARTUP setzen.

 

Totaler Murks. Lies einfach der Reihe nach die Skripte, die beim Start abgearbeitet werden, dann wirst Du sehen, dass Du um ein anderes System + eigene Konfiguration nicht herumkommst. Kurz die Alternativen: runit ist hässlich, init-ng lahm und halb tot, einit nutzt xml(!), upstart ist bloat - bleiben ua. minit, ninit...

----------

## michael_w

Hi,

da ich auch sowas plane:

 *Anarcho wrote:*   

> 
> 
> Ich habe folgendes gemacht:
> 
> 1. mir eine SSD gekauft

 

Welche genau und an welchem Controlller(Mobo?) hängt die? Wie gross ist die SSD und hast Du das komplette System drauf oder nur /boot, oder  .... ? 

thx

mw

----------

## flammenflitzer

 *doedel wrote:*   

> Man kann aber auch ohne ein anderes init-System das Zeug flotter machen.
> 
> In der /etc/rc.conf oder so (weiss nicht mehr genau) RC_PARALLEL_STARTUP setzen.

 

```
/etc/conf.d/rc
```

```
RC_PARALLEL_STARTUP="yes
```

"

----------

## Anarcho

 *michael_w wrote:*   

> Hi,
> 
> da ich auch sowas plane:
> 
>  *Anarcho wrote:*   
> ...

 

Hi,

ich habe eine Patriot 64 GB SSD per SATA am internen Controller angeschlossen. Dort ist das komplette System drauf. Nur /boot würde ja nicht viel bringen, dort wird ja nur der Kernel in den Speicher geladen (also ca. 2 MB sequentiell).

----------

## l3u

Ich benutze seit kurzem auch baselayout-2 (ohne parallell startup), und das hat meiner Meinung nach einen erheblichen Geschwindigkeitsschub beim Booten (und keine Nachteile) gebracht.

----------

## mv

Mit /bin/sh als Symlink auf dash wird baselayout-2 noch einmal eine Ecke schneller.

----------

## Anarcho

 *mv wrote:*   

> Mit /bin/sh als Symlink auf dash wird baselayout-2 noch einmal eine Ecke schneller.

 

Hat aber eventuell andere Nebeneffekte mit Scripten die von der bash ausgehen.

----------

## mv

 *Anarcho wrote:*   

> Hat aber eventuell andere Nebeneffekte mit Scripten die von der bash ausgehen.

 

Ja, aber die meisten dieser Bugs sind inzwischen behoben. (Ein paar gibt es noch: Umso mehr Grund es zu benutzen und ggf. die Bugs zu melden).

----------

## Anarcho

 *mv wrote:*   

>  *Anarcho wrote:*   Hat aber eventuell andere Nebeneffekte mit Scripten die von der bash ausgehen. 
> 
> Ja, aber die meisten dieser Bugs sind inzwischen behoben. (Ein paar gibt es noch: Umso mehr Grund es zu benutzen und ggf. die Bugs zu melden).

 

Ich habe meine Aussage nicht unbedingt über OpenRC gemacht sondern vielmehr über all die anderen Scripte von verschiedenen Paketen die alle "#!/bin/sh" in der ersten Zeile haben. Diese könnten alle ebenso beeinträchtigt werden und das eventuell Monate später wenn man sich an die Änderung nicht mehr erinnert.

----------

## Knieper

 *Anarcho wrote:*   

> über all die anderen Scripte von verschiedenen Paketen die alle "#!/bin/sh" in der ersten Zeile haben. Diese könnten alle ebenso beeinträchtigt werden und das eventuell Monate später wenn man sich an die Änderung nicht mehr erinnert.

 

Wer gegen /bin/sh programmiert und bash erwartet, dessen Software kann man eh nicht für voll nehmen.

----------

## mv

 *Anarcho wrote:*   

>  *mv wrote:*    *Anarcho wrote:*   Hat aber eventuell andere Nebeneffekte mit Scripten die von der bash ausgehen. 
> 
> Ja, aber die meisten dieser Bugs sind inzwischen behoben. (Ein paar gibt es noch: Umso mehr Grund es zu benutzen und ggf. die Bugs zu melden). 
> 
> Ich habe meine Aussage nicht unbedingt über OpenRC gemacht sondern vielmehr über all die anderen Scripte von verschiedenen Paketen die alle "#!/bin/sh" in der ersten Zeile haben.

 

Die meinte ich auch. Genauer: Ich meinte die Skripte, die es in Gentoo-Paketen gibt. Von diesen sind die meisten inzwischen gefixt.

(Wer natürlich eigene #!/bin/sh-Skripte mit Bashismen produziert hat, wird das schon wissen).

----------

## schachti

Danke für den Tipp mit dash - das hat den Bootprozess deutlich mehr beschleunigt als alles andere!

Eine Frage habe ich, vielleicht kann mir jemand helfen: Nachdem dhcpcd eine IP zugewiesen bekommen hat, wird sie immer erst getestet:

```

eth0: checking 192.168.x.y is available on attached networks

```

Kann man das irgendwie deaktivieren?

----------

## Anarcho

 *schachti wrote:*   

> Danke für den Tipp mit dash - das hat den Bootprozess deutlich mehr beschleunigt als alles andere!
> 
> Eine Frage habe ich, vielleicht kann mir jemand helfen: Nachdem dhcpcd eine IP zugewiesen bekommen hat, wird sie immer erst getestet:
> 
> ```
> ...

 

Nutzt du OpenRC und hast dort mit dash einen Geschwindigkeitsvorteil?

Für einen schnellen Boot habe ich eine feste IP eingestellt.

Auf welchen Bootzeitwert kommst du jetzt?

----------

## schachti

 *Anarcho wrote:*   

> 
> 
> Nutzt du OpenRC und hast dort mit dash einen Geschwindigkeitsvorteil?
> 
> 

 

Ich habe (da ~x86 System) bereits seit einigen Monaten OpenRC im Einsatz - der Umstieg auf OpenRC hat damals einen deutlichen Geschwindigkeitszuwachs gebracht. Seit gestern habe ich /bin/sh auf /bin/dash gesetzt, und das hat einen deutlich höheren Einfluss als OpenRC.

 *Anarcho wrote:*   

> 
> 
> Für einen schnellen Boot habe ich eine feste IP eingestellt.
> 
> 

 

Das könnte ich in der Tat auch tun - man muss daran nur denken, wenn man mal den Router wechselt.

 *Anarcho wrote:*   

> 
> 
> Auf welchen Bootzeitwert kommst du jetzt?
> 
> 

 

Ich sitze derzeit nicht vor der Kiste und kann es nicht genau stoppen - heute morgen waren es zwischen dem Druck auf "Enter" im grub und dem Erscheinen des kdm-Login-Fensters gefühlte 10-15 Sekunden.

----------

## Anarcho

Also bei mir hat die Umstellung auf dash keine nennenswerten Verbesserungen gebracht. Weder gefühlt noch gemessen.

----------

## schachti

Das ist komisch - bei mir geht's seit der Umstellung auf dash dermaßen schnell, dass ich teilweise das Gefühl habe, an einem ganz anderen Rechner zu sitzen - die Meldungen der Init-Skripte rauschen nur so vorbei...

----------

## schachti

ok, gerade nochmal getestet: ohne Placebo-Effekt sind es real 22 Sekunden bis zum kdm-Login-Screen.

----------

## Josef.95

Zur genauen Messung bietet sich auch das Paket

```
app-benchmarks/bootchart

     Available versions:  0.9-r2 {acct debug doc elibc_FreeBSD java source}

     Installed versions:  0.9-r2(00:38:48 24.02.2009)(java -acct -debug -doc -elibc_FreeBSD -source)

     Homepage:            http://www.bootchart.org/

     Description:         Performance analysis and visualization of the system boot process
```

an.

Siehe zb auch http://wolf-u.li/810/bootvorgang-visualisieren-mit-bootchart/

----------

## Anarcho

 *schachti wrote:*   

> ok, gerade nochmal getestet: ohne Placebo-Effekt sind es real 22 Sekunden bis zum kdm-Login-Screen.

 

Und war das jetzt mit oder ohne dash? Und wie sieht jetzt der Unterschied aus?

Ich verwende auch bootchart. Daher kommen meine 19s. Was am längsten braucht ist der X-Server.... Der startet glaube ich nach bereits ca. 10s. Aber bei mir ist bootchart etwas ungenau denn ich kann mich schon vorher einloggen, danach passieren aber noch Dinge im Hintergrund welche das Arbeiten bzw. das Einloggen nicht weiter stören. Daher sind es real für den Benutzer wahrscheinlich nur ca. 15s.

----------

## dirk_salewski

 *Knieper wrote:*   

> ... init-ng lahm und halb tot ...

 

"Lahm" ist sicher relativ gemeint (wobei manche Dinge ohne Frage absolut lahm sein können). Meinst Du das im Vergleich zu, sagen wir, upstart? Hast Du da vergleichbare Benchmarks?

Halb tot ist etwas übertrieben, oder nicht? Der ursprüngliche Entwickler arbeitet an einem neuen Projekt, aber in der Timeline auf der Projektwebsite sind ziemlich viele aktuelle Einträge für ein "halbtotes" Projekt.

----------

## schachti

 *Anarcho wrote:*   

> 
> 
> Und war das jetzt mit oder ohne dash? Und wie sieht jetzt der Unterschied aus?
> 
> 

 

Das war mit dash. Mit bash sind es 29 Sekunden. Ich habe auch den Eindruck, dass sich der Beschleunigungseffekt reduziert, sobald der X-Server startet (der Zeitraum zwischen dem ersten "Schwarzwerden" des Monitors und der Anzeige des kdm-Login-Fensters scheint durch die Umstellung auf dash kaum beschleunigt zu werden).

----------

## Anarcho

 *schachti wrote:*   

>  *Anarcho wrote:*   
> 
> Und war das jetzt mit oder ohne dash? Und wie sieht jetzt der Unterschied aus?
> 
>  
> ...

 

Wie auch. Da dürfte /bin/sh auch nichts mit zu tun haben. Das ist alles X bzw. Treiberinitialisierung. Da kann man nur hoffen das hier was verbessert wird.

----------

## Silkepil

Hallo,

ich muss mich hier auch mal einklinken. Nachdem ich diesen Thread verfolgt habe, habe ich auch dash installiert und den Symlink entsprechend gesetzt.

Allerdings erhalte ich jetzt beim Start die Meldung, dass net.lo nicht gestartet werden konnte aufgrund eines unexpected "(".

Scheint so, als würde das net.lo-Script nicht mit der dash funktionieren?!

Da das das einzige Problem zu sein scheint, wollte ich fragen, ob es dafür Abhilfe gibt? Hat denn niemand anderes das Problem?

Zur Info: Ich habe mein System komplett auf "~x86" und somit die jeweils aktuellsten Versionen von dash und net.lo installiert.

Grüße,

Silkepil

----------

## schachti

Ich habe das Problem nicht (oder es ist mir nicht aufgefallen).

Nur, um das als mögliche Ursache auszuschliessen: Du hast Deine /etc/conf.d/net aber schon auf die neuen Anforderungen von baselayout-2 umgestellt, oder? Also speziell bezogen auf den Punkt, Einträge der Form

```

config_eth0=( "1.2.3.4 netmask 255.255.255.0 brd 1.2.3.255" )

```

umzuschreiben in die Form

```

config_eth0="1.2.3.4 netmask 255.255.255.0 brd 1.2.3.255"

```

----------

## Anarcho

 *schachti wrote:*   

> Ich habe das Problem nicht (oder es ist mir nicht aufgefallen).
> 
> Nur, um das als mögliche Ursache auszuschliessen: Du hast Deine /etc/conf.d/net aber schon auf die neuen Anforderungen von baselayout-2 umgestellt, oder? Also speziell bezogen auf den Punkt, Einträge der Form
> 
> ```
> ...

 

Das Script hier kann helfen auf DASH Complicance zu prüfen: http://svn.debian.org/viewsvn/devscripts/trunk/scripts/checkbashisms.pl

Ich habe jetzt nochmal nachgesehen. Laut bootchartd endet die Aktivität meines gdm-greeters bei 13s. Das dürfte der Zeitpunkt sein an dem ich den Login-Screen sehe. Mit manuellem Login (Benutzername / Passwort) und laden meines Gnome-Desktops (Profil liegt auf NFS-Share) bin ich bei gesamt ca. 25 - 30 Sekunden. Das finde ich schon ganz akzeptabel.

----------

## Eulalia

 *schachti wrote:*   

> 
> 
> Nur, um das als mögliche Ursache auszuschliessen: Du hast Deine /etc/conf.d/net aber schon auf die neuen Anforderungen von baselayout-2 umgestellt, oder?

 

So einfach ist die Lösung? Das war es wirklich!

Ich muss das bei der Umstellung auf baselayout-2 überlesen haben.

Danke!

Silkepil

----------

## ChrisJumper

Ich komme jetzt auf 33 Sekunden... von vorherigen 47. Das Problem mit dem unexpected "(" habe ich noch bei den init-Skripten von mysql + mysqlmanager. Dies scheint aber zu kein Problem zu sein.

Edit:

Das /etc/init.d/mysql runscript reagiert empfindlich auf eine Änderung von /bin/sh -> /bin/bash nach /bin/dash.

Mir ist es zuerst nicht aufgefallen, weil ich mysql so selten benutze. Ich habe mich zuerst lediglich auf die Fehlermeldung beim Bootvorgang bezogen. Doch dabei vergessen das ich die Initialisierung von mysql, anschließend aus dem Bootvorgang verbannt habe.Last edited by ChrisJumper on Tue Mar 24, 2009 4:14 am; edited 1 time in total

----------

## mv

 *ChrisJumper wrote:*   

> Ich komme jetzt auf 33 Sekunden... von vorherigen 47. Das Problem mit dem unexpected "(" habe ich noch bei den init-Skripten von mysql + mysqlmanager. Dies scheint aber zu kein Problem zu sein.

  Ich denke schon, dass das ein Riesenproblem ist, sobald Du mysql benutzen willst: Die dev-db/mysql-init-scripts scheinen konzeptionell auf Arrays zu basieren. M.E. wäre da ein Bug-Report fällig. Ich schaue mir mysql-Zeugs aber prinzipiell nicht an (die erzwungene Abhängigkeit war der Grund für mich, amarok2 zu entsorgen).

----------

## avx

Hat jemand eine Idee, wie man die Geschwindigkeitsunterschiede der verschiedenen Shells am besten testen könnte, ohne ständige Reboots zu fahren?

----------

## schachti

Du kannst Dir gentoo in einer VM, zum Beispiel VirtualBox, installieren und dort testen...

----------

## Knieper

 *dirk_salewski wrote:*   

>  *Knieper wrote:*   ... init-ng lahm und halb tot ... 
> 
> "Lahm" ist sicher relativ gemeint (wobei manche Dinge ohne Frage absolut lahm sein können). Meinst Du das im Vergleich zu, sagen wir, upstart? Hast Du da vergleichbare Benchmarks?
> 
> Halb tot ist etwas übertrieben, oder nicht? Der ursprüngliche Entwickler arbeitet an einem neuen Projekt, aber in der Timeline auf der Projektwebsite sind ziemlich viele aktuelle Einträge für ein "halbtotes" Projekt.

 

1. lahm im Vergleich zu zB. minit/ninit, richtige "Benchmarks" habe ich nicht, nur alle mal auf meinem Rechner durchprobiert/-gemessen

2. das betrifft aber nur kleinere Bugfixes und minimale Änderungen, die letzte richtige Version ist über 2 Jahre alt und war noch nicht berauschend

Ich habe jetzt auch mal zu baselayout-2/openrc gewechselt und - wahnsinn - das ist fast so schnell wie der Vorgänger und nur einen Tick langsamer, bringt also bei ordentlichen Systemen nüscht.

----------

