• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gelöst Win10 löschen beim Dualboot

B

BeastXXL

Hallo zusammen,

da Win10 nun quasi tot ist, möchte ich jetzt den letzten Schritt gehen und meine Windows-Installation von der Platte putzen.
So sieht meine Festplatte aus (es geht dabei natürlich um die nvme-Platte):
Code: 
beastxxl@linux-5099:~> lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 465,8G  0 disk
└─sda1        8:1    0 365,8G  0 part /Games
sr0          11:0    1  1024M  0 rom 
nvme0n1     259:0    0 465,8G  0 disk
├─nvme0n1p1 259:1    0   529M  0 part
├─nvme0n1p2 259:2    0    99M  0 part /boot/efi
├─nvme0n1p3 259:3    0    16M  0 part
├─nvme0n1p4 259:4    0  82,4G  0 part
├─nvme0n1p5 259:5    0   100G  0 part
├─nvme0n1p6 259:6    0     2G  0 part [SWAP]
├─nvme0n1p7 259:7    0    30G  0 part /
└─nvme0n1p8 259:8    0    50G  0 part /home
beastxxl@linux-5099:~> sudo fdisk -l
[sudo] Passwort für root:
Festplatte /dev/nvme0n1: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: Samsung SSD 970 EVO Plus 500GB         
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: gpt
Festplattenbezeichner: EA09713B-815A-4E24-AB75-68DB3CF06510

Gerät             Anfang      Ende  Sektoren Größe Typ
/dev/nvme0n1p1      2048   1085439   1083392  529M Windows-Wiederherstellungsumgebung
/dev/nvme0n1p2   1085440   1288191    202752   99M EFI-System
/dev/nvme0n1p3   1288192   1320959     32768   16M Microsoft reserviert
/dev/nvme0n1p4   1320960 174112767 172791808 82,4G Microsoft Basisdaten
/dev/nvme0n1p5 174112768 383827967 209715200  100G Microsoft Basisdaten
/dev/nvme0n1p6 593543168 597737471   4194304    2G Linux Swap
/dev/nvme0n1p7 597737472 660649983  62912512   30G Linux-Dateisystem
/dev/nvme0n1p8 660649984 765507583 104857600   50G Linux-Dateisystem


Festplatte /dev/sda: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: Samsung SSD 850
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: gpt
Festplattenbezeichner: E4F1D4C0-633D-03B3-3075-3C79CFD8EC00

Gerät      Anfang      Ende  Sektoren  Größe Typ
/dev/sda1    2048 767055871 767053824 365,8G Linux-Dateisystem
beastxxl@linux-5099:~>
In meine jugendlichen Naivität würde ich ein Live-GParted-OS starten und folgende Partitionen einfach löschen:
/dev/nvme0n1p1
/dev/nvme0n1p3
/dev/nvme0n1p4
/dev/nvme0n1p5

Bei der Gelegenheit würde ich die EFI-Partition noch auf 512MB od. 1GB vergrößern und alles an den Anfang der Platte schieben.

Gibt es dabei etwas, was nach der Löschung der Win-Partitionen bei openSuse nicht mehr funktionieren könnte?
In der fstab wird UUID verwendet:
Code: 
beastxxl@linux-5099:/etc> cat fstab
# Root-Partition
UUID=28a0cea7-1a39-4603-b845-5dfe9c9ab8ba  /               ext4  acl,user_xattr  0  1
# Boot-Partition
UUID=3E4E-DC5C                             /boot/efi       vfat  defaults        0  0
# Swap-Partition
UUID=0326f565-5953-47fa-aae4-6f53912f355e  swap            swap  defaults        0  0
# Home-Partition
UUID=53742a4a-dfb6-4ca2-86c7-1a9ee8dfc09f  /home           ext4  acl,user_xattr  0  2
# Zweite SSD - Partition 1
UUID=5fb24952-f39a-4be7-8909-29e1e795cfff  /Games          ext4  acl,user_xattr  0  2
beastxxl@linux-5099:/etc>
Ich denke mal, dass sich die UUID der EFI-Partition nicht verändert, nur weil ich deren Größe verändere, oder?

Wie bekomme ich die Windows-Einträge aus der EFI-Partition raus?

Bei GRUB gehe ich davon aus, dass der Windows-Eintrag allein verschwindet, wenn es keine Einträge mehr in der EFI-Partition gibt.

Das Einzige, was evtl. nicht mehr funktioniert sind meine tune2fs-Einstellungen für die Linux-Partitionen, da dort tatsächlich /dev/nvme verwendet wurde.
Aber ich sehe gerade, dass ich das device auch mit UUID angeben kann. Wenn ich das vorher mache, sollte es nachher auch funktionieren.

Also ganz allgemein die Frage: mit welchen Problemen könnte ich konfrontiert sein und wie behandle ich die EFI-Partition? Mal abgesehen von Datenverlust durch GParted, was mir noch nie passiert ist.
Danke für eure Hinweise.
 
A

abgdf

Win10 zu löschen, würde ich nicht empfehlen, denn es kann vorkommen, daß man doch nochmal Windows-Software ausführen will.
Will man aber doch löschen, würde ich sagen: Komplette Neuinstallation.
 
J

josef-wien

Prinzipiell sehe ich keine Probleme. Ob sich beim Vergrößern einer FAT-Partition die Dateisystem-UUID ändert, kann ich nicht sagen, aber Du kannst die UUID von Dateisystem und Partition ja speichern und dann vergleichen:lsblk -o NAME,UUID,PARTUUID
Die PARTUUID (mit der das UEFI zugreift) sollte dabei unverändert bleiben.

Beim Löschen von Partitionen würde ich dafür sorgen, daß die Namen der anderen Partitionen nicht geändert werden (frage mich nicht, ob bzw. was bei GParted zu tun ist). Bevor Du mit dem Verschieben (das bekanntlich längere Zeit dauert) beginnst, sollste Du Dir überlegen, wie Du den freigewordenen Platz nutzen willst. Wo sich eine Partition physisch auf der Platte befindet, ist irrelevant.

Mit dem Entfernen der alten Einträge aus dem UEFI-Bootmenü befassen wir uns später, dazu brauchen wir dann:efibootmgr -v
Die von Windows vorgenommenen Eintragungen auf der EFI-Systempartition müssen von Dir entfernt werden. Zu GRUB-2 kann ich nichts sagen.
 
T

th.giese

abgdf schrieb:
Win10 zu löschen, würde ich nicht empfehlen, denn es kann vorkommen, daß man doch nochmal Windows-Software ausführen will.
Will man aber doch löschen, würde ich sagen: Komplette Neuinstallation.
Zum Vergrößern anklicken....
Wenn jemand ganz umsteigt, dann wird der das (hoffentlich) gut durchdacht haben und für alle Anwendungsfälle eine Lösung auf Linux haben.
Wozu dann ein BS noch vor halten, das beim Start ggf schon seit Monaten keine Sicherheitsupdates mehr erhalten hat.
Wenn alles erforderlich auch auf Linux läuft, dann ab mit dem zopf.....
 
OP
B

BeastXXL

Hallo zusammen,

also, Windows will ich auf keinen Fall installiert lassen. Wenn ich es brauchen sollte (Gott bewahre), würde ich es in eine VirtualBox packen. Gestartet hatte ich es in den letzten Monaten nur für ein Spiel, aber nachdem es auch auf Linux läuft, ist das nicht mehr nötig.

