Hallo Klaus,
danke für den Hinweis. Ich werde das im nächsten Release von Linbo4 rausnehmen. Allerdings ist der Code so schon seit 26.10.2016 drin.
VG, Thomas
Hallo Klaus,
dein Problem hab ich an meinen Testsystem nachgestellt. Linbo überschreibt tatsächlich die Partionierung, indem die GPT Tabelle aus dem Cloop zurückgeschrieben wird. Die anschließende Startvorgänge von Windows und Linbo schlagen bei mir dann fehl. Über das UEFI des EXSI-Clients kann man aber das kopierte Windows System erfolgreich starten und normal nutzen. Das NTFS Dateisystem weist beim Check darauf hin, dass seine Anfangs- und Endpunkte nicht mit den Werten der GPT Tabelle übereinstimmen, ist selbst aber intakt und fehlerfrei. Die Größe ist mit der Partition identisch, es gibt keinen ungenutzen Platz. Die Angaben in der start.conf wurden ignoeriet.
Folgenden Workaround kannst du ausprobieren:
Erstelle eine neue Gruppe mit den Partitionen in der gewünschten Größe. Als Basisimage wählst du dein win10_21H1 Image aus. Die Clients der Gruppe mit Linbo partionieren und da sich der Name gptlabel.win10_21H1 nicht geändert hat und Linbo den nicht anpasst, bleibt die Partionierung hier beim Start erhalten. Die NTFS Partiton wird von ntfsresize erfolgreich angepasst.
Leider trifft dich dann aber ein anderer Fehler von Linbo. Da die von Linbo erstellte uuid der Festplatte nicht mit den gespeicherten Daten aus dem Image übereinstimmt wird Windows beim Start in einen BSOD geschickt. Das musst du dann reparieren oder du nimmt gleich ein generisches Image von Windows, um dieses Problem von Linbo dauerhaft zu umgehen.
Viele Grüße
Christian
Hallo Thomas,
wenn du das restore gpt label rausnimmts, funktioniert dann der Start von Windows noch?
Die ursprüngliche uuid der Festplatte, von der das Image stammt muss ja zurückgeschrieben werden.
Viele Grüße
Christian
Sollte kein Problem sein, die Anpassung der uuids werden an anderer Stelle gemacht. Evtl ist das gptlabel-Ding inzwischen obsolet. Wir werden sehen.
VG, Thomas
Hallo zusammen,
@Blair Danke Christian für die Bestätigung meiner Tests und Deinen Workaround. Diesen muß ich noch probieren.
Bei meinem Testsystem bootet der Client dann auch, bei einem anderen System dann leider nicht. Ist ja auch irgendwie verständlich, denn:
- Partitionieren mit den neuen Partitionsgrößen aus start.conf
- ntfsclone ok
- ntfsresize ok
Jetzt ist das Dateisystem so groß wie die Partition - Dann nimmt man die alte Partitionstabelle und schreibt diese mit
ddan den Anfang der Platte und beschneidet damit also das Dateisystem.
@thomas
Leider kann man den erwähnten Abschnitt nicht so ohne weiteres rausnehmen, da sonst Windows auch in einen BSOD läuft. 0xc000000e
Da müssen wir uns wohl noch ein paar Gedanken dazu machen, wie man das elegant lösen kann.
Danke und viele Grüße
Klaus
@thomas
Du hattest die Änderungen ja jetzt doch umgesetzt, trotz meines Kommentars. So denke ich, daß Deine Änderung im Zusammenhang mit dieser steht:
Ich kann die Umsetzung leider nicht testen, da ich das Paket linuxmuster-linbo7 aus testing nicht ohne größere Abhängigkeiten installieren kann. Aber ich denke Du weißt was Du tust 
Viele Grüße
Klaus
Ja, durch das Patchen der Disk-UUID wird gptlabel obsolet. Läuft hier.
VG, Thomas
Hallo Thomas,
wahnsinn, das ist ja Klasse! Damit werden auf einen Schlag gleich 2 wichtige Probleme gelöst:
- PC kann jetzt problemlos in eine andere Gruppe verschoben werden
- Partitionsgrößen können problemlos in Linbo geändert werden
- und vermutlich noch andere BSOD Ursachen, die damit behoben wurden
Danke! Ich freue mich auf die Umsetzung in stable!
Viele Grüße
Klaus
Die wird nicht kommen. Dafür fehlen die Ressourcen. Umstellen auf linuxmuster-linbo7 ist ohne großen Aufwand möglich: GitHub - linuxmuster/linuxmuster-linbo7: Next generation linbo
Hallo Thomas,
ich meinte linuxmuster-linbo7. Im Moment ist Deine Änderung ja noch in Testing, nicht in Stable.
Hallo @thomas
ich habe jetzt das Testing Repository mit Linbo 4.0.0-4 installiert und das Image laut Anleitung in ein .qcow Format konvertiert. Erstmal in start.conf die Partitionsgrößen so eingetragen, wie diese auch im Image waren, also 50G/50G. Wenn ich das Image dann zurückschreibe bekomme ich dann beim Starten von Windows den besagten Bluescreen 0xc000000e
Wenn ich die Partition ändere auf 75G/20G, partitioniere, neu+start, dann bleibt die Partitionsgröße so erhalten, aber ich bekomme auch einen BSOD
Im UEFI Bios sehe ich, daß kein Windows Bootmanager geschrieben worden ist.
Irgend etwas stimmt da noch nicht.
Viele Grüße
Klaus
Hallo Klaus,
ich habe hier ein Windows10-UEFI-Testsystem mit 60GB-Partition. Wenn ich das neu partitioniere und darauf ein Image restauriere, das in einer anderen Gruppe von einer 50GB-Partition gemacht wurde, bootet das ohne Probs. Die Windows-Datenträgerverwaltung zeigt 60GB für die Partition, Linbos fdisk sowieso. Allerdings habe ich vom Quellsystem ein neues Image mit Linbo 4.0.0 erzeugt. 
VG, Thomas
Hallo Thomas,
ok, ich habe jetzt auch ein Image mit 4.0.0 erzeugt und kann nun auch Partitionen vergrößern und auch in eine andere Gruppe verschieben.
Die Partition ist dann vergrößert, das ist richtig. Allerdings wird das Dateisystem nicht vergrößert, also ntfsresize wird nicht ausgeführt. Manuell ausgeführt klappt das. Evtl. kannst Du da nochmal schaun?
Wäre noch interessant, warum es nicht mit einem Image funktioniert, welches in Linbo 2.4.3 einwandfrei läuft. Evtl. läuft bei der Konvertierung des Images ins qcow2 Format etwas schief?
Danke!
Viele Grüße
Klaus
Weil erst ab Linbo 4.0.0-4 die Disk-UUID gesichert und gepatcht wird.
Was steht im log?
[StdOut] (99.02/100%)
[StdOut] (100.00/100%)
[StdOut] (100.00/100%)
[StdOut] Trying to resize filesystem on /dev/sda3.
[StdOut] ntfsresize v2017.3.23 (libntfs-3g)
[StdOut] Sectors allocated to volume : old 146800632 current 146800632 difference 0
[StdOut] Clusters allocated to volume : old 18350079 current 18350079 difference 0
[StdOut] ERROR: Cannot expand volume : the partition has not been expanded
[StdOut] ERROR: The backup bootsector does not match the old bootsector
## Sun Nov 28 08:51:39 CET 2021 : Update status of /dev/sda3 using win10-21H1.qcow2.
[StdOut] ## Sun Nov 28 08:51:39 CET 2021 : Update status of /dev/sda3 using win10-21H1.qcow2.
[StdOut] ## Sun Nov 28 08:51:39 CET 2021 : Full restore from win10-21H1.qcow2 finished.
[StdOut] Done.
[StdOut] Restoring disk guid of /dev/sda.
[StdOut] GPT fdisk (gdisk) version 1.0.3Manuell nachträglich ausgeführt:
win10-client1: ~ # fdisk -l /dev/sda
Found valid GPT with protective MBR; using GPT
Disk /dev/sda: 251658240 sectors, 0
Logical sector size: 512
Disk identifier (GUID): 3a93fec6-fce1-4990-993d-fb9448510b7a
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 251658206
Number Start (sector) End (sector) Size Name
1 2048 411647 200M EFI system partition
2 411648 673791 128M Microsoft reserved partition
3 673792 147474431 70.0G Basic data partition
4 147474432 189417471 20.0G cache
5 189417472 251656191 29.6G Basic data partition
win10-client1: ~ # ntfsresize /dev/sda3
ntfsresize v2017.3.23 (libntfs-3g)
Device name : /dev/sda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 53687087616 bytes (53688 MB)
Current device size: 75161927680 bytes (75162 MB)
New volume size : 75161924096 bytes (75162 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use : 24303 MB (45.3%)
Collecting resizing constraints ...
WARNING: Every sanity check passed and only the dangerous operations left.
Make sure that important data has been backed up! Power outage or computer
crash may result major data loss!
Are you sure you want to proceed (y/[n])? y
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device '/dev/sda3'.Hallo Thomas,
wenn die Images von Linbo 2.4.3 zu Linbo 4.0.0-x nicht kompatibel sind, dann macht es keinen Sinn, diese mit linbo-cloop2qcow2 zu konvertieren. Bitte also in das Tool einbauen, daß die Disk-UUID bei der Konvertierung entsprechend in die konvertierten Images gepatcht wird.
Danke!
Viele Grüße
Klaus
Hallo Klaus,
das ist AFAIK nur ein Problem bei Windows-Images, die mit mehreren Hardwareklassen genutzt werden.
Sicher könnte ich bei der Konvertierung die Disk-UUID reinpatchen, aber das Tool kennt die ja nicht. Man müsste die also erst selbst auf dem Rechner, auf dem das Image gemacht wurde, auslesen und dann per Parameter bei der Konversion übergeben. Falls das so als sinnvoll angesehen wird, bitte einen entsprechenden Issue anlegen.
VG, Thomas
Hallo Thomas,
das Problem trifft alle Windows UEFI Images. Dort wurde die uuid der Festplatte nur in der GPT Tabelle gespeichert. Ohne das restore gpt label wird das nicht wiederhergestellt und linbo-cloop2qcow2 erstellt keine .gpt.disk.
Viele Grüße
Christian
Issue erstellt: