Boot sehr verzögert

[scientific]

Hi Leute.
Ich habe gestern mit "apt update && apt upgrade" mein System auf den neuesten Stand gebracht.

Code: Alles auswählen

$ uname -r
4.7.0-1-amd64

Code: Alles auswählen

$ cat /etc/debian_version
stretch/sid

Seitdem dauert das Booten extrem lange. Im bootchart von systemd wird "firmware" mit 71 Sekunden angezeigt.
Ich habe refind installiert, das benötigt dan auch über eine Minute bis das Menü angezeigt wird. (Das war zuvor nicht so!)

Anschließend benötigt das Laden des Kernels doppelt so lange wie bisher (sonst immer 8 Sekunden, jetzt 16 oder sogar mehr).

In der Ausgabe von dmesg finde ich z.B. folgendes Zeitsprünge von jeweils 4 Sekunden:

Code: Alles auswählen

[    0.536971] ACPI: SSDT 0xFFFF88014A3CFE00 000119 (v01 PmRef  ApCst    00003000 INTL 20130927)
[    0.538658] ACPI : EC: EC started
[    4.880771] ACPI: Interpreter enabled
[    4.880805] ACPI: (supports S0 S3 S4 S5)
[    4.880807] ACPI: Using IOAPIC for interrupt routing

Code: Alles auswählen

[    5.021950] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022011] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022068] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022126] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022183] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022239] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022295] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022351] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    5.022798] ACPI: Enabled 5 GPEs in block 00 to 7F
[    5.022949] ACPI : EC: EC stopped
[    5.022996] ACPI : EC: GPE = 0x6, I/O: command/status = 0x66, data = 0x62
[    5.022998] ACPI : EC: EC started
[    9.355563] vgaarb: setting as boot device: PCI:0000:00:02.0
[    9.355567] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    9.355570] vgaarb: loaded

Immer nach "ACPI : EC: EC started.

Hat das etwas zu bedeuten? Ist hier ACPI beschädigt?

lg scientific

[Patsche]

Ich habe gestern mit "apt update && apt upgrade" mein System auf den neuesten Stand gebracht.

So bringst du dein System nicht auf den neusten Stand. Am besten verwendest du:

Code: Alles auswählen

apt update && apt full-upgrade

So werden auch alle neuen Abhängigkeiten installiert.

[whiizy]

Hi scientific,

ich kann erstmal nur mit Vergleichsmaterial dienen. Debian Sid auch hier.

Seitdem dauert das Booten extrem lange. Im bootchart von systemd wird "firmware" mit 71 Sekunden angezeigt.

"firmware" kommt bei mir in journalctl -b nicht vor, falls Du das mit "bootchart" meinst.

In der Ausgabe von dmesg finde ich z.B. folgendes Zeitsprünge von jeweils 4 Sekunden:

... sieht an dieser Stelle bei mir anders aus:

Code: Alles auswählen

[    0.340876] ACPI : EC: EC started
[    0.341505] ACPI: Interpreter enabled
[    0.341640] ACPI: (supports S0 S3 S4 S5)

Und beim zweiten Start:

Code: Alles auswählen

[    1.397190] ACPI : EC: EC stopped
[    1.397397] ACPI : EC: GPE = 0x18, I/O: command/status = 0x66, data = 0x62
[    1.397494] ACPI : EC: EC started
[    1.398381] vgaarb: setting as boot device: PCI:0000:00:02.0
 

Immer nach "ACPI : EC: EC started.
Hat das etwas zu bedeuten? Ist hier ACPI beschädigt?

Kann ich leider nicht beurteilen. Schau vielleicht zunächst nochmal, was die tools von systemd anzeigen:

Code: Alles auswählen

systemd-analyze blame
systemd-analyze critical-chain

Gruß

[dufty2]

Hi scientific,

ich kann erstmal nur mit Vergleichsmaterial dienen. Debian Sid auch hier.

scientific hat testing

Fuer testing (stretch) ist übers WE kernel 4.7 reingeflattert.
Würde an Deiner Stelle mal bei Grub unter "advanced-options" in den 4.6er booten.
Hast den 4.6 hoffentlich nicht gleich mit aufgeräumt

[scientific]

Ein Bootchart erstelle ich mit:

Code: Alles auswählen

systemd-analyze plot > bootchart.svg
eog bootchart.svg

Da wird alles vom Einschalten des Rechners bis zum Start der Graphischen Oberfläche angezeigt.

Mit systemd-analyze blame|chritical-chain werden nur die Dienste ausgegeben, also alles nach dem Laden des Kernels.

lg scientific

[whiizy]

scientific hat testing

Hätte auch unstable sein können, denn "uname -r" und "cat /etc/debian_version" sieht dort genauso aus.

[dufty2]

scientific hat testing

Hätte auch unstable sein können, denn "uname -r" und "cat /etc/debian_version" sieht dort genauso aus.

Ist richtig, würde aber auch bedeuten, scientific macht updates nur spärlich, denn unstable hat den 4.7er schon länger

[whiizy]

Ein Bootchart erstelle ich mit:

Code: Alles auswählen

systemd-analyze plot > bootchart.svg
eog bootchart.svg

Ah ok, das meintest Du. Aber auch in dieser grafischen Darstellung taucht der Begriff "firmware" bei mir nicht auf. - Ich gehe mal davon aus firmware-linux ist bei Dir installiert.

Gruß

[scientific]

Ich habe testing, und nur für manche Pakete verwende ich sid. (Unlängst war das gnome-control-center in testing kaputt, da griff ich dann auf jenes aus sid zurück, welches lt. Berichten den Fehler schon ausgebessert hatte).

Dementsprechend ist der 4.7-Kernel jetzt in Testing auch am WE gekommen. Und seitdem sind diese Probleme.

firmware-linux ist natürlich installiert.

Ich hab hier mal das bootchart.svg 39526
Hoffe das klappt so über nopaste... runterladen und mit eog öffnen.

lg scientific

[whiizy]

Ich hab hier mal das bootchart.svg 39526
Hoffe das klappt so über nopaste... runterladen und mit eog öffnen.

Einen gnome viewer eog habe ich z.B. nicht, aber SVG-Grafiken kann man auch in praktisch jedem Browser öffnen. - Aber über Deinen Link kriege ich leider nur zeilennumerierten Text.

[scientific]

Ich hab hier mal das bootchart.svg 39526
Hoffe das klappt so über nopaste... runterladen und mit eog öffnen.

Einen gnome viewer eog habe ich z.B. nicht, aber SVG-Grafiken kann man auch in praktisch jedem Browser öffnen. - Aber über Deinen Link kriege ich leider nur zeilennumerierten Text.

eog war nur ein Vorschlag

Ganz unten auf der Seite findest du einen Button "Paste als Datei herunterladen". Das machst du und speicherst es als bootchart.svg ab.

lg scientific

[whiizy]

Ganz unten auf der Seite findest du einen Button "Paste als Datei herunterladen". Das machst du und speicherst es als bootchart.svg ab.

Ja, danke, hatte mich da zwischenzeitlich auch schon durchgewurstelt. Gespeichert werden will "39526.txt" und man kann das auch unter einem freigewählten Dateinamen abspeichern. Meine mich zu erinnern, daß es alternativ auch eine Textdarstellung (die ohne SVG-Grafik auskommt) gibt, erinnere mich aber gerade nicht an das Kommando. - Egal. Was mir in Deiner Grafik auffällt, daß bei Dir zwei Stationen vorgelagert sind: firmware->loader->kernel->systemd.
Bei mir beginnt die Aufzeichnung direkt mit kernel->systemd. Was ist der Grund?

Gruß

[scientific]

Ganz unten auf der Seite findest du einen Button "Paste als Datei herunterladen". Das machst du und speicherst es als bootchart.svg ab.

Ja, danke, hatte mich da zwischenzeitlich auch schon durchgewurstelt. Gespeichert werden will "39526.txt" und man kann das auch unter einem freigewählten Dateinamen abspeichern. Meine mich zu erinnern, daß es alternativ auch eine Textdarstellung (die ohne SVG-Grafik auskommt) gibt, erinnere mich aber gerade nicht an das Kommando. - Egal. Was mir in Deiner Grafik auffällt, daß bei Dir zwei Stationen vorgelagert sind: firmware->loader->kernel->systemd.
Bei mir beginnt die Aufzeichnung direkt mit kernel->systemd. Was ist der Grund?

Gruß

Ja wenn ich das wüsste... Ich hab eine SSD im Laptop. Und wärend der 71 Sekunden Wartezeit für loader rödelt diese SSD vor sich hin (erkennbar an der LED die wie wild blinkt).

Möglicherweise eine Fehlkonfiguration in refind? Ich bin damit noch nicht sehr fix... Aber warum wird die erst seit dem neuen Kernel schlagend?

Ich verwende ein btrfs auf meiner SSD, und darauf sind einige Snapshots. Möglicherweise durchsucht refind ja auch all diese Snapshots. Das fällt mir grad ein zu dem Thema.

Kennst du dich mit der Konfiguration von refind aus?

lg scientific

[whiizy]

Möglicherweise eine Fehlkonfiguration in refind? Ich bin damit noch nicht sehr fix... Aber warum wird die erst seit dem neuen Kernel schlagend?

Ich verwende ein btrfs auf meiner SSD, und darauf sind einige Snapshots. Möglicherweise durchsucht refind ja auch all diese Snapshots. Das fällt mir grad ein zu dem Thema.

Da endet die Vergleichbarkeit wohl. Hier auf dem Laptop läuft nur ein einziges OS mit dem boot-loader grub-pc, legacy mode BIOS/UEFI und ext4 auf einer SSD genauer 32 GB eMMC. Mit refind hatte ich bisher noch nicht zu tun, bedaure.

Gruß

[smutbert]

Bei mir beginnt die Aufzeichnung direkt mit kernel->systemd. Was ist der Grund?

Das hängt zumindest von der systemd-Version ab - das Original-systemd von jessie kennt das zB noch nicht. Darüber hinaus, denke ich mir, muss das BIOS bzw. UEFI ja irgendetwas (richtig) machen, damit systemd weiß, wie lange das BIOS benötigt hat.

Jedenfalls muss ich bei solchen Problemen vor allem an BIOS/Firmware denken. Einer meine Systeme mag zB gewisse USB-Sticks nicht und braucht immer recht lange zum Booten, wenn so ein Stick einmal beim Booten dringesteckt ist.
Helfen tut dagegen bei mir soweit ich es bis jetzt mitbekommen habe nur ein Reset aller BIOS/UEFI-Einstellungen inklusive UEFI-Booteinträge. In Foren habe ich bei ähnlichen Problemen auch schon gelesen, dass es hilft den Computer von der Stromversorgung zu trennen und die CMOS-Batterie eine Zeit lang herauszunehmen.

Allerdings kommt das als Fehlerursache nur in Frage, wenn das Problem nun auch mit dem alten Kernel auftritt.

[whiizy]

Bei mir beginnt die Aufzeichnung direkt mit kernel->systemd. Was ist der Grund?

Das hängt zumindest von der systemd-Version ab - das Original-systemd von jessie kennt das zB noch nicht.

Hallo smutbert,

also ich habe mir gerade den systemd-analyze plot von einer reinen Jessie Workstation angeschaut, da beginnt der plot auch mit kernel->systemd. Wie kommst Du darauf?

Gruß

[smutbert]

Weil bei mir die Punkte firmware und loader erst mit einem systemd-Update aus den jessie-backports aufgetaucht sind.

[scientific]

Bei mir beginnt die Aufzeichnung direkt mit kernel->systemd. Was ist der Grund?

Das hängt zumindest von der systemd-Version ab - das Original-systemd von jessie kennt das zB noch nicht. Darüber hinaus, denke ich mir, muss das BIOS bzw. UEFI ja irgendetwas (richtig) machen, damit systemd weiß, wie lange das BIOS benötigt hat.

Jedenfalls muss ich bei solchen Problemen vor allem an BIOS/Firmware denken. Einer meine Systeme mag zB gewisse USB-Sticks nicht und braucht immer recht lange zum Booten, wenn so ein Stick einmal beim Booten dringesteckt ist.
Helfen tut dagegen bei mir soweit ich es bis jetzt mitbekommen habe nur ein Reset aller BIOS/UEFI-Einstellungen inklusive UEFI-Booteinträge. In Foren habe ich bei ähnlichen Problemen auch schon gelesen, dass es hilft den Computer von der Stromversorgung zu trennen und die CMOS-Batterie eine Zeit lang herauszunehmen.

Allerdings kommt das als Fehlerursache nur in Frage, wenn das Problem nun auch mit dem alten Kernel auftritt.

Das kann ich leider erst wieder testen, wenn ich wieder am Gerät bin.
Momentan greif ich nur per ssh drauf zu. Und wenn ich da jetzt reboote, und dann kommt der Rechner nicht mehr hoch... Also später mehr Infos, ob der alte Kernel noch normal bootet.

lg scientific

[whiizy]

@smutbert

Sender/Empfänger-Problem Du meintest demnach wohl "firmware->loader->kernel->systemd" kennt "das Original-systemd von jessie" noch nicht. Dem stimme ich zu und sagte es ja auch bereits. Alles klar!.

Gruß

[smutbert]

Genau das meinte ich.

[scientific]

War übrigens ein refind-config Problem.

Dennoch bleiben 8sek für das Laden des Kernls konstant... Trotz ssd.