Linbo startet nur einmal - dann immer Win10 direkt

Hallo zusammen,

ich stehe irgendwie auf dem Schlauch und finde den Fehler nicht:

auf neuen Laptops mit UEFI wurde Windows 10 nach Anleitung erfolgreich installiert, in die Domäne aufgenommen und alles läuft gut so wie es soll.

Das einzige Problem ist jetzt, dass die Bootreihenfolge nach jedem Start von Windows so verändert wird, dass immer Windows direkt startet und Linbo nie wieder hoch kommt. Erst wenn man im BIOS/UEFI wieder den Netzwerkboot in der Reihenfolge hochschiebt oder EFI/grub/grubx64 als Boot-Option hinzufügt, landet man wieder in Linbo.

Für das Anlegen der Hardwareklasse, start.conf und des Reg-Patches habe ich jeweils die Beispiele genommen - also alles Standard.

Hat jemand eine Idee, warum die Bootreihenfolge dauerhaft geändert wird und der Windows Boot Manager immer ganz oben steht?

Viele Grüße
Manuel

Ich antworte mir einmal selbst:
Ich werde wohl versuchen alles nochmals von vorn zu installieren - vielleicht klappt es dann ja.
Bis dafür Zeit ist, wird jetzt nach dem Start ein Script aufgerufen, dass als Admin folgenden Befehl aufruft:

bcdedit /set {bootmgr} path \EFI\grub\grubx64.efi

Dann startet beim nächsten Start wieder Linbo (lokal).

viele Grüße

Hallo,
ich wollte nur sagen, dass ich nun genau an dieser Stelle stehe. Ich habe Dell Notebooks, bei denen der legacy boot mit linbo nicht funktioniert (=> Illegal partition table) und qäule mich nun mit efi.

Es ist bei mir genau so, wie Du beschreibst: Immer Windows und wenn man BIOS an der Bootreihenfolge “bastelt”, dann erscheinen Einträge. Einträge verschwinden. Es wird umsortiert.

Das einzige, was bisher ohne Probleme funktioniert hat: Der Windows Boot Manager ist vorne und wenn man an Linbo will, ein Netzwerkkabel anstecken und per F12 auf NIC booten.

In einem anderen Threat habe ich gelesen, dass cache nicht die letzte Parition sein darf. Ist das immer noch so?

Nun habe ich Dein Script probiert und schon wieder Probleme: Es gibt unter shell:startup einen Autostart Ordner aber das klappt nicht. Also in die Aufgabenplanung. Da habe ich aber das Problem: Die Rechner sind nicht in der Domäne, haben aber alle individuelle Namen. Ich habe es zwar noch nicht probiert, aber ich denke, es wird nach dem Klonen and 115-pc01\admin scheitern, wenn der Rechner 115-pc02 heißt.
Außerdem klappt die Aufgabenplanung im Moment auch nicht, weil es einfach Notebooks sind: User Admin, kein Passwort und da meckert die Aufgabenverwaltung.

Gruß,
Markus

Hallo,

In einem anderen Threat habe ich gelesen, dass cache nicht die letzte
Parition sein darf. Ist das immer noch so?

auch ich hatte mal das Problem, ist aber schon lange her.
Ich konnte es so lösen: cache nicht letzte Partition (warum auch immer).

Offensichtlich ist hier eine Logic im UEFI am Werk, das meint, immer den
Windows Bootmanager nach oben zu stellen: wer sollte den auch jemals auf
die Idee kommen was anderes booten zu wollen …

LG

Holger

IHallo,
die letzte Partition ist wie empfohlen bei uns nicht der Cache, aber leider hat das keine Abhilfe gebracht.
Ich werde im neuen Jahr die Geräte nochmals komplett von vor hochziehen und dann gucken - vielleicht hat sich das Problem dann ja behoben.

Viele Grüße
Manuel

Hallo,
ich glaube, ich habe das Script so eingerichtet, dass es vom lokalen Admin (der hat ein Passwort) aus aufgerufen wird (mittels Aufgabenplanung) - ich kann aber bei Interesse nochmals nachgucken. Die Lösung läuft seit meinem Post oben eigentlich gut.
Viele Grüße
Manuel die

Hallo,
ja das wäre sehr nett. Haben bei Dir diese Rechner verschiedene Namen?

Gerade eben, ich könnte fast lachen: Der ganze Aufriss kommt ja nur, weil diese Dell Notebooks bei legacy boot + linbo meinen: Invalid Parition table.

Unter efi hat das Einrichen und booten von Windows geklappt. Nur der Weg über Linbo ging nur mit Netzwerkstart. Nun habe ich alles so gelassen, habe dem cache eine feste Größe zugeteilt und noch eine sda5 am Ende (dummy).
Ergebnis: Invalid Parition table. Also genau wieder am Anfang. Arghhhhhh.

