Grub soll bei PXE-Boot automatisch Linbo starten

Liebe Linuxmustler,

im Dunstfeld von meinem alten,ungelösten Problem (Linbo: alle Icons grau nur bei Laptops) komme ich vom Hölzchen aufs Stöckchen.

Was ich will:

  • Admin weckt per Linbo-Remote die Rechner per WOL auf. Die Rechner booten automatisch ins Linbo.
  • Lehrer startet die Rechner per Einschalttaster. Die Rechner starten automatisch in das Clientensystem.

Warum will ich das:

  • PXE, Linbo, Reboot, PXE, Client dauert echt lange. Gerade unsere T430 Denkbretter verbringen locker 60s im PXE, wenn kein Netzwerkkabel eingesteckt ist.
  • Lehrer sind mit Linbo überfordert. („Und dann ist da ein Fenster und noch eines mit einer Zahl und bis ich was lesen kann, ist es schon wieder weg.“ Und das ist mit dem ganzen Beamergeflacker aufgrund des Bildsyncs auch nicht übertrieben)
  • Bisher habe ich eine Zeitsteuerung: Ist schon cool: Boot vor 7 oder nach 15 Uhr -> LINBO, ansonsten Ubuntu.
    • Jedoch: Einmal ein vergurktes Image ausgerollt und alle Rechner funktionieren nicht und dies nicht bemerkt -> Turnschuhe herausholen. (Ein vergurktes Image ausgerollt? Wie blöd kann man sein! Oder rsyncd stürzt sang und klanglos nach fünf PCs ab und der Rest macht keine Postsyncs mehr. Bei uns dann unnutzbar.)

Was habe ich bisher erreicht:

  • Unsere Rechner booten normalerweise über die eingebaute Festplatte.
  • Unsere PCs (alles HP, bis auf die T430 Denkbretter und ein paar Dellen) bieten alle eine Bioseinstellung á la "Wenn über WOL gestartet, dann Boote via PXE.
  • Grub erhält dann eine IP „$pxe_default_server“
  • Diese kleine If-Abfrage funktioniert dann super:
#by fh: Gibt es einen PXE-Server? Dann haben wir ueber das Netzwerk per PXE gebootet. Dann wurde
#wahrscheinlich per Wake-On_Lan gebootet. Dann wollen wir Linbo. Voraussetzung: Der Rechner bootet
#nur bei WOL über PXE
if [ -n "$pxe_default_server" ]; then
 echo
 echo -n "Via WOL aufgeweckt. -> Linbo starten  "
 sleep --verbose  1
 set default=0
else
 echo -n "Dieser Rechner wurde per Knopfdruck gestartet. -> gleich starten  "
 sleep --verbose 1
 set default=1
fi

Was will der denn dann noch?

  • Sollte Linbo jedoch sich selbst aktualisieren oder den Grub neu schreiben, bootet es danach neu.
  • Dann bootet das Bios nicht mehr via PXE und
  • Grub erhält keine IP mehr und deshalb
  • startet das erste Mal zwar Linbo, führt jedoch die per Linbo-Remote gesetzten Befehle nicht aus und das zweite Mal startet Grub dann Ubuntu.

Ich brauche also noch eine Erkennungsmöglichkeit in Grub, wenn Linbo sich selbst aktualisiert hat. Wie könnte das gehen?

1 „Gefällt mir“

Hmm. Meine Idee war, dass Linbo irgendeine Datei als Flag auf der Cache-partition setzten würde, anhand dessen grub erkennen könnte, dass es nochmals in Linbo booten muss.

ich habe mir mal https://github.com/linuxmuster/linuxmuster-linbo/blob/master/linbofs/usr/bin/linbo_cmd ab Zeile 3037 und https://github.com/linuxmuster/linuxmuster-linbo/blob/master/linbofs/init.sh ab Zeile 485 angeschaut.
Es gibt die Datei rebootflag="/tmp/.linbo.reboot". Wenn ich das richtig verstehe überlebt sie aber den Reboot nicht, da sie nicht auf der Festplatte landet.

Kurz: Ich finde ein solches Flag nicht.

Bei einem Einsatzszenario in dem immer Linbo gebootet wird, ist das sicher ok. Ansonsten führt es aber immer dazu, dass die linbo-cmd Befehle nicht ausgeführt werden, wenn ein Linbo-Update ansteht.

Stimmt das? Das könnte man schon als Bug bezeichnen, oder?

Hallo frithjof!

Würde ich nicht sagen, kommt immer auf den Einsatzzweck an.

Ohne es hundertprozentig zu wissen, würde ich sagen, dass es sich hierbei um das reboot flag handelt für den BS-Start. Also normales vom Entwickler für diesen Zweck programmiertes Verhalten.

Boot -> PXE -> LINBO -> Auswahl des BS -> Reboot -> ausgewähltes BS startet

Mein Tipp, schaue dir mal linbo -p <cmd1, cmd2 , …> an.

Beste Grüße

Thorsten

Hallo Frithjof,

Bei einem Einsatzszenario in dem immer Linbo gebootet wird, ist das
sicher ok. Ansonsten führt es aber immer dazu, dass die linbo-cmd
Befehle nicht ausgeführt werden, wenn ein Linbo-Update ansteht.

