Grub und geklonte Festplatte

[HRo]

Moin,
ich habe in meinem Notebook zwei Laufwerke (SSD & M.2 NVMe SSD).

Slot 2 (sbd)( M.2 NVMe SSD) das ursprüngliche Dualbootlaufwerk mit Debian und Windows.
Das zweite Laufwerk (sda)(SSD) in Slot 1 ist ein Klon von dem Laufwerk in Slot 2.

Wenn ich mittels Grub die Windows-Installation auswähle, dann nutzt Windows sofort die Partition auf dem Klon (sda). Soweit super.

Debian aber nutzt weiterhin die Slot 2 (sdb).
Was muss ich jetzt wo ändern, damit auf Debian vom Klon startet.

Wie kann ich erkennen, welches Grub (Slot 2 oder Slot 1) aktiv ist?
Wie kann ich unter Debian ermitteln - ob Slot 2 oder Slot 1 genutzt wird?

Gruß Heiko

[cosinus]

Moment mal, nicht so schnell. Was genau hast du da wie genau geklont? Die gesamte Platte /dev/sda zu /dev/sdb? Falls ja, zu welchem Zweck?

[debiankaios]

Spontan würde ich sagen das du beim Mainboard die Boot-Reihenfolge abändern musst(zu sda). Es könnte sein(ich kenne mich mit Windows nicht aus) das Windows direkt auf die richtige Festplatte zugreift.

[cosinus]

Spontan würde ich sagen das du beim Mainboard die Boot-Reihenfolge abändern musst(zu sda). Es könnte sein(ich kenne mich mit Windows nicht aus) das Windows direkt auf die richtige Festplatte zugreift.

Windows tickt leider tw. sehr bescheuert. Ich kann mich gut daran erinnern, dass sich Windows einfach nicht auf eine andere Platte installieren lassen wollte, d.h. es wollte sein Bootvolume immer auf die erste Platte ablegen. Egal ob man die Syspartition woanders hinhaben wollte. Und deswegen kann ich mir auch gut vorstellen, dass trotz scheinbarem erwarteten Verhalten, Windows wieder auf die ursprünglichen, also ersten Platte operiert.

Mal sehen was der TO noch so schreibt. Denn ich sehe keinen Sinn eine Platte zu klonen und dann diese Klonplatte im selben Rechner zu lassen. Wer sowas tut hat meinem Eindruck nach zu wenig Erfahrung damit wie Windows tickt (geschweige von UUIDs in Datenträgern und Volumes)

[HRo]

Moin,

Moment mal, nicht so schnell. Was genau hast du da wie genau geklont? Die gesamte Platte /dev/sda zu /dev/sdb? Falls ja, zu welchem Zweck?

Die eingebaute "M.2 NVMe SSD" wurde zu klein.
Deshalb habe ich in den noch freien SSD-Slot eine SSD eingebaut.
Dann habe ich die vorhandene Platte geklont.
Da die SSD für das Mainboard die erste Platte ist, hätte ich jetzt erwartet, das Grub und Linux von dort genutzt werden.
Von wo Grub jetzt startet weiß ich nicht, aber Linux nutzt noch die alte Platte und Windows schon die Neue.

Aus meiner Sicht habe ich jetzt mehrere Möglichkeiten:

• 1. Ich akzeptiere die aktuelle Situation und lösche auf der Platte die Windows nutzt den Linux-Bereich und umgekehrt

• 2. Ich lösche Linux auf der Windows-Platte und die komplette kleine Platte, hoffe das Grub von der ersten Platte genutzt wird und installiere Debian neu

• 3. Ich mache alles platt, installiere erst wieder Windows und dan Debian

• 4. Ich finde heraus welches Grub genutzt wird, sorge dann dafür das das auf der neuen Platte genutzt wird und passe es so an, das auch das Linux auf der neuen Platte genutzt wird

• 5. ???

Gruß Heiko

[HRo]

Moin,

Spontan würde ich sagen das du beim Mainboard die Boot-Reihenfolge abändern musst(zu sda). Es könnte sein(ich kenne mich mit Windows nicht aus) das Windows direkt auf die richtige Festplatte zugreift.

Laut Bios, gibt es eh nur die neue Platte an Port 1.

Gruß Heiko

[DeletedUserReAsG]

Die betreffende Konfigurationstemplates finden sich unter /etc/grub.d/, zum Testen kann man Änderungen auch erstmal direkt in der /boot/grub/grub.cfg vornehmen. Dabei drauf achten, auf der Platte zu arbeiten, welche von der Firmware des Rechners (früher BIOS genannt) des Rechners aufgerufen wird – wärest nicht der Erste, der auf der falschen Platte hantiert und sich wundert, warum die Änderungen keinerlei Auswirkungen haben

Es gibt zudem das Programm os-prober, das dir auf Wunsch alle bootbaren Systeme in die GRUB-Config schreibt, wenn du dich nicht manuell drum kümmern möchtest.

Ich hoffe, du hast dem geklonten Dateisystem eine eigene UUID gegeben? Ansonsten hättest du nämlich das zweite „U“ ausgehebelt, und den Weg für undefiniertes Verhalten des Systems freigemacht.

[HRo]

Moin,

Ich hoffe, du hast dem geklonten Dateisystem eine eigene UUID gegeben? Ansonsten hättest du nämlich das zweite „U“ ausgehebelt, und den Weg für undefiniertes Verhalten des Systems freigemacht.

Also, ich habe bewusst keine UUID neu vergeben. Ich habe zum Klonen "Rescuezilla" genutzt und da wurde ich auch nicht nach einer neuen UUID gefragt.
Kann ich die UUID nachträglich ändern (am Besten wohl von der alten Platte)?

Gruß Heiko

[DeletedUserReAsG]

Kann ich die UUID nachträglich ändern (am Besten wohl von der alten Platte)?

Ich kenne dieses Rescuezilla nicht, du solltest also zunächst erstmal schauen, ob es da überhaupt ein Problem gibt. Ein Werkzeug, um das in Erfahrung zu bringen, wäre beispielsweise blkid.

[grubenlicht]

zunächst mal müßte die Bootmethode (EFI/"legacy") geklärt werden. (bei Anwesendheit von Windows 10 reicht dazu ein 'parted -l')
Und btw., Original und Klon in einem PC? Soll das eine Sicherungskopie sein?

[HRo]

Moin,

zunächst mal müßte die Bootmethode (EFI/"legacy") geklärt werden. (bei Anwesendheit von Windows 10 reicht dazu ein 'parted -l'

Weder unter Windows 10 noch unter Debian wird der Befehl gefunden.

Und btw., Original und Klon in einem PC? Soll das eine Sicherungskopie sein?

Nein, keine Sicherungskopie. Umzug von kleiner M2.SSD auf eine größere SSD.
Nur leider wird durch Grub nur Windows von der neuen Platte gestartet.
Debian startet weiterhin von der alten "Platte". So mag ich natürlich nicht die zweite Platte löschen.
Da ich dieses Verhalten auch erst festgestellt habe, nachdem ich das Notebook wieder zusammen gebastelt habe, möchte ich das Problem gerne ohne erneutes Zerlegen lösen.

Gruß Heiko

[HRo]

Moin,

Ein Werkzeug, um das in Erfahrung zu bringen, wäre beispielsweise blkid.

Das Tool gibt es in meinem Debian nicht und wird auch nicht als installierbares Tool im Katalog von "Discover" gefunden.

Gruß Heiko

[MSfree]

Moin,

Ein Werkzeug, um das in Erfahrung zu bringen, wäre beispielsweise blkid.

Das Tool gibt es in meinem Debian nicht

Code: Alles auswählen

/usr/sbin/blkid

[fischig]

blkid ist Bestandteil des Paketes util-linux. Kann mich nicht erinnern, dieses Paket jemals nachinstalliert zu haben. Meiner Laienmeinung nach ist das ein Kernbestandteil einer Debian-Installation.

Das Kommando blkid erfordert Root-Rechte.

[MSfree]

Das Kommando blkid erfordert Root-Rechte.

Nein, aufrufen läßt es sich auch als normaler Benutzer.

Aber entweder ist die Angabe des vollständigen Pfads nötig oder eben su -, damit die PATH-Variable korrekt gesetzt ist.

Alternativ kann man aber auch

Code: Alles auswählen

lsblk -fs

aufrufen, auch ohne root-Rechte.

[fischig]

Aber entweder ist die Angabe des vollständigen Pfads nötig

So ist das hier. und der Pfad ist hier /sbin/blkid. Fällt mir meistens nicht auf, weil ich bei sowas eh als Root arbeite und dann geht's auch ohne Pfad.

[grubenlicht]

...reicht dazu ein 'parted -l'

Weder unter Windows 10 noch unter Debian wird der Befehl gefunden.

sorry, hatte wohl zu viel vorausgesetzt. In Linux, im Terminal führst du den Befehl

Code: Alles auswählen

parted -l

als "root" aus # es ist ein kleines L (du hast wohlmöglich parted -1 geschrieben ?)

Und für die Ermittlung von UUID nimmst du eher

Code: Alles auswählen

lsblk -f

für blkid sind immer RootRechte erforderlich!

[cosinus]

Die eingebaute "M.2 NVMe SSD" wurde zu klein.
Deshalb habe ich in den noch freien SSD-Slot eine SSD eingebaut.
Dann habe ich die vorhandene Platte geklont.
Da die SSD für das Mainboard die erste Platte ist, hätte ich jetzt erwartet, das Grub und Linux von dort genutzt werden.
Von wo Grub jetzt startet weiß ich nicht, aber Linux nutzt noch die alte Platte und Windows schon die Neue.

Also ich hätte die ursprüngliche (kleine) Platte nach dem Klonen ausgebaut und geschaut ob man wirklich vom Klon auch aus so booten/arbeiten kann wie gedacht. Und vllt ne Zeit lang hätte ich die kleinere SSD einfach in den Schrank gelegt und wenn ich mir sicher bin, dass alles OK ist, diese dann geleert.

Wie und wovon gebootet wird ist Einstellungssache. Du kannst nicht davon ausgehen, dass automatisch "von der ersten Platte" gebootet wird. Woher weißt du denn überhaupt, dass die andere SSD die erste sein soll? Ist die neue/größere SSD denn auch eine M2-SSD?

[MSfree]

für blkid sind immer RootRechte erforderlich!

Auch für dich nochmal: das ist schlicht und ergreifend falsch. blkid darf man als normaler Benutzer ausführen und es kommt auch dieselbe Ausgabe wie mit root-Rechten. Das einzige Manko ist, daß blkid sich in /usr/sbin befindet und damit nicht im PATH eines normalen Benutzers liegt, was jedoch kein Hinderungsmechanismus ist, es als normaler Benutzer auszuführen.

Noch was:
/sbin/blkid und /usr/sbin/blkid sind ein und dieselbe Datei. Auf meine Bullseye liegen die auf derselben iNode, sind also hart verlinkt.

[cosinus]

Noch was:
/sbin/blkid und /usr/sbin/blkid sind ein und dieselbe Datei. Auf meine Bullseye liegen die auf derselben iNode, sind also hart verlinkt.

Hart verlinkt? /sbin ist doch ein Symlink, der auf usr/sbin zeigt oder nicht?

Code: Alles auswählen

$ file /sbin
/sbin: symbolic link to usr/sbin

[MSfree]

/sbin ist doch ein Symlink, der auf usr/sbin zeigt oder nicht?

Ach stimmt, da hatte ich gar nicht hingesehen.

[grubenlicht]

...
Auch für dich nochmal: das ist schlicht und ergreifend falsch. blkid darf man als normaler Benutzer ausführen und es kommt auch dieselbe Ausgabe wie mit root-Rechten.

Du hast wohl recht, allein, ich bin halt hier gestolpert

Code: Alles auswählen

test@test-db:~$ blkid
bash: blkid: Kommando nicht gefunden.
test@test-db:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0    8G  0 disk 
├─sda1   8:1    0  512M  0 part /boot/efi
├─sda2   8:2    0  6,5G  0 part /
└─sda3   8:3    0  977M  0 part [SWAP]
sr0     11:0    1 1024M  0 rom  
test@test-db:~$ /sbin/blkid
test@test-db:~$ /sbin/blkid /dev/sda1
test@test-db:~$ /sbin/blkid
/dev/sda2: UUID="6f96c85d-38ca-4c3b-9faf-07ac141034da" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b5c5f964-c45a-4041-8d9e-1872f9947638"
/dev/sda3: UUID="04dde2df-1c93-4125-95a7-ceed215308d5" TYPE="swap" PARTUUID="966ad30a-83bb-440f-97ea-bb5247ce155f"
/dev/sda1: UUID="5F42-B11A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ec64214e-6122-4b91-9cfd-a870d6f76ff2"
test@test-db:~$ 

warum das jetzt bei der letzten Eingabe funktioniert, bei den zweien davor aber nicht…?

[HRo]

Moin,

Also ich hätte die ursprüngliche (kleine) Platte nach dem Klonen ausgebaut und geschaut ob man wirklich vom Klon auch aus so booten/arbeiten kann wie gedacht. Und vllt ne Zeit lang hätte ich die kleinere SSD einfach in den Schrank gelegt und wenn ich mir sicher bin, dass alles OK ist, diese dann geleert.

Tja, bin in dem Fall etwas zu naiv an die Sache herangegangen.

Wie und wovon gebootet wird ist Einstellungssache.

Wie und wo?

Du kannst nicht davon ausgehen, dass automatisch "von der ersten Platte" gebootet wird.

Weiß ich inzwischen leider auch.

Woher weißt du denn überhaupt, dass die andere SSD die erste sein soll?

Vielleicht daher, das sie die einzige Platte ist, die im Bios angezeigt wird.
Die M2 im Slot 2 wird nicht angezeigt (obwohl von Debian genutzt)

Ist die neue/größere SSD denn auch eine M2-SSD?

Nein. Ist eine "normale" SSD.

Gruß Heiko

[HRo]

Moin,

Code: Alles auswählen

blkid

gibt folgendes aus:

Code: Alles auswählen

/dev/sda1: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="F8B7-E6D9" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="ca8f72e9-4c81-4b72-84e0-22d3ca049195"
/dev/sda3: LABEL="Windows_1" BLOCK_SIZE="512" UUID="4CE8BAD6E8BABE10" TYPE="ntfs" PARTLABEL="Basic data partition - Windows_1" PARTUUID="58ff2c9b-4807-4763-bbf3-bab66e0c378c"
/dev/sda4: BLOCK_SIZE="512" UUID="A81C0C9D1C0C6920" TYPE="ntfs" PARTUUID="f5f9a4e6-0622-44e3-bcb6-53c7411762a7"
/dev/sda5: UUID="d3fcee1f-92a8-4f85-aa49-4da19e56bdc5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="linux_1" PARTUUID="5c0db36e-d2a3-45d1-b017-d57336d075ef"
/dev/sda6: LABEL="Recovery" BLOCK_SIZE="512" UUID="4E7ABB4D7ABB3097" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="d21c64dc-c935-4b87-8368-5e054235dc81"

/dev/sdb1: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="F8B7-E6D9" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="04843eb7-8775-11ed-a9fe-b80478eb218e"
/dev/sdb3: LABEL="Windows_2" BLOCK_SIZE="512" UUID="4CE8BAD6E8BABE10" TYPE="ntfs" PARTLABEL="Basic data partition - Windows_2" PARTUUID="04843eb9-8775-11ed-a9fe-b80478eb218e"
/dev/sdb4: BLOCK_SIZE="512" UUID="A81C0C9D1C0C6920" TYPE="ntfs" PARTUUID="04843eba-8775-11ed-a9fe-b80478eb218e"
/dev/sdb5: UUID="d3fcee1f-92a8-4f85-aa49-4da19e56bdc5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="linux_2" PARTUUID="04843ebb-8775-11ed-a9fe-b80478eb218e"
/dev/sdb6: LABEL="Recovery" BLOCK_SIZE="512" UUID="4E7ABB4D7ABB3097" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="04843ebc-8775-11ed-a9fe-b80478eb218e"

/dev/sda2: PARTLABEL="Microsoft reserved partition" PARTUUID="c6051731-6ab9-47df-afff-63aff9f4246b"
/dev/sdb2: PARTLABEL="Microsoft reserved partition" PARTUUID="04843eb8-8775-11ed-a9fe-b80478eb218e"

Code: Alles auswählen

lsblk

gibt folgendes aus:

Code: Alles auswählen

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465,8G  0 disk 
├─sda1   8:1    0   260M  0 part 
├─sda2   8:2    0   128M  0 part 
├─sda3   8:3    0 195,2G  0 part /mnt/4CE8BAD6E8BABE10
├─sda4   8:4    0   552M  0 part 
├─sda5   8:5    0 268,6G  0 part 
└─sda6   8:6    0     1G  0 part 
sdb      8:16   0 223,6G  0 disk 
├─sdb1   8:17   0   260M  0 part /boot/efi
├─sdb2   8:18   0   128M  0 part 
├─sdb3   8:19   0  97,5G  0 part 
├─sdb4   8:20   0   552M  0 part 
├─sdb5   8:21   0 124,1G  0 part /
└─sdb6   8:22   0     1G  0 part 
sr0     11:0    1  1024M  0 rom  

Auf welchem Laufwerk muss ich jetzt in welchem Ordner welche Datei bearbeitet, damit beide Systeme die SSD in Slot 1 nutzen?

Gruß Heiko

[HRo]

Moin,

Aus meiner Sicht habe ich jetzt mehrere Möglichkeiten:

• 1. Ich akzeptiere die aktuelle Situation und lösche auf der Platte die Windows nutzt den Linux-Bereich und umgekehrt

Selbst wenn ich jetzt diesen Weg gehen würde, dann müsste ich immer noch verstehen, wo steht welches OS von wo bootet, damit ich im Störungsfall die entsprechenden Einträge wieder herstellen könnte.

Gruß Heiko