Ich habe nur Linux-Clients.
Beim Hochfahren der Clients macht allerdings eine Rechnergruppe Probleme und zwar HP dc7700 (ssf und cmt beide mit Intel-Chipsätzen). Bei diesen Rechnern startet das neue LINBO nicht durch:
Eigentlich müsste danach der graue Bildschirm mit orangenem Logo kommen.
Es bleibt nur ein hartes Ausschalten des Rechners übrig (selbst Alt-Druck+B startet den Rechner nicht neu).
Nach dem harten Ausschalten und dem Einschalten läuft LINBO allerdings durch und die Anmeldemaskevon Linux erscheint.
NACHTRÄGLICHE ÄNDERUNG: DAS STIMMT SO NICHT: Bein nächsten Neustart startet LINBO wieder nicht…
… Gerade habe ich bemerkt, dass aus dem LINBO-Menü heraus das Ausschalten eines HP dc7700 auch nicht funktionierte.
Vielleicht liegt’s an einer BIOS-Einstellung???
Danke für den Tipp, habe es auch so mit Thorsten vom Support besprochen.
Ich habe auch noch Label für die Partitionen gesetzt, wenn ich schon am partitionieren bin…
Nach ersten Syncs auf den neu partitionierten Platten kann ich sagen:
Das ursprüngliche Problem von oben (Bild), dass der schwarze Bildschirm stehen bleibt, ist nicht mehr aufgetreten.
Clients versch. Hardwareklassen bleiben öfters stehen am Ende des Sync nach der Meldung “Veranlasse Upload von linbo.log”. Es erfoglt einfach kein Neustart. Das passierte auch schon beim ersten durch linbo-remote ausgelösten Sync öfters und auch später.
Was ergibt ein df auf dem Server? Nicht das er die log nicht schreiben kann weil kein Platz mehr vorhanden ist.
Wie sieht deine Netzwerk-Belastung aus?
vielleicht hast Du in den Rechnern Kartenleser und die Slots wurden als Festplatten eingehängt. Damit ist das Starten dann nicht mehr möglich. Ich hatte das Problem kürzlich mit einem Drucker der am USB-Anschluss hängt und einen Kartenleser hat. War der Drucker eingeschaltet, dann funktionierte der Rechner nicht mehr, weil der Kartenleser zu sda wurde.
Weil ich zur Zeit nicht an alle Switche rankomme, habe ich es etwas anders getestet.
Ich habe jetzt testweise an den Server nur einen einzigen Switch gehängt, einen HP 1810-24G, der absolut neu ist. Daran habe ich meine 5 Testclients und das Admin-Laptop gehängt und sonst nichts.
Leider bleiben bei machen Starts einige Clients immer noch ab und zu hängen:
Am häufigsten sind die zwei HP dc7700 betroffen, aber auch das Lenovo T430 und das T60 hingen ab und an:
Schaltet man diese Clients hart aus und startet sie wieder, booten sie direkt ins Linux-Betriebssystem.
Hier einmal einige LINBO-Logs der Clients:
Ich habe die Logs dieser Clients unter /var/linbo/log nach jedem Durchlauf gelöscht, so dass immer nur 1 Durchlauf pro Log erscheint.
Ich habe synchronisierte und unsynchronisierte Starts ausprobiert und bei beiden gibt es Hänger. Bei unsynchronisierten Starts bleibt die Zeit bei ‚Bitte Warten…‘ dann bei 00:01 hängen.
ein ziemlich seltsames Problem, da es ja auch sporadisch und nicht
durchgehend auf taucht.
Kannst du etwas erkennen wie: nur Rechner X, Y und Z sind betroffen aber
nicht Rechner A, B und C?
Wobei XYZ sowie ABC durchaus in der selben Hardwareklasse sein dürfen.
Oder ist das Chaotisch über alle Rechner der Hardwareklassen verteilt?
Sind alle Hardwareklassen betroffen?
Hast du Änderungen in der /var/linbo/boot/grub/.cfg ?
Ist die Zeile
ich habe jetzt nochmal ganz von vorne begonnen und es sieht bislang gut aus!
Kernelparameter ‚nolapic‘ aus start.conf entfernt, jetzt steht nur noch ‚dhcpretry=10 drin‘.
LMN6.1 auf 6.2 upgedatet:
Dabei gab es ein paar Fehlermeldungen:
Errors were encountered while processing:
linuxmuster-base
linuxmuster-linbo
linuxmuster-schulkonsole
linuxmuster-migration
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ich habe dann die 4 Pakete nochmals installiert und bei # apt-get install linuxmuster-base
wurde auch was gemacht.
Danach ein # update-linbofs
wie von Holger empfohlen.
Zum Schluss noch # import_workstations
Dann habe die Clients, die schon mit Labeln partitioniert waren, problemlos mehrmals funktioniert!
Aber: Ein noch nicht mit Labeln partitionierter Client blieb noch immer nach der Meldung “Veranlasse Upload von linbo.log” hängen.
Nach dem Partitionieren mit Labeln blieb das Problem bestehen.
Erst als ich nochmal ein import_workstations gemacht habe, lief der Client problemlos.
??? Ist das logisch, dass man nach dem Partitionieren der Clients mit Labeln ein import_workstations machen muss???
Das liese mich etwas ratlos wie ich das Partitionieren aller Clients gestalten soll. An manche komme ich gar nicht ran, die werden von den Fachschaften irgendwann im Schuljahr mal gestartet.
Und wie kann ich überhaupt herausfinden, welcher Client partitioniert wurde und welcher nicht, ohne am Client zu stehen?
Und hier noch die Antworten auf Eure Fragen:
Habe immer nur 1 Client am Booten und auch nur einen einzigen Switch am Server (diesmal nochmal einen anderen neuen),
LMN6.1 auf 6.2 upgedatet:
Dabei gab es ein paar Fehlermeldungen:
Errors were encountered while processing:
linuxmuster-base
linuxmuster-linbo
linuxmuster-schulkonsole
linuxmuster-migration
E: Sub-process /usr/bin/dpkg returned an error code (1)
schau da mal ins log von apt, was da genau los war.
Sowas gab es bei über 10 Upgrades die ich schon gemacht habe, nie.
Aber: Ein noch nicht mit Labeln partitionierter Client blieb noch immer
nach der Meldung “Veranlasse Upload von linbo.log” hängen.
Nach dem Partitionieren mit Labeln blieb das Problem bestehen.
Erst als ich nochmal ein import_workstations gemacht habe, lief der
Client problemlos.
??? Ist das logisch, dass man nach dem Partitionieren der Clients mit
Labeln ein import_workstations machen muss???
nein: das sollte nichts miteinander zu tun haben.
Und wie kann ich überhaupt herausfinden, welcher Client partitioniert
wurde und welcher nicht, ohne am Client zu stehen?
mit linbo-remote und dem Befehl
blkid
vielleicht auch mittels
fdisk -l
Ich poste hier/var/logs/apt/term.log
Es enthält einige Male ‚error‘ und ‚warning‘.
Noch habe ich alles ja unter einem Xen-Snapshot ausprobiert, den ich nicht produktiv verwende.
Für Tipps, was ich vor dem nächsten Updateversuch von 6.1 auf 6.2 machen sollte, wäre ich dankbar.
14:01/130 server ~ # dpkg-reconfigure -a
14:05/0 server ~ # dpkg -l | grep tftp
rc atftpd 1:0.7.dfsg-11.1 advanced TFTP server
ii tftpd-hpa 5.2-1ubuntu1fifopatch HPA's tftp server
14:15/0 server ~ #
