bei mir funktioniert Linbo nicht so wie es vermutlich sollte. Was bei mir funktioniert:
Von einem Client ein komplett neues Image erstellen. Andere Clients dann formatieren / partitionieren und das komplette Image synchronisieren.
Was bei mir nicht funktioniert:
Differentielles Image erstellen. Oder auch nur einfach ohne die Formatierung am Client auf Synchronisierung klicken. Dann wird Synchronisierung gestartet und nach kurzer Zeit mit folgenden Fehlermeldung abgebrochen:
Image sync failed
rsync warning: some files vanished before they could be transferred (code 24) at main.c(1338)[sender=3.2.7]
files has vanished: (und dann kommen diverse Pfade von VS22 wie z.B.)
/mnt/Program Files/Microsoft Visual Studio/2022/Professional/Common7/IDE/CommonExtensions/Microsoft/TextMate/Starterkit/Extensions/shellscript/Snippets/do_done.tmSnippet
bitte stell sicher, dass auf dem Cleint, von dem das Iamge erstellt wird, vorher der hybride Schlafzustand ausgeschaltet ist. Ist er das nicht, dann fährt Windows nie herunter: und hinterläßt damit auch das Dateisystem nicht „sauber“.
Das kann dazu führen, dass ein Vollsync den SChlammeassel wieder herstellen kann, ein rsync aber nicht.
Es gibt auch nicht öffentliche Fähigkeiten von ntfs, die Windows verwendet, die ebenfalls beim syncen Probleme machen können. Das haben wir aber inzwischen mit moderneren ntfs Treibern im linbokernel ganz gut im Griff.
Trotzdem empfiehlt es sich auch vor dem Klonen Windows ein wenig ab zu specken.
Vor allem sollte man darauf achten, dass im Downloadverzeichnis für die Uüdates (C:\Windows\downloadedIRGENDWAS\ ) möglichst nichts mehr rum liegt.
Das bekommt man entweder durch die Windows Datenträgerbereinigung hin, oder man hält den updatedienst und den hintergrundübertragungsdienst an und löscht den Inhalt (so mach ich das: nicht jeder findet das eine Gute Idee ).
Aber wichtiger ist das mit dem Hybriden Schlaf.
Wie der ab zu schalten ist steht hier:
Beides ist beschrieben als „für Windows 10“ … funktioniert aber auch unter Windows 11… ist ja nciht gerade so, als das Microsoft dafür bekannt wäre, alte Zöpfe ab zu schneiden oder mal was wirklich neues zu entwickeln …
danke für die Rückmeldung. Ich habe das im regedit soeben überprüft. HibernateEnabled ist bereits auf 0. Aufräumen mit der Datenträgerbereinigung habe tatsächlich noch nie ausprobiert. Könnte ich mal machen.
Die Fehler werden allerdings ausschließlich von /mnt/Program Files/Microsoft Visual Studio/2022/Professional/ Einträgen verursacht. Es sind Dutzende verschiedene Dateien, aber alle in diesem Pfad, die nicht gefunden werden.
ich hatte tatsächlich erwartet, dass das Problem von windows selbst, oder von einer Microsoft Software hervorgerufen wird, weil Microsoft bei ihren eigenen Produkten eben „geheime“ Dateisystemeigenschaften verwendet wie „Schattenkopien“ (das gibt es seit ewigkeiten bei linux: dort heißt das Hardlinks).
Schau dir mal den
takedown
Befehl an in einem der beiden verlinkten wikiartikel: das könnte dir helfen bei dem Verzeichnis.
wenn der neue NTFS-Kerneltreiber bestimmte NTFS-Features unterstüzt, dann sind das keine „geheimen“ Sachen, die Microsoft da macht, sondern dann sind das öffentliche Sachen, die sogar in Open-Source implementiert wurden.
Schattenkopien sind speicherkonsistente Snapshots und keine Hardlinks. Allerdings können meiner erfahrung nach tatsächlich Hardlinks ein Problem für rsync sein. Der Befehl takeown (ohne d) steuert Besitzrechte (take ownership) an Dateien/Ordnern. Vor dem Aufzeichnen eines Images lohnt es sich bei Windows sporadisch mal ein chkdsk auszuführen. Das bereinigt dann ggf. auch nicht mehr gültige ACL-Einträge im NTFS, wenn dort irgendwann mal Benutzer(gruppen) Berechtigungen erhalten haben sollten, die es nicht mehr im Verzeichnisdienst gibt.
Dake für die weitergehenden Infos.
Zum Kerneltreiber: das Problem ist ja, dass er das eben nciht unterstützt: so hatte ich das auch gemeint.
Inzwischen ist er wirklich gut (der ntfs-3g), weswegen wir ja vor einiger Zeit auf den umgestiegen sind: aber manchmal trifft man trotzdem auf Probleme.
FSCheck ist tatsächlich eine Gute Idee: das hatte ich vergessen zu erwähnen
Hallo,
der im aktuellen Linbo verwendete Treiber ntfs3 stammt von Paragon. Dieser hat die neueste Version 3.1 der NTFS-Dateisystemspezifikation vollständig implementiert und unterstützt sogar Journaling. Da gibt es kein geheimes Wissen mehr.
Problematisch ist der Umgang von Linbo mit einem gesetzten Dirty Bit, das in der Regel einfach entfernt wird, um ein sauberes Herunterfahren vorzutäuschen. Dann ist das Dateisystem aber in einem inkonsistenten Zustand.
Die Fehlermeldung von Roman deutet ja auch auf ein beschädigtes Dateisystem.
Hallo zusammen,
ich habe es mit chkdsk /f und diff. Image probiert, führt leider zu gleichen Fehlern.
Wo kann ich eigentlich das vollständige Log des Vorgangs einsehen? Wird es irgendwo am Server gespeichert, wenn ein Linbo-Client die Synchronisierung abbricht?
Gruß
Roman
Das war nicht immer so. Das standardmäßige Entfernen des dirty bit wurde vor einiger Zeit auf vielfachen Anwenderwunsch implementiert. Ich sehe allerdings auf github keinen Issue, der fordert das zu ändern.
War das vielleicht eine Folge des neu aufgekommenen Hybrid Boot/Fast Start in Windows, den die Anwender nicht kannten und entsprechend das Windows eben nicht vor Aufzeichnung vollständig heruntergefahren war?
dann wäre es sinvoll, ähnlich zu Linux auch den Windowsbenutzern ein Skript zur Verfügung zu stellen, das sich um solche Dinge kümmert.
Im win11.reg und win10.reg wird Hybrid Boot/Fast Start zwar deaktiviert, aber das ist erst nach einem Reboot aktiv.
Ich stelle mal einen Vorschlag in ask rein.
@lmnuser
Wir sind hier etwas von deinem Problem abgekommen.
Ich hab VS2022 mal in einer VM installiert und kann den Fehler reproduzieren.
Die Datenintegrität der Festplatte ist vorhanden.
Ich vermute, dass es was mit Pfad oder dem Dateinamen auf sich hat und rsync damit Probleme hat.
Edit: Der Fehler ist ja bei der Image-Erstellung. Also quemu und nicht rsync…
Nein, Linbo kann Windowssysteme nicht starten, wenn auf der Root-Partition das dirty bit gesetzt ist. Die Partition muss mountbar sein, das ist sie so nicht.
@Blair
Vielen Dank, dass du das mit einer VM getestet hast. Wenn bei dir das gleiche Problem in Zusammenhang mit VS2022 auftritt, dann weiß ich zumindest, dass bei mir am Client nichts völlig falsch ist.
Der Fehler tritt übrigens nur bei der Erstellung eines differentiellen Images, nicht beim Voll-Image.
Bei Synchronisieren tritt allerdings dann ebenfalls ein rsync-Fehler auf. Synchronisieren mit frisch formatierten Platte geht. Synchronisieren mit bereits existierenden Daten → rsync Fehler.
Gruß
Roman
).