[gelöst] Bootvorgang einsehen

[spice1001]

Hallo,
wenn ich meinen Rechner boote, bleibt er irgendwann für ca. 10-15 Sekunden stehen, ehe der Vorgang zügig weiter läuft. Ich würde gern sehen wollen, was genau passieren soll an der Stelle, wo er stecken bleibt. Bei Mandriva konnte man das unter /var/log/messages nachschauen. Die Datei gibt es zwar jetzt auch, ist aber keine Textdatei. Finde ich das Gesuchte überhaupt dort und wenn ja, wie kann man die Datei öffnen. Wenn ich es mit kwrite versuche, wir mir nichts angezeigt

Gruß
harald

[peterdit]

Hallo Harald,

versuchs doch mal als root.

Gruss
Peter

[unklar]

Hallo Harald,
das Problem kenne ich. Neben dem Tipp von peterdit kannst Du die Kernelzeile in der menu.lst von splash=quiet in splash=verbose ändern.

title Mageia2
kernel (hd0,6)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=23936e83-d30f-40f9-a136-57059cc5190a resume=UUID=016d8cde-618e-4236-9395-1a3b36fe3d1a splash=verbose vga=788

Das bewirkt die Anzeige der Bootmeldungen beim Start.
Das kurzfristige "Stehen-Bleiben" des System verursachte bei mir eine nicht mehr vorhandene UUID einer Swap-Partition.

[doktor5000]

Um die Verzögerung herauszufinden, das Paket systemd-tools installieren und mittels

Code: Alles auswählen

systemd-analyze plot > plot.svg

das Analogon zum früheren bootchart erzeugen und auswerten oder ggf. hier anhängen. Zum Vergleich oder besseren Ablesbarkeit die Ausgabe von

Code: Alles auswählen

systemd-analyze blame

mit heranziehen.

Ansonsten einfach während des Bootvorgangs die Esc-Taste drücken, dann siehst du was gerade passiert.

[hwm]

Oder während des Bootens die ESC Taste drücken, dann sieht man eventuelle Fehlermeldungen

[doktor5000]

Ansonsten einfach während des Bootvorgangs die Esc-Taste drücken, dann siehst du was gerade passiert.

[spice1001]

Oder während des Bootens die ESC Taste drücken, dann sieht man eventuelle Fehlermeldungen

genau, dann sehe ich, dass es eine Verzögerung gibt, aber nicht, weswegen. Das hab ich ja schon gemacht, sonst wüsste ich nicht, d a s s es irgendwo hängt

danke für die Tiipps, werd morgen schaun.

[spice1001]

Um die Verzögerung herauszufinden, das Paket systemd-tools installieren und mittels

Code: Alles auswählen

systemd-analyze plot > plot.svg

das Analogon zum früheren bootchart erzeugen und auswerten oder ggf. hier anhängen. Zum Vergleich oder besseren Ablesbarkeit die Ausgabe von

Code: Alles auswählen

systemd-analyze blame

mit heranziehen.

Ansonsten einfach während des Bootvorgangs die Esc-Taste drücken, dann siehst du was gerade passiert.

Das Problem ist, wenn ich den Bootvorgang auf der Konsole beobachte, sehe ich den "Hänger", wenn es aber weiter geht, dann passiert alles so schnell, dass ich nciht mitlesen kann, was der nächste Schritt war. Hier die Ausgabe von systemd-tools:

Code: Alles auswählen

