Eine Serie Laptops starten, wenn sie ins Netz eingebunden sind völlig problemlos.
Wenn ich sie offline starte, wird im Auswahlfenster von Linbo nichts (kein Betriebssystem mit der Möglichkeit zum Start, Sync etc) anzeigt.
Der Bildschirm sieht so aus, als ob ein neuer Client angemeldet werden sollte:
Der Hostname ist linbo
Es wird keine Gruppe angezeigt, keine Festplattendaten usw.
Was tun?
Gruß Wolfgang
Hallo Wolfgang,
schaue bitte nach ob in der workstations die letzte Zahl größer als Null ist.
Entweder über die Schulkonsole anmelden als Administrator unter hosts oder über die Konsole mit einem Editor (vi, nano, mc …) in der Datei /etc/linuxmuster/workstations
Gruß
Manfred
Die letzte Ziffer ist größer als 0.
Wenn sie 0 wäre, dann würde ja gar keine LINBO Einbindung vorliegen.
Gruß Wolfgang
Kann ja eigentlich nur bedeuten, das im lokalen Cache die start.conf nicht richtig ist oder gar nicht vorhanden ist??
Starte den Client doch mal und mounte die Cache-Partition … da sollte neben den .cloops eine start.conf liegen, die identisch mit derjenigen vom Server ist…
Alles vorhanden und identisch.
Sonst würde online ja auch nichts funktionieren.
Gruß Wolfgang
Hallo Wolfgang,
im Offline-Modus wird noch nicht einmal die Festplatte erkannt, das ist
schon reichlich merkwürdig, da ja eigentlich dasselbe Linbo verwendet wird.
Hast Du schon mal bei einem Client die Festplatte komplett neu
partitioniert, dann formatiert und den Cache aktualisiert?
Viele Grüße
Jörg
Hallo Wolfgang,
https://ask.linuxmuster.net/uploads/default/original/1X/8b66abb72af3753e5a1224a50161ec8ff127a87a.jpg
der Client ist offline: ich nehme an, dass du in die start.conf auf dem
Server bei den KernelOptions = dhcpretry=10
zu den vorhandenen KernelOptions dazu schreiben mußt: dann geht es.
Danach ein import_workstations
und: in der /var/linbo/boot/grub/.cfg
muß die Zeile
noch drin stehen: sonst kommen die Änderungen nicht am CLient an.
LG
Holger
Habe alles gemacht, wie vorgeschlagen.
Keine Veränderung des Verhaltens.
Online : startet problemlos.
Offline: leerer Client (siehe Bild)
Ich habe bei anderen Gruppen nach gesehen:
KernelOptions ist dort nicht eingetragen.
Die ### managed …
ist dort auskommentiert.
Trotzdem lassen sich diese Clients auch problemlos Offline starten.
Gruß Wolfgang
Hallo Wolfgang,
dem Bildschirmphoto nach scheint Linbo offline die Festplatte nicht zu
erkennen. Wenn du Dich da bei Linbo anmelden kannst, dann könntest Du
eine Konsole starten und mit “cat /proc/partitions” nachprüfen, ob das
tatsächlich der Fall ist. Du kannst dann auch mal testweise die
Cache-Partition mounten. Wenn das erfolgreich ist, dann fällt mir nichts
mehr ein.
Wenn die Festplatte aber tatsächlich nicht erkannt wird, dann kann ich
mir nur irgendwelche Bios-Einstellungen als Ursache denken.
Viele Grüße
Jörg
Lieber Wolfgang,
das neuere linbo ab 2.3 schreibt sich in der Regel bei der default-Einstellung auf die Bootplatte, sodass es keinen Unterschied zwischen dem Booten über das lokale linbo und beim PXE-Booten geben dürfte.
Es gab jedoch beim Wechsel von linbo 2.2 auf 2.3 ab und zu den Fall, dass die komplette “Boot-Maschinerie” nicht immer korrekt auf den Clients landete. Außerdem muss dann oft der lokale GRUB wissen, dass auch er evtl. mit erhöhtem dhcpretry - Wert starten muss, sonst findet er natürlich weder IP noch Serverimage .
Ich würde folgendes machen:
BIOS überprüfen:
Virus Protection…)Nun zunächst mal per Texteditor in die start.conf.[gruppe] reingehen und dort oben “autoinitcache = yes” setzen. Damit erreichst Du, dass auch die Boot-Maschinerie ganz sicher auf dem client landet.
Dann erhöhst Du in der start.conf.[gruppe] den dhcpretry-Wert, indem Du folgende Zeile einfügst:
KernelOptions = dhcpretry=20
(Bei mir steht sie unter der SystemType-Zeile).
Jetzt bitte unter /var/linbo/boot/grub/[gruppe].cfg nachprüfen, ob da die Zeile
### managed by linuxmuster.net # steht !
Wenn nicht, dann bitte einfügen. Die Auskommentierung bedeutet lediglich, dass grub nicht von ihr irritiert ist, von den linumxuster-skripten wird sie AUSGEWERTET !
Gut, nun machst Du ein
import_workstations
Überprüfe mit ls -aFl, ob die /var/linbo/boot/grub/[gruppe].cfg
den aktuellen Zeitstempel enthält, denn sie muss jetzt nochmals neu geschrieben worden sein !
Wenn ja,
dann starte einen der Rechner - natürlich per PXE - , setze Dich davor und beobachte, ob der grub auf die dortige lokale Festplatte geschrieben wird (das wird angezeigt, danach gibt es einen Reboot).
Lass den Rechner einmal hochlaufen, dann schalte ihn aus und stelle den Boot auf lokal um.
Jetzt muss, da der Bootanager Grub auf der lokalen Festplatte neu erstellt wurde, und auch das dhcp-timing verlängert wurde, das Ganze funktionieren !
Gruß Christoph
P.S.
Wenn’s geklappt hat, stelle, damit Deine Schüler nicht immer warten müssen, den default-Wert in
/var/linbo/boot/grub/[gruppe].cfg
von
default=0
um auf
default=[x],
fallback=0
wobei x häufig 1-4 ist - je nach Aufbau der start.conf.
Leider kein Erfolg.
Via console kann man feststellen, daß alle Dateien auf dem richtigen Stand sind. Dateien haben den richtigen Zeitstempel …
Es ist aber nichts gemountet, außer /devtempfs.
Der TimeOut steht übrigens auf 120s, also auf dem Wert, den er bei der Neuaufnahme eines Rechners hat.
/temp/linbo.log steht folgende Meldung
ntfs -3g : failed to access volume
In der start.conf.gruppe steht
…
Id =c
FSType = vfat
…
Bei Online Start habe ich auch überprüft, daß die Partition so formatiert ist.
Gruß Wolfgang
Diese Meldung erscheint in linbo.log am Ende beim
Online-Start
Irgendwie nicht so richtig durchschaubar.
Gruß Wolfgang
Hallo Wolfgang,
hast Du jetzt schon komplett neu partitioniert?
kannst Du mal beim Offline-Boot, falls Du auf den Reiter “Imaging” kommst, im Termial mal
"cat /proc/partitions"
eingeben?
LG
Max
Neu partitioniert etc. habe ich auch schon mehrfach, gleich als der Fehler auftrat.
Beim Linbo-Vorgänger (güner Bildschirm, linuxmuster.net unten links)
hat das ganze noch funktioniert.
Der Dreh- und Angelpunkt scheint der Aufruf von ntfs-3g zu sein.
(Ich hoffe, ich erinnere mich richtig, da ich zur Zeit nicht vor dem Client sitze)
Per ssh habe ich auf den Client zugegriffen: der Aufruf von ntfs-3g erfolgt in linbo-cmd
dort habe ich die aufrufende Zeile mit “echo” versehen.
Und dann neu gestartet.
Leider zu kurz gedacht.
Beim Start scheint Linbo auf eine Ramdisk zuzugreifen, das veränderte Skript ist durch sein Original ausgetauscht worden, daher kein “echo” mehr.
Und ab jetzt wird es kompliziert.
Diese Ramdisk liegt in einem gepackten Format vor, das von GRUB direkt gelesen wird.
Also müßte man vorgehen wie folgt:
Entpacken (geht, getestet) - das Skript verändern - packen - dafür sorgen, daß alles auf den Client kommt.
(Kurzform, da gibt es wahrscheinlich noch ein paar Zwischenschritte)
… und dann die Ausgabe bewundern und die entsprechenden Schlüsse ziehen.
Mein derzeitiger Workarround:
Ich starte jeden Client (Laptops!) Online, dann gebe ich das laufende Gerät an die Schüler aus.
Geht so einigermaßen.
Grüße
Wolfgang
Hallo Wolfgang,
wenn Du in dieser Richtung weitersuchen willst, dann schau Dir mal das
Skript “update_linbofs” auf dem Server an, daraus geht hervor, wie Du
Dir Dein angepasstes linbofs.gz bauen kannst.
Da aber sowohl offline wie beim PXE-Boot dasselbe linbofs zum Einsatz
kommt liegt das Problem wohl eher indirekt an linbo_cmd.
Bitte poste doch mal die start.conf der Rechnergruppe.
Noch eine Idee: Hast Du eventuell Reiserfs für die Cache-Partitiopn
verwendet? Da ist Ext4 besser geeignet.
Viele Grüße
Jörg
Lieber Wolfgang,
neuer Versuch:
Hinweis: Dein erstes Photo und Deine Aussage, dass linbo die 120 sec. Startzeit (wie bei der Neuaufnahme) zeigt.
Laut Handbuch sollte die IP nicht im Neuaufnahmebereich liegen, das bedeutet, dass 10.20.111.213 vielleicht im dynamischen Adress-Zuweisungsbereich des dhcp-Bereich liegt und daher bestimmte Aktionen nicht “greifen” - sprich, der GRUB wurde nie korrekt geschrieben. Ändere doch mal das letzte Oktett (213) auf etwas < 100.
Gruß Christoph G.
Hallo Christoph,
neuer Versuch:
Hinweis: Dein erstes Photo und Deine Aussage, dass linbo die 120 sec.
Startzeit (wie bei der Neuaufnahme) zeigt.
Laut Handbuch sollte die IP nicht im Neuaufnahmebereich liegen, das
bedeutet, dass 10.20.111.213 vielleicht im dynamischen
Adress-Zuweisungsbereich des dhcp-Bereich liegt und daher bestimmte
Aktionen nicht „greifen“ - sprich, der GRUB wurde nie korrekt
geschrieben. Ändere doch mal das letzte Oktett (213) auf etwas < 100.
guter Einwand: aber nur, wenn Wolfgang subnetting hat.
Der normale Aufnahmebereich ist 10.16.1.100 und 10.16.1.200
LG
Holger
Lieber Wolfgang,
mich würde interessieren, ob Du weitergekommen bist - und ggf., wie !
MfG
Christoph Gü
