Hallo zusammen, weiterführend zu dem Thread "SSD kaputt" möchte ich gerne noch einige Informationen sammeln, bevor ich die SSD kopiere. Da die neue SSD größer ist als die alte und ich die Partitionen gerne in einer anderen Reihenfolge hätte, habe ich die neue SSD erst einmal partitioniert. beide GPT Partitionsschema alt: 49GB ext4 Opensuse 15.4 500MB fat16 EFI 47GB ext4 Opensuse 15.5 neu: 500MB fat32 EFI 50GB ext4 Opensuse 15.4 50GB ext4 Opensuse 15.5 Rest erstmal unbelegt Ist das so zulässig ? Nur damit ich's verstehe: Reicht es eigentlich nicht, wenn ich den Inhalt der jeweiligen Partition "alt" oben auf die zugehörige Partition "neu" kopiere ? (alle alten Partitionen werden NICHT benutzt) Oder muss da noch etwas auf die neue SSD kopiert werden, das sich an einer Stelle befindet wo ich über den Mountpoint nicht hinkomme. Denke da an sowas wie den MBR, gibt's unter GPT was ähnliches? Ich habe mir auch einen USB-Stick mit Clonezilla gemacht und werde mir das da mal ansehen. Wenn ich dann die neue SSD fertig habe, kann ich die dann einfach an Stelle der alten SSD einbauen, das UEFI anpassen und die Kiste bootet ? Danke für erhellendes? Werner
Am 03.11.23 um 16:11 schrieb Werner Franke:
Nachtrag: Grup2 war das Zauberwort. Wie kommt grub2 auf die neue SSD ? Clonezilla sagt was von grub, aber ich denke das ist nicht Grub2. Leider finde ich nichts passendes im Internet, was meinen Fall beschreibt. Um den Grub2 schreiben zu können, muss doch von dem jeweiligen System gebootet sein (?) Bei (sehr) alten SUSE Installationsmedien gab es den Punkt Installiertes System starten Ich habe nur einen Net-USB-Stick von 15.5 und ob das da noch drauf ist habe ich noch nicht nachgeschaut. Habe das Feature schon lange nicht mehr benötigt. Kann mir bitte jemand einen Tipp oder eine URL geben ? viele Grüße Werner
Am Freitag, 3. November 2023, 18:03:24 CET schrieb Werner Franke:
Hallo, mangels besserer Kenntnis würde ich erstmals die ganze Platte klonen und mich um die Partitionsgrößen später mit gparted kümmern, nachdem die alte Platte auch schon GPT hat. Dann ist der Bootsektor auch mit dabei, und dass die neue Platte größer ist, sollte kein Problem sein. Allerdings weiß ich nicht, ob dein Vorhaben umsetzbar ist. Nach alter Schule dürfen Boot- u. OS-Partitionen nicht verschoben werden, anderenfalls muss der Boot-Manager angepasst werden. Weiß nicht, ob das noch gilt, gparted gibt jedenfalls eine beängstigende Warnung aus. Grüße Richard
Hallo, Am 03.11.2023 um 20:47 schrieb Richard Hafenscher:
Was sollte daran "unzulässig" sein? Was sind Deine Bedenken?
So etwas in der Art meine ich bei meinen letzten Tests mit 15.5 auch gesehen zu haben. Je nachdem, wie grub konfiguriert ist, könntest Du bei einer exakten Kopie mittels dd sogar gute Chancen haben, dass das System neu startet. Ich muss allerdings gestehen, dass ich etwas aus der Übung mit SUSE bin, weil ich wegen AD-DC zu ubuntu gewechselt bin. Ich würde grundsätzlich bei solchen Sachen immer mit einem kompletten Stick experimentieren.
Doch. Denn anders als MBR schreibt GPT seine Infos an den Anfang und an das Ende der HDD [1]. Wenn die neue SSD größer ist, landen diese Infos nicht am Ende, sondern irgendwo in der Mitte - wo sie nicht hingehören. Ich hatte mit gparted aber bisher immer die Erfahrung gemacht, dass es das "reparieren" konnte. Ich würde es also tatsächlich so machen, die alte SSD 1:1 mittels dd auf die neue SSD zu übertragen und dann schauen, wie weit ich mit gparted komme. Gruß, Alex [1] https://de.wikipedia.org/wiki/GUID_Partition_Table#Header_der_GUID-Partition... -> nebst schönem Bild
Hallo, warum nicht gleich mit Gparted Live das ganze erledigen? Habe schon mehrmals eine kleinere SSD durch eine größere ersetzt, der folgenden Prozedere nach: 1) Neue SSD extern oder intern einbauen; 2) Live System starten; 3) Mit Gparted eine neue Partitionstabelle auf der *neuen* SSD machen; 4) Partitionen von der alten auf neue SSD kopieren, ggf. dabei vergrößern; 5) Fertig (alte SSD ausbauen, dann booten)! GGf. mit "grub-repair" mögliche Boot-Probleme beheben. BG, Kimmo la, 2023-11-04 kello 09:54 +0100, Alex Winzer kirjoitti:
Hallo Richard, Alex, Kimmo, Am 04.11.23 um 11:53 schrieb Kimmo Elo:
vielen Dank für Eure Tipps. Wie ihr eventuell in diesem Thread mit "[erledigt]" im Subject gelesen habt, steht dort, was ich so gemacht habe. Inzwischen habe ich auch herausgefunden, dass sie alte SSD noch einen MBR, keinen GPT, hat. Vor 11 Jahren gab's GPT wohl noch nicht. Als ich den Bericht geschrieben habe, wusste ich noch nicht, dass das ältere der beiden OS (15.4) nicht bootot und die letzten Tage mich viel mit Grub2 und EFI beschäftigt. Das war es aber nicht. Nachdem ich gestern eine neue initrd für 15.4 gemacht hatte, funktioniert jetzt wieder alles. Sieh auch Thread "Dualboot: EFI unvollständig" Viel Grüße Werner
Hallo, nur mal als Tip. In den meisten Fällen kann man ganz gut auch mit virtuellen Systemen arbeiten. Das vermeidet Fehlerquellen und Backup/ Restore/ Transfer von Systemen ist deutlich einfacher. Ausnahme: Spezielle Hardware wird benötigt oder man spielt auf dem System. Vmware Workstation Keys gibt es für kleines Geld bei ebay. Es gibt aber auch kostenlose Virtualisiserer. Von meinem iPad gesendet
Am 07.11.23 um 12:37 schrieb Ralf Prengel:
Was soll mir das jetzt sagen ? Auch wenn ich mit einem virtuellen System arbeite, brauche ich einen PC mit einem OS. Und ich habe keinen Windows PC. Also einen Linux PC. Und der muss ab und zu, wenn z.B. wieder eine neue OS Vesion herauskommt neu Installiert werden. Zwar lange nicht mehr so oft, wie das noch vor ein paar Jahren der Fall war, aber bestimmt wieder mal. Und nach einen Neuinstallation, geht vieles erst mal nicht mehr, je nachdem wie intensiv man am OS geschraubt hat. Und so lange man das nicht wieder behoben hat, kann man den PC erst mal nicht in der Weise wie vorher nutzen. Dafür habe ich die zweite Partition. Da installiere ich die neue Version und kann aber in der anderen Partitin das alte OS weiterhin nutzen. Wenn dann die neue Version wieder so Spielt, wie die alte, schalte ich in GRUB das Default OS um und benutze die neue Version. Ich benutze Virtualbox auf dem Systen, wo ich gerade die SSD getauscht habe, aber nur für Windows und für einige Spezial-Linuxe. Brauche ich sehr selten. Ich mache Bild- nnd Videobearbeitung (kdenlife) und ob dazu ein virtuelles System reichen würde... ? Aber trotzdem Danke für den Hinweis. viele Grüße Werner
On Fri, Nov 03, 2023 at 04:11:04PM +0100, Werner Franke wrote:
Sollte passen. Denk dran, dass Suse beim Einbinden UUIDs verwendet. Wenn Du also nicht clonst, sondern kopierst, mußt Du entweder beim mkfs die alte UUID mitgeben oder im jeweiligen Zielsystem die /etc/fstab anpassen. Und ggf. /etc/default/grub* Abschließend im Rescue alle notwendigen Filesysteme mounten, rein- chroot'en und grub2-install laufen lassen Hinweise hierzu findest Du unter https://askubuntu.com/questions/831216/how-can-i-reinstall-grub-to-the-efi-p... das ist zwar für Ubuntu, sollte aber nicht soweit weg sein. Viele Grüße Ulf
Am 04.11.23 um 10:48 schrieb Ulf Volmer:
Danke Ulf, UUID: Ja das weiss ich und ich finde die extrem scheußlich. So absolut nichtssagend. Ich ändere das immer gleich in der fstab nach by-id Werte. Ich nehme an, in /etc/default/grub kann ich diese Werte auch benutzen. Da ich nicht weiss, wer oder was die grub-Dateien erzeugt und welche dabei als Src verwendet werden: ist /etc/default/grub die einzige source ? /boot/grub2/grub.cfg Die wird durch grub2-install erzeugt (?) Muss ich etwas in der EFI Partition anpassen ? Ich starte nun ein Live System und kopiere den Inhalt aller 3 Partitionen auf die neue Disk und passe /etc/fstab und /etc/default/grub an. (vereinfacht mit: tar -cpf - * |(cd /mnt/new_part && tar -xvpf -) Auf einer Partition ist 15.5, auf einer anderen 15.4. Muss ich das chroot Zeug für beide machen oder erledigt das grub2-install mit ? Viele Grüße Werner
On Sat, Nov 04, 2023 at 01:18:16PM +0100, Werner Franke wrote:
Die und /etc/default/grub_installdevice.
/boot/grub2/grub.cfg Die wird durch grub2-install erzeugt (?)
Ja.
Muss ich etwas in der EFI Partition anpassen ?
Das sollte grub2-install erledigen. Falls nicht, ist efibootmgr das Tool der Wahl.
Auf einer Partition ist 15.5, auf einer anderen 15.4. Muss ich das chroot Zeug für beide machen oder erledigt das grub2-install mit ?
Für beide. Bei Dualboot brauchst Du zwei Einträge im EFI Bootmgr. Zumindest soweit ich mich erinnere, Dualboot mache ich normalerweise nicht. Viele Grüße Ulf
Am 04.11.23 um 15:17 schrieb Ulf Volmer:
Die Datei gibt es bei mir nicht, Weder unter 15.4 noch 15.5. Auch auf meinem Laptop mit 15.5 nicht. Nur ein grub und ein grub.old
Das sollte dann hoffentlich so sein, denn der PC war schon immer ein Dualboot und das Grub Bootmenü hat YAST2 erzeugt. Also auch alle notwendigen Einträge in /boot/efi. Viele Grüße Werner
Hallo zusammen, Danke an alle, die mir hierbei Tipps gegeben haben. Der Umzug einer wahrscheinlich im Sterben liegenden SSD auf eine neue SSD hat geklappt. Da ich auf der neuen SSD eine andere Reihenfolge der Partitionen haben wollte, und ich für diesem speziellen Fall keine Hilfen im Netz gefunden habe, habe ich das Ganze händisch gemacht. Der PC ist ein Dual-boot PC. Alte SSD: (eine Sandisk SSD) 49GB ext4 Opensuse 15.4 -> /mnt/san_p1 500MB fat16 EFI -> /mnt/san_efi 47GB ext4 Opensuse 15.5 -> /mnt/san_p2 Neue SSD: (eine Kingston SSD) 500MB fat32 EFI -> /mnt/king_efi 50GB ext4 Opensuse 15.4 -> /mnt/king_p1 50GB ext4 Opensuse 15.5 -> /mnt/king_p2 Rest erstmal unbelegt 1. neue SSD in den PC provisorisch angeschlossen. (ich habe dazu ein freies SATA Kabel und einen freien Stromanschluss im PC) 2. Partitionen mit GParted angelegt 3. /etc/fstab anpassen Die Einträge für die alte SSD müssen auf die neue SSD geändert werden. Die neuen Eingräge erst mal nur zusätzlich und mit # am Beginn als Kommentar eintragen 3. Life System von einem USB-Stick gebootet 4. Mounterei cd /mnt; sudo mkdir san_efi san_p1 san_p2 king_efi king_p1 king_p2 Alle Partitionen mounten z.B. sudo mount /dev/disk/by-id/ata-SanDisk_SDSSDX120GG25_121179401087-part2 /mnt/san_efi sudo mount /dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7784F657BC-part1 /mnt/king_efi 5. Partitionen kopieren sudo su - cd /mnt/san_efi tar -cpf - EFI | (cd /mnt/king_efi && tar -xvpf -) cd /mnt/san_p1 tar -cpf - bin boot dev etc home lib lib64 media mnt opt \ proc root run sbin selinux srv sys tmp usr var vol |(cd /mnt/king_p1 && tar -xvpf -) cd /mnt/san_p2 tar -cpf - bin boot dev etc home lib lib64 media mnt opt \ proc root run sbin selinux srv sys tmp usr var vol |(cd /mnt/king_p2 && tar -xvpf -) 6. /etc/fstab anpassen # bei den Einträgen der neuen SSD die # entfernen und # bei den Einträgen der alten SSD einfügen (Wenn man das vergisst - wie ich - muss man beim booten in der Konsole das Root PW eingeben und die /etc/fstab mit dem vi anpassen. Danach CTRL-D) 7. EFI Remount sudo umount /mnt/king_efi sudo mount /dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7784F657BC-part1 /mnt/king_p2/boot/efi 8. Grub2 installieren for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt/king_p2$i; done sudo chroot /mnt/king_p2 Nachschauen was die neue SSD für ein /dev/sdX hat (bei mir war's /dev/sdb) grub2-install /dev/sdb grub2-mkconfig -o /boot/grub2/grub.cfg exit 9. Reboot Da die alte SSD noch im System war, hatte das Bootmenü ein paar zusätzliche Einträge. PC runterfahren, alte SSD ausbauen, booten und mit YAST2 den bootloader schreiben lassen. Danach sah das Bootmenü wieder wie zu Beginn der ganzen Session aus. Ich hoffe das hilft auch jemanden, der ein ähnliches 'spezielles' Problem hat. Gruß Werner
Am 03.11.23 um 16:11 schrieb Werner Franke:
Nachtrag: Grup2 war das Zauberwort. Wie kommt grub2 auf die neue SSD ? Clonezilla sagt was von grub, aber ich denke das ist nicht Grub2. Leider finde ich nichts passendes im Internet, was meinen Fall beschreibt. Um den Grub2 schreiben zu können, muss doch von dem jeweiligen System gebootet sein (?) Bei (sehr) alten SUSE Installationsmedien gab es den Punkt Installiertes System starten Ich habe nur einen Net-USB-Stick von 15.5 und ob das da noch drauf ist habe ich noch nicht nachgeschaut. Habe das Feature schon lange nicht mehr benötigt. Kann mir bitte jemand einen Tipp oder eine URL geben ? viele Grüße Werner
Am Freitag, 3. November 2023, 18:03:24 CET schrieb Werner Franke:
Hallo, mangels besserer Kenntnis würde ich erstmals die ganze Platte klonen und mich um die Partitionsgrößen später mit gparted kümmern, nachdem die alte Platte auch schon GPT hat. Dann ist der Bootsektor auch mit dabei, und dass die neue Platte größer ist, sollte kein Problem sein. Allerdings weiß ich nicht, ob dein Vorhaben umsetzbar ist. Nach alter Schule dürfen Boot- u. OS-Partitionen nicht verschoben werden, anderenfalls muss der Boot-Manager angepasst werden. Weiß nicht, ob das noch gilt, gparted gibt jedenfalls eine beängstigende Warnung aus. Grüße Richard
Hallo, Am 03.11.2023 um 20:47 schrieb Richard Hafenscher:
Was sollte daran "unzulässig" sein? Was sind Deine Bedenken?
So etwas in der Art meine ich bei meinen letzten Tests mit 15.5 auch gesehen zu haben. Je nachdem, wie grub konfiguriert ist, könntest Du bei einer exakten Kopie mittels dd sogar gute Chancen haben, dass das System neu startet. Ich muss allerdings gestehen, dass ich etwas aus der Übung mit SUSE bin, weil ich wegen AD-DC zu ubuntu gewechselt bin. Ich würde grundsätzlich bei solchen Sachen immer mit einem kompletten Stick experimentieren.
Doch. Denn anders als MBR schreibt GPT seine Infos an den Anfang und an das Ende der HDD [1]. Wenn die neue SSD größer ist, landen diese Infos nicht am Ende, sondern irgendwo in der Mitte - wo sie nicht hingehören. Ich hatte mit gparted aber bisher immer die Erfahrung gemacht, dass es das "reparieren" konnte. Ich würde es also tatsächlich so machen, die alte SSD 1:1 mittels dd auf die neue SSD zu übertragen und dann schauen, wie weit ich mit gparted komme. Gruß, Alex [1] https://de.wikipedia.org/wiki/GUID_Partition_Table#Header_der_GUID-Partition... -> nebst schönem Bild
Hallo, warum nicht gleich mit Gparted Live das ganze erledigen? Habe schon mehrmals eine kleinere SSD durch eine größere ersetzt, der folgenden Prozedere nach: 1) Neue SSD extern oder intern einbauen; 2) Live System starten; 3) Mit Gparted eine neue Partitionstabelle auf der *neuen* SSD machen; 4) Partitionen von der alten auf neue SSD kopieren, ggf. dabei vergrößern; 5) Fertig (alte SSD ausbauen, dann booten)! GGf. mit "grub-repair" mögliche Boot-Probleme beheben. BG, Kimmo la, 2023-11-04 kello 09:54 +0100, Alex Winzer kirjoitti:
Hallo Richard, Alex, Kimmo, Am 04.11.23 um 11:53 schrieb Kimmo Elo:
vielen Dank für Eure Tipps. Wie ihr eventuell in diesem Thread mit "[erledigt]" im Subject gelesen habt, steht dort, was ich so gemacht habe. Inzwischen habe ich auch herausgefunden, dass sie alte SSD noch einen MBR, keinen GPT, hat. Vor 11 Jahren gab's GPT wohl noch nicht. Als ich den Bericht geschrieben habe, wusste ich noch nicht, dass das ältere der beiden OS (15.4) nicht bootot und die letzten Tage mich viel mit Grub2 und EFI beschäftigt. Das war es aber nicht. Nachdem ich gestern eine neue initrd für 15.4 gemacht hatte, funktioniert jetzt wieder alles. Sieh auch Thread "Dualboot: EFI unvollständig" Viel Grüße Werner
Hallo, nur mal als Tip. In den meisten Fällen kann man ganz gut auch mit virtuellen Systemen arbeiten. Das vermeidet Fehlerquellen und Backup/ Restore/ Transfer von Systemen ist deutlich einfacher. Ausnahme: Spezielle Hardware wird benötigt oder man spielt auf dem System. Vmware Workstation Keys gibt es für kleines Geld bei ebay. Es gibt aber auch kostenlose Virtualisiserer. Von meinem iPad gesendet
participants (6)
-
Alex Winzer -
Kimmo Elo -
Ralf Prengel -
Richard Hafenscher -
Ulf Volmer -
Werner Franke