[wiregate] Booten benötigt manuelle Auswahl nach DIY Kernel Update

[cava]

Guten Morgen,

seit dem Update auf Kernel 3.5.1 bootet das Wiregate nicht mehr selbständig. Wählt man hingegen den 1. Bootloader-Eintrag manuell aus, fährt es hoch und es scheint alles korrekt zu funktionieren. Ich bitte den Hersteller freundlicherweise um kurze Prüfung, ob mehr schief gegangen ist, oder nur eine Eintrag in einer Config-Datei nicht passt. VPN ist aktiv, Wiregate 133.

Gruß
Werner

[StefanW]

Werner,

der "automatische" Reboot funktioniert nicht? Welchen Reboot soll das Wiregate automatisch machen?

Du solltest auch angeben, dass Du das Kernel-Update von Hand selbst gemacht hast, das ist eine ziemlich wichtige Info.

Stefan

[cava]

Werner,

der "automatische" Reboot funktioniert nicht? Welchen Reboot soll das Wiregate automatisch machen?

Du solltest auch angeben, dass Du das Kernel-Update von Hand selbst gemacht hast, das ist eine ziemlich wichtige Info.

Stefan

Wie bereits im falschen Thread beschrieben habe ich den von Makki geposteten Befehl zum Update des Kernel manuell als root ausgeführt. Beim anschließenden Reboot war das Gerät im Netzwerk nicht mehr erreichbar. Ich habe es dann aus dem Serverschrank geholt und an einen Monitor und Tastatur angeschlossen und habe versucht die einzelnen Booteinträge auszuführen. Nach einiger Zeit hat es dann auch gebootet. Zurück im Serverschrank ist wieder nichts passiert. Also Tastatur und Monitor hingeschleppt und geschaut was los ist. Am Monitor war nur ein "-"-Zeichen zu sehen. Also habe ich neu gestartet und den 1. Eintrag ausgewählt. Das Wiregate ist wieder hochgefahren und funktioniert wieder. Sobald ich aber reboote wird es wieder nicht hochfahren.

Bisher hatte ich aber noch nie als root Einstellungen am Wiregate geändert oder Software installiert. Lediglich vor einem knappen Jahr wollte ich IPv6 aktivieren, habe die ein Zeile, die ich in der Konfiguration aufgenommen hatte aber anschließend wieder gelöscht, weil das Wiregate nicht mehr im Netz erreichbar war. D.h. mein Wiregate ist genau in dem Zustand der Auslieferung + den Patches, die seither von Euch herausgegeben wurden.

Logfiles sind bei Bedarf alle über VPN einsehbar. Sollte für die Fehlerbehebung Kosten anfallen bitte ich im Vorfeld um einen Kostenvoranschlag.

Was mir noch aufgefallen ist, ist folgende Fehlermeldung, die aber nichts mit dem Kernel zu tun hat, da sie schon vor dem Update aufgetreten ist:
Feb 3 06:31:22 wiregate133 monit[8148]: 'lighttpd' failed to start

Gruß
Werner

[StefanW]

Ich habe es dann aus dem Serverschrank geholt und an einen Monitor und Tastatur angeschlossen und habe versucht die einzelnen Booteinträge auszuführen. Nach einiger Zeit hat es dann auch gebootet.

Also geht es nicht um einen "automatischen Reboot" der nicht zu funktionieren "scheint", sondern darum, dass das WireGate beim Booten einer manuellen Auswahl bedarf.

Edit: Habe den Threadtitel nun entsprechend abgeändert.

D.h. mein Wiregate ist genau in dem Zustand der Auslieferung + den Patches, die seither von Euch herausgegeben wurden.

Welcher PL ist denn installiert?

Was mir noch aufgefallen ist...:
Feb 3 06:31:22 wiregate133 monit[8148]: 'lighttpd' failed to start

Danke, ein interessanter Hinweis. Kommt manchmal vor, wenn es ein Apache auf das System geschafft hat und vor dem lighty startet. Werden wir uns ebenfalls ansehen.

Stefan

[cava]

welcher pl ist denn installiert?

pl34.

[cava]

Also geht es nicht um einen "automatischen Reboot" der nicht zu funktionieren "scheint", sondern darum, dass das WireGate beim Booten einer manuellen Auswahl bedarf.

Eigentlich wird es immer dubioser. Ich habe nun noch ein paar Versuche mit angeschlossenem Monitor und ohne Tastatur gemacht, um zu sehen, was passiert. Das Wiregate ist bis zu folgender Stelle gekommen und hat dann noch einmal selbständig rebooted:
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]

Anschließend ist es durchgelaufen bis zur Anmeldemaske und war im Netzwerk.
Beim nächsten Versuch hab ich den Monitor abgeklemmt und eine zeitlang gewartet. Dann habe ich versucht das WG zu pingen, allerdings ohne Erfolg. Nach Anschließend des Monitors war wieder der Bildschirm mit dem "-"-Zeichen zu sehen.

Beim dritten Versuch hab ich den Monitor wieder angeschlossen. Wie beim ersten Mal hat er bei der PARPORT-Stelle nochmal gebootet bis er auf der Anmeldemaske war.

Beim vierten Mal habe ich mit angeschlossenem Monitor und Dauerping gebootet -> auch hier ist er bis zur Anmeldemaske gekommen und war im Netz.

Der fünte Versuch ohne Monitor war erfolglos, der sechste mit Monitor war wieder erfolgreich.

Wenn es hängt, dann immer an der Stelle mit dem "-"-Zeichen, kurz bevor es normalerweise piepst und die Anmeldemaske zeigt.

Ich kann mir ehrlich gesagt nicht erklären, wie man ein Kernel-Upgrade so falsch machen kann, dass man nur noch mit Monitor booten kann.

[cava]

Ich hab noch etwas recherchiert zum Thema "Booten ohne Monitor". Es gibt eine Option "nomodeset" für Grub, die das Problem beheben sollte. Ich will jetzt aber erstmal selber nichts eintragen.

Was mich allerdings wundert, dass viele andere WG-User mit dem neuen Kernel das Problem scheinbar nicht haben. Ihr schreibt ja, dass die neuen Geräte bereits mit dem neuen Kernel ausgeliefert werden. Oder betreiben alle anderen das WG mit Monitor?

[makki]

Derartige Phänomene wären nicht bekannt und natürlich muss kein Monitor angesteckt sein.

Ein kurzer Blick genügte nach dem Hinweis jedoch: IPv6 ist aktiviert und damit interessiert mich das ehrlichgesagt solange nicht mehr: Betrieb mit IPv6 ist *absichtlich* deaktiviert und nicht nur unsupported sondern NO-GO
Damit darf man sich ja gerne in der Testumgebung spielen, produktiv verwendbar ist das aber nicht, schon gleich garnicht im KNX-Umfeld.

Das der lighty nicht startet, liegt auch daran.. Sorry: wieder abschalten oder alleine testen, was damit alles kaputt ist;
im Orginal:

/etc/modprobe.d/00wiregate:alias net-pf-10 [B]off[/B]

Diskussionspotential über IPv6 in diesem Kontext: 0,0

Makki

[cava]

Ein kurzer Blick genügte nach dem Hinweis jedoch: IPv6 ist aktiviert und damit interessiert mich das ehrlichgesagt solange nicht mehr:

Das ist ehrlich gesagt interessant, denn wissentlich war IPv6 gar nicht aktiviert. Ich hatte ja geschrieben, dass ich letztes Jahr versucht hatte, testweise IPv6 zu aktivieren, nach dem Booten aber gar kein Netzwerkzugriff mehr möglich war, auch nicht mit IPv4. Ich habe dann die Zeile wieder aus der Config entfernt, das war aber in /etc/network/interface (laut letzter Änderung der Datei am 30.09.2012). Danach hat alles wieder wie bisher funktioniert und von IPv6 war dann auch nichts zu sehen. Das war auch die einzige Änderung, die ich jemals vorgenommen hatte, die aber meiner Meinung nach wieder restlos beseitigt war. Erst vorgestern habe ich mitbekommen, dass IPv6 aktiv ist und dachte, das wäre von euch in einem der letzten Patches aktiviert worden.

