Hallo @thomas !
Die Situation mit linbo ist wie folgt:
- Die glibc-Fehler lassen sich bei mir umgehen, wenn ich auf den Clients den cache aktualisieren lasse (mittlerweile schon über 100 mal gemacht) → funktioniert
- die postsync-Datei auf meinen Clients ist noch eine mit Variablen für die ServerIP, die jetzt nicht mehr funktionieren - siehe Lmn 7.2 testing - #101 von foer
- ein Sync der zugehörigen Partition holt aber die aktuelle postsync-Datei - siehe Lmn 7.2 testing - #166 von thomas → funktioniert
Und jetzt kommt mein aktuelles Problem, für das ich keine Lösung finde - grub:
- Wenn ich nun einen U2204-Client synchronisiere, dann wird anschließend zum Starten im grub immer EINE feste Festplatten-UUID verwendet (ce6d5ca4-60df-…-a3ce).
Da die UUID nicht gefunden wird, landen alle synchronisierten Clients in der BusyBox und sind nicht mehr benutzbar.
Wenn ich mit linbo-ssh auf einem Client bin, erhalte ich mit „linbo_wrapper start:1“ folgende Ausgabe:
Starting Ubuntu 22.04 …
Found kernel boot/vmlinuz on partition /dev/sda2.
mk_boot /dev/sda2 boot/vmlinuz boot/initrd.img root=/dev/sda2 root=/dev/sda2 ro nosplash video=radeonfb vga=791 locale=de_DE
prepare_grub /cache/boot/grub /cache/boot/grub/grubenv /usr/share/grub
prepare_reboot /dev/sda /dev/sda2 /cache/boot/grub/grubenv boot/vmlinuz boot/initrd.img root=/dev/sda2 root=/dev/sda2 ro nosplash video=radeonfb vga=791 locale=de_DE /dev/sda1
repair_efi /dev/sda1
EFI bootnext for Ubuntu 22.04 has been set to 0002.
EFI bootorder has been successfully set.
BootNext: 0002
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0004
Boot0000* Diagnostic Program
Boot0001* grub
Boot0002* Ubuntu 22.04
Boot0003* Micron_1100_MTFDDAK256TBN
Boot0004* UEFI: PXE IP4 Realtek PCIe GBE Family Controller
Boot0005* UEFI: PXE IP6 Realtek PCIe GBE Family Controller
Installing GRUB in MBR/EFI of /dev/sda … OK!
Gestern konnten die Clients nach dem Synchronisieren noch starten, da hatte das postsync-Script aber noch den Fehler mit den Variablen. Trotzdem wurden die /etc/fstab der Rechner richtig gepatched und die Rechner waren benutzbar. (Vermutlich weil alle notwendigen Dateien noch im cache vorhanden waren.)
Wenn ich einen solchen Client heute starte, der noch kein aktuelles postsync erfahren hat, dann sieht die Ausgabe (über linbo-ssh) gleich aus und der Rechner startet weiterhin. Sobald aber einmal das postsync durchgelaufen ist, ist der Client kaputt.
Am postsync-Script selbst kann es aber nicht liegen, denn eine leere postsync-Datei liefert das gleiche Ergebnis.
Ich denke das fehlerhafte postsync-Script verhindert etwas anderes, was dann den grub „zerschießt“.
Wer hat eine Idee?
Gruß - Rainer