Partition klonen

Hinweis: In dem Thema Partition klonen gibt es 32 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Moin,

    Zitat von su_lin_user

    Also ich kann mich noch genau daran erinnern, dass im Yast - Bootloader unter Reiter "Bootcode-Optionen" unter "Speicherort des Bootcodes", die Option "In Master-Boot-Record schreiben (/dev/sda) markiert war.

    das kann schon sein, wie aber hast du das bei den anderen Installationen (sda6,7 und 8) gemacht; und in welcher ist zuletzt ein update-grub angestoßen worden (durch irgendeine Aktualisierung – kernel oder auch grub)?

    Läßt sich nun nicht mehr ergründen, Partitionen gelöscht/überschrieben.

    Zitat von su_lin_user

    Kommandos wie z. B. "search"

    nun ja, search ist ein grub cli Kommando. (in Linux heißt das dann find


    LG b_b

    Für den Inhalt des Beitrages 308174 haftet ausdrücklich der jeweilige Autor: black_boot

    Zitat von black_boot

    aber hast du das bei den anderen Installationen (sda6,7 und 8) gemacht

    hier kann ich nur vermuten, dass es gleich war - Option "In Master-Boot-Record schreiben (/dev/sda) markiert. Aus dem Grund, da ich immer alles gleich halte, um es so unkompliziert wie möglich zu halten.

    Zitat von black_boot

    und in welcher ist zuletzt ein update-grub angestoßen worden

    das habe ich aber noch mal wiederholt erwähnt.

    Zitat von su_lin_user

    Vielleicht ist das jetzt nicht mehr besonders wichtig, aber ... zuerst habe ich mit P9 gebootet und die boot-Konfiguration gespeichert, damit P9 aktiv ist.

    damit habe ich die grub2.cfg gemeint.


    Zitat von black_boot

    nun ja, search ist ein grub cli Kommando. (in Linux heißt das dann find

    das sind so die unscheinbaren Herausforderungen für einen Nicht-Profi, wenn er eine beliebige Anleitung vor sich hat. Dafür könnt ihr freundlichen Helfer im Forum natürlich nichts dafür. Ich kenne diesen typischen Probleme für Nur-Anwender unter Linux ja lang genug - und trotzdem bleibe ich dabei.


    Gruß

    -

    Gruß, su_lin_user

    Leap 15.5 |KDE 5 |AMD Ryzen 3600, 6 Core |RAM 16GB

    Für den Inhalt des Beitrages 308177 haftet ausdrücklich der jeweilige Autor: su_lin_user

    Hallo,


    Ich habe mit dem neuen System (UEFI) auf dem PC gebootet (von nvme0n1).

    Folgende Schritte sind ausgeführt:

    1) / Partition von sdb6 ist auf /mnt gemountet.

    2) /home Partition sda3 ist auf /mnt/home gemountet.

    3) Die Verzeichnisse /dev, /proc und /sys sind mit

    Code
    sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys

    eingehängt.

    4) Jetzt in die Root-Partition "Chrooten"

    Code
    sudo chroot /mnt


    also, ich bin jetzt soweit den grub2 zu installieren.


    Zitat von https://www.fosslinux.com/1150…talling-grub-on-linux.htm

    Hier ist ein Profi-Tipp: Achten Sie darauf, in diesem Schritt keine Partitions-Nummer anzugeben.

    Wir installieren GRUB auf der gesamten Festplatte, nicht auf einer bestimmten Partition.



    5) Grub2 neu installieren.

    Code
    localhost:/ # grub2-install /dev/sdb
grub2-install: error: /usr/share/grub2/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.

    Könnte es sein dass hier das UEFI-BIOS hier für die Fehlermeldung verantwortlich ist ?


    Also ich habe ein /boot Verzeichnis.

    Darunter noch ein /boot/grub2 Verzeichnis. Darin befinden sich allerhand Dateien. Könnte interessant sein,


    Wer könnte hier weiter helfen ? Hier benötige ich Experten-Rat.

    Danke.


    Gruß, su_lin_user

    -

    Gruß, su_lin_user

    Leap 15.5 |KDE 5 |AMD Ryzen 3600, 6 Core |RAM 16GB

    Für den Inhalt des Beitrages 308179 haftet ausdrücklich der jeweilige Autor: su_lin_user

    Hallo,


    weitere Neuigkeiten:


    Zitat von black_boot

    und in welcher ist zuletzt ein update-grub angestoßen worden (durch irgendeine Aktualisierung – kernel oder auch grub)?


    Zitat von neoghb

    Vermutlich war der Bootloader in P9 - was man auch gesehen hätte, hättest du mal mit fdisk da rein geschaut.

    Also, wenn ich die /mnt/boot/grub2/grub.cfg öffne, dann ist hier ... zu lesen

    Code
    else
insmod part_msdos
insmod ext2
set root='hd0,msdos9'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos9 --hint-efi=hd0,msdos9 --hint-baremetal=ahci0,msdos9 -->
else
  search --no-floppy --fs-uuid --set=root eee0f27c-2f88-4ade-9266-b6573ecd969f

    ist das nicht ein Hinweis darauf, dass P9 aktiv war ?


    neoghb oder black_boot

    Sollte ich vielleicht mal entgegen dem Profi-Tipp aus FOSSLINUX versuchen den Grub2 auf P9 zu installieren ?

    Ich frage vorsichtshalber nach, bevor ich wieder einen unbedachten Fehler mache.


    Gruß

    -

    Gruß, su_lin_user

    Leap 15.5 |KDE 5 |AMD Ryzen 3600, 6 Core |RAM 16GB

    Für den Inhalt des Beitrages 308184 haftet ausdrücklich der jeweilige Autor: su_lin_user


    Ohne direkt davor zu sitzen ist es leider auch jetzt schwer das zu beurteilen. Eventuel musst du noch die efi Partition in das Chroot mounten - also vom Hauptsystem der nvme einen --bind mount von /boot/efi zu /mnt/boot/efi


    Das grub-install (wenns denn läuft) auf jedenfall auf sdb und sdb6 machen.

    Für den Inhalt des Beitrages 308185 haftet ausdrücklich der jeweilige Autor: neoghb

    Hallo,


    neoghb

    danke für Dein Bemühen.


    Ich muss hier kurz noch mal für alle Leser wiederholen, dass der PC

    1) ein neues System ist, mit SSD nvme0n1 (momentan gebootet). UEFI, GPT.

    2) Auf dem PC habe ich ein altes Multiboot-System (aus einem nicht mehr vorhandenem PC) integriert, bestehend aus 2 HDD Laufwerken (sdb Betriebssysteme und sda Benutzerdaten). Das alte System bootet mit Legacy Bios und MBR.


    Der PC konnte schon mit jeden der beiden Systeme ohne Fehler booten. Erst durch die Beseitigung der Partition P9 (die durch Klonen, von P6 ersetzt wurde), wie schon vorher zu lesen war, ergab sich das Problem.


    Deshalb noch einmal meine Frage speziell dazu, ob es wirklich richtig sein kann, jetzt den Grub2 in die EFI-Partition zu installieren ? die EFI-Partition liegt auf der nvme0n1 SSD. Vielleicht bringt der PC diese Fehlermeldung, weil er erkennt, dass das System momentan mit UEFI und GPT Laufwerk gebootet ist.

    Ich habe versucht nach dem Vorschlag der Anleitung Grub2 auf /mnt/sdb (altes System-Laufwerk) zu installieren.


    Dein Vorschlag wäre gewesen Grub2 auf die / Partition (altes System-Laufwerk), jetzt P6, zu installieren. Das habe ich noch nicht versucht. Wie schätzt Du ein, das zu versuchen ?


    Gruß, su_lin_user

    -

    Gruß, su_lin_user

    Leap 15.5 |KDE 5 |AMD Ryzen 3600, 6 Core |RAM 16GB

    Für den Inhalt des Beitrages 308186 haftet ausdrücklich der jeweilige Autor: su_lin_user

    Moin,

    hattest du nicht schon geschrieben, daß du das System auf (neu) sdb6 gebootet hast? Deine Anstrengungen jetzt sagen mir, Suse auf sdb6 booten nicht, oder warum das Ganze?

    Ich hatte dir empfohlen, per SG²D dieses Suse auf sdb6 zu booten, und dann aus dem laufenden System heraus mit sudo grub-install /dev/sdb zu reparieren.

    Wenn du das per chroot machen möchtest, mußt du auch im CSM Modus booten (z.B. von dem LiveSystem, welches auch zur Installation verwendet wurde)


    (Es geht evt. auch von einem System im EFI Modus, dann muß aber das Paket grub-pc nachinstalliert werden, es dürfte im EFI System nicht vorhanden sein. Ein solches chroot habe ich noch nicht gemacht!)


    LG b_b


    Edit Was willst du? die alte Bootvariante (sdb6 etc.) auf efi umstellen?

    Wenn nein, dann hat grub (und seine Teile stage1 und core.img) nur etwas im MBR und in dem Bereich vor der ersten Partition zu suchen.

    Im EFI Boot wird dafür eine extra Partition (ESP) eingerichtet, die firmware sucht also nicht im MBR, sondern eben in dieser ESP. (!CSM=>MBR; EFI=>ESP)

    Im CSM (früher BIOS) Modus muß der Bootloader im MBR und nicht in einer Partition stehen. (steht er in einer Partition, brauchst du einen Bootloader, der den im PBR (Partitions Boot Record) per 'chainload' bootent

    2 Mal editiert, zuletzt von black_boot ()

    Für den Inhalt des Beitrages 308187 haftet ausdrücklich der jeweilige Autor: black_boot

    Hallo,

    black_boot

    danke für Deine wiederholte Meldung.

    Zitat von black_boot

    hattest du nicht schon geschrieben, daß du das System auf (neu) sdb6 gebootet hast?

    Ich habe das System gebootet als sdb9 noch existierte. Ich sah, dass aber sdb6 gemountet war. Das kam zustande, da sdb6 ja 1:1 von sdb9 kopiert war. Das System (bzw. wahrscheinlich die fstab) nahm, was als erstes zu greifen war. Und da sdb6 die gleiche UUID hatte, fand die fstab sdb6, um als / zu mounten.

    Nachdem ich die Partition sdb9 löschte war das Problem (grub rescue>) zum ersten Mal.

    Zitat von black_boot

    Wenn du das per chroot machen möchtest, mußt du auch im CSM Modus booten (z.B. von dem LiveSystem, welches auch zur Installation verwendet wurde)

    Hier hast Du mir eine ganz wichtige Information gegeben ! Ich habe ja mit der SSD im UEFI gebootet und wollte dann die Restore-Arbeiten erledigen.

    Zitat von black_boot

    (Es geht evt. auch von einem System im EFI Modus, dann muß aber das Paket grub-pc nachinstalliert werden, es dürfte im EFI System nicht vorhanden sein. Ein solches chroot habe ich noch nicht gemacht!)

    Danke für eine weitere wichtige Information. Ich versuche erst mal die einfachen Möglichkeiten.

    Zitat von black_boot

    Edit Was willst du? die alte Bootvariante (sdb6 etc.) auf efi umstellen?

    Nein, nein blos nicht. ... nicht vergessen dass ja auch noch Windows in 2 Varianten im MBR auf sdb zu booten sind.

    Um es nicht zu kompliziert zu machen, wollte ich ja deshalb das alte System einfach nur integrieren so wie es war, aber ein bisschen aufräumen (also unnötige Partitionen löschen).

    Zitat von black_boot

    Im CSM (früher BIOS) Modus muß der Bootloader im MBR und nicht in einer Partition stehen. (steht er in einer Partition, brauchst du einen Bootloader, der den im PBR (Partitions Boot Record) per 'chainload' bootent

    Danke für die klare Feststellung.

    Dann ist es eigentlich klar, dass der Bootloader im MBR von sdb installiert war. Das zeigt ja auch jetzt noch das Sternchen bei einer Ausgabe von fdisk -l /dev/sdb (jetzt sda)


    Zitat von black_boot

    Ich hatte dir empfohlen, per SG²D dieses Suse auf sdb6 zu booten, und dann aus dem laufenden System heraus mit sudo grub-install /dev/sdb zu reparieren.

    Also bevor ich mir die SG²D brenne ... Ich habe Leap15.5_Live auf einem USB. Wäre es möglich auch davon zu booten, oder besteht da wieder das gleiche Problem wie jetzt, wo ich von nvme0n1 unter UEFI gebootet habe ? Leap15.5_Live ist auch unter EFI auf dem USB ... ich nehme an.

    Ich habe jetzt eine Anleitung gefunden, eine grub2 Installation direkt aus grub rescue> zu machen. Wäre das auch ratsam bzw. praktikabel ?


    Gruß, su_lin_user

    -

    Gruß, su_lin_user

    Leap 15.5 |KDE 5 |AMD Ryzen 3600, 6 Core |RAM 16GB

    Für den Inhalt des Beitrages 308189 haftet ausdrücklich der jeweilige Autor: su_lin_user

    Moin,

    Zitat von su_lin_user

    Ich habe jetzt eine Anleitung gefunden, eine grub2 Installation direkt aus grub rescue> zu machen.

    hmm…

    das hatte ich ja bereits in Antwort #19 vorgeschlagen.


    LG b_b

    Für den Inhalt des Beitrages 308190 haftet ausdrücklich der jeweilige Autor: black_boot

    Hallo,

    black_boot

    Zitat von black_boot

    das hatte ich ja bereits in Antwort #19 vorgeschlagen.

    Dadurch, dass ich von Anfang an bemerkt hatte, dass der Befehlssatz im grub rescue> sehr reduziert und anders ist, und ich damit nicht umgehen konnte, habe ich das erst mal weiter unbeachtet lassen,


    Happyend

    Also ich hab es geschafft. Es funktioniert wieder alles wie anfangs. Altes System Legacy Multiboot. Neues System UEFI Boot. 2 getrennte Systeme im neuen PC.


    Auf welchen Weg ich zum Ziel gekommen bin.

    1. grub rescue> war mir zu beschwerlich. Nach kurzzeitiger Beschäftigung damit, war mir klar, dass zu viel nachzulesen ist.

    2. Boot von SSD UEFI-Boot und chroot hat nicht geklappt, weil das System über UEFI gebootet war. Da lässt sich dann kein Bootloader in ein Legacy Bios System installieren (siehe weiter oben Fehlermeldung).

    3. Das gleiche mit Live-Boot Leap 15.5 mit USB, weil mit UEFI gebootet wird.

    4. Die SG²D war ganz leicht zu handhaben. Es hat aber auch nicht auf Anhieb vollständig geklappt. Es waren 2 unterschiedliche Schritte nötig.

    Mit "SG²D UEFI 64bit" konnte ich openSUSE Tumbleweed auf sdb6 als erstes OS des Legacy Multiboot-Systems booten. Dann habe ich über Yast - Bootloader und Option "Fremdes OS testen" gespeichert. Bei einem weiteren Öffnen gleich danach, hat Windows noch gefehlt. Ich habe noch einmal mit "SG²D UEFI 64bit" gebootet und versucht mit Windows zu starten. Das hat nicht geklappt. Es ergab die Fehlermeldung, dass mit UEFI kein Legacy Bios gestartet werden kann. Nach weiteren erfolglosen Versuchen, nahm ich "SG²D hybrid" und versuchte damit noch einmal Windows zu booten, und es hat geklappt. Danach habe ich das System mit Tumbleweed von dem schon wieder vorhandenen Grub2 Bootloader booten lassen. Danach habe ich wieder mit Yast - Bootloader gespeichert. Danach war Windows wieder in der Bootreihenfolge zu sehen. Das war's dann schon.


    black_boot, neoghb

    Danke für die Unterstützung. Wenn es auch etwas gedauert hat, bis ich die beste Methode gefunden habe. Das Ziel ist erreicht. Es hätte schlimmer kommen können.


    Gruß, su_lin_user

    -

    Gruß, su_lin_user

    Leap 15.5 |KDE 5 |AMD Ryzen 3600, 6 Core |RAM 16GB

    Für den Inhalt des Beitrages 308201 haftet ausdrücklich der jeweilige Autor: su_lin_user