Das war jetzt nicht so geil und hat uns mehr als drei Stunden gekostet. Wir haben gerade ein stranges Problem mit dem e1000e-Intelnetzwerkkartentreiber und das tritt sporadisch auf, das Linboproblem kam da mittenrein und ploetzlich ging gar nix mehr und die Techniker haben Abendunterricht in den Raeumen, also Zeitdruck. Altes Backup versucht zurueckzuspielen, das war so eine Dominonummer, wo man hinlangt faellt ein Steinchen und reisst unzaehlige mit sich.
Ich spiel das jetzt mal remote ein und schau ob das dann geht.
Gruss Harry
P.S. wenn Du uns was Gutes tun willst, dann pack wenn Du mal Zeit hast (hahaha…) in linbo-remote noch den Parameter postsync rein, also linbo-remote -g jammy_225 -p postsync , das ware fuer uns eine grosse Nummer.
Ich hab mir den Code selbst schonmal angesehen, werde aber nicht so ganz schlau aus dem Ablauf. Denke man muesste nur den Schritt sync weglassen.
Nochwas ist mir aufgefallen, kann aber auch wieder an unseren anderen Problemen liegen.
Das neue Linbo macht beim Umschalten auf dem Monitor ganz fiese Streifen, geht aber wieder weg. Aber schon im Limboschirm scheint mir das zu flimmern, ich hab gerade ein aehnliches Problem mit dem 6er-Kernel, der Startschirm crasht.
Hallo Thomas,
mit der neuen Version kann ich linbo auf einer leeren Festplatte wieder starten und die Partitionierung und Cache-aktualisierung klappt auch.
Grüße Ralf
Ich denke, jetzt haben wir wieder einen stabilen Stand mit verbesserten Möglichkeiten der Hardwareunterstützung. Und denkt dran immer schön einen Snapshot der Server-VM zumachen.
Hallo Thomas,
vielen Dank! Bei mir geht es jetzt auch wieder - ich musste aber linbo per USB-Stick booten.
Irgendwie zieht sich linbo nicht das aktuelle 4.2.9 (sonst hat sich doch beim Start von Linbo zunächst linbo sich selbst upgedatet) - oder mache ich da was falsch?
Wer lesen kann ist klar im Vorteil - steht ja oben alles. Danke! Hat sich also erledigt!
Vielen Dank für deine tolle Arbeit!
Danke für den Wink ich hatte schon -t ntfs-3g probiert, -t ntfs3 wäre es gewesen. linbo-mount dürfte der nachhaltigere Weg sein, habe ich entsprechend geändert,
kurz mal einen Zwischenstand: bei uns laufen derzeit alle Rechner wieder! Und mit den vielen neuen Möglichkeiten gibt es ein paar Stellschrauben mehr, mit denen man Probleme angehen kann. Vielen Dank @thomas dafür!
Was noch nicht gelingt: Netwerk-Boot vom Stick mit USB2LAN-Adapter. Währed ich bei eingebauter Netzwerkkarte im Aufnahmebildschirm lande, kommt bei USB2LAN-Adapter immer noch der Textbildschirm mit reboot/shutdown-Möglichkeit.
IP bekommt der Rechner und Zugriff per SSH ist möglich.
Händisch Aufnehmen und linbo-remote-Befehl lösen das Problem für uns (wir nehmen eh seltenst über die GUI auf), aber ich gebe es trotzdem mal weiter.
Meine Vorgehensweise war bei LINBO-4.2.8-1-Clients die partout nicht das 4.2.9 ziehen wollten so:
auf grub_forced_netboot auf dem server umstellen
mittels linbo-ssh auf den Client gehen (soweit erreichbar)
mittels efibootmgr auf PXE Boot umstellen mit (efibootmgr -n (IPv4 PXE Eintrag))
reboot
Dann war da LINBO 4.2.9 drauf
Etwas was mir noch aufgefallen ist war das solange der forced_netboot auf dem Server aktiv war, dass das zweite Betriebssystem auf dem Client nicht booten wollte, Fehlermeldung war „Unable to mount operating system Partition /dev/nvme0n1p4“ o.ä… Nachdem der forced_netboot auf dem Server wieder zurückgesetzt wurde funktionierte das allerdings wieder nach einem Clientreboot.
Noch ein Vorschlag: Es wäre cool wenn die Hardwareklasse beim einloggen mit linbo-ssh auch angezeigt werden würde
Abend,
forced_netboot hat auch hier getan, wenn ich nur mal eben einen Rechner an Linbo zwingen will, dann geh ich in die Konsole am Rechner und Nulle die Festplatte mit dd if=/dev/zero of=/dev/nvme0n1 , danach reboot. Man braucht auch nicht warten bis die durchgenullt ist, nach ein paar Sekunden kann man das abbrechen.
mir ist aufgefallen, dass ein alternativer Linux-Kernel aus der start.confbei UEFI-Systemen nicht übernommen wird.
Wir haben einige Surface-Geräte und für die ist ein eigener Kernel im Image. Bisher wurde dieser (vmlinuz-surface/initrd.img-surface) auch gebootet, so wie er in der start.conf angegeben war. Derzeit bootet aber nur vmlinuz/initrd.img, egal, was ich angebe.
Erneut: ob das 7.2-spezifisch ist, kann ich nicht sagen, die letzte Synchronisation eines Surface-Gerätes liegt lange zurück.
Man bekommt das auch über Postsync-Skripte repariert, aber es wäre schön, wenn das grundsätzlich möglich wäre.
Für dieses „Black Week“ Release habe ich mal ein wenig aufgeräumt und obsoleten Code entfernt. Außerdem sind ein Paar kleinere Fixes im Angebot:
auf manchen Systemen schob der Kernel in seiner Tabelle das WLAN- vor das Ethernet-Adapter, was unschöne Effekte zur Folge hatte (eth0 wurde nicht intialisiert und immer wlan0 benutzt). Das habt ihr wahrscheinlich nicht bemerkt, weil ihr das Feature nicht nutzt. Ich schon.
Das linbo_gui startete beim Booten von Iso nicht.
nomodeset ist jetzt bei unregistrierten Clients standardmäßig gesetzt, damit die auch sicher in das Gui booten.
Bzgl. Kernel ist für manche die Version 6.6.2 evtl. schon eine vorgezogene Bescherung, es enthält nämlich einen Fix für den nvme-Treiber („Driver may return an error before submitting the command to the device.“).
Das Beste zum Schluss: Da jetzt mehrere Kernels zu packen sind, zog sich der Paketbau in die Länge. Nicht schön. Zum Glück gibt es xz, das bei gleicher Kompressionsleistung deutlich performanter agiert als lzma. Also habe ich kurzerhand die Kernel- und Linbofs-Komprimierung auf xz umgestellt und kann jetzt früher Feierabend machen. Ihr habt natürlich auch was davon: update-linbofs ist jetzt ca. 3mal schneller und beim Linbo-Boot ist die Verkürzung der Bootzeit ebenfalls signifikant. Bleibt zu erwähnen, dass ein mit xz komprimiertes Linbofs klarerweise nicht mehr linbofs64.lz heißen kann. Also wird es im Zuge des Paketupgrades einfach in linbofs64 umbenannt. Eure grub configs werden automatisch angepasst und vorher gesichert. Zur Sicherheit wird zusätzlich das neue linbofs64 nach linbofs64.lz verlinkt, sodass Clients, die aus irgendeinem Grund stockkonservativ sind, noch auf ihre Kosten kommen. Danach ist es trotzdem eine gute Idee linuxmuster-import-devices zu starten, damit auch die oben erwähnte Aufräumaktion zur Geltung kommt.
ich hatte schon 