Hallo @jochen,
tut mir leid, das zu lesen, aber hier auf meinen UEFI-Systemen kann ich das nicht nachvollziehen. Beim Windows-Sync werden die Partitions-UUIDs von EFI- und Windowspartition auf die Werte des Mastersystems gesetzt, beim Windows-Start werden die Windows-EFI-Bootdateien auf die EFI-Partition nach EFI/Microsoft/Boot kopiert und ein efibootmgr-Eintrag für „Windows Boot Manager“ erstellt, der auf den Bootloader "EFI/Microsoft/Boot/bootmgfw.efi auf der EFI-Partition verweist. Dieser Eintrag wird als BootNext markiert, dann rebootet. Läuft auf hier und woanders auch, denke ich, sonst hätten wir hier schon einen grandiosen Shitstorm.
Der Unterschied von 4.0.26 zu 4.0.27 besteht allein darin, dass der falsche Pfad /boot/efi nach /cache/boot/efi korrigiert wurde, d.h. unter 4.0.26 wurden die Windows-EFI-Bootdateien beim Start nicht auf die EFI-Partition kopiert. Heißt weiter, deine Systeme haben von einem Fehler profitiert. Hier müsste man weiter suchen.
Hilfreich beim Debuggen sind div. Konsolenausgaben von betroffenen Systemen.
Booteinträge:
efibootmgr -vblkid <efipartition>
Ausgabe von LInbo-Update:
rm /tmp/.*linbo_cmd update <serverip> <cachepartition>
Ausgabe des Linbo-Startbefehls, hierzu muss zunächst der Reboot abgeschaltet werden:
sed -i 's|reboot -f|echo no reboot|' /usr/bin/linbo_cmdlinbo_wrapper start:1
Bewirken die Linbo-Kernelparameter
forcegrub(bootet zuerst grub, welches dann das OS bootet, umgeht UEFI)noefibootmgr(überspringt das Bereitstellen der EFI-Bootdateien und Booteinträge, simuliert quasi oben erwähnten Fehler)
eine Verhaltensänderung?
Reboot ohne/mit Linbo-Start/Sync? Hatten wir IMO schon, hier findet das BIOS die Cachepartition nicht.
VG, Thomas