/etc/modprobe.d/wiregate00 ist von mir niemals angefasst worden und sieht so aus (letzte Änderung der Datei war am 30.10.2012 vermutlich durch einen der Patches):

# disable ipv6 at all
alias net-pf-10 off
alias ipv6 off
# WireGate: don't load builtin linux-drivers as we use owfs
blacklist wire
blacklist ds2490

Warum IPv6 trotzdem aktiv ist, weiß ich nicht. Ich hab es nicht aktiviert, zumindest nicht wissentlich. Die Probleme mit lighttpd sind auch erst seit 20.01. im Logfile zu sehen, was kurz nach dem Patch PL34 war (14.01). Wenn aktives IPv6 die Ursache für den Fehler mit lighttpd ist, dann sieht es für mich so aus, als wäre IPv6 nach dem Patch auf PL34 aktiviert worden. Vielleicht ist es ein Bug, von dem die meisten nicht betroffen sind, weil in deren LAN IPv6 grundsätzlich nicht aktiviert ist.

Ich habe übrigens auch versucht das Wiregate nach dem Kernel-Update ohne Netzwerkverbindung zu starten. Das hat auch nicht funktioniert. IPv6 als Ursache für mein Problem würde ich daher ausschließen, mag mich aber täuschen.

Gruß
Werner

[cava]

So, es gibt neue Infos:

1. Manuell von 2.6.32 gebooted und den 3.5.1 deinstalliert -> System bootet wieder ohne Monitor und mit deaktiviertem IPv6.
2. 3.5.1 neu installiert -> IPv6 ist wieder aktiv, fragt mich nicht wieso.
3. 3.5.1 wieder deinstalliert -> alles wieder ok

Was folgt daraus:

1. IPv6 ist nicht schuld an den Fehlermeldungen von lighty, denn die sind vor dem Kernel Update aufgetaucht und auch wieder verschwunden.
2. Ich kann nichts für das aktivierte IPv6 unter 3.5.1.
3. Das Update auf 3.5.1 funktioniert auf meinem Wiregate nicht richtig.
4. Ich bitte deshalb um eine funktionierende Installation von 3.5.1 durch euch, so wie es in einem anderen Thread angeboten wurde: "jeder der "hier" ruft, bekommts.."

Gruß
Werner

[makki]

4. Ich bitte deshalb um eine funktionierende Installation von 3.5.1 durch euch, so wie es in einem anderen Thread angeboten wurde: "jeder der "hier" ruft, bekommts.."

Dieser fordernde Ton ist nicht unbedingt hilfreich, denn es gibt dafür keine Grundlage. Es wäre möglich, wenn ich Lust hätte. Warum sollte ich Lust haben? Welches Ereignis/Problem sollte mich dazu bewegen?

Bei den letzten 100++ gings, manuell geprüft, die haben sich aber auch nicht per IPv6 zuletzt per SSH angemeldet und was-weiss-ich-sonstnoch gemacht..



Makki

PS: aber das sch* v6 ist echt wieder aktiv, ist mir entgangen weil es als Problem#1 auch auf sämtlichen anderen System abgeschaltet ist.. Das hat aber nichts mit dem booten zu tun..

[cava]

Dieser fordernde Ton ist nicht unbedingt hilfreich, denn es gibt dafür keine Grundlage. Es wäre möglich, wenn ich Lust hätte. Warum sollte ich Lust haben? Welches Ereignis/Problem sollte mich dazu bewegen?

Wenn dir mein Ton als fordern vorkommt, dann tut mir das leid, ich kann es aber nicht rückgängig machen. Das Angebot "jeder bekommt es" hätte ich schon als Grundlage gesehen. Wenn du aber keine Lust hast respektiere ich das.

