Blog

News from Nerdistan. Hier ist die Ausgangssituation: Ein älteres hochwertiges Laptop mit zwei SSD. Eine mit Windows 10, die andere mit Linux Mint 21.3 Virginia, Dual Boot per Grub. Nun wird der Speicher auf beiden Laufwerken knapp. Das Laptop hat einen weiteren freien M.2 SATA Steckplatz. Für wenig Geld kann ich eine Transcend-SSD im 2242-Format mit ausreichend Speicherplatz erwerben. Die ist schnell eingebaut und wird auch gleich vom System erkannt. Ich nehme das Problem vorweg, cloned Disk – duplicate UUID issue.

Mit der Gnome Disk Utility, bei Linux Mint unter Zubehör „Laufwerke“ zu finden, ist es zügig möglich, auf der neuen SSD eine Partition für Linux mit dem Dateisystem Ext4 bootfähig zu erstellen, zunächst gleiche Größe wie die alte Partition. Eine weitere Partition erhält das Dateisystem NTFS, sodass der Austausch von Daten zwischen Windows und Linux problemlos möglich ist. Theoretisch zumindest, denn auch hier gibt es natürlich Fallstricke. Dennoch, bis dahin ist noch alles recht einfach möglich.

Achtung, das neue Laufwerk hat jetzt die Bezeichnung /dev/sdb vom alten Linux-Laufwerk erhalten, welches anschließend /sdc heißt. Alle Laufwerke verwenden einen MBR, nicht GPT, das Laptop bootet im Legacy-Modus, nicht per UEFI. Ich habe das so belassen, um nicht noch weitere Probleme zu schaffen. Das Windows-Laufwerk, bei mir auf /sda, auf keinen Fall anfassen! Sonst droht noch mehr Ärger.

Jetzt wird es schon schwieriger, nämlich das Klonen der Linux Partition auf das neue Laufwerk. Das gelingt mit Bordmitteln per „sudo dd fi=/dev/sdc1 fo=/dev/sdb1 status=progress“ eigentlich recht simpel. Dabei ist das Dienstprogramm dd ein uraltes Unix-Kommando, hochwirksam und damit nicht ganz ungefährlich. Das Akronym dd kann auch statt „duplicate disk“ als „disk destroyer“ gedeutet werden. Aber diesmal hat alles gut geklappt.

Jetzt gilt es, noch Grub, den Linux Bootmanager, auf Triple Boot zu konfigurieren. Dabei geschehen zunächst merkwürdige Dinge, das System scheint beim Booten zufällig zwischen den beiden Linux-Laufwerken auszuwählen. Per „Laufwerke“ kann ich nämlich sehen, von welchem gerade gebootet wurde. Die zahlreichen Grub-Menueinträge sind nicht wirksam. Ich sichere die Daten aus dem Home-Verzeichnis, denn wer weiß, was noch geschieht.

Anschließend präpariere einen schnellen USB-Stick mit Linux Bordmitteln als Linux-Live-System. Die erforderliche ISO-Datei lade ich von der Website von Linuxmint.com. Jetzt kann ich problemlos vom USB-Stick aus booten. Eine WLAN-Verbindung zum Internet ist anschließend dennoch nötig, es empfiehlt sich unter „Keyboard“ auf das deutsche Layout umzuschalten. Die Bluetooth-Maus wird partout nicht erkannt, ich verzichte auf weitere Anstrengungen. Das Live-System enthält alle erforderlichen Utilities. GParted und Disks stehen zur Verfügung zum Umgang mit den Laufwerken.

Aber das wesentliche Utility ist immer Boot Repair. Dieses macht leider das System zwischenzeitlich nicht bootbar. Da kommt ordentlich Stress auf. Irgendwann bootet das System beim xten Durchlauf von Boot Repair wieder von /sdb1 aus richtig. Nicht jedoch von /sdc1 aus, das nur „grub_rescue“ anbietet. Die zufällige Auswahl der Linux-Systeme von /sdb1 aus bleibt bestehen.

Nachdem ich mir im Texteditor die Datei /boot/grub/grub.cfg angesehen habe, wird mir klar, dass die beiden Laufwerke die gleiche UUID haben. Das darf natürlich nicht sein, das chaotische Verhalten wie „disk at random“ kommt dadurch zustande. Wie das korrigieren? Den Gedanken, auf alte Laufwerksbezeicher (/sdb1 oder /sdc1 umzuschalten, verwerfe ich, da das nicht zukunftsfähig ist, und möglicherweise andere Probleme schafft.

Ich entscheide, die UUID der „alten“ Partition /sdc1 zu ändern. Das gelingt mit einer Option von GParted, das seinerseits zu diesem Zweck das Utility tune2fs benutzt. Zuvor ist allerdings mit GParted ein „Check“ dieser Partition nötig! Die UUID notiere ich mir sicherheitshalber. Der nächste Schritt ist das Mounten von /sdc1 mit „Laufwerke“, dann die manuelle Korrektur der UUID in der /etc/fstab über „sudo nano /media/..your_home…/… your_UUID…/etc/fstab“. Dabei tritt doch etwas Schweiß auf die Stirn. Eine Operation am offenen Herzen…

Das Ändern der UUID gelingt mir mit dieser Methode tatsächlich. Ich kürze nun etwas ab. Es empfiehlt sich vom Stick aus per Boot Repair beide Laufwerke /sdb1 und sdc1 mit einem komplett neuen Grub („purge“) zu versehen. Beginnen sollte man mit /sdc1, da hier die UUID verändert wurde. Ggf. könnte man danach noch von beiden Laufwerken aus sudo update-grub aufrufen. Spätestens jetzt sollte alles so funktionieren, wie gewünscht. Triple Boot, einmal Windows und zweimal Linux.

Das war insgesamt ein ziemlicher Irrweg, learning by doing. Ich habe nicht einmal alle Zwischenschritte aufgeschrieben. Aber dabei habe ich allerhand über Linux, die Utilities und Grub gelernt. Die vorhandenen drei Systeminstallationen blieben dabei unberührt. Cloned Disk – Duplicate UUID Issue, das Klonen per dd führt zunächst zu identischer UUID. Das sollte schon direkt nach dem Klonen behoben werden. Die Neuinstallation von Grub ist danach hilfreich. Möglicherweise reicht bei der empfohlenen Reihenfolge dann auch „sudo update-grub“ auf beiden Laufwerken, das mit der geänderten UUID zuerst.

Irritierenderweise ist die neue NTFS-Partition /dev/sdb2 nur lesbar, nicht beschreibbar. Das interessante Linux-Utility ntfs-3d meldet beim Aufruf von „sudo ntfs-3d dev/sdb2 /mnt/….“, dass die Partition nicht „clean“ sei, Windows Schnellstart und Energiesparoptionen müssten ausgeschaltet sein. Das gelingt mir unter Windows 10 per Admin-Kommandozeile durch Eingabe von „shutdown /g /t 000“. Danach klappt das Mounten und der Schreib-Lesezugriff auf die NTFS-Partition unter Linux Mint wie geschmiert.