Ich habe etwas recherchiert und auch ChatGPT mit Fragen gelöchert.
Mein jetziger Stand:
Nur durch das Verändern der Größe oder das Verschieben ändert sich nicht die UUID.
Das wird aber vermutlich nicht mein Problem werden.
ChatGPT hat angemerkt, dass es Probleme geben kann, weil UEFI nicht mehr den richtigen Pfad zur EFI-Partition kennt. Evtl. muss ich den UEFI-Startpfad manuell anpassen und schlägt dafür "efibootmgr (unter Linux) oder bcdedit (unter Windows)" vor.
Außerdem schlägt es eine Wiederherstellungsumgebung vor, in der (bei Linux) mit grub-install oder efibootmgr der Bootloader und die UEFI-Konfiguration manuell repariert werden kann.
Lange Rede, kurzer Sinn: Ich kenne mich zu wenig mit UEFI aus. Daher weiß ich nicht, wie der Pfad zur EFI-Partition gespeichert ist. Geht UEFI über die Flag "boot" oder "efi"? Oder nach der UUID (die bei fat-Partitionen eine VSN ist)? Beides wäre kein Problem. Ist es anders, wird es ein Problem.
Bei GRUB bin ich mir eigentlich sicher, dass es keine Probleme geben sollte, da die grub.cfg mit der UUID der root-Partition gespickt ist.

CHatGPT schlägt folgendes für die Reparatur vor:
GRUB
Code: 
sudo mount /dev/sda1 /mnt
sudo grub-install --target=x86_64-efi --efi-directory=/mnt --bootloader-id=GRUB --recheck
sudo grub-mkconfig -o /boot/grub/grub.cfg
sudo reboot
sda1 ist hier die EFI-Partition
Wenn ich das richtig verstanden habe, ist das nötig, wenn GRUB nicht mehr EFI-Partition installiert ist. Und das Ganze kann man über ein Live-OS machen.
EFI
Code: 
sudo mount /dev/sda1 /mnt
sudo efibootmgr -v
#Wenn ein Eintrg fehlt, dann
sudo efibootmgr --create --disk /dev/sda --part 1 --label "GRUB" --loader '\EFI\ubuntu\grubx64.efi'
#Evtl. Bootreihenfolge ändern
sudo efibootmgr --bootorder 0002,0001,0003
#Wenn alles passt, dann
sudo reboot

OK, so oder so sollte ich ein Backup von der EFI-Partiton machen. Blöde frage: wie mache ich das am besten?
 
OP
B

BeastXXL

@josef-wien : Mal abgesehen davon, dass ich die Ergüsse von ChatGPT nicht ohne Grund hier einstelle (weil ich mir nicht sicher bin, ob sie richtig sind), hast du mir mit deinem Post fast gar nicht weitergeholfen bei der Frage, wie ich die EFI-Partition bzw. GRUB repariere, wenn ich nach dem löschen der Win-Partitonen nicht mehr ins Linux booten kann.

Unter EFI Problembehebung › Wiki › ubuntuusers.de habe ich etwas gefunden, was ich in abgewandelter Form mit dem opensuse-Rescue-OS versuchen würde.
Statt
Code: 
update-grub
müsst es
Code: 
grub2-mkconfig -o /boot/grub2/grub.cfg
heißen.

Ist dieser Weg geeignet, die Einträge in der EFI-Partition (inkl. Shim) zu reparieren?
 
susejunky

susejunky

Moderator
Teammitglied
@BeastXXL :

Unter der Annahme, dass
  • Du openSUSE (Leap 15.x/16.0 oder Tumbleweed) als Betriebssystem auf Deiner SSD installiert hast
  • secureboot auf Deinem System abgeschaltet ist
  • weder Dein aktuelles "/"- noch Dein aktuelles SWAP-Verzeichnis verschlüsselt sind und
  • Du GRUB2 als Bootloader verwendest
würde ich wie folgt vorgehen:
  1. Das installierte openSUSE-System starten.
  2. umount /boot/efi um die EFI-Systempartition auszuhängen.
  3. Mit gparted die Partitionen 1-5 auf /dev/nvme0n1 löschen. (Durch das Löschen von Partition 2 kann ein zusammenhängender, freier Speicherbereich auf /dev/nvme0n1 geschaffen werden, was dessen weitere Verwendung ggf. etwas vereinfacht.)
  4. Mit gparted eine neue ESP auf /dev/nvme0n1 anlegen und formatieren.
  5. Mit blkid die UUID der neu erstellten ESP ermitteln.
  6. Mit einem Editor die UUID der ESP in der Datei /etc/fstab durch die UUID der neu erstellten ESP ersetzen.
  7. mount -a um die neu erstellte ESP einzuhängen.
  8. update-bootloader --install um GRUB2 auf der (neu erstellten) ESP zu installieren.
  9. update-bootloader --config um GRUB2 zu konfigurieren.
  10. [OPTIONAL]: ls -lR /boot/efi um zu kontrollieren, ob der Bootloader korrekt installiert wurde.
  11. [OPTIONAL]: efibootmgr um zu kontrollieren, ob die Bootreihenfolge korrekt gesetzt wurde.
Falls die eingangs erwähnten Annahmen nicht zutreffen, dann muss die obige Vorgehensweise natürlich angepasst werden.
 
J

josef-wien

Bei 11 sollte kontrolliert werden, ob 8 oder 9 eine neue Eintragung im UEFI-Boot-Menü vorgenommen hat. Alle bisherigen zeigen ja auf die alte EFI-Systempartition (und sollten von einem vernünftigen UEFI beim nächsten Start entfernt werden).
 
susejunky

susejunky

Moderator
Teammitglied
josef-wien schrieb:
Bei 11 sollte kontrolliert werden, ob 8 oder 9 eine neue Eintragung im UEFI-Boot-Menü vorgenommen hat.
Zum Vergrößern anklicken....
Das sehe ich auch so!

Ich führe die Schritte 10. und 11. immer aus, um zu überprüfen, ob
  • die ESP korrekt "bestückt" wurde,
  • im NVRAM ein Boot-Eintrag angelegt wurde,
  • im NVRAM die gewünschte Boot-Reihenfolge festgelegt wurde.
Meist prüfe ich auch noch, ob unter /boot/grub2 eine grub.cfg angelegt wurde und ob diese einen plausiblen Inhalt hat. Allerdings wird mir hin und wieder vorgeworfen, ich sei zu penibel, daher habe ich 10. und 11. als optional gekennzeichnet.
 
OP
B

BeastXXL

@susejunky:
Na, das sieht doch mal nach einem Plan aus! Vielen Dank! Damit kann ich arbeiten.:)(y)

Deine Annahmen treffen zu, wenn
  • ich secureboot für diese Aktion abschalte
  • grub2-efi auch zu GRUB2 zählt
Ich gehe davon aus, dass shim auch installiert wird, damit ich secureboot wieder nutzen kann.

Penibel oder nicht, ich werde auf jeden Fall alles kontrollieren, was ich kann. Nur werde ich mir wohl ein Backup der grub.cfg machen müssen, sonst weiß ich nicht mehr, was mir wichtig ist.

Ich hatte zwar vor, gparted zu nehmen, aber der KDE/Yast-Partitionierer sollte es auch tun.
Eine Sache ist mir noch aufgefallen: lt. den Manual-Angaben gibt es weder update-bootloader --install noch update-bootloader --config.
update-bootloader is just a symlink to pbl and corresponds to pbl --init and pbl --config, respectively.

update-bootloader is not intended to called manually. It is a preserved interface to the boot loader configuration that is used in the post-install section of
some boot loader related packages (e.g. shim).

OPTION
--reinit
Install or update boot loader, then update boot loader configuration.
Zum Vergrößern anklicken....
Schritt 8 und 9 könnte zu update-bootloader --reinit zusammengefasst werden. Allerdings ist mir nicht ganz wohl dabei, wenn ich lese, dass es nicht dazu gedacht ist, manuell aufgerufen zu werden.
pbl --install und pbl --config sind vermutlich die richtigen Schritte 8 und 9. (Anmerkung: eine Option "--init" scheint es bei pbl auch nicht zu geben).
 
S

Sauerland

update-bootloader hat anscheinend unter Leap 15.6 und Leap 16.0 andere Optionen. Evtl. auch unter Tumbleweed.

Bei Leap 16.0 sagt:
Code: 
opensuse160:/home/stephan # update-bootloader --help
Usage: update-bootloader [OPTIONS]
Configure/install boot loader.

