4
Grub verschieben
Moin,
ich habe eine nvme1n1 (Intel) mit Windows und eine nvme2n1 (Samsung) mit Linux Mint 20.1 Linux Mint wurde nach Windows installiert und der GRUB-Manager wurde wohl auf der Windows NVMe-abgelegt. Wie kann ich den auf nvme2n1 verschieben, ohne alles kaputt zu machen? nvme2n1 ist verschlüsselt. nvme0n1 ist der Optane-Speicher.
df -h gibt aus:
sudo fdisk -l gibt Folgendes inkl. Fehler aus:
sudo efibootmgr --verbose:
Mit
sudo grub-install /dev/nvme2n1p2
sudo update-grub
hat es nicht geklappt. Wahrscheinlich war es auch Blödsinn. Sorry, bin kein Linux-Profi
Normalerweise wäre mir das auch egal. Ich habe aber vor, die Linux-NVMe zu klonen und in einen anderen Rechner einzubauen (oder würde das technisch keinen Sinn machen?)
Ich bedanke mich im Voraus!
ich habe eine nvme1n1 (Intel) mit Windows und eine nvme2n1 (Samsung) mit Linux Mint 20.1 Linux Mint wurde nach Windows installiert und der GRUB-Manager wurde wohl auf der Windows NVMe-abgelegt. Wie kann ich den auf nvme2n1 verschieben, ohne alles kaputt zu machen? nvme2n1 ist verschlüsselt. nvme0n1 ist der Optane-Speicher.
df -h gibt aus:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 7,7G 0 7,7G 0% /dev
tmpfs 1,6G 2,0M 1,6G 1% /run
/dev/mapper/vgmint-root 467G 71G 372G 17% /
tmpfs 7,8G 0 7,8G 0% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 7,8G 0 7,8G 0% /sys/fs/cgroup
/dev/nvme2n1p2 705M 208M 447M 32% /boot
/dev/nvme1n1p1 96M 74M 23M 77% /boot/efi
tmpfs 1,6G 16K 1,6G 1% /run/user/1000sudo fdisk -l gibt Folgendes inkl. Fehler aus:
Die Sicherungs-GPT-Tabelle befindet sich nicht am Ende des Gerätes. Das Problem wird durch »write« korrigiert.
Festplatte /dev/nvme1n1: 476,96 GiB, 512110190592 Bytes, 1000215216 Sektoren
Festplattenmodell: INTEL HBRPEKNX0202AH
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: A679C8FB-75D1-4AEA-8693-AD96B8FBCF34
Gerät Anfang Ende Sektoren Größe Typ
/dev/nvme1n1p1 2048 206847 204800 100M EFI-System
/dev/nvme1n1p2 206848 239615 32768 16M Microsoft reserviert
/dev/nvme1n1p3 239616 999155519 998915904 476,3G Microsoft Basisdaten
/dev/nvme1n1p4 999155712 1000179711 1024000 500M Windows-Wiederherstellungsumgebung
Festplatte /dev/nvme2n1: 476,96 GiB, 512110190592 Bytes, 1000215216 Sektoren
Festplattenmodell: Samsung SSD 970 PRO 512GB
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: E2FC3E05-12B4-41A2-9F9D-0C1080C68B5D
Gerät Anfang Ende Sektoren Größe Typ
/dev/nvme2n1p1 2048 1050623 1048576 512M EFI-System
/dev/nvme2n1p2 1050624 2549759 1499136 732M Linux-Dateisystem
/dev/nvme2n1p3 2549760 1000214527 997664768 475,7G Linux-Dateisystem
Die gesicherte GPT-Tabelle ist beschädigt, aber die primäre Tabelle scheint in Ordnung zu sein, so dass diese nun benutzt wird.
Die Sicherungs-GPT-Tabelle befindet sich nicht am Ende des Gerätes. Das Problem wird durch »write« korrigiert.
Festplatte /dev/nvme0n1: 27,26 GiB, 29260513280 Bytes, 57149440 Sektoren
Festplattenmodell: INTEL HBRPEKNX0202AHO
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: C056F950-A262-432F-96CF-DEA152C7EB22
Festplatte /dev/mapper/nvme2n1p3_crypt: 475,73 GiB, 510787584000 Bytes, 997632000 Sektoren
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
Festplatte /dev/mapper/vgmint-root: 474,77 GiB, 509758930944 Bytes, 995622912 Sektoren
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
Festplatte /dev/mapper/vgmint-swap_1: 980 MiB, 1027604480 Bytes, 2007040 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytessudo efibootmgr --verbose:
BootOrder: 0000,0001,0004,0005,9999
Boot0000* ubuntu HD(1,GPT,fc7c9551-073d-48e7-a655-10e00e937d34,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* Windows Boot Manager HD(1,GPT,fc7c9551-073d-48e7-a655-10e00e937d34,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...,................
Boot0004* Solid State Disk PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-58-01-41-32-CF)/HD(1,GPT,cb38439a-ef48-4f76-ab38-f0bfef2d8343,0x800,0x100000)..BO
Boot0005* Internal Hard Disk PciRoot(0x0)/Pci(0x17,0x0)/Sata(6144,32768,1)/HD(1,GPT,fc7c9551-073d-48e7-a655-10e00e937d34,0x800,0x32000)..BO
Boot9999* USB Drive (UEFI) PciRoot(0x0)/Pci(0x1d,0x0)/USB(16,0)..BOMit
sudo grub-install /dev/nvme2n1p2
sudo update-grub
hat es nicht geklappt. Wahrscheinlich war es auch Blödsinn. Sorry, bin kein Linux-Profi
Normalerweise wäre mir das auch egal. Ich habe aber vor, die Linux-NVMe zu klonen und in einen anderen Rechner einzubauen (oder würde das technisch keinen Sinn machen?)
Ich bedanke mich im Voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 639682
Url: https://administrator.de/forum/grub-verschieben-639682.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
Hm - grundsätzlich würde ich jetzt tatsächlich ganz beherzt ein write absetzen.
Ohne Gewähr :-P
Gruß,
Jörg
Hm - grundsätzlich würde ich jetzt tatsächlich ganz beherzt ein write absetzen.
Ohne Gewähr :-P
Gruß,
Jörg
Halo,alternativ:
- clonen
- Reperaturdisk und Grub reparieren ( sprich neu installieren)
- Bedenke das unterschiedliche Verhalten BIOS/UEFI beim Bootvorgang
Fred
- clonen
- Reperaturdisk und Grub reparieren ( sprich neu installieren)
- Bedenke das unterschiedliche Verhalten BIOS/UEFI beim Bootvorgang
Fred
Hi Palpatine,
Du hast 2 EFI-Partitionen im System.
Wenn Du ein EFI-Board hast, sollte Grub-PC deinstalliert werden und nur Grub-efi-amd64 / grub-efi-amd64-signed installiert sein.
Mit...
grub-install
update-grub
...installierst Du dann den Grub-efi automatisch in die EFI-Partition der Windows-Festplatte.
Da es sich bei Dir wohl um 2 Festplatten handelt die direkt auf dem Board sind, könnte man nur die eine erst einmal ausbauen, damit es kein Mismatch gibt. Ich hatte das in der Konstellation auch noch nicht.
Hier mal zum Vergleich eine nvme0n1 mit Windows und eine sda mit Debian. Grub-efi in die EFI-Partition der Windows-SSD installiert.
Gruß orcape
Du hast 2 EFI-Partitionen im System.
Wenn Du ein EFI-Board hast, sollte Grub-PC deinstalliert werden und nur Grub-efi-amd64 / grub-efi-amd64-signed installiert sein.
Mit...
grub-install
update-grub
...installierst Du dann den Grub-efi automatisch in die EFI-Partition der Windows-Festplatte.
Da es sich bei Dir wohl um 2 Festplatten handelt die direkt auf dem Board sind, könnte man nur die eine erst einmal ausbauen, damit es kein Mismatch gibt. Ich hatte das in der Konstellation auch noch nicht.
Hier mal zum Vergleich eine nvme0n1 mit Windows und eine sda mit Debian. Grub-efi in die EFI-Partition der Windows-SSD installiert.
root@orca:~#df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 7,8G 0 7,8G 0% /dev
tmpfs 1,6G 1,6M 1,6G 1% /run
/dev/sda1 23G 7,8G 14G 36% /
tmpfs 7,8G 19M 7,8G 1% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
/dev/nvme0n1p1 96M 32M 65M 33% /boot/efi
/dev/sda5 9,2G 3,3G 5,5G 38% /var
/dev/sda8 182G 72G 101G 42% /home
/dev/sda7 1,9G 5,8M 1,7G 1% /tmp
tmpfs 1,6G 140K 1,6G 1% /run/user/1000
root@orca:~#fdisk -l
Disk /dev/nvme0n1: 232,89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: KINGSTON SA2000M8250G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 8AD4D437-A134-424B-A785-DC15A1D41FCC
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 206847 204800 100M EFI System
/dev/nvme0n1p2 206848 239615 32768 16M Microsoft reserved
/dev/nvme0n1p3 239616 243791871 243552256 116,1G Microsoft basic data
/dev/nvme0n1p4 487344128 488394751 1050624 513M Windows recovery environment
/dev/nvme0n1p5 243791872 487344127 243552256 116,1G Microsoft basic data
Partition table entries are not in disk order.
Disk /dev/sda: 223,58 GiB, 240065183744 bytes, 468877312 sectors
Disk model: SanDisk SSD PLUS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdebeb961
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 48828415 48826368 23,3G 83 Linux
/dev/sda2 48830462 468875263 420044802 200,3G 5 Extended
/dev/sda5 48830464 68360191 19529728 9,3G 83 Linux
/dev/sda6 68362240 76746751 8384512 4G 82 Linux swap / Solaris
/dev/sda7 76748800 80652287 3903488 1,9G 83 Linux
/dev/sda8 80654336 468875263 388220928 185,1G 83 Linux
root@orca:~#efibootmgr --verbose
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0000,0005
Boot0000* Windows Boot Manager HD(1,GPT,f772a3aa-8087-40ba-a9d6-73c888d4cef1,0x800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...h................
Boot0004* debian HD(1,GPT,f772a3aa-8087-40ba-a9d6-73c888d4cef1,0x800,0x32000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0005* debian HD(1,GPT,f772a3aa-8087-40ba-a9d6-73c888d4cef1,0x800,0x32000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Hi,
merci für deine Antwort. Hatte den gleichen Gedanken, habe allerdings dann gleich neu installiert, geht ja schnell. Trotzdem danke!
merci für deine Antwort. Hatte den gleichen Gedanken, habe allerdings dann gleich neu installiert, geht ja schnell. Trotzdem danke!