Bei den letzten 100++ gings, manuell geprüft, die haben sich aber auch nicht per IPv6 zuletzt per SSH angemeldet und was-weiss-ich-sonstnoch gemacht..

Und genau das ist es, was mich nervt. Jetzt wird mir schon wieder unterstellt, dass es mein Fehler war, dass das Update nicht richtig funktioniert hat. Ich hab nicht was-weiss-ich-sonstnoch gemacht, sondern genau das, was ich bisher beschrieben hatte. Ich kann aus technischer Sicht darin keinen Fehler finden.

PS: aber das sch* v6 ist echt wieder aktiv, ist mir entgangen weil es als Problem#1 auch auf sämtlichen anderen System abgeschaltet ist.. Das hat aber nichts mit dem booten zu tun..

Und was bedeutet das jetzt?

[makki]

Also resetten wir das Gespräch doch mal..

Irgendwas ist da wohl, an dem Bootloader (grub) wo's bei dir wohl hängt, wurde allerdings seit dem allerersten WireGate kein einziges Bit geändert..

Vorraussetzung für "jeden der hier schreit" ist aber auch ein permanent aktives Wartungs-VPN; wollte heute Mittag noch was nachsehen, ist nicht an, das kostet unnötig Zeit..

Grundsätzlich aber bitte: wenn man meint ein Kernel-Update machen zu wollen (es hat nen Grund warum ich das lieber manuell - bei Bedarf! - mache), dann brauchen wir mehr Infos, Details, Screenshot/Foto, PL, wo genau was usw.
Nen Verdacht hab ich aber blind: war *vor* dem Kerel-Update >=PL32 installiert?

Makki

[cava]

VPN ist aktiv. Vor Installation war PL34 installiert, so wie es auch von dir beschrieben war.

[makki]

Ich hab jetzt lange gegrübelt, was ich anders mache.. Genau deswegen schaue ich mir das lieber ein paar Monate kontrolliert. händisch an..

Ich entfernte vorher immer (unterbewusste Reinigungs-Aktion, wenn man schon da ist) die ganz alten, nie benutzten Kernel von den ganz alten, ersten Maschinen:

apt-get remove linux-image-2.6.26-1-486 
apt-get remove linux-image-2.6.26-wiregate-1.0 
apt-get install linux-image-3.5.1-wiregate-1.41

Da kommt evtl. - je nach Installationsreihenfolge - was anderes in der /boot/grub/menu.lst bei raus als gewollt.. Muss ich in Ruhe nochmal mit PL0 bis PL34 im Werdegang nachvollziehen, ist ja glaube ich auch noch ein Beta-Gerät aus den ersten Tagen, da war nicht alles 100% rund, deswegen ja auch das "lieber selbst&manuell"

Anyway -> Ich hab den Kernel 3.5.1 jetzt nicht installiert, weil ich könnte die menu.lst nun zwar auf die schnelle so befummeln, das er default bootet aber Lösung ist das für den nächsten auch keine.

Ausgangsfrage: gibt es irgendeinen Indikator/Problem, der zu dem neuen Kernel führt? Es gibt nämlich bei 98% keinen handfesten Grund, der ist weder höher/schöner/weiter/schneller noch in sonstwas besser..
Es gibt nur wohl ein paar wenige, seltene Konstellationen, meist stecken da aber 100 andere Sachen dran, wo es hilft.
Also kein Grund zur Update-Panik, mein Credo ist "never touch a running system" ausser ich hab Probleme, erhoffe mir aus dem Changelog was besseres; das Changelog von 2.6.32 -> 3.5.1 ist allerdings mehr als 5x Abendfüllend

Makki

P.S.: In Anbetracht meiner kommenden Abwesenheit ist das bewusst etwas ausführlich.. Es ist nunmal kritisch aber meist nicht notwendig, aktuelle Geräte werden seit 2012-12 damit eh ausgeliefert..