Options:
    --install                   Install boot loader.
    --config                    Create or update boot loader config.
    --show                      Print current boot loader.
    --loader BOOTLOADER         Set current boot loader to BOOTLOADER.
                                Supported values: none, grub2, grub2-bls, grub2-efi, systemd-boot, u-boot.
    --default ENTRY             Set default boot entry to ENTRY.
    --add-option OPTION         Add OPTION to default boot options.
    --del-option OPTION         Delete OPTION from default boot options.
    --get-option OPTION         Get OPTION from default boot options.
    --add-kernel VERSION [KERNEL [INITRD]]
                                Add kernel with version VERSION. Optionally pass kernel and initrd
                                explicitly.
    --remove-kernel VERSION     Remove kernel with version VERSION.
    --default-settings          Return default kernel, initrd, and boot options.
    --log LOGFILE               Log messages to LOGFILE (default: /var/log/pbl.log)
    --version                   Show pbl version.
    --help                      Write this help text.

Legacy options:
    --reinit                    Re-install boot loader (equivalent to --install --config).
    --add                       Add new entry to boot loader configuration. Requires also --name,
                                --image, and --initrd options. Use --add-kernel instead.
    --image KERNEL              Use KERNEL as kernel when adding a boot loader entry.
    --initrd INITRD             Use INITRD as initrd when adding a boot loader entry.
    --name VERSION              Use VERSION as name for new boot loader entry.
    --refresh                   Create or update boot loader config (equivalent to --config).

There are a number of legacy options that are accepted but ignored. They are:
    --force, --force-default, --man, --previous, --xen, --xen-kernel

Calling update-bootloader without any options will rebuild the boot loader configuration
(as if --config would have been used).

Unter Leap 15.6 bekommst du mit dem Befehl keine Hilfe......
 
OP
B

BeastXXL

Sauerland schrieb:
Unter Leap 15.6 bekommst du mit dem Befehl keine Hilfe......
Zum Vergrößern anklicken....
Richtig, weshalb ich meinen Text aus der man-Angabe zitiert habe.
Aber, wenn ich das richtig verstehe, dann kann hier update-bootloader und pbl synonym verwendet werden.
Leider finde ich im Netz keine Hinweise oder Erklärungen zu pbl, was ich ehrlich gesagt etwas spooky finde.
 
S

Sauerland

Leap 15.6:
Hier mal pbl in Action, den Parameter nomodeset hinzufügen:
Code: 
linux64:/home/stephan # cat /boot/grub2/grub.cfg | grep -i nomodeset
linux64:/home/stephan # pbl --add-option nomodeset
linux64:/home/stephan # pbl --config
linux64:/home/stephan # cat /boot/grub2/grub.cfg | grep -i nomodeset
        linux   /boot/vmlinuz-6.4.0-150600.23.73-default root=UUID=53d51072-1db6-4412-9955-0ccd307a2993  splash=silent resume=/dev/disk/by-uuid/40b208a5-8a0a-4eca-8948-fe42610ebca0 preempt=full rd.driver.blacklist=nouveau ipv6.disable=1 mitigations=auto nomodeset
                linux   /boot/vmlinuz-6.4.0-150600.23.73-default root=UUID=53d51072-1db6-4412-9955-0ccd307a2993  splash=silent resume=/dev/disk/by-uuid/40b208a5-8a0a-4eca-8948-fe42610ebca0 preempt=full rd.driver.blacklist=nouveau ipv6.disable=1 mitigations=auto nomodeset
                linux   /boot/vmlinuz-6.4.0-150600.23.70-default root=UUID=53d51072-1db6-4412-9955-0ccd307a2993  splash=silent resume=/dev/disk/by-uuid/40b208a5-8a0a-4eca-8948-fe42610ebca0 preempt=full rd.driver.blacklist=nouveau ipv6.disable=1 mitigations=auto nomodeset
                linux   /boot/vmlinuz-6.4.0-150600.23.65-default root=UUID=53d51072-1db6-4412-9955-0ccd307a2993  splash=silent resume=/dev/disk/by-uuid/40b208a5-8a0a-4eca-8948-fe42610ebca0 preempt=full rd.driver.blacklist=nouveau ipv6.disable=1 mitigations=auto nomodeset
                linux   /boot/vmlinuz-6.4.0-150600.23.53-default root=UUID=53d51072-1db6-4412-9955-0ccd307a2993  splash=silent resume=/dev/disk/by-uuid/40b208a5-8a0a-4eca-8948-fe42610ebca0 preempt=full rd.driver.blacklist=nouveau ipv6.disable=1 mitigations=auto nomodeset