[root@localhost harald]# systemd-analyze plot > plot.svg
[root@localhost harald]# systemd-analyze blame
 17369ms mandriva-everytime.service
 11629ms network-up.service
  4419ms udev-settle.service
  3321ms bluetooth.service
  3259ms fedora-readonly.service
  2453ms avahi-daemon.service
  2429ms fedora-loadmodules.service
  2319ms udev-trigger.service
  2131ms systemd-logind.service
  2051ms polkitd.service
  1962ms udisksd.service
  1841ms sys-kernel-security.mount
  1801ms upowerd.service
  1740ms dev-mqueue.mount
  1719ms mandriva-kmsg-loglevel.service
  1590ms acpid.service
  1570ms rsyslog.service
  1569ms partmon.service
  1569ms ip6tables.service
  1560ms dev-hugepages.mount
  1559ms vboxdrv.service
  1540ms iptables.service
  1519ms msec.service
  1480ms irqbalance.service
  1459ms shorewall.service
  1450ms sys-kernel-debug.mount
  1430ms nscd.service
  1419ms resolvconf.service
  1300ms sensord.service
  1251ms udev.service
  1230ms dbus.service
  1059ms systemd-sysctl.service
   989ms mandriva-clean-var-run-lock.service
   989ms systemd-modules-load.service
   949ms systemd-user-sessions.service
   921ms systemd-readahead-replay.service
   899ms systemd-vconsole-setup.service
   889ms remount-rootfs.service
   822ms systemd-readahead-collect.service
   609ms mandriva-save-dmesg.service
   599ms mandriva-boot-links.service
   499ms systemd-remount-api-vfs.service
   499ms systemd-tmpfiles-setup.service
   339ms vboxweb-service.service
   318ms vboxballoonctrl-service.service
   266ms home.mount
   239ms fedora-wait-storage.service
   160ms hddtemp.service
   109ms rc-local.service
   109ms console-kit-log-system-start.service
   109ms udisks2.service
    99ms fedora-storage-init.service
    99ms fedora-storage-init-late.service
    87ms console-kit-daemon.service
    42ms mandi.service
     5ms rtkit-daemon.service
     1ms proc-bus-usb.mount
[root@localhost harald]#


[doktor5000]

Ok, zum Vergleich mal meins, mit WLAN was beim Starten verbunden ist (und System mit einer SSD) mit allen Diensten, die länger als eine Sekunde brauchen, der Rest ist eher irrelevant:

Code: Alles auswählen

28136ms network-up.service
  4439ms mandriva-everytime.service
  3942ms ntpdate.service
  1194ms udev-settle.service

Der mandriva-everytime Dienst beinhaltet etwa den Aufruf von harddrake2 während des Bootens, taucht bei manchen während des Booten öfters auf als Meldung "Reconfigure the system on administrator request" und was er macht, steht in /etc/init.d/mandrake_everytime
Zur Not schaltest du den Dienst für den Systemstart einfach mal testhalber ab mittels

Code: Alles auswählen

systemctl disable mandriva-everytime.service

und bootest nochmal.

[spice1001]

systemctl disable mandriva-everytime.service

also das hat keine Veränderung bewirkt. Auf jeden Fall folgt nach der Meldung

Code: Alles auswählen

started Legacy usb proc File system

das von Dir beschriebene

Code: Alles auswählen

Reconfigure the system on administrator request

Also ich empfinde es nicht als richtiges Problem, hab mich nur gewundert, weil ich einen so langen "Boxenstop" weder von Mandriva noch von Mageia 1 gwohnt bin und wollte wissen, woran es liegt.
So wie es sich liest, ist ja der Vorgang .....legacy USB proc..... gestartet. Also ist die Pause der folgenden Aktion "Reconfigure the system...... zuzuordnen oder seh ich das falsch

[doktor5000]

So wie es sich liest, ist ja der Vorgang .....legacy USB proc..... gestartet. Also ist die Pause der folgenden Aktion "Reconfigure the system...... zuzuordnen oder seh ich das falsch

Jepp, letzteres. Habs mir gerade angeschaut, und ja es lässt sich nicht wirklich abschalten ...
Wenn man nochmal genauer hinschaut:

