Gelöst Win10 löschen beim Dualboot

[BeastXXL]

Nunja, bei meiner openSuse Version (15.6) ist "--reinit" die einzige verfügbare Option bei update-bootloader.
Ich habe die pbl-Variante nur genommen, um sicher zu gehen, dass wirklich das passiert, was erwartet wird (ich wollte möglich "Übersetzungsfehler" umgehen.

Die Nummerierung sehe ich immer, wenn ich mir die Partitionen in /dev ansehe (fdisk -l, lsblk oder in Gparted).
/dev/nvme0n1p1 ist /boot/efi
/dev/nvme0n1p6 ist /swap
/dev/nvme0n1p7 ist /
/dev/nvme0n1p8 ist /home

Nach einem intensiven "Gespräch" mit ChatGPT soll es wohl ein Weg ohne Neuinstallation geben, allerdings muss ich den Stunt von gestern wiederholen (Live-OS, chroot etc.), um dann mit einem bestimmten Befehl die Partitonstabelle neu schreiben zu lassen. Am Ende dann dracut --force und pbl oder update-bootloder. Pflichtschuldig schlägt es grub2-install und grub2-config vor.

Anmerkung: Ich bin kein Fan von dem ganzen LLM/ChatGPT-Hype und es ist noch lange nicht da, wo es nach Aussagen mancher Menschen sein soll, aber ich kann langsam verstehen, warum viel Leute darauf so abfahren.

 

[josef-wien]

Da ich nicht annehme, daß der durch die gelöschten Partitionen frei gewordene Platz zur Gänze für die EFI-Systempartition verwendet wurde, solltest Du zuerst den freien Platz partitionieren.

Namen bzw. Nummern von Partitionen sind Schall und Rauch und ein reines Identifizierungsmerkmal. Theoretisch sollte ein Sortieren der Partitionentabelle Deinen Wunsch erfüllen, ob die Praxis mit der Theorie Schritt hält, kann ich nicht sagen. Führe gdisk /dev/nvme0n1 aus. Mit p zeigst Du den derzeitigen Status an, mit s sortierst Du, und mit p zeigst Du den neuen Status an. Bist Du zufrieden, dann nimm w zum Speichern, bist Du nicht zufrieden, dann nimm q zum Beenden ohne Speichern. Wenn Dir fdisk lieber ist: x p f p w bzw, q (Von chroot ist in diesem Absatz keine Rede.)

Eine neue initrd wäre nur dann notwendig, wenn dort /dev/nvme0n1px verwendet wird, und das kann ich mir nicht vorstellen. Die PARTUUID ändert sich nicht, und die Dateisystem-UUID schon gar nicht. Auch auf den Bootloader hat diese kosmetische Operation keine Auswirkungen.

 

[susejunky]

Nunja, bei meiner openSuse Version (15.6) ist "--reinit" die einzige verfügbare Option bei update-bootloader.

Dann ist die Verwendung auch vollkommen in Ordnung.

Die Lebensdauer von openSUSE Leap 15.6 beträgt (nach aktueller Planung) noch 6 Monate und openSUSE Leap 16.0 ist bereits verfügbar. Der Beitrag #12 von @Sauerland zeigt, dass in openSUSE Leap 16.0 die Option "--reinit" bereits als "legacy" gelistet ist. Und nur darauf wollte ich hinweisen (keine Kritik an Deiner Vorgehensweise).

Ich habe die pbl-Variante nur genommen, um sicher zu gehen, dass wirklich das passiert, was erwartet wird (ich wollte möglich "Übersetzungsfehler" umgehen.

Zwar teile ich Deine Bedenken ("Übersetzungsfehler") nicht, aber trotzdem steht es Dir frei pbl anstelle von update-bootloader zu benutzen. Auch hier sollte meine Anmerkung keine Kritik an Deinem Vorgehen sein. Vielmehr wollte ich für all jene, die hier mitlesen aber in der openSUSE Dokumentation vorrangig auf update-bootloader stoßen, klar machen, dass pbl kein anderes Programm ist.

Die Nummerierung sehe ich immer, wenn ich mir die Partitionen in /dev ansehe (fdisk -l, lsblk oder in Gparted).
/dev/nvme0n1p1 ist /boot/efi
/dev/nvme0n1p6 ist /swap
/dev/nvme0n1p7 ist /
/dev/nvme0n1p8 ist /home

"/dev/nvme0n1p1" sind die vom Kernel beim Systemstart generierten Gerätenamen. Inwieweit sich diese oder gar eine darin enthaltene "Reihenfolge" beinflussen lässt, kann ich nicht sagen (daher wird auch empfohlen UUIDs oder PARTUUIDs zur Referenzierung von Geräten/Dateisystemen zu verwenden).

Heutige Speichermedien (Festplatten, SSDs, NVMes, ...) verfügen in alle Regel über eigene Kontroller und entscheiden selbst, auf welchem Ort und in welcher Reihenfolge Informationen auf dem Medium abgelegt werden. Bei rotierenden Festplatten konnte man früher angeblich eine gezielte Anordnung und damit eine Verbesserung der Zugriffszeiten erreichen. Bei Speichermedien wie SSDs, NVMes, usw. dürfte es kaum eine Rolle spielen, in welcher Speicherzelle und in welcher Reihenfolge was abgelegt wird.

Langer Rede kurzer Sinn: Meines Erachtens ist der Aufwand für ein "Umsortieren" (und das damit verbundene Risiko) die Mühe nicht wert.

Aber es ist Dein System ...

 

[BeastXXL]

Danke für dein rücksichtsvolles Klarstellen, wie du was gemeint hast.

Langer Rede kurzer Sinn: Meines Erachtens ist der Aufwand für ein "Umsortieren" (und das damit verbundene Risiko) die Mühe nicht wert.

Ja, das denke ich auch. Ich werde die drei Partitionen noch an den Anfang schieben, damit ich den Platz für /home zur Verfügung habe, aber die Mühe für eine einheitlich fortlaufende Nummerierung (1,2,3,...) werde ich mir nicht machen.
Das könnte dann passieren, wenn ich bei einer Neuinstallation root neu aufsetze. Allerdings tendiere ich gerade zu einer Migration in Slowroll mittels openSuses Migrations-Tool. Ich würde es auch gerne so machen, wie ich bisher die Upgrades gemacht habe, aber mir fehlen die Infos über die Slowroll-Repositories.
Ich würde ja gern fragen, ob schon jemand das Migrations-Tool ausprobiert hat, aber das würde dann doch etwas weit vom ursprünglichen Thema abkommen.