(gelöst) jessie, Boot-Verzögerung

[guennid]

Ich habe hier ein jessie mit systemd. Ich möchte einen Eigenbaukern 4.2.5 benutzen. Der funktioniert soweit, aber beim Booten hängt der Vorgang für längere Zeit bei einer Meldung deren verkürzter Inhalt lautet: "sys-subsystem-net-devices-wlan0.device". Nach Abschluss des Bootvorgangs ist das wlan aktiv. Wo und wie ich mit systemctl suchen soll, weiß ich nicht. Bei Verwendung des Standard-Kerns 4.2.0 hängt das System nicht. Bei arch [1] und einem ähnlichen Phänomen habe ich das hier gefunden:

Code: Alles auswählen

systemctl disable netcfg

hat aber nach Neustart keine Änderung bewirkt. Auch dann war das wlan nach dem Booten aktiv.

Mein Englisch ist nicht besonders, Info auf Deutsch habe ich keine gefunden.

[1] http://blog.binchen.org/posts/why-some- ... -work.html

Grüße, Günther

[edit] wlan wird realisiert über einen USB-Stick.

Code: Alles auswählen

# lsusb
Bus 002 Device 005: ID 7392:7622 Edimax Technology Co., Ltd

[tomi89]

In /etc/default/networking eintragen:

EXCLUDE_INTERFACES=wlan0

Falls es das ist was du suchst.

[guennid]

Naja, da ich ja am System nichts geändert habe außer der Verwendung eines eigenen Kernels (Sourcen von kernel.org, keine initrd, Ausgangsconfig war nicht der 4.2.0 jessie-kernel), vermute ich, dass die Verzögerung durch meinen Kernel verursacht wird. Ergo suche ich eigentlich das/die Kernel-Module, die ich einpflegen/verändern müsste.

Ob die Verzögerung andere Ursachen haben könnte, müssten Leute beurteilen, die davon mehr verstehen als ich.

die vorgeschlagene Veränderung in /etc/default networking hat die Verzögerung nicht beseitigt, ebenso wenig wie

Code: Alles auswählen

CONFIGURE_INTERFACES=no

Wlan ist trotzdem in beiden Fällen am Ende des Bootprozesses aktiv. Ich denke systemd ist mitbeteiligt. Will sagen, falls es eine andere Lösung als die der kernel-config gibt, müsste wohl an der systemd-Konfiguration was geändert werden.

Grüße, Günther

[MSfree]

dmesg liefert ein Log über die Systeminitialisierung mit Zeitangabe. Eventuell findest du dort ein größeres Zeitintervall zwischen zwei Zeilen.

[smutbert]

Code: Alles auswählen

$ systemd-analyze blame

listet die Dienste, der Reihe nach auf, beginnend mit denen, die am längsten zum Starten gebraucht haben. Noch interessanter wäre die Ausgabe von

Code: Alles auswählen

$ systemctl --failed

Wie konfigurierst du das WLAN (und so vorhanden deine anderen Netzwerkadapter) eigentlich? Dafür gibt es ja angefangen mit Tools wie network-manager, wicd, connman, des weiteren der althergebrachten Variante mit »/etc/network/interfaces« und dem in systemd eingebauten "systemd-networkd" so einige Möglichkeiten.

[mat6937]

Wlan ist trotzdem in beiden Fällen am Ende des Bootprozesses aktiv. ..., falls es eine andere Lösung als die ...

Du könntest z. B. auch den Treiber für das WLAN-Interface, blacklisten.

[guennid]

bei systemctl --failed für Kern 4.2.5 gab es keine Ausgabe. Deswegen habe ich das bei 4.2.0 gar nicht mehr laufen lassen. Interessant erschien mir aber systemctl --all.
Hier zunächst mal die systemd-Ausgaben
systemd-analyze blame 4.2.0
systemd-analyze blame 4.2.5
sytemctl --all 4.2.0
systemctl --all 4.2.5

Hmmm, vielleicht bin ich auch völlig auf der falschen Spur:
Die eingangs von mir kekürzt gepostete Meldung, wlan betreffend, wechselt beim Booten dauernd mit einer "dev-disk-by\x2duuid..." betreffenden ab (siehe systemclt --all-Meldungen bei 4.2.5). Und die betrifft, wenn ich recht sehe, die root-Partition der (einzigen) Festplatte. Hält das den Bootvorgang auf? Nur beim 4.2.5 Eigenbaukern erscheint ein fsck an 2. Stelle von systemd-analyze blame.

Hoffentlich habe ich alles richtig zugeordnet gepostet. Für mich alles sehr verwirrend.

Grüße, Günther

[TomL]

Ich habe hier ein jessie mit systemd. Ich möchte einen Eigenbaukern 4.2.5 benutzen. Der funktioniert soweit, aber beim Booten hängt der Vorgang für längere Zeit....

Bei mir ist es das gleiche, wenn kein Patchkabel angeschlossen ist. Da hängt er nicht beim WLAN-Connect, sondern beim Versuch, sich via ETH0 zu verbinden.... und irgendwann ist die WLAN-Verbindung dann endlich aktiv. Das habe ich abgeschaltet, mit der Reduzierung des Timeouts von 60 auf 10 Sekunden:

Code: Alles auswählen

nano /etc/dhcp/dhclient.conf
    timeout 10

Alternativ -da überlege ich noch- gibts bei mir noch die Möglichkeit, eth0 nicht auf "auto" zu setzen, weil ich die Kabelverbindung eher selten brauche.
Vielleicht hilft das ja. Man muss sich dann nur monate später wieder dran erinneren... ... wenn mans mal braucht und nicht weiss, warum das jetzt gerade nicht funktioniert....

[smutbert]

Aufs erste Hinschauen stört mich

Code: Alles auswählen

dev-disk-by\x2duuid-330d966b\x2d5fb5\x2d4eda\x2da272\x2d370947c99ab7.swap   loaded    inactive dead      /dev/disk/by-uuid/330d966b-5fb5-4eda-a272-370947c99ab7

das beim Kernel 4.2.0 so aussieht

Code: Alles auswählen

dev-disk-by\x2duuid-330d966b\x2d5fb5\x2d4eda\x2da272\x2d370947c99ab7.swap   loaded    active   active    /dev/disk/by-uuid/330d966b-5fb5-4eda-a272-370947c99ab7

Hast du beim selbst gebauten Kernel vielleicht die Unterstützung für swap weggelassen?
Falls du in der fstab Einträge für swap hast, kannst du sie eigentlich entfernen, denn swap-Partitionen sollten automatisch verwendet werden.

[guennid]

Falls du CONFIG_SWAP meinst: Das ist einkompiliert.

Grüße, Günther

[smutbert]

Ja, das habe ich mir jetzt im Nachhinein auch gedacht. Da fehlt vermutlich irgendetwas anderes bei der Kernelkonfiguration, denn es betrifft genauso den WLAN-Controller und womöglich noch mehr Geräte, die nichts miteinander zu tun haben

Code: Alles auswählen

sys-subsystem-net-devices-wlan0.device                                      loaded    inactive dead      sys-subsystem-net-devices-wlan0.device

vs

Code: Alles auswählen

sys-subsystem-net-devices-wlan0.device                                                   loaded    active   plugged   RTL8192S_WLAN_Adapter

aber ich habe momentan keine Idee, was die Ursache sein könnte und die Suche danach hat etwas von der Suche nach der Nadel im Heuhaufen...

Würde ich mir selbst einen Kernel kompilieren wollen, dann würde ich als Basis die Konfiguration eines Debiankernels nehmen, das Anpassen was ich ändern will und wenn es dann nicht funktioniert sozusagen die Unterschiede der Kernelkonfiguration nacheinander durchgehen, aber wenn du deine eigene Kernelkonfiguration sozusagen von 0 aus aufgebaut hast, dann dürften die Unterschiede so zahlreich sein, dass das keinen Sinn hat.

[guennid]

Ursprünglich (vor Jahren) ging's mir darum, einen kleinen Kernel zu bekommen. Das habe ich immer fortgeschrieben und hat bisher auch funktioniert. Tut's ja auch jetzt - bis auf diesen vertrackten timeout. Aber du hast insofern recht, dass die Untersuchung meiner eigenen config wohl der Suche nach der sprichwörtlichen Nadel ähneln würde. Ok, wenn man die initrd los wird, bringt das ja auch schon mal was und eine standard-config nur daraufhin umzubiegen, traue ich mir zu.

Was ist mit diesem fsck von systemd? Der dürfte Zeit in Anspruch nehmen.
Was hältst du von TomLs Vorschlag?

Nachtrag: die Netzkonfiguration erfolgt über /etc/network/interfaces. DHCP wird nicht benutzt.

[smutbert]

Das Netzwerk braucht nicht auffällig lange zum Starten, daher würde der DHCP Timeout nichts bringen, schon gar nicht, wenn du DHCP gar nicht verwendest...

In einer Mailingliste [1] bin ich auf eine Konfigurationsoption gestoßen, die offensichtlich solche Probleme verursachen kann und die beim Debiankernel aktiviert ist: CONFIG_FHANDLE=y

[1] http://lists.freedesktop.org/archives/s ... 34156.html

[guennid]

Das ist in der Tat ein Unterschied in den hier vorliegenden configs. Mal schauen. Z.Z. wird gerade ein h264-Video gerippt. Wird noch ein Weilchen dauern, bis ich das testen kann.

Apropos: RTL8192S gibt's weder in der 4.2.0 noch in der 4.2.5 config, wohl aber rtl8192se. Nach Auskunft von make menuconfig ist das ein PCIe-Gerät. Hab' ich sowas überhaupt? Auch da muss ich warten, bis ich den 4.2.0 wieder starten kann. lspci mit dem anderen Kern verrät's mir nicht (kernel driver in use).

[MSfree]

Was ist mit diesem fsck von systemd? Der dürfte Zeit in Anspruch nehmen.

Wenn das Dateisystem intakt ist, beschränkt sich die Dateisystemprüfung auf das Lesen eines einzigen Byes, welches bedeutet, ob das Dateisystem sauber ausgehängt wurde. Das dauert nicht lange, innerhalb einer Sekunde sind alle Parttitionen getestet (wenn du nicht gerade 50 Partitionen auf 17 Platten verteilt hast). Das darf eigentlich nicht dein Problem sein.

Ein unsauber ausgehängtes Dateisystem, was durch mutwilliges ausschalten des Rechners, Stromausfall oder Kernelpanic entsteht, braucht natürlich länger, ist aber nicht der Normalfall.

[guennid]

Tja, Herr smutbert,

da muss ich wohl wieder mal kniefällig werden! Verzögerung ist weg! Ich habe außer fhandle zwar noch ein paar andere Änderungen vorgenommen, die mir aufgrund von lspci -nnk mit dem 4.2.0er backports-Kern sinnvoll erschienen, aber fhandle wird's wohl gewesen sein !

Grüße, Günther

[smutbert]

Das war nur ein Glückstreffer, aber freut mich, dass es gelöst ist.

[guennid]

fhandle war's definitv: Neugierig, wie ich bin, habe ich den Kern nochmal kompiliert - ohne fhandle. Verzögerung war wieder da.