MX Linux Forum

Posted: **Thu Apr 24, 2025 1:14 pm**

Hi,

ich war dumm und habe eine Linux Partition gelöscht und mein Hauptsystem mehr Platz gegönnt.

Habe "gparted" im laufenden Betrieb benutzt, die Partition gelöscht und damit auch Grub zerschossen.

Der nächste Boot endete in der grub shell

Code: Select all

grub>

nach vielen Versuchen mit:

Code: Select all

set boot=(hd2,gpt2)
liunux /boot/vmlinuz... boot=(hd2,gpt2)
usw. usw

von hier: https://superuser.com/questions/1237684 ... grub-shell
konnte ich kein Lösung finden.

Ich fand heraus dass es primär darum geht die grub.cfg anzupassen.
Also habe ich mit dem MX Live System via Ventoy

die grub.cfg von einem Backup kopiert und in den boot/grub/ Folder des Systems eingefügt.
Die bestehende als grub.cfg-old gespeichert
Die kopierte grub.cfg habe ich zum aktuellen Kernel anpassen müssen.
Hauptsächlich vmlinuz und initrd.img.

Dann konnte ich booten.

Jetzt will vor dem nächsten Boot prüfen ob alles okay ist.
Ein Update wurde auch durchgeführt ebenso.

Code: Select all

sudo update-grub

So jetzt wundere ich mich dass die grub wieder so aussieht wie vorher...da steht nix drin.
Aber hier komme ich ins straucheln weil es ja auch unter /etc/grub.d/backup auch eine grub.cfg gibt.

Daher müsste ihr mir bitte mal helfen ob alles okay ist.
Welche Ausgaben braucht ihr noch?

Ich bedanke mich im voraus.

OSI:

Code: Select all

Snapshot created on: 20250415_2259
System:
  Kernel: 6.14.2-1-liquorix-amd64 [6.14-3~mx23ahs+1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: audit=0
    intel_pstate=disable amd_pstate=disable BOOT_IMAGE=/boot/vmlinuz-6.14.2-1-liquorix-amd64
    root=UUID=<filter> ro
  Desktop: KDE Plasma v: 5.27.5 tk: Qt v: 5.15.8 wm: kwin_x11 vt: 7 dm: SDDM
    Distro: MX-23.6_ahs_x64 Libretto Jan 12 2025 base: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Desktop Mobo: Micro-Star model: MAG Z790 TOMAHAWK MAX WIFI (MS-7E25) v: 2.0
   UEFI: American Megatrends LLC. v: A.71 date: 08/14/2024
CPU:
  Info: model: Intel Core i5-14600K bits: 64 type: MST AMCP arch: Raptor Lake gen: core 14
    level: v3 note: check built: 2022+ process: Intel 7 (10nm) family: 6 model-id: 0xB7 (183)
    stepping: 1 microcode: 0x12C
  Speed (MHz): avg: 1649 high: 3501 min/max: 800/3501 boost: enabled scaling:
    driver: acpi-cpufreq governor: ondemand
  Flags:*
  Vulnerabilities:*
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel Raptor Lake-S GT1 [UHD Graphics 770] vendor: Micro-Star MSI driver: i915
    v: kernel alternate: xe arch: Gen-13
  Device-2: NVIDIA AD103 [GeForce RTX 4070 Ti SUPER] vendor: Palit Microsystems driver: nvidia
    v: 535.216.03
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X:
    loaded: nvidia gpu: i915,nvidia display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 81
  Monitor-1: DP-5 res: 1920x1080 hz: 60 dpi: 82
  API: OpenGL v: 4.6.0 NVIDIA 535.216.03 renderer: NVIDIA GeForce RTX 4070 Ti SUPER
Audio:
  Device-1: Intel Raptor Lake High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel
    bus-ID: 1-11:6 v: kernel alternate: snd_soc_avs,snd_sof_pci_intel_tgl chip-ID: 0db0:a74b
    class-ID: 0300 bus-ID: 00:1f.3 chip-ID: 8086:7a50 class-ID: 0403
  Device-2: NVIDIA vendor: Palit Microsystems driver: snd_hda_intel v: kernel pcie: gen: 4
    speed: 16 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 10de:22bb class-ID: 0403
  Device-3: Micro Star USB Audio type: USB driver: hid-generic,snd-usb-audio,usbhid
  API: ALSA v: k6.14.2-1-liquorix-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Intel Ethernet I225-V vendor: Micro-Star MSI driver: igc v: kernel pcie: gen: 2
    speed: 5 GT/s lanes: 1 port: N/A bus-ID: 03:00.0 chip-ID: 8086:15f3 class-ID: 0200
  IF: eth0 state: up speed: 100 Mbps duplex: full
Drives:
  Local Storage: total: 6.61 TiB used: 376.68 GiB (5.6%)
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: SSD 990 PRO 1TB size: 931.51 GiB
    block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 4B2QJXD7 temp: 28.9 C scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: SanDisk model: SSD PLUS 1000GB size: 931.51 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 9100 scheme: GPT
  ID-3: /dev/sdb maj-min: 8:16 vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB
    block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD scheme: GPT
  ID-4: /dev/sdc maj-min: 8:32 type: USB vendor: Seagate model: Expansion HDD size: 4.55 TiB
  ID-5: /dev/sdd maj-min: 8:48 type: USB vendor: Verbatim model: STORE N GO size: 14.46 GiB
  SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Partition:
  ID-1: / raw-size: 931.26 GiB size: 915.57 GiB (98.32%) used: 376.68 GiB (41.1%) fs: ext4
    dev: /dev/sda2 maj-min: 8:2
  ID-2: /boot/efi raw-size: 256 MiB size: 252 MiB (98.46%) used: 275 KiB (0.1%) fs: vfat
    dev: /dev/sda1 maj-min: 8:1
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 8 GiB used: 0 KiB (0.0%) priority: -2 file: /swap/swap
Sensors:
  System Temperatures: cpu: 27.8 C
Repos:
  Packages: 3170 pm: dpkg pkgs: 3145 libs: 1761 tools: apt,apt-get,aptitude,nala,synaptic pm: rpm
    pkgs: 0 pm: flatpak pkgs: 25
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/repo/ bookworm main non-free
    2: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/testrepo/ bookworm test
    3: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/repo/ bookworm ahs
  Active apt repos in: /etc/apt/sources.list.d/*
    1: deb [arch=amd64] https://updates.*
  Active apt repos in: /etc/apt/sources.list.d/*
    1: deb [arch=amd64 arm64] https://*
Info:
  Processes: 394 Uptime: 35m wakeups: 1 Memory: 62.58 GiB used: 4.24 GiB (6.8%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI

Posted: **Thu Apr 24, 2025 1:19 pm**

Code: Select all

2025-04-24 18:20:30.612 DBG default: mx-boot-repair version: 25.4.01
2025-04-24 18:20:30.643 DBG default: lsblk -ln -o NAME,SIZE,LABEL,MODEL -d -e 2,11 -x NAME | grep -E '^x?[h,s,v].[a-z]|^mmcblk|^nvme'
2025-04-24 18:20:30.649 DBG default: "nvme0n1 931,5G       Samsung SSD 990 PRO 1TB\nsda     931,5G       SanDisk SSD PLUS 1000GB\nsdb     232,9G       Samsung SSD 850 EVO 250GB\nsdc       4,5T       Expansion HDD\nsdd      14,5G       STORE N GO"
2025-04-24 18:20:30.649 DBG default: lsblk -ln -o NAME,SIZE,FSTYPE,MOUNTPOINT,LABEL -e 2,11 -x NAME | grep -E '^x?[h,s,v].[a-z][0-9]|^mmcblk[0-9]+p|^nvme[0-9]+n[0-9]+p'
2025-04-24 18:20:30.652 DBG default: "nvme0n1p1   100M vfat              \nnvme0n1p2    16M                   \nnvme0n1p3 930,9G ntfs              \nnvme0n1p4   538M ntfs              \nsda1        256M vfat   /boot/efi  EFI-SYSTEM\nsda2      931,3G ext4   /          rootMX23\nsdb1         16M                   \nsdb2      232,9G ntfs              Source\nsdc1        200M vfat              EFI\nsdc2        4,5T exfat             Expansion\nsdd1       14,4G exfat             Ventoy\nsdd2         32M vfat              VTOYEFI"
2025-04-24 18:20:46.823 DBG default: lsblk -ln -o PARTTYPE /dev/nvme0n1| grep -qEi '0x83|0fc63daf-8483-4772-8e79-3d69d8477de4|44479540-F297-41B2-9AF7-D131D5F0458A|4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709'
2025-04-24 18:20:46.828 DBG default: lsblk -ln -o PARTTYPE /dev/sda| grep -qEi '0x83|0fc63daf-8483-4772-8e79-3d69d8477de4|44479540-F297-41B2-9AF7-D131D5F0458A|4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709'
2025-04-24 18:20:46.831 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p1| grep -q rootMX
2025-04-24 18:20:46.833 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p2| grep -q rootMX
2025-04-24 18:20:46.836 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p3| grep -q rootMX
2025-04-24 18:20:46.841 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p4| grep -q rootMX
2025-04-24 18:20:46.844 DBG default: lsblk -ln -o LABEL /dev/sda1| grep -q rootMX
2025-04-24 18:20:46.847 DBG default: lsblk -ln -o LABEL /dev/sda2| grep -q rootMX
2025-04-24 18:20:46.850 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p1| grep -q rootMX
2025-04-24 18:20:46.853 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p2| grep -q rootMX
2025-04-24 18:20:46.859 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p3| grep -q rootMX
2025-04-24 18:20:46.863 DBG default: lsblk -ln -o LABEL /dev/nvme0n1p4| grep -q rootMX
2025-04-24 18:20:46.866 DBG default: lsblk -ln -o LABEL /dev/sda1| grep -q rootMX
2025-04-24 18:20:46.869 DBG default: lsblk -ln -o LABEL /dev/sda2| grep -q rootMX
2025-04-24 18:20:59.798 DBG default: "lsblk" ("-nro", "MOUNTPOINTS", "/dev/sda2")
2025-04-24 18:20:59.808 DBG default: "/"
2025-04-24 18:20:59.808 DBG default: update-grub
2025-04-24 18:21:02.894 WRN default: "Generating grub configuration file ..."
2025-04-24 18:21:02.894 WRN default: ""
2025-04-24 18:21:02.956 WRN default: "done"
2025-04-24 18:21:02.956 WRN default: ""

Posted: **Sat Apr 26, 2025 6:49 am**

Nun habe ich doch neu gebootet.

PS: Die Linux Mint Partition befand sich neben der MX Partition.

Leider blieb nach dem

Code: Select all

update-grub

die Vorgabe nicht bestehen und hat sich so überschrieben, dass ich wieder in der grub-shell lande.
Wenn ich das also nicht mache sollte der nächte Bootvorgangen korrekt ablaufen. Das ist aber nicht korrekt.

Nun habe ich die modifizierte grub erneut kopiert und angepasst, der boot funktioniert.
Alle folgenden Infos sind vom aktuellen System.
v-v-v-v-v

Zudem habe ich viele zu viele Bootloader auf dem Dualboot-System.
Mitunter weil die Ausgabe in der Grub-Shell, bei der Reparatur über die Grub-Shell falschzu sein schien und ich vermutlich in einen falschen Root-Ordner kopiert habe.
Mit wurde Linux Root in HD2,GPT2 angezeigt (also SDC2), allerdings ist Linux in der SDA laut gparted:

Meine Wiindows SSD sieht so aus:

Screenshot_20250426_123426.png

Die Ausgabe von efibootmgr vom Live System gestartet:

Code: Select all

$ efibootmgr -v

BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0005,0006,0000,0001,0002,0003,0007,0008,0009
Boot0000  Windows Boot Manager	HD(1,GPT,af097f80-11a4-430f-ac1e-15369846c136,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.}...d................
Boot0001  MX Linux	HD(1,GPT,c2569ad7-5435-46aa-9278-a1639326686d,0x800,0x80000)/File(\EFI\MX\grubx64.efi)
Boot0002  UEFI OS	HD(1,GPT,c2569ad7-5435-46aa-9278-a1639326686d,0x800,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003  Ubuntu	HD(1,GPT,af097f80-11a4-430f-ac1e-15369846c136,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* UEFI: VerbatimSTORE N GO PMAP, Partition 2	PciRoot(0x0)/Pci(0x14,0x0)/USB(23,0)/USB(0,0)/HD(2,MBR,0xe4688a46,0x1cdc000,0x10000)..BO
Boot0006* UEFI: VerbatimSTORE N GO PMAP, Partition 1	PciRoot(0x0)/Pci(0x14,0x0)/USB(23,0)/USB(0,0)/HD(1,MBR,0xe4688a46,0x800,0x1cdb800)..BO
Boot0007* UEFI:CD/DVD Drive	BBS(129,,0x0)
Boot0008* UEFI:Removable Device	BBS(130,,0x0)
Boot0009* UEFI:Network Device	BBS(131,,0x0)

Zeigt hier das von Ventoy gebootet wurde.

aktuelle Ausgabe vom korrekten gebootetem System:

Code: Select all

$ efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,0002,0003
Boot0000* Windows Boot Manager  HD(1,GPT,af097f80-11a4-430f-ac1e-15369846c136,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.}...d................
Boot0001* MX Linux      HD(1,GPT,c2569ad7-5435-46aa-9278-a1639326686d,0x800,0x80000)/File(\EFI\MX\grubx64.efi)
Boot0002* UEFI OS       HD(1,GPT,c2569ad7-5435-46aa-9278-a1639326686d,0x800,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003* Ubuntu        HD(1,GPT,af097f80-11a4-430f-ac1e-15369846c136,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)

Im UEFI Manager werden mir 4 Boot-Optionen gezeigt.

Ubuntu müsste von der Linux Mint Partition sein die ich gelöscht habe.

MX Boot Optionen:
Ich weiß nicht ob ich von hier Grub neu installieren sollte. Ich hab das noch nie gemacht.
Der aktuelle Kernel 6.14.2-1-liquorix mit MX 23.6 fehlt!!

Wie sollte ich jetzt vorgehen um das in Ordnung zu bringen?
Letztendlich sollte nur

- MX Linux 23.6 mit Kernel 6.14.***
- MX Linux 23.5 mit vorherigem Kernel 6.13.***
- Windows 10

im Grub-Menü stehen.
Dazu muss ich aber etwas aufräumen.
Für jede Heilfe bin ich äußerst dankbar.

Posted: **Mon Apr 28, 2025 4:55 am**

Hallo, 5th.attempt

So richtig steige ich durch deine Beschreibungen nicht durch.
Das liegt aber hauptsächlich an meiner Auffassungsgabe.

Jedenfalls Respekt, vor deiner eingangs geschilderten Bastellösung.

Ich gehe aber davon aus, dass es sich auch mit MX-Boot-Reparatur hätte machen lassen.

Anbei:
In den MX-Werkzeugen gibt es
- MX-Boot-Reparatur
- MX-UEFI-Manager ( welche meiner Meinung nach ebenfalls unter "Maintenance" statt unter "Software" gelistet sein sollte )
- MX-Boot-Optionen
- MX-Chroot-Rescue-Scan
- MX-Cleanup

Mit MX-Boot-Reparatur kannst du Grub neu installieren

Mit MX-UEFI-Manager kannst du ein Ranking der UEFI-Systeme festlegen oder UEFI-Systeme aus der Liste der Einträge löschen.

Mit MX-Boot-Optionen kannst du bestimmen, welcher Kernel oder Welches System beim Boot-Start automatisch gebootet werden soll.
z. B. Windows oder Linux-Mint mit Kernel xyz oder MX mit kernel 5.10-192-antix ( sofern installiert ) usw.

Mit MX-Cleanup kannst du Kernelballast loswerden.
Es werden dir alle im laufenden MX installierten Kernel aufgelistet. Du kannst dann wählen, welche deinstalliert werden sollen.
Wie geschrieben, es bezieht sich auf das laufende System.
Bist du im Live-System, bezöge sich MX-Cleanup auf die Kernel des Live-Systems. Bei einem MX-Snapshot könnten da schon auch mehrere sein. Im Normalfall ist es absolut unsinnig, die Kernel eines Live-Systems zu löschen.

MX-Chroot-Rescue-Scan kannst du verwenden, um in deinem defekten System ein update-grub oder ein update-initramfs -u -k all vorzunehmen.
Vor dem Starten von MX-Chroot-Rescue-Scan darauf achten, dass das System, welches du bearbeiten möchtest, nicht gemountet ist.
Falls doch, dann vorher mit gparted aushängen.
Anschließend chroot-rescue-scan benutzen, um die entsprechenden Reparatur-Befehle über das chroot-Terminal anwenden.

Bei allem was du machen wirst, solltest du vorher abklären, ob deine Ausgabe von

Code: Select all

blkid

übereinstimmt, mit deinen Einträgen in

Code: Select all

/etc/fstab

des zu reparierenden Systems.
Wenn nicht, dann Korrigieren und Speichern.
Danach

Code: Select all

update-grub

Das ist der Punkt wo chroot-rescue-scan nützlich ist- wenn man diese Korrekturen über Live-System vorgenommen hat.

O.K.
In einem ähnlich verqueren, noch etwas komplizierteren Fall, bin ich so vorgegangen:

Ich habe mein MX-Live-System benutzt.
Habe von dem aus die EFI-Partition des zu reparierenden Systems eingehängt, damit ich darauf zugreifen kann.
In der EFI-Partition habe ich alle vorhandenen Ordner entfernt.
Entfernt, nicht gelöscht.
Meint erst mal da wegkopiert, als BkUp, und dann doch gelöscht.
Ist da ein Windows-Eintrag, dann würde ich den aber in jedem Fall stehen lassen.

Ich bin mir nicht mehr sicher, ob ich auch alle Einträge aus dem UEFI-Manager gelöscht hatte.
Ich glaube ja ... Aber ... vielleicht lieber erst mal noch nicht.
Kann man ja in einem zweiten Durchgang überlegen falls dieser erste keinen Erfolg hat.

Nach dem also die EFI-Partition leer Ist ( bis auf den Windows-Eintrag ),
mit MX-Boot-Reparatur den Grub für die MX-Boot-Reparatur noch mal neu installieren.
Danach sollte in der EFI-Partition ein sauberer neuer Boot-Entrag vorhanden sein.
Booten klappt dann hoffentlich wieder.

Eigentlich würde ich die Situation gleich nutzen und die vorhandene EFI-Partition für Windows lassen und für Linux eine eigene Partition ESP-Linux anlegen.
Am Liebsten am Ende der Festplatte, damit Windows da nicht dran rumfummelt.
fat32, 500MB
ESP-Boot-Markierung.
Diese Partition dann bei der Neuinstallation von Grub wählen.

Gut aber vielleicht erst mal die schlichtere Variante, die ich davor vorgeschlagen hatte, um bei Misslinge nicht mit mehreren Unbekannten kämpfen zu müssen.

Ob meine Vorschläge bei dir zum Erfolg führen, wie es bei mir der Fall war oder eher was verschlimmern, kann ich nicht einschätzen.
Wäre schon schön, wenn meine Vorschläge noch mal jemand bestätigt oder korrigiert.

Posted: **Tue May 06, 2025 10:50 am**

Danke Loik für den Versuch.

Meine Angst ist, dass ich bei jedem Bootvorgang, die grub-cfg kopieren und anpassen muss, wenn ich nicht eine Lösung finde wie grub konstant bleibt.
Deswegen bin ich seit paar Tagen wieder auf Windows.

Wie erwähnt updated die grub jedesmal in den INIT Zustand, sobald Grub geupdatet wird.
Scheinbar muss ich noch weitere Daten anpassen.

Mit scheint, dass eine neuinstallation die beste Option ist.

Was ich nicht weiß:

- wohin muss grub exakt installiert werden, wenn ich grub neu installieren wollte für dualboot.

Soll ich auf sda1 (boot/efi) oder sda2 (root) installieren?
https://postimg.cc/zH1fV1NP

- warum führt update grub, im installierten system, bei einem zweiten boot in die grub-shell? Sie wird mit einem INIT überschrieben, und es bootet die grubshell, woher kommt das?
- wie führe ich alle vorhandenen Daten so zusammmen, dass ich in das grub menü laden kann und windows und MX-Linux auswählen kann?
- was stimmt mit der windows partition nicht? Was sit mfstres?

https://forum.mxlinux.org/download/file ... &mode=view

Vielleicht erreiche ich mit kleineren Fragen eher Aufmerksamkeit.
Ich will mal versuchen Grub neu zu installieren mittels der MX-Boot-Optionen.

Posted: **Tue May 06, 2025 1:15 pm**

Ich poste einfach mal was ich so mache bis sich jemand erbarmt.

- boot repair hat nicht funktioniert
- boot reparatur ersetzt die grub-cfg in den init ohne boot daten (bsp. unten). (das führt beim nächsten boot in die grub-shell)
- grubx64.efi ist aus dem EFI folder verschwunden

bin aktuell im Live System

MX Boot Options:
- Starten von: ist leer

MX Boot Reparatur
- nochmalige installation in den root ordner hat nicht funktioniert (ort: sda, root:sda2 /mnt/chroot-rescue-scan/rootmx23 rootmx23)
- instaliere auf ESP im zweiten Versuch (ich glaube ich habe eine separate boot auf sda1 vielleicht ist das das problem) wir werden sehen.

Erfolgreich abgeschlossen.

ich schaue mal wie die grub-cfg aussieht.
EFI is noch leer
grub unverändert, die sieht immer so aus und endet in der grubshell, is egal was ich mache
update oder neu install, sieht immer gleich aus. das einzige was funktioniert hat, für eimaliges booten, ist das kopieren einer anderen grub.cfg aus dem backup.

Code: Select all

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

terminal_input console
terminal_output console
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=2
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=2
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux_proxy ###

### END /etc/grub.d/10_linux_proxy ###

### BEGIN /etc/grub.d/40_custom_proxy ###
### END /etc/grub.d/40_custom_proxy ###

### BEGIN /etc/grub.d/44_linux_proxy ###
### END /etc/grub.d/44_linux_proxy ###

### BEGIN /etc/grub.d/45_linux_xen ###
### END /etc/grub.d/45_linux_xen ###

### BEGIN /etc/grub.d/46_memtest86+_proxy ###

### END /etc/grub.d/46_memtest86+_proxy ###

### BEGIN /etc/grub.d/47_os-prober ###
### END /etc/grub.d/47_os-prober ###

### BEGIN /etc/grub.d/48_memtest86+_proxy ###
### END /etc/grub.d/48_memtest86+_proxy ###

### BEGIN /etc/grub.d/49_custom_proxy ###
### END /etc/grub.d/49_custom_proxy ###

### BEGIN /etc/grub.d/50_uefi-firmware ###
### END /etc/grub.d/50_uefi-firmware ###

### BEGIN /etc/grub.d/51_fwupd ###
### END /etc/grub.d/51_fwupd ###

### BEGIN /etc/grub.d/52_custom_proxy ###

### END /etc/grub.d/52_custom_proxy ###

### BEGIN /etc/grub.d/53_custom ###
### END /etc/grub.d/53_custom ###

chroot-rescue-scan zeigt mit immer noch MX 23.6 in rootmx23 - schön.

Posted: **Tue May 06, 2025 1:57 pm**

loik wrote: Mon Apr 28, 2025 4:55 am So richtig steige ich durch deine Beschreibungen nicht durch.

Ich auch nicht

5th.attempt wrote: Tue May 06, 2025 10:50 am Mit scheint, dass eine neuinstallation die beste Option ist.

Scheint mir auch so.

Posted: **Wed May 07, 2025 3:38 am**

Hallo, 5th.attempt

Ich bleibe doch mal hier im Thema, statt bei PM, weil so andere mit einsteigen könne, wenn sie wollen und weil so andere Netz-Sucher, die Change haben, für ihr Problem eine Lösung abzuleiten oder eine Anregung für die Lösung ihres Problems zu erhalten.

Grundsätzlich bist du zu ungeduldig und versuchst zu viel auf einmal.
Das erinnert mich an meine eigenen Herangehensweise.
Ist aber nicht nützlich.
Wenn du schnell hintereinander an mehreren Schrauben, fast zeitgleich drehst, verlierst du den Überblick und weißt nicht mehr, ob mit deinem Versuch bei Y nicht der Lösungsweg für X versperrt wurde.
Dann scheitern wohl möglich korrekte Hilfestellungen aus der Ferne für X, weil weder du und erst recht nicht die Helfer aus der Ferne, die Änderungen bei Y auf dem Zettel haben, usw.

Ich habe, weil zu unkonzentriert gelesen, erst jetzt erkannt, dass du mit Zwei Festplatten arbeitest.
Eine für Windows eine für Linux und diese so gar mit eigener ESP.
Das ist schon mal sehr gut.
Diese Konstellation habe ich auch auf einer CSL-Narrowbox-Ultra.
Funktioniert.
Allerdings mit win10 ( ob es mit win11 komplizierter ist, habe ich noch nicht getestet. )
In der ESP der Windows-Platte ist nur der EFI-Eintrag für Windows.
In der ESP der Linux-Platte sind die Einträge der Linux-Systeme meines Multiboots.
So sollte es auch bei dir sein.
Bzw. da willst du hin.
Du hattest von einer separaten Boot-Partition geschrieben.
Die konnte ich auf deinen Screenshots aber nicht erkennen.
Wo soll die sein ?

Ob VenToy da ein Problem ist, weiß ich nicht.
Verstehe gar nicht wozu das nötig sein sollte.
Habe ich noch nie gebraucht und benutze sehr viele unterschiedliche Multiboot-Konstellationen.

Zum Bearbeiten der Systeme reicht eigentlich ein MX-Live-System, das bringt alles mit was es braucht.
Es sollte aber unbedingt ein MX.23.6_64bit-xfce sein.
Xfce, weil einfacher mit umzugehen.
MX-23.6, weil nur damit der Grub für UEFI erfolgreich neu installiert werden kann.
64bit, weil für die Grub-Neuinstallation das MX-Live-System den gleiche Bit-Typ haben muss, wie das zu bearbeitende System, sonst scheitert die Installation von Grub.
( Also bei einem 32bit-System müsste es ein MX-Live-System-32bit sein.)
Welches Live-System hast du benutz ?

Für die Grub-Neuinstallation mit MX-Boot-Reparatur müsstest du wählen:
- Nochmalige Installation des Grub ......
- ESP
- ORT: - sda1 ( laut deinem Screenshot )
- root-Speicherort: - sda2 ( laut deinem Screenshot )

Danach sollte in der ESP-Partition sda1 ein Boot-Eintrag für MX-23 zu finden sein.
( Ist nur einsehbar vom Live-system aus )

Vor der Grub-Neuinstallation
solltest du entfernen, alle Linux-Einträge die sich befinden in der
Windows-ESP-Partition "nvme0n1p1"
Wie schon beschrieben, als BkUp irgendwo sichern, dann in der Win-ESP Löschen.
( Ich würde von der gesamten ESP eine Sicherungskopie machen. )

Wenn dem so geschehen, einen Neustart versuchen.
Kann sein, dass du dafür in deinen EFI-Bios erst mal die Bootreihenfolge deiner Datenträger festlegen musst.
Also Sandisk vor Samsung.

Jetzt zu deiner Frage aus deiner PM

Bisher bin ich wieder in Windows unterwegs, weil ich nicht weiß wie ich den Bootvorgang fixen kann.
Booten tue ich Windows über den Ventoy-Stick, ich glaube über Window-Boot Rescure oder so ähnlich.

Meine Hauptfrage ist eigentlich warum ein update-grub, die grub-cfg zurücksetzt im installierten Sytem.
Diese grub-cfg habe ich ja ersetzt von einem Backup und angepasst, so dass sie einmal funktioniert.
Beim nächsten Boot geht es wieder nicht.

Also

Code: Select all

/boot/grub/grub.cfg

Ich denke, die meinst du.
Und die sollst du nicht anfassen.
Steht extra oben drüber.

Code: Select all

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

Ja, die wird jedes mal neu überschrieben, von den Einträgen, die stehen in

Code: Select all

/etc/default/grub

Das soll so.
https://wiki.ubuntuusers.de/GRUB_2/Konfiguration/

https://de.linux-console.net/?p=35292

Grundlagen der GRUB2-Konfiguration

GRUB2 verwendet keine menu.lst-Datei. Stattdessen ist die Hauptkonfigurationsdatei die Datei /boot/grub/grub.cfg. Sie sollten diese Datei jedoch nicht von Hand bearbeiten! Diese Datei ist nur für den eigenen Gebrauch von GRUB2 bestimmt. Es wird automatisch erstellt, indem der Befehl update-grub oder grub2-mkconfig als root ausgeführt wird, d. h. durch Ausführen von sudo update-grub unter Ubuntu.

Ihre eigenen GRUB-Einstellungen werden in der Datei /etc/default/grub gespeichert. Bearbeiten Sie diese Datei, um die Einstellungen von GRUB2 zu ändern. Skripte befinden sich ebenfalls im Verzeichnis /etc/grub.d/. Unter Ubuntu gibt es hier beispielsweise Skripte, die das Standarddesign konfigurieren. Es gibt auch ein os-prober-Skript, das die internen Festplatten des Systems auf andere installierte Betriebssysteme überprüft – Windows, andere Linux-Distributionen, Mac OS X und so weiter – und sie automatisch zum Menü von GRUB2 hinzufügt.

Wenn Sie den Befehl update-grub ausführen, kombiniert GRUB automatisch die Einstellungen aus der Datei /etc/default/grub, die Skripte aus dem Verzeichnis /etc/grub.d/ und alles andere und erstellt eine Datei /boot/grub/grub.cfg, die beim Booten gelesen wird.

Mit anderen Worten, um Ihre GRUB2-Einstellungen anzupassen, müssen Sie die Datei /etc/default/grub bearbeiten und dann den Befehl sudo update-grub oder unter Fedora Linux den Befehl sudo grub2-mkconfig ausführen.

Bearbeiten der GRUB-Konfigurationsdatei
Öffnen Sie die Datei /etc/default/grub, um sie in einem Standardtexteditor zu bearbeiten .....

Du musst also nicht /boot/grub/grub.cfg bearbeiten oder ersetzen, sondern /etc/default/grub.
Vorher aber eine BkUp-Kopie der Datei /etc/default/grub erstellen.
Die kann im selben ordner verbleiben, braucht nur einen anderen Namen.
/etc/default/grub_(kopie)_BkUp_old
oder ähnlich.
Danach aber unbedingt

Code: Select all

sudo update-grub

Code: Select all

sudo update-initramfs -u -k all

Wenn es vom Live-System aus gemacht werden muss, dann mit Chroot-Rescue-Scan aus den MX-Werkzeugen.
Die beiden Befehle sind dann aber ohne sudo anzuwenden.

Posted: **Mon May 12, 2025 2:46 am**

loik wrote: Wed May 07, 2025 3:38 am
In der ESP der Windows-Platte ist nur der EFI-Eintrag für Windows.
In der ESP der Linux-Platte sind die Einträge der Linux-Systeme meines Multiboots.

Verstehe, mir war nicht ganz klar bezüglich des Versuchs der Neuinstallation, ob ich da was rein installieren sollte.

loik wrote: Wed May 07, 2025 3:38 am So sollte es auch bei dir sein.
Bzw. da willst du hin.
Du hattest von einer separaten Boot-Partition geschrieben.
Die konnte ich auf deinen Screenshots aber nicht erkennen.
Wo soll die sein ?

da lag ich wohl falsch, es gibt nur den EFI Eintrag bzw boot, esp auf beiden SSD's.

loik wrote: Wed May 07, 2025 3:38 am Ob VenToy da ein Problem ist, weiß ich nicht.
Verstehe gar nicht wozu das nötig sein sollte.
Habe ich noch nie gebraucht und benutze sehr viele unterschiedliche Multiboot-Konstellationen.

Aktuell komme ich nur mit Ventoy in irgend ein System (Windows SSD1) oder mit der grub manipulation ins MX Linux SSD2.
Windows steht nicht mal im BIOS Boot Menü des PC nur MX Linux steht drin, was aber in der Grubshell endet.
Ins Windows komme ich mit der Option von MX Linux - Bootloader Rescue oder so ähnlich, der zeigt mir auch viele verschiedene Boot-Loader an.

loik wrote: Wed May 07, 2025 3:38 am Zum Bearbeiten der Systeme reicht eigentlich ein MX-Live-System, das bringt alles mit was es braucht.
Es sollte aber unbedingt ein MX.23.6_64bit-xfce sein.
Xfce, weil einfacher mit umzugehen.
MX-23.6, weil nur damit der Grub für UEFI erfolgreich neu installiert werden kann.
64bit, weil für die Grub-Neuinstallation das MX-Live-System den gleiche Bit-Typ haben muss, wie das zu bearbeitende System, sonst scheitert die Installation von Grub.
( Also bei einem 32bit-System müsste es ein MX-Live-System-32bit sein.)
Welches Live-System hast du benutz ?

Live System mit Ventoy, hab da mehrere ISO drauf.
Habe für die ganze Grub Manipulations Geschichte MX-23.5_ahs_x64.iso (=XFCE) benutzt.
Ich konnte nur Ventoy nutzen es ging nichts anderes.

OT: Installiert auf SSD2 habe ich ja auch XFCE, wollte KDE haben und habe es komplett mit KDE überspielt.
Das hat auch funktioniert. Ich konnte KDE wegen der Grafikkarte nicht installieren oder booten vom Stick. Erst zu spät wurde mir klar,
dass ich eine Bootoption nutzen könnte um nicht bei "UDEV done" hängen zu bleiben.

Also ziehe ich mir zur Problemlösung eine ISO mit 23.6-AHS-XFCE und wie komme ich dann auch KDE? Wieder überspielen?
Kann ich denn NUR GRUB und was dazugehört neu installieren ohne den Rest des Sytems zu überspielen?
Kannst du den Vorgang näher erklären?
Vielleicht muss ich ja nur paar Ordner kopieren dass es wieder richtig läuft?!

loik wrote: Wed May 07, 2025 3:38 am Für die Grub-Neuinstallation mit MX-Boot-Reparatur müsstest du wählen:
- Nochmalige Installation des Grub ......
- ESP
- ORT: - sda1 ( laut deinem Screenshot )
- root-Speicherort: - sda2 ( laut deinem Screenshot )

Also von der Live 23.6 Version...welche auch immer ich booten kann.
Genau SDA sind die beiden partitionen von ESP, BOOT und mxroot23, OK.

loik wrote: Wed May 07, 2025 3:38 am Danach sollte in der ESP-Partition sda1 ein Boot-Eintrag für MX-23 zu finden sein.
( Ist nur einsehbar vom Live-system aus )

aha, okay muss ich schauen.

loik wrote: Wed May 07, 2025 3:38 am Vor der Grub-Neuinstallation
solltest du entfernen, alle Linux-Einträge die sich befinden in der
Windows-ESP-Partition "nvme0n1p1"
Wie schon beschrieben, als BkUp irgendwo sichern, dann in der Win-ESP Löschen.
( Ich würde von der gesamten ESP eine Sicherungskopie machen. )

Ja das krieg ich bestimmt irgendwie hin, wenn diese nicht zufällig auch kaputt wäre.
Also die Partition löschen? Kann ich ja quasi alles mit gparted und anderen apps machen vom Live System?!

loik wrote: Wed May 07, 2025 3:38 am Wenn dem so geschehen, einen Neustart versuchen.
Kann sein, dass du dafür in deinen EFI-Bios erst mal die Bootreihenfolge deiner Datenträger festlegen musst.
Also Sandisk vor Samsung.

klar. Linux first.

loik wrote: Wed May 07, 2025 3:38 am Jetzt zu deiner Frage aus deiner PM
Bisher bin ich wieder in Windows unterwegs, weil ich nicht weiß wie ich den Bootvorgang fixen kann.
Booten tue ich Windows über den Ventoy-Stick, ich glaube über Window-Boot Rescure oder so ähnlich.

Meine Hauptfrage ist eigentlich warum ein update-grub, die grub-cfg zurücksetzt im installierten Sytem.
Diese grub-cfg habe ich ja ersetzt von einem Backup und angepasst, so dass sie einmal funktioniert.
Beim nächsten Boot geht es wieder nicht.
Also
Code: Select all
/boot/grub/grub.cfg
Ich denke, die meinst du.
Und die sollst du nicht anfassen.
Steht extra oben drüber.
Code: Select all
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
Ja, die wird jedes mal neu überschrieben, von den Einträgen, die stehen in
Code: Select all
/etc/default/grub
Das soll so.
https://wiki.ubuntuusers.de/GRUB_2/Konfiguration/

https://de.linux-console.net/?p=35292
Grundlagen der GRUB2-Konfiguration

GRUB2 verwendet keine menu.lst-Datei. Stattdessen ist die Hauptkonfigurationsdatei die Datei /boot/grub/grub.cfg. Sie sollten diese Datei jedoch nicht von Hand bearbeiten! Diese Datei ist nur für den eigenen Gebrauch von GRUB2 bestimmt. Es wird automatisch erstellt, indem der Befehl update-grub oder grub2-mkconfig als root ausgeführt wird, d. h. durch Ausführen von sudo update-grub unter Ubuntu.

Ihre eigenen GRUB-Einstellungen werden in der Datei /etc/default/grub gespeichert. Bearbeiten Sie diese Datei, um die Einstellungen von GRUB2 zu ändern. Skripte befinden sich ebenfalls im Verzeichnis /etc/grub.d/. Unter Ubuntu gibt es hier beispielsweise Skripte, die das Standarddesign konfigurieren. Es gibt auch ein os-prober-Skript, das die internen Festplatten des Systems auf andere installierte Betriebssysteme überprüft – Windows, andere Linux-Distributionen, Mac OS X und so weiter – und sie automatisch zum Menü von GRUB2 hinzufügt.

Wenn Sie den Befehl update-grub ausführen, kombiniert GRUB automatisch die Einstellungen aus der Datei /etc/default/grub, die Skripte aus dem Verzeichnis /etc/grub.d/ und alles andere und erstellt eine Datei /boot/grub/grub.cfg, die beim Booten gelesen wird.

Mit anderen Worten, um Ihre GRUB2-Einstellungen anzupassen, müssen Sie die Datei /etc/default/grub bearbeiten und dann den Befehl sudo update-grub oder unter Fedora Linux den Befehl sudo grub2-mkconfig ausführen.

Bearbeiten der GRUB-Konfigurationsdatei
Öffnen Sie die Datei /etc/default/grub, um sie in einem Standardtexteditor zu bearbeiten .....
Du musst also nicht /boot/grub/grub.cfg bearbeiten oder ersetzen, sondern /etc/default/grub.
Vorher aber eine BkUp-Kopie der Datei /etc/default/grub erstellen.
Die kann im selben ordner verbleiben, braucht nur einen anderen Namen.
/etc/default/grub_(kopie)_BkUp_old
oder ähnlich.
Danach aber unbedingt
Code: Select all
sudo update-grub
Code: Select all
sudo update-initramfs -u -k all
Wenn es vom Live-System aus gemacht werden muss, dann mit Chroot-Rescue-Scan aus den MX-Werkzeugen.
Die beiden Befehle sind dann aber ohne sudo anzuwenden.

ah, verstehe update-grub vom live system, das war mir bei einigen anleitungen auch nicht ganz klar, weil ich dachte dass der Befehl die grub vom livesystem verändern müsste.
Mit chroot macht das aber Sinn, weil ich dadurch zugriff auf die installierte version habe. Logisch.

---

Der Kern der Sache ist mit dem Livesystem, dass dem installieren System ähnlich ist 23.6

- in der Windows SSD die ESP Partition sichern und entfernen, die wird dann vermutlich neu angelegt bei der Grub Installation.
- GRUB mit der BOOT Reparatur neu zu installieren.
- Für die Grub-Neuinstallation mit MX-Boot-Reparatur müsstest du wählen:
- Nochmalige Installation des Grub ......
- ESP
- ORT: - sda1 ( laut deinem Screenshot )
- root-Speicherort: - sda2 ( laut deinem Screenshot )
-- Da die Screenshots noch aktuell sind dürfte das passen.

- Check ob in der ESP,BOOT also SDA1 ein eintrag steht.
- Boot in BIOS -Reihenfolge ändern, Linux first.

Okay ich bereite mich geistig und Moralisch auf das Project vor und melde mich.
Herzlichsten Dank für deine präzisen Ausführungen. *kuss*

Posted: **Wed May 14, 2025 4:35 am**

Moin.

Habe es jetzt erst gelesen.

NICHT die ESPs lösche!

Nur die Inhalte der ESP von sda, falls dort welche vorhanden sind.

In der ESP von nvme0n1p1 sollte nur der Windows-Booteintrag bleiben.

Ich glaube, das Ventoy alles verschlimmbessert.

Du solltest dir ein MX-Live-System auf einen separaten Datenträger installieren.
Eigentlich geht es auch, dass man mit den MX-Live-Systemen installierte OSs booten kann ( Starthilfe quasi ).
Ich habe es noch nicht dafür genutzt.
Aber Fehlix hatte es mal beschrieben.

Ich würde grundsätzlich in deinem Fall so vorgehen:
Die SanDisk-SSD sda vom Rechner entfernen.
Dann im Netz nach Anleitungen oder Tools suchen, mit denen du den MBR bzw das UEFI für Windows wieder herstellen kannst.
Also, erst mal nur Windows zum Booten bringen, so wie du den PC bekommen hattest.
Dann sollte das Windows auch wieder in der UEFI-BIOS-Boot-Auswahl zu finden sein.
Wenn Windows nun wieder eigenständig bootet, dann in Windows in den Energie-Einstell-Optionen Fast-Boot deaktivieren !

Wenn dir das alle gelungen ist und Windows wieder läuft, können wir weiter machen, mit einem separaten MX-Live-Boot-Stick.

Interressant wäre, ob die Samsung-SSD nvme0n1 sich aus dem Rechner entfernen lässt.

Wenn ja, würde ich dann ( aber erst wenn das Windows, da wieder eigenständig bootbar ist, ) diese Platte aus dem Gerät entfernen.
Dann die SanDisk-SSD einbauen oder anschließen.

Nun diese entweder genervt reparieren mit dem separaten MX-Live-System oder falls das installierte MX-KDE noch völlig roh und unkonfiguriert ist, MX noch mal komplett neu installieren.
Falls das bereits vorhandene System aber von Wert ist und sich booten lässt, kannst du davon auch einen MX-Schnappschuss machen.
Dieses Schnappschuss-ISO dann wiederum als MX-Live-System auf einen separaten USB-Stick bringen und den nun für die Installation benutzen.
Du kannst es vollständig auf die Platte installieren.
Da das Windows nicht anwesend ist, kannst du ja nichts falsch machen.
Und du hast recht, in diesem Fall wird die notwendige ESP für das Linux, auf dieser Platte neu erstellt.

Wenn dein Linux nach der Installation, bootet und hochgefahren ist, dann solltest du die ESP mit gparted umbenenn, in "ESP-Linux_SanDisk" oder ähnlich, damit du in Zukunft, falls es noch mal dazu kommt, dass du Grub neu installieren musst, die ESP eindeutig erkennen kannst und nicht mit der von Win verwechselst.

Falls du deine SanDisk-SSD nun doch noch partitionieren willst, wäre jetzt ein guter Zeitpunkt.
Das machst du dann aber wieder mit dem separaten MX-Live-System und dessen gparted.

Hat das geklappt und bootet das System danach auch korrekt, kann die Samsung-SSD wieder mit in den Rechner genommen werden.
Es sollte nun möglich sein, dass beide System in der UEFI-BIOS-Bootauswahl aufgelistet werden ebenso auch im UEFI-Setup.

Stelle im UEFI-BIOS-Setup die Boot-Reihenfolge ein:
USB
CD
MX
Windows
EFI
usw.

Wichtig ist, dass MX vor Windows steht und EFI (-Shell ) am Ende.

Wenn dem so geschehen und du MX gebootet hast, dann machst du im Terminal ein

Code: Select all

sudo update-grub

Danach sollte es so sein, dass beim Einschalten des PCs, automatisch das Grub-Boot-Menü von MX erscheint.
In diesem dürfte nun auch ein Eintrag für Windows zu finden sein, so dass du nun an dieser Stelle auswählen kannst, welches System du Booten möchtest.

Welches der beiden Systeme nach 5 Sekunden automatisch booten soll, falls du keine Auswahl triffst, kannst du in MX-Boot-Optionen einstellen.

MX Linux Forum

Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Re: Überflüssige Partition gelöscht, grub shell boot und gefixt - jetzt alles okay?

Re: Überflüssige Partition gelöscht, grub shell boot und gefixt - jetzt alles okay?

Re: Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Re: Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Re: Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Re: Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Re: Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Re: Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot

Re: Überflüssige Partition gelöscht, grub.cfg, zu viele Bootloader, Dualboot