für eine neue Rechnerklasse brauch ich dringend das neue Linbo, also habe ich das Update jetzt und nicht in den Ferien gamacht. Jatzt habe ich nach Anleitung das Update von 6.1 erledigt und import und alles durchgeführt. Das neue linbo startet aus dem Netz. Das grub-Menü ist so angepasst, dass es mit einem Timeout von 10 Win7 automatisch startet.
Die linbo-remote-Befehle wurde abgesetzt und das neue Linbo startet auch.
Problem. Wenn man dann linbo wählt bekomme ich bei einigen Rechnern eine dauerbootschleife ins Grub-Menü!?!?
2.Problem: Einen Testrecher habe ich benutzt um ein neues .cloop zu erstellen und diesen dann gestartet, partitioniert und auf den “roten” Knopf gedrückt. Die Meldung ist die gleiche, wie auf dem Bild, nur im Linbo-Outfit. Es tut sich nichts weiter.
Einige der anderen Rechner versuchen nun beim Start von Linbo vor dem Start der grafischen Oberfläche dieses .cloop zu ziehen und bleiben auch hängen.
ich konnte das Problem mit einem reboot des Servers lösen. jetzt werden die Abblilder vernünfitg geladen und die Bootschleife ist wohl auch verschwunden.
Dafür habe ich ein weiteres Problem:
Wie in der Anleitung habe ich von einem Recher mit Linbo 2.3 ein IMG erzeugt.
Dann habe ich den Rechner mit Linbo neu partitioniert und ein Reboot gemacht. Jetzt konnte ich das neue IMG neu syncronisieren und habe mich darauf eingestellt mit dem Reperaturdatenträger nachzuhelfen.
Aber: Die Fehlermedung ist eine andere. “BOOTMGR ist missing.”
Hab trotzdem 8 mal die den Rereraturdatenträger durchlaufen lassen und HolgerTipps von hier: 6.2 + Win10: Start nicht möglich: "Bootmgr is missing"
getestet.
Ergebnis: Nichts hilft!
Dafür habe ich ein weiteres Problem:
Wie in der Anleitung habe ich von einem Recher mit Linbo 2.3 ein IMG
erzeugt.
Dann habe ich den Rechner mit Linbo neu partitioniert und ein Reboot
gemacht. Jetzt konnte ich das neue IMG neu syncronisieren und habe mich
darauf eingestellt mit dem Reperaturdatenträger nachzuhelfen.
Aber: Die Fehlermedung ist eine andere. „BOOTMGR ist missing.“
da fehlen wirklich Dateien: das hilft nicht nur die Bootreparatur.
Bitte den Client nochmal syncen und dann die Bootreparatur.
Wenn das nicht hilft: bitte mal die Logdateien eines Clients posten.
Im Notfall mal ein älteres Image nehmen.
im *image.log findet sich der Fehler. *linbo.log ist leer.
Warum macht er jetzt die Partition etwas kleiner?
Habe ich bei linbo-remote etwas vergessen?
linbo-remote -p initcache,reboot -r220
WOL funktioniert trotz Bios-Einstellung nicht. (Habe ich aber auch gestern zum ersten mal getestet.)
schlag in der start.conf einfach ein wenig auf die Partitionsgröße drauf.
Die UNterschiedlichen Größen rühren daher, dass linbo <2.3 fdisk als
Partitionstool verwendet hat udn linbo >2.3 gparted.
Wir mußten umsteigen, weil fdisk kein gpt kann, was wir für UEFI benötigen.
Die beiden Tools interpretieren die Partitionsgrößen aber leider leicht
unterschiedlich.
Nachdem du mit neuer Größe Partitioniert hast mit linbo und das Image
zurück gespielt hast, wir Windows höchstwahrscheinlich rumflennen, dass
es nicht booten könne, weil es seinen Bootloader nicht merh findet: dann
mußt du die startdateienreparatur von Windows Stick machen und, wenn es
wieder bootet, ein Image erstellen.
Tut mir Leid, dass es etwas aufwändig ist: linbo 2.3 war ein großer
Schritt … … und Windows flennt gerne rum …
Der technische Rückschritt bei Windows ist aber auch bemerkenswert.
Zwei Beispiele: die Updates: seit Vista können sehr viele Updates nicht
mehr im laufenden Betrieb eingespielt werden: deswegen beim
hoch/runterfahren die Meldungen.
Ebenso können die „alten“ updates seit Vista nicht mehr
ordentlich/vollständig entfernt werden. Seit Win7 SP2 gibt es zwar eine
Updatebereinigung in der Datenträgerbereinigung, die entfernt aber nur
ca. 1/3 des Updatevolumens: deswegen neigen alle Windwos Varianten seit
Vista zu einer biblischen verfettung in kurzer Zeit … wenn man UPdates
macht …
Das ist bei Win10 nicht anders.
Das zweite ist das Bootverhalten.
Während Windowsanhänger vor 20 Jahren linux belächelt haben, weil der
damals verwendete LILO die Plattengeometrie kennen mußte um die Letzte
Stufe des Bootcodes zu finden und dieser Code nicht jenseitz des 1024ten
Zylinders liegen durfte, gab es bei linux gerne mal bootprobleme.
Daher rührte auch die extra Bootpartition: damit sie vollständig
unterhalb des 1024ten lag.
Inzwischen will Windows unbedingt eine Bootpartition: der Grund ist zwar
ein anderer (Plattenverschlüsselung) aber der Effekt ist ähnlich. grub
bringt Dateisystemtreiber mit: deswegen muss es nur eine Partition
kennen, nicht die physikalische Lage des Bootcodes.
Der Windwosbootloader benötigt aber wohl inzwischen die physikalische
Lage… deswegen kann er nicht mehr booten, wenn sich was verschiebt …
technologische Rückschritt zu linux von vor über 15 Jahren …