linux64:/home/stephan #
Zeile 1zuerst hab ich nachgeschaut, ob nomodeset schon im Grub eingetragen ist.
Zeile 2 fügt den Eintrag zwar hinzu, aber erst
Zeile 3 übernimmt den Eintrag in die /boot/grub2/grub.cfg
Zeile 4 bestätigt den Eintrag.

Unter Leap 16.0 kannst du dies alles mit update-bootlader statt pbl machen.
 
susejunky

susejunky

Moderator
Teammitglied
BeastXXL schrieb:
... Allerdings ist mir nicht ganz wohl dabei, wenn ich lese, dass es nicht dazu gedacht ist, manuell aufgerufen zu werden.
Zum Vergrößern anklicken....
Ich verstehe zwar nicht, was Dich hier so beunruhigt aber da Du openSUSE Leap 15.6 installiert hast, kannst Du auch gerne YaST verwenden, um den Bootloader neu zu installieren (allerdings kann ich Dir dazu nicht weiterhelfen, da ich YaST nicht verwende und auch nicht installiert habe).

BeastXXL schrieb:
Leider finde ich im Netz keine Hinweise oder Erklärungen zu pbl, was ich ehrlich gesagt etwas spooky finde.
Zum Vergrößern anklicken....

Ich verwende openSUSE Tumbleweed 20251024 und da sagt man pbl:

"...
update-bootloader is a light wrapper to unify some common boot loader configuration tasks. pbl is an alternative name for the same program. ..."

Aber wenn Dir bei Änderungen an der Bootloader-Installation unwohl ist, dann behalte die bestehende ESP einfach bei.
 
J

josef-wien

Du änderst (vorest) ja nichts an der Systempartition, also kannst Du (wenn alle Stricke reißen, wovon ich absolut nicht ausgehe) Dein installiertes Linux immer noch über die Super Grub2-Disk starten, indem Du Kernel und initrd von Deiner Systempartition auswählst.
 
OP
B

BeastXXL

Es hat eine Weile gedauert, aber nun ist es endlich geschafft.
Die Anleitung von @susejunky war gut, hatte nur leider etwas vergessen: dracut bzw. die initramfs zu regenerieren.

Ich habe alles genau so gemacht, wie es in der Liste stand, allerdings am Ende update-bootloader --reinit
Habe auch mit Schritt 10 und 11 kontrolliert und dann neugestartet.

Irgendwann im Bootprozess nach irgendwas mit "Virtual Console" passierte lange nichts und dann kam die Fehlermeldung von dracut. Irgendeine .sh-Datei sucht noch die UUID von der alten EFI-Partition.

Nach vielem rumprobieren hat wahrscheinlich folgender Hinweis von ChatGPT geholfen (ich wusste einfach nicht mehr weiter):
  • Live-opensuse 15.6 geladen
  • folgende Befehle als root ausgeführt:
  • Code: 
    mount /dev/nvme0n1p7 /mnt
mount /dev/nvme0n1p1 /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt /bin/bash
dracut --regenerate-all --force
pbl --install
pbl --config

Ich denke, der richtige Befehl ist das dracut --regenerate-all --force gewesen. Alles, was ich sonst versucht habe, hatte nicht funktioniert.

Jetzt muss ich nur noch herausfinden, wie die die Nummerierung der Partitionen ändern kann. Swap ist noch immer #6, /root #7 und /home #8.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben