Moin,
du mußt von der noch vorhandenen alten Partition die uuid ändern, auch in der alten fstab.
Dann bootest du mit SuperGrub2Disk (oder machst von einem livesystem ein chroot), und installierst grub neu in den MBR von sda.
LG b_b
Partition klonen
- su_lin_user
- Erledigt
-
-
Hallo,
so sieht es jetzt aus.
Code
Alles anzeigenlinux1@localhost:~> sudo fdisk -l /dev/sda Festplatte /dev/sda: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren Festplattenmodell: WDC WD5000AADS-0 Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: dos Festplattenbezeichner: 0x2e3dc31f Gerät Boot Anfang Ende Sektoren Größe Kn Typ /dev/sda1 * 2048 102402047 102400000 48,8G 7 HPFS/NTFS/exFAT /dev/sda2 102402048 163842047 61440000 29,3G 7 HPFS/NTFS/exFAT /dev/sda3 164864000 226303999 61440000 29,3G 7 HPFS/NTFS/exFAT /dev/sda4 226304000 976773119 750469120 357,9G 5 Erweiterte /dev/sda5 226306048 236546047 10240000 4,9G 82 Linux Swap / Solaris /dev/sda6 236548096 338948095 102400000 48,8G 83 LinuxVermutlich war der Bootloader in P9 - was man auch gesehen hätte, hättest du mal mit fdisk da rein geschaut.
Ich habe mir nach dem Klonen sda mit fdisk angeschaut, da war aber zwischen sda9 und sda6 kein Unterschied.
Die Partition wurde ja auch 1:1 kopiert (mit GParted), deshalb dachte ich, dass dann auch kein Unterschied sein darf.
Was zeigt in fdisk an wo der Bootloader installiert ist?
Nachdem das System dann auch selbständig auf sda6 gebootet hat, anstatt auf sda9, war ich mir noch mehr der Sache sicher, dass sda6 und sda9 in allem identisch sind.
Und so habe ich dann voreilig schon die Partition entfernt.
Also ich denke ich kann die Neuinstallation von Grub2 auch von hier aus machen, ohne ein Livesystem zu verwenden.
Code
Alles anzeigenlinux1@localhost:~> lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ├─sda1 ntfs F67A86027A85BFBB ├─sda2 ntfs BCB6D564B6D51FA6 ├─sda3 ntfs 5D7C652702341B77 ├─sda4 ├─sda5 swap 1 Linux_Swap 7bd81ea3-4515-4437-8d94-4d5ada9c3dfa └─sda6 ext4 1.0 Suse_Tumb_64bit eee0f27c-2f88-4ade-9266-b6573ecd969f sdb ├─sdb1 ├─sdb2 vfat FAT32 Transfer 6370-8B23 └─sdb3 sdc └─sdc1 ext4 1.0 7f8e53ed-de1b-4bf7-b043-4f6031b9bb2f sdd sr0 nvme0n1 ├─nvme0n1p1 vfat FAT16 SYSTEM 4254-464B 93,9M 5% /boot/efi ├─nvme0n1p2 ext4 1.0 ROOT aa98023d-d89d-4189-a6a2-879f6bad9476 37,4G 15% / ├─nvme0n1p3 swap 1 SWAP 9606fdf8-d458-4d80-8374-bda2e3cc9c45 [SWAP] └─nvme0n1p4 ext4 1.0 HOME 786f72c5-09e9-4936-be83-23719c730f62 156,8G 0% /homeGruß, su_lin_user
-
Mal etwas off-topic: Vor vielen, vielen Jahren habe ich Dualboot (Win 10/Suse Leap) auch auf einem PC betrieben.
Windows habe ich dann nur noch für die Steuererklärung benutzt, 1x im Jahr.
Nach der Anschaffung eines 2. PC laufen darauf jetzt 2x Tumbleweed und 1x Leap 15.5 auf jeweils 3 separaten "Platten", 1 NVME, 2 SSDs.
Es gibt grundsätzlich nur jeweils 3 Partitionen: /, /home und Swap, mehr ist auch nicht nötig.
Im Laufe der Zeit ist eine externe HD-Docking Station(USB 3.2) dazugekommen, mit der ich externe Platten "verarbeite", mit verschiedenen Linuxen: Arch, EOS, Manjaro, Debian, Microos. Manche Systeme haben nur 1 Partition aber kein System hat mehr als 3 Partitionen.
Will ich mal ein externes System updaten, meistens Sonntags, stecke ich die Platte in die Station, boote und fertig zum Update. Jedes einzelne System hat die Standard-Software + Lamp-Server.
Bei deinen Posts habe ich den Eindruck, du weißt nicht wirklich was du willst, und verschlimmbesserst dein System mit jedem zusätzlichen Eingriff.
-
Was zeigt in fdisk an wo der Bootloader installiert ist?
Siehst du doch in Yast --> System --> Bootloader
-
Hallo Jürgen,
danke für die kurze Erzählung über den eigenen Umgang mit Deinem IT Equipment.
Bei deinen Posts habe ich den Eindruck, du weißt nicht wirklich was du willst, und verschlimmbesserst dein System mit jedem zusätzlichen Eingriff.
Ich verwende openSUSE schon sehr lang ca. ab Version 11.x. Ich bin deshalb aber kein Experte mit Linux. Nur wenn es wirklich erforderlich ist, beschäftige ich mich dann mit Administration. Die meiste Zeit bin ich nur Benutzer von Linux. Deshalb brauche ich dann auch Unterstützung.
Ich habe ein altes System (MBR, Legacy) das über 10 Jahre gewachsen ist, in ein neues System eingebaut. Bei der Gelegenheit wollte ich es ein bisschen schlanker machen und Aufräumen und dann getrennt weiter verwenden. Wenn das wieder geschafft ist, benutze ich das System wieder nur als Anwender.
Wenn etwas sinnvoll weiter verwendbar ist, dann versuche ich das auch. Das liegt immer an der persönlichen Einschätzung und Abwägung.
Der grobe Fehler der mir nun passiert ist, hätte nicht sein müssen. Ich war etwas leichtsinnig.
Gruß, su_in_user
-
Hallo,
Siehst du doch in Yast --> System --> Bootloader
Kannst Du auch noch verraten woran und wie ? Ich kann nur erraten, dass es die erste Stelle in der Bootreihenfolge sein kann. Wie ich aber gerade durch meinen leichtsinnigen Fehler enttäuschend erfahren musste, kann man schnell falsch liegen. Danke.
Gruß
-
Hallo,
Vermutlich war der Bootloader in P9 - was man auch gesehen hätte, hättest du mal mit fdisk da rein geschaut.
Also, danke für die gute Schritt für Schritt Anweisung.
Ich bin gerade bei Schritt 6.
Hier wird dazu geraten, den Grub2 ohne Angabe der Partitions-Nummer zu installieren.
Zitat:
"Wir installieren Grub auf der gesamten Festplatte, nicht auf einer bestimmten Partition,"
Wenn der Bootloader vorher angeblich auf P9 war, warum soll nun ohne Angabe der Partition installiert werden ?
Kannst Du dazu eine Erklärung geben ?
Gruß, su_lin_user
-
Moin,
Vermutlich war der Bootloader in P9 - was man auch gesehen hätte, hättest du mal mit fdisk da rein geschaut.
es handelt sich um diese Anordnung (vor den hiesigen Änderungen)
Codesdb ... ├─sdb6 btrfs Suse_Leap_15.1 35d6f6e2-513c-41e8-964d-e3d96118b2b3 0x83 ├─sdb7 btrfs Suse_Tumb_32bit cf1882f5-f695-4f5e-8c31-a33e4dc1e6d4 0x83 ├─sdb8 btrfs Suse_Leap_15.2 5d257700-aebf-4329-8813-82114ee5ef87 0x83 └─sdb9 ext4 1.0 Suse_Tumb_64bit eee0f27c-2f88-4ade-9266-b6573ecd969f 0x83ich vermute da eher, daß bei den jeweiligen Installationen grub jeweils in den MBR von /dev/sdb geschrieben wurde, sonst hätte die Platte im alten System (RE: MBR Multiboot: Getrennte Partitionen, System löschen und Benutzer löschen) gar nicht booten können.
Und verrückterweise soll die Platte ja auch im neuen System (EFI) weiter im CSM Modus betrieben werden, also jedesmal im UEFI den Modus umschalten.
Ich riet, per chroot oder mit SG²D das System zu starten und grub einfach durch grub-install /dev/sdb neu zu installieren.
Btw., (=> mal hier reinschauen grub analysieren)
LG b_b
-
Moin,
Ergänzung: In einem CSM Bootsystem muß grub in den MBR der Platte (sdX), sonst kann nicht gebootet werden.
grub war nicht in sdb9! sondern eins der gelöschten p6-8 hat vorher den grub "regiert". (grub stage1 im MBR, core.img im Bereich vor der 1. Partition, die übrigen grub Dateien in /boot/grub, also auf einer Partition, ehemals 6,7 oder 8, je nachdem, in welchem System zuletzt ein update-grub angestoßen wurde.)
Die grub Dateien sind jetzt weg, daher grub rescue>
Von dort kann man das System (mit etwas Glück) ebenfalls starten. Rettungsmodus
LG b_b
-
Hallo,
Ergänzung: In einem CSM Bootsystem muß grub in den MBR der Platte (sdX), sonst kann nicht gebootet werden.
Wenn das sicher gesagt werden kann, dann hätte das unten stehende Zitat seine Gültigkeit.
Hier ist ne gute Anleitung: https://www.fosslinux.com/1150…talling-grub-on-linux.htm
Aber wie gesagt: Ich weiß nicht, was dass mit deinen Windowsinstallationen macht.Zitat aus obenstehenden Link der Anleitung:
" > grub-install /dev/sdX
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."
grub war nicht in sdb9! sondern eins der gelöschten p6-8 hat vorher den grub "regiert". (grub stage1 im MBR, core.img im Bereich vor der 1. Partition, die übrigen grub Dateien in /boot/grub, also auf einer Partition, ehemals 6,7 oder 8, je nachdem, in welchem System zuletzt ein update-grub angestoßen wurde.)
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.
Vielleicht ist das jetzt nicht mehr besonders wichtig, aber ... zuerst habe ich mit P9 gebootet und die boot-Konfiguration gespeichert, damit P9 aktiv ist. Danach habe ich die P7, P8 formatiert und damit geleert. P9 habe ich dann in P6, 1:1 kopiert (mit GParted). In diesem Zustand habe ich das Verhalten des PC beim Booten überprüft. Ich habe festgestellt, dass seltsamer Weise die geklonte P6 gemountet war und nicht P9. P6 und P9 hatten die gleiche UUID durch das Klonen. Da P6 gemountet war und das System davon ohne Fehler gebootet hatte, dachte ich mir, ich bräuchte P6 nicht unbedingt mit einer neuen UUID versehen. Leider habe ich nicht zusätzlich daran gedacht, den Bootloader mit gebooteter P6 zu speichern. Somit wäre P6 und nicht P9 aktiv gewesen. Dann hätte es wahrscheinlich kein Problem nach Beseitigung von P9 mit dem Booten gegeben.
Das ist meine Vermutung.
Die grub Dateien sind jetzt weg, daher grub rescue>
Von dort kann man das System (mit etwas Glück) ebenfalls starten. Rettungsmodus
Eine generelle Frage:
Ich habe schon des öfteren bemerkt, dass Debian orientiertes Linux unterschiedlich zu Fedora orientiertes Linux ist. Manche Kommandos wie z. B. "search" und auch andere, ergeben kein Ergebnis. In wie weit kann man den Anordnungen von Ubuntuu folgen ? Ich bin da immer etwas misstrauisch und unsicher, wann man dem 1:1 folgen kann, und wann nicht. Gibt es dazu einen guten Rat.
Danke für eure Beiträge.
Gruß, su_lin_user
