meine Kollegen und ich sind der neue IT-Dienstleister für die staatlichen Schuleinrichtungen in unserem Gebiet.
Wir möchten perspektivisch alle Schulen auf Linuxmuster umstellen. Daher haben wir eine Menge an Geräten welche wir über Linbo aufnehmen wollen.
Es handelt sich um zwei untschiedliche Gerätemodelle, den Fujitsu Esprimo G9010 und Fujitsu Esprimo G6012 auf denen Windows 10 als OS verwendet wird.
Mein Thema ist, dass der G9010 nachdem boot vom linbo (linbo Auswahlfenster weiter zu Windows) immer den Windows bootloader als erstes nach oben schiebt. Darauf hin kommt es zum BCD-error.
Die Parameter noefibootmgr und force grub sind angegeben.
Ich habe bereits ein seperates Master-Image und Bios update für das Modell erstellt. Diverse Powershell skripte, welche in die Bootreihenfolge eingreifen ausgeführt.
bcdedit /enum {fwbootmgr}
bcdedit /enum all | Select-String „description“ -Context 1,0
Hat jemand Erfahrungen mit Geräten gemacht welche den Windows bootloader
nachdem Linbo boot immer nach oben schieben?
ein solches Verhalten wurde schon beobachtet.
Manchmal konnte es behoben werden durch,
etnweder BIOS Update
oder/und Einstellen von „Bootreihenfolge schützen“ im BIOS.
Manche „BIOS“ haben eine solche Einstellung (heißt natürlich irgendwie
ander: protect blabla … oder so).
Außerdem hab ich zu Fujitsu G??? Dingern auch Forenthreads im
Hinterkopf: da war schon mal was mit denen.
War es die Grafikkarte? War es linbo?
Ich weiß nicht mehr.
Such mal nach Fujutsu im Forum… das könnte noch was bringen
das Problem kommt mit bekannt vor. Man könnte das evtl. durch ein Skript lösen, welches per bcdedit die Bootreihenfolge ändert, dieses Skript in die Windows-Taskplanung integriert und z.B. beim Herunterfahren ausführen läßt.
Hallo Holger,
danke für deine schnelle Rückmeldung.
Ein Bios Update hatte ich bereits gemacht und einen Option zum Schutz der Bootreihenfolge gibt es in dem BIOS nicht.
Wenn ich nach Fujitsu hier im Forum suche, finde ich nur mein Thema.
Den Ansatz hatte ich bereits ebenfalls versucht siehe oben. Ich habe beobachtet das sich der Windows Bootloader immer nachdem verlassen aus dem Linbo nach oben schiebt. Das heißt die Einstellung der Reihenfolge im BIOS selbst oder per bcdedit wird übernommen, jedoch nachdem verlassen von Linbo „verworfen“.
Vielleicht hatte ich mich eingangs nicht konkret ausgedrückt, ist es jetzt genauer klar?
nach meinen Beobachtungen ändert sich der Bootloadereintrag erst zur Windows-Laufzeit und hat mit LINBO gar nichts zu tun. Daher sollte das Skript auch beim Herunterfahren ausgeführt werden.
nach meinen Beobachtungen ändert sich der Bootloadereintrag erst zur
Windows-Laufzeit und hat mit LINBO gar nichts zu tun. Daher sollte das
Skript auch beim Herunterfahren ausgeführt werden.
ich habe beides schon beobachtet: dass WIndows die Reihenfolge ändert,
aber auch das linbo das tut (bei manchen UEFI BIOSen).
Welche linbo Version wird den verwendet?
Hallo Jonas,
ich habe an meiner Schule mehrere Q7010 und P7012. Ich denke das EFI sollte ähnlich sein. Die einzig notwendige Einstellung, um ein vernünftiges boot-Verhalten zu bekommen, war folgende Einstellung:
„New UEFI OS Boot Option: Place First“
Vielleicht hilfts ja…
Hallo zusammen,
ich habe eine neue Beobachtung gemacht.
Wenn ich das Masterimage ausrolle (patchstand vom März des G6012), dann Funktioniert alles tadellos. Bei der nach Installation der Gerätespezifischen Treiber ebenfalls. Sobald die Windowsupdates egal ob über online oder Wsus offline (Patchstand 14.06.2023) kommt es wieder zum Bootreihenfolge error sobald das Linbo verlassen wurde. Da möchte man meinen das es an den Windows updates liegt.
Jetzt kommt der Knaller, wenn ich das Netzwerkkabel trenne und aus dem Linbo ins Windows boote, dann Funktioniert es.
Das sieht für mich klar nach einer Konfiguration des Linbo aus, was mir allerdings nicht klar ist wieso tritt es nur bei diesem einen Gerätetypen auf und nicht bei allen?
Ist es möglich durch eine genaue Linbo „fein Justierung“ diesen Gerätetypen ebenfalls zu nutzen?
du hast mit linbo 4.0.43 nicht die aktuelle Version 4.0.44
Ich hab mal nachgeschaut: da ist leider nichts beschrieben, was auf dein
Problem passen könnte:
Trotzdem würde ich folgenden Vorschlag machen:
was bringt es lange rum zu probieren, wie man das hin bekommt: mach doch
mal die aktuelel linbo Version drauf, schau ob da das Problem auch noch
existiert und fix es dort, wenn es da auch besteht.
und mit aktueller linbo Version meine ich linbo 4.1.30 …
Für wann ist den das upgrade 7.1 auf 7.2 bei euch angedacht?
grundsätzlich bin ich da bei dir. Allerdings sind wir in wenigen Tagen dabei die Netzwerktechnik in der Schule zu verbauen und ggf. die ersten Geräte aufzunehmen. Da ist es nicht Ratsam die Dinge ggf. zu verschlimmbessern.
Da wir uns ganz frisch mit dem Thema auseinandersetzen, gab es bisher kein Update/Upgrade. Ist nach deiner Erfahrung ein Linbo update von 4.0.43 auf 4.1.30 unbedenklich, wie sieht Versionsabhänigkeiten zur Opensense und dem Linusmuster Server aus?
Da wir uns in der produktiven Aufbauphase befinden, wollten wir mit dem Upgrade auf 7.2 noch warten, außerdem wird darauf hingewiesen das es eine Beta ist und für Produktiv noch nicht genutzt werden soll.
grundsätzlich bin ich da bei dir. Allerdings sind wir in wenigen Tagen
dabei die Netzwerktechnik in der Schule zu verbauen und ggf. die ersten
Geräte aufzunehmen. Da ist es nicht Ratsam die Dinge ggf. zu
verschlimmbessern.
das kann ich verstehen.
Da wir uns ganz frisch mit dem Thema auseinandersetzen, gab es bisher
kein Update/Upgrade. Ist nach deiner Erfahrung ein Linbo update von
4.0.43 auf 4.1.30 unbedenklich, wie sieht Versionsabhänigkeiten zur
Opensense und dem Linusmuster Server aus?
die OPNsense bleibt wie sie ist: da passiert nichts.
Ein Upgrade von linbo 4.0 auf 4.1 schneidet alte Zöpfe ab (cloop
Unterstützung fällt weg) und macht so den Weg frei zu viel aktuelleren
Kernels (6er statt 5er bei 4.0.xx).
Da wir uns in der produktiven Aufbauphase befinden, wollten wir mit dem
Upgrade auf 7.2 noch warten, außerdem wird darauf hingewiesen das es
eine Beta ist und für Produktiv noch nicht genutzt werden soll.
… ich würde das anders machen.
Wenn es noch nciht produktiv ist, dann geht auf die 7.2 vorher und dann
geht in die produktive Umgebung und schaut wo es klemmt.
Schlimmstenfalls, wenn ihr das macht, wie ihr es jetzt vorgesehen habt,
kommt ihr in die Produktive Umgebung, behebt Probleme in der 7.1 die ihr
mit der 7.2 vielleicht gar nicht gehabt hättet.
Und ja: 7.2 ist Beta, aber ich und wenigstens zwei weitere Schulen,
setzen sie seit Monaten produktiv ein.
Ganz ehrlich: ich würde keine 7.1 mehr aufsetzen, sondern gleich die 7.2
nehmen…
Macht doch ein Snapshot, führt das upgrade aus (das ist in 15 Minuten
gemacht) und probiert es aus…
Potenzielle Probleme sind vor allem an einer Stelle zu erwarten: linbo
hat ein paar neue Kernelparameter wie z.B. warmstart
Die hießen früher anders …
Die Umstellung an meiner Schule im März brachte mir nur ein Problem: ein
paar Hardwareklassen hatten Probleme mit dem wechsel von 4.0 auf 4.1 am
Client: das lag daran, dass ich denen „warmstart=no“ hätte mitgeben sollen.
Der Vorgang ist so: 4.0 bootet am Client, es merkt, dass 4.1 vorhanden
ist und aktualisiert sich: dann macht es ein warmstart um so 4.1 zu
laden, bevor die GUI erscheint. Das klappte aber an zwei Hardwareklassen
bei mir in der Schule nicht: die mußte ich einmal von Hand neustarten
schon bootete 4.1 ohne Probleme.
Ich habe „ACPI BIOS Error“ mal nachgeschlagen, es wird als erstes immer in Verbindung mit Linux aufgezeigt und da es nach der Linbo Initialisierung erscheint denke ich weiterhin das es ein Linbo Thema ist.
Ich habe „ACPI BIOS Error“ mal nachgeschlagen, es wird als erstes immer
in Verbindung mit Linux aufgezeigt und da es nach der Linbo
Initialisierung erscheint denke ich weiterhin das es ein Linbo Thema ist.
Wie siehst du das ganze?
Nach 30 Jahren BIOS Entwicklung war die allgemeine Qualität der BIOSe
langsam annehmbar… UEFI benötigt wohl auch diese 30 Jahre und hat
davon erst 15 hinter sich …
Solche Fehlermeldungen sind eher „Hinweise“, dass das BIOS da irgend
einen Mist macht.
Ich ignoriere sie stets: in aller Regel wissen die Kernelentwickler
davon und „umschiffen“ die Probleme in den aller meisten Fällen erfolgreich.