VG,
Markus

Hallo Markus,

Gerade eben, ich könnte fast lachen: Der ganze Aufriss kommt ja nur,
weil diese Dell Notebooks bei legacy boot + linbo meinen: Invalid
Parition table.

hast du mal folgendes probiert:

  1. Rechner von Stick booten und mit gparted eien MBR Patririon anlegen
  2. jetzt ein BIOS linbo booten udn Partitionieren.

Ich nehme an, dass die invalid Partitiontable möglicherweise daher
kommt, dass die Dinger mit einer GPT Partitionierten PLatte ausgeliefert
werden und linbo GPT nicht (ohne weiteress) in MBR umwandelt.

Dann könntest dudir das ganze Theater sparen mit uefi

LG

Holger

Hallo Holger,
wenn es so ist, müsste das unbedingt in die Anleitung. Diese Notebooks haben mich mittlerweile Tage gekostet…

Leider hat mir Dein Tipp nicht geholfen: Wieder Invaild Parition Table.

Nebenbei: Bisher liefen die Notebooks “problemlos” legacy unter Win7 mit fog. Ich habe noch einen alten fog herumstehen, denn ich für Bildschirm-Auflösungsgeschichten, Druckerzuweisungen und solche Sachen recht gerne noch nutze. Dann hatte ich diese Rechner in der custom dhcp. Aber alles aus einem Guß mit linbo wäre schon schöner. Das Upgrade auf Win10 kam wegen dem neuen Unifi WLAN. Denn wir wissen: WPA Enterprise unter Win7, das will man eher nicht … :wink: Und selbst wenn es gehen sollte: Da wäre linbo schon schön, damit das WLAN ein Schülers auch immer wieder herausgelöscht (gesynct wird).

Was ich jetzt noch testen werde. Zurück zu WIn 10 efi. Dann dem admin ein Passwort geben, damit die Aufgabenplanung nicht mehr schimpft und die Sache mit dem Skript oben probieren. Als man das Skript per Hand gestartet hat, hat es eigentlich so getan, wie gewünscht.

Ach ja: Die Parition hinter cache hat auch nichts gebracht. Ich habe dann nochmal geklont und er startet wieder Windows.

VG,
Markus

“Nachruf”: Danke Manuel Brendle.
Das Script hat die Lösung gebracht. Es muss in die Aufgabenplanung hinein, damit es beim Start als Admin ausgeführt wird. Leider muss deswegen der Schlepptop ein Passwort haben. Das Anhängen einer Parition nach cache hat bei mir nicht funktioniert. Mein Befürchtung, dass ein anderer Rechnername dazu führt, dass der 115-pc01\admin dann nicht mehr funktioniert, trat nicht ein. Das Skript startet auch auf geklonten Rechnern.

Hallo Leute,

Die Lösung mit dem Bios-Passwort klappt bei unseren Dell-Rechnern leider nicht. Er überschreibt die Startreihenfolge dennoch. Nun habe ich einfach den bcdedit-Befehl in eine Batch-Datei gepackt. Wenn man die von Hand (als Administrator) ausführt, dann reicht das auch für den nächsten Systemstart. Nun meine Frage: Wo packe ich diese Datei hin und wie bekomme ich Windows dazu, sie beim Systemstart als Administrator auszuführen? Der übliche Rechtsklick klappt bei Batch-Dateien nicht.
Viele Grüße, Andi

Hallo Andi,
das Script wird bei uns nach jedem Start über die “Aufgabenplanung” ausgeführt.
Vielleicht hilft das:

https://www.lexo.ch/blog/2012/04/starten-eines-cmd-bat-skripts-in-der-windows-aufgabenplanung-mit-administrator-rechten-als-nicht-angemeldeter-admin-benutzer/

Viele Grüße
Manuel

Hi,

Ich habe seit kurzem auf einem Rechner, der sein eigenes Image hat, das gleiche Problem. Warum??? Er hat bisher einwandfrei gebootet. Dann habe ich ein neues Image erstellt, Updates etc. Einfach nur vorhandenes Image aktualisiert.
Ich habe den Lösungsansatz noch nicht probiert, aber kann jemand erklären, warum, wieso sich die Bootreihenfolge plötzlich immer ändert? Zwischen früheren und jetzigem Image liegt ein Server Update und bestimmt auch Windows Updates.
Ich habe noch ca 35 identische PCs mit anderem Image. Passiert das gleiche, sobald ich das Image aktualisiere?

super. vorschlag hilft, egal, denke nicht über das wieso warum nach…

8 Beiträge wurden in ein neues Thema verschoben: (UEFI) Windows Installation verträgt PXE aus der Bootreihenfolge