Stimmt das? Das könnte man schon als Bug bezeichnen, oder?

… nun ja: bei mir funktioniert das mit den linbo-remote Befehlen mit -c
auch wenn ein linbo update am Cleint gemacht wird.
Ich muß dann halt den Timer hochsetzen: normal: -w 60 mit update -w 100

Aber besser ist Thorstens Idee: nimm -p
Dabei wird der remote Befehl nicht nach einer festen Zeit an den Cleint
gesendet (-w) sondern einfach vom linbo beim nächsten start in die
Oberfläche ausgeführt: egal wann der passiert.
Da das linbo update vor der Oberfläche passiert, hat das keinerlei
Auswirkungen.

Ich halte inzwischen den -p Befehl für die bessere Lösung: nutze selbst
aber noch immer -c, weil ich es einfach gewohnt bin …

LG

Holger

Man kann auch -w 0 und -p kombinieren.

Viele Grüße

Andreas

Hi,

ich glaube @frithjof meint etwas anderes. Da bringen im -c oder -p nicht viel, da sie - soweit ich weiß - erst nach dem Linbo-Upgrade (falls es eins gab) ausgeführt werden.

Seine Rechner starten nicht in Linbo, wenn man sie normal anschaltet, sondern direkt ins OS durch. Nur wenn sie per WOL geweckt werden, landen sie in Linbo. Sein Problem ist, das der Rechner beim Aufwecken in Linbo landet, dann das Linbo Update geholt wird und dann beim nächsten Start ins OS, statt nach Linbo gebootet wird.

vG Stephan

1 „Gefällt mir“

Kurz: Zefanja sagt genau das, was ich meine! Linbo updated sich: linbo-cmds werden nicht ausgeführt.

Lange Version:

Nein, dass ist hier nicht der Fall. Das Reboot-Flag in Grub wird nicht gesetzt. Ich habe es jedenfalls an den genannten Orten nicht gefunden. Ich glaube auch nicht, dass es das von den Entwickerln gewünschte Verhalten ist. Meiner Verständnis nach wäre dann auch das einzig sinnvolle Vorgehen, dass Linbo sich selbst neu startet. Ohne Rebootflag für Grub ist es jedoch der jeweiligen Umgebung überlassen, was gestartet wird. Stimmt das?

Hier mal die Use-Cases die ich mir vorstellen kann:

  • User Mike startet den PC. Der PC startet immer über PXE und immer Linbo. Linbo aktualisiert sich, startet neu. Mike startet sein Lieblingssystem per Mausklick in Linbo. Alles ist super, Mike stellt keinen Fehler fest.

  • User Tim startet den PC, er will mit dem Clientsystem Windows arbeiten. Linbo startet, aktualisiert sich und startet Ubuntu, weil dies nun eben der default-case ist. Tim sieht die im vertraute Linboumgebung nicht und Tim muss den PC neu starten.

  • Admin Lisa will ein Image ausrollen. Sie startet per linbo-cmd und WOL. Linbo aktualisiert sich und startet Ubuntu. Lisas Image wird nicht ausgerollt. Sie kann per ssh ein poweroff veranlassen und es noch einmal versuchen.

  • Admin Maria will ein Image ausrolen. Sie startet per linbo-cmd und WOL. Linbo aktualisiert sich und startet danach Windows. Das Image wird nicht ausgerollt. Maria kommt nicht mehr an den Rechner heran, weil sie keine Fernwartungssoftware installiert hat.

In den letzten beiden Usecases ist linbo-cmd -c oder -p nicht von belang, sie würden beide zu dem gleichen, unerwünschten Ergebnis führen: Das Image wird nicht ausgerollt.

Zusammenfassend:
Es ist ein Bug. Voraussetzung: Grub startet per default ein Client-OS und nicht Linbo wird als valider Usecase angesehen.
Abhilfe: Linbo setzt nach einem Update ein Rebootflag, so dass es nach einem Reboot erneut startet.

Das würde in diesem Fall nicht helfen: Linbo müsste Grub anweisen, dass Grub erneut Linbo startet. Aber genau das unterbleibt: Es wird kein „rebootflag“ geschrieben.

PS: Ein wenig amüsiert es mich, dass du mir vorschlägst, den Timer hochzusetzen. :slightly_smiling_face: Ein Zitat aus diesem Thread: Linbo: alle Icons grau nur bei Laptops

Hallo Fritjof,

ich habe nochmal deinen ersten Post gelesen.

„Normaler“ Einsatz von Linbo ist eigentlich PXE als erstes Bootmedium.
Hast Du dir schon mal menue.lst angeschaut.

https://wiki.linuxmuster.net/community/anwenderwiki:pxe-windows?s[]=menue&s[]=lst

Da ich das selber nicht einsetze, Holger @baumhof kannst Du mal was dazu sagen.
Ich denke, damit könnte Fritjof das erwünschte erreichen.

Beste Grüße

Thorsten

Nein, ihm geht es um was anderes.

Hallo,

ich hab das Problem Thomas gemeldet und in GitHub ein issue erstellt.

LG

Holger

@baumhof: Danke dir dafür.