[doktor5000@Mageia2 ~]$ systemctl status mandriva-everytime.service
mandriva-everytime.service - Reconfigure the system on administrator request
Loaded: loaded (/lib/systemd/system/mandriva-everytime.service; static)
Active: active (exited) since Mon, 16 Jul 2012 20:50:26 +0200; 1 day and 1h ago
Main PID: 616 (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/mandriva-everytime.service

und auf die Ausgabe von

Code: Alles auswählen

systemctl list-unit-files --type=service

schaut sieht man dass es ein statischer Bestandteil ist, und sich nicht mehr so ohne weiteres abschalten lässt. Gefällt mir ehrlich gesagt pauschal erstmal gar nicht

[spice1001]

das bedeutet, man muss damit leben?
Die Frage ist, wieso ist bei anderen diese Boot-Pause nicht existent

[doktor5000]

Gute Frage, weil jeder eine andere Hardware-Konfiguration und ein anderes BIOS und sowas hat?

Ist das ein Upgrade oder eine Neuinstallation von Mageia 2?

[lula]

Hallo,

mich hat diese Pause bzw. der lange Start auch etwas genervt und habe mal ein wenig recherchiert. Dabei bin ich auf diesen Bugreport gestoßen. Dort wird vorgeschlagen in /etc/sysconfig/system folgende Einträge zu ergänzen:

Code: Alles auswählen

DKMS_ONBOOT=no
HARDDRAKE_ONBOOT=no

Dabei wird allerdings - wenn ich das richtig interpretiere - dkms und die Hardware-Erkennung beim booten abgeschaltet. Ich habe das mal probiert und die Zeit für mandriva-everytime.service fiel bei mir von ähnlichen Werten wie bei spice1001 auf jetzt 499ms.

Grüße,
Lutz

[man-draker]

Euch ist schon klar, dass systemd verschiedene Services parallel startet, so dass eine lange Laufzeit allein noch keine Aussagekraft hat? Es bleibt erforderlich, sich in der Bootchart anzusehen, was das System in der Zeit noch getrieben hat.

[Pitti]

Bei Mandriva konnte man das unter /var/log/messages nachschauen. Die Datei gibt es zwar jetzt auch, ist aber keine Textdatei. Finde ich das Gesuchte überhaupt dort und wenn ja, wie kann man die Datei öffnen. Wenn ich es mit kwrite versuche, wir mir nichts angezeigt

Bezugnehmend auf den Ausgangsthread: Abgesehen davon, dass die Dateien unter Angabe von cat <Dateiname> in der Konsole betrachtet werden können (notwendige Berechtigung vorausgesetzt), wer hindert Dich daran, beispielsweise ein Tool, wie ksystemlog zu installieren? Nach der Installation befindet sich die Programmverknüpfung unter "Werkzeuge" im K-Menü (Ich nehme an, Du nutzt KDE). Nach Abfrage des Root-Passwortes kannst Du dort jede beliebige log-Datei komfortabel betrachten. Neben der Vorauswahl lassen sich selbstverständlich auch Änderungen vornehmen. Ein Blick in das mitinstallierte KDE-Handbuch sollte dazu genügen.

[doktor5000]

Komfortabel suchen in den den wichtigsten System-Logs kann man auch im MCC -> System -> Betrachten und Durchsuchen von System-Protokollen

Und ich hatte ja schon geschrieben, dass man beides zu Rate ziehen muss, die alleinige Auflistung nach den Zeiten, die die Dienste brauchen ist ohne Kontext für sich gesehen fast nutzlos. Das hab ich eigentlich nur der Vollständigkeit halber mit dazugepackt.

[spice1001]

Euch ist schon klar, dass systemd verschiedene Services parallel startet, so dass eine lange Laufzeit allein noch keine Aussagekraft hat? Es bleibt erforderlich, sich in der Bootchart anzusehen, was das System in der Zeit noch getrieben hat.

Ehrlich gesagt, hab ich nicht gefunden, wo genau der Bootvorgang dokumentiert ist. /var/log/messages zeigt andere Meldungen

[spice1001]

Bei Mandriva konnte man das unter /var/log/messages nachschauen. Die Datei gibt es zwar jetzt auch, ist aber keine Textdatei. Finde ich das Gesuchte überhaupt dort und wenn ja, wie kann man die Datei öffnen. Wenn ich es mit kwrite versuche, wir mir nichts angezeigt

Bezugnehmend auf den Ausgangsthread: Abgesehen davon, dass die Dateien unter Angabe von cat <Dateiname> in der Konsole betrachtet werden können (notwendige Berechtigung vorausgesetzt), wer hindert Dich daran, beispielsweise ein Tool, wie ksystemlog zu installieren? Nach der Installation befindet sich die Programmverknüpfung unter "Werkzeuge" im K-Menü (Ich nehme an, Du nutzt KDE). Nach Abfrage des Root-Passwortes kannst Du dort jede beliebige log-Datei komfortabel betrachten. Neben der Vorauswahl lassen sich selbstverständlich auch Änderungen vornehmen. Ein Blick in das mitinstallierte KDE-Handbuch sollte dazu genügen.

das hab ich gemacht, danke für den Tipp. Ich muss mich nur da erst mal rein vertiefen.

[man-draker]

Ehrlich gesagt, hab ich nicht gefunden, wo genau der Bootvorgang dokumentiert ist. /var/log/messages zeigt andere Meldungen

Ich schlage vor, dass du dir diese zwei Artikel zu Gemüte führst, dann dürftest du klarer sehen:
http://www.heise.de/open/artikel/Das-Init-System-Systemd-Teil-1-1563259.html
http://www.heise.de/open/artikel/Das-Init-System-Systemd-Teil-2-1563461.html

[doktor5000]

Pffff - die Essenz dessen, was dort drinsteht, hab ich doch bereits gepostet. Zumindest das relevante, was das Monitoring des Bootvorgangs angeht. Mehr als posten, und dann nochmal drauf hinweisen ist nicht drin. Da kann ich meine Zeit auch sinnvoller verwenden, ernsthaft ...

[spice1001]

Pffff - die Essenz dessen, was dort drinsteht, hab ich doch bereits gepostet. Zumindest das relevante, was das Monitoring des Bootvorgangs angeht. Mehr als posten, und dann nochmal drauf hinweisen ist nicht drin. Da kann ich meine Zeit auch sinnvoller verwenden, ernsthaft ...

@doktor5000
es tut mir leid, ich hab nicht ignoriert, was Du geschrieben hast. Dein Posting hat mich nicht wirklich schlauer gemacht, ohne jetzt beleidigend sein zu wollen. Aber irgendwie konnte ich mich da nicht so richtig rein denken. Die Links von man-draker waren da wirklich hilfreich, so konnte ich in Ruhe mehr über die Zusammenhänge erfahren. Vielleicht hast Du ja auch Wissen voraus gesetzt, das nicht wirklich vorhanden war. Ich weiß, Du meinst es wirklich gut und willst helfen. Leider hab ich es auf die Art nicht kapiert. Sorry

[doktor5000]

Du hättest eigentlich bloß das erzeugte SVG-Bild und die Ausgabe der Zeiten hier posten müssen, dann hätte man es analysieren können, ohne dass du dich da groß reindenken musst. Die beiden Befehle waren ja quasi schon "mundfertig".

[spice1001]

Du hättest eigentlich bloß das erzeugte SVG-Bild und die Ausgabe der Zeiten hier posten müssen, dann hätte man es analysieren können, ohne dass du dich da groß reindenken musst. Die beiden Befehle waren ja quasi schon "mundfertig".

also entweder ich hab da was falsch verstanden oder Du etwas überlesen, ich habe doch die Ausgabe der beiden Befehle gepostet. Ich meine diese beiden:

Code: Alles auswählen

systemd-analyze plot > plot.svg

Code: Alles auswählen

systemd-analyze blame

bei ersterem Befehl gibt es keine Ausgabe, das ist doch auf meiner Antwort zu sehen. Oder meintest Du etwas anderes?

[doktor5000]

Du hättest eigentlich bloß das erzeugte SVG-Bild und die Ausgabe der Zeiten hier posten müsse

also entweder ich hab da was falsch verstanden

Code: Alles auswählen

systemd-analyze plot > plot.svg

bei ersterem Befehl gibt es keine Ausgabe, das ist doch auf meiner Antwort zu sehen. Oder meintest Du etwas anderes?

Ja, die erzeugte Datei (Die Ausgabe des Befehles systemd-analyze plot wird per Ausgabeumleitung in die Datei plot.svg geschrieben) plot.svg hier hochladen, wie schon erwähnt.