Bootloader bei Linux durch geplante Installation auf 2. SSD zerschossen - kurze Frage

[Evil E-Lex]

so schauts aus - ich weiß schon, warum ich die angefragten Ausgaben aus dem wohl funktionierenden Zorin heraus haben möchte, dann lässt sich das alles eindeutiger zuordnen und man muss nicht spekulieren.

Da der Zorin Datenträger komplett fehlt, wird das schwierig. An der Variablenbezeichnung ändert das trotzdem nichts. Es gibt Ubuntu-Derivate die schlicht zu bequem sind, diesen Eintrag anzupassen. Das führt dann gern zur Verwirrung, wenn man verschiedene Ubuntu-Derivate installiert hat und nun im UEFI-Bootmenü mehrere Ubuntu-Einträge auftauchen, obwohl man kein "echtes" Ubuntu installiert hat.

Ergänzung (27. September 2026)

Aber gut, mein System ist es nicht und auch nicht mein Problem - Vorschlag, wenn dir die vorhandenen Infos reichen, dann mach doch einfach mal einen Lösungsvorschlag oder wenigstens mal einen verwertbaren Versuch, eine Lösung zu finden.

Wenn du meine Beitrag gelesen hast, wirst du feststellen, dass auch mir nicht alle nötigen Infos vorliegen. Unter anderm fehlt die vom TE beschriebene zweite SSD. Das ist ein viel größeres Problem als die UEFI-Booteinträge, da so die aktuelle Systemkonfiguration nicht der entspricht, die der TE durch die Installation von Zorin geschaffen hat.

Mir jedenfalls reicht es nicht und darum bitte ich um die angefragten Infos aus Zorin heraus.

Mit welcher Erwartung? Was soll da anders aussehen?

 

[Habicht]

Mit welcher Erwartung? Was soll da anders aussehen?

das kann ich erst sagen, wenn die angeforderten Abfragen da sind - ich fasse nochmals zusammen:

sudo efibootmgr

sudo lsblk -o NAME,UUID,FSTYPE,SIZE,LABEL,MOUNTPOINT,PartUUID

sudo update-grub

alles bitte aus Zorin heraus - ob das sudo überall notwendig ist, weiß ich nicht, hab schon lange nicht mehr mit "Ubuntu" gearbeitet, schaden tut es aber auch nicht.

Aber gut, da ich mittlerweile eh davon aus gehe, dass hier vom TE nichts mehr kommt, bin ich erst mal raus - es sei denn, der TE meldet sich doch nochmal.

 

[santander]

Ich hätte gerne das "efibootmgr" aus Zorin heraus.

Zorin gibt es nicht.

Wo ist die zweite SSD jetzt? In der angehängten Boot Repair Textdatei taucht die nicht auf. Da sieht man eine 2 TB große SSD und einen 64 GB großen USB-Stick mit Ventoy.

Warum? Schau dir mal deine Ausgabe an - das "BootCurrent 000A" wird da nicht gelistet, ebenso sehe ich da kein "Zorin" - oder trägt sich das so wie Mint ebenfalls als "Ubuntu" ein?

Ich habe die Installation von ZorinOS dann sein lassen, also während der anfänglichen Installation abgebrochen. Wobei, wirklich installiert kann er ja noch nicht haben, weil ich noch nicht 'mal an dem Punkt angelangt war, wo er nachfragte, wohin es sich installieren soll.

Die SSD (eine 512 GB zum Testen, auf die Zorin installiert werden sollte) habe ich dann, nachdem ich die Zorin-Installation abgebrochen hatte, aus dem Laptop wieder ausgebaut.

Die 2 TB-SSD ist jene, auf der sich die Mint-Installation befindet. Die möchte ich gerne wiederhergestellt haben.

Sorry, das mit dem Ausbau der 2. SSD hatte ich vergessen zu erwähnen. Wusste gar nicht, dass Zorin in dieser Boot-Info festgehalten ist.

Mit welcher Erwartung? Was soll da anders aussehen?

Ja, das frage ich mich auch. Und wie gesagt: Zorin ist nicht existent.

Und Entschuldigung für die späte Rückmeldung. War heute den ganzen Tag unterwegs.

 

[Sensei21]

ok,

linux mint cryptsetup luks system restore grub bootloader

To restore the GRUB bootloader on a Linux Mint system using LUKS encryption, you must boot from a live USB, unlock the encrypted volume, mount the partitions, chroot into the system, and reinstall the bootloader.

1. Unlock and Mount​

Open the terminal in the live environment and unlock the LUKS partition (replace /dev/sdaX with your encrypted partition):

sudo cryptsetup luksOpen /dev/sdaX cryptroot
sudo vgchange -ay # Activate LVM if used
sudo mount /dev/mapper/cryptroot-root /mnt # Replace with your logical volume
sudo mount /dev/sdaY /mnt/boot # Mount unencrypted boot partition
sudo mount /dev/sdaZ /mnt/boot/efi # Mount EFI partition if UEFI
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done

2. Chroot and Reinstall​

Enter the chroot environment and reinstall GRUB:

sudo chroot /mnt
grub-install /dev/sda # Replace sda with the target disk, not partition
update-grub
update-initramfs -u -k all # Ensure initramfs includes cryptsetup hooks
exit

3. Troubleshooting​

If GRUB fails to detect the encrypted drive, ensure /etc/default/grub contains GRUB_ENABLE_CRYPTODISK=y and that cryptsetup-initramfs and lvm2 are installed. For UEFI systems, use grub-install --target=x86_64-efi --efi-directory=/boot/efi.

<-- für mich scheint die Anleitung Sinn zu machen (search.brave.com)

für die Anderen auch ?

https://avivace.com/notes/fix-grub-on-lvm-luks/
sieht auch interessant aus.

Wie bereits erwähnt wäre es sinnvoller von einem Linux Mint Bootmedium zu booten, die luks Partition zu öffnen und die Daten (alle ? oder die wichtigsten) auf einen zusätzlichen externen Datenträger zu sichern,

dann erst an das wiederherstellen wagen.

Mit verschlüsselten Partitionen und GUI tools ist nicht zu spassen, wenn da etwas schief läuft ...

Hatte in der Vergangenheit mit Windows schon Probleme, wo diskmanager immer penetrant nachfragt, ob eine "unformatierter" Datenträger (luks) formiert werden soll und in einem Augenblick mit weniger Konzentration reflexartig draufgeklickt und futsch waren alle Daten (zum Glück gutes Backup gehabt, trotzdem immens geärgert - hat ewig gedauert mehrere TB an Daten wiederherzustellen bzw. kopieren)

 

[santander]

Mache ein Backup der Daten.
Versuche https://www.supergrubdisk.org/ - hat bei mir immer funktioniert ins OS zu kommen und dann update-grub zu starten oder grub neu zu installieren.

Damit werde ich es jetzt als nächstes versuchen. Der Fehler kann eigentlich nicht so schwerwiegend sein, alsdaß er sich nicht einfach beheben lassen könnte.

Wie bereits erwähnt wäre es sinnvoller von einem Linux Mint Bootmedium zu booten, die luks Partition zu öffnen und die Daten (alle ? oder die wichtigsten) auf einen zusätzlichen externen Datenträger zu sichern,

dann erst an das wiederherstellen wagen.

Wenn das nun scheitert, bleibt mir nur der Weg einer Neuinstallation. Ist auch nicht so tragisch. Wichtige Daten waren auf der BS-Partition nicht vorhanden. Kostet halt nur 4 oder 5 Stunden an Zeit, bis alles wieder einigermaßen so ist, wie ich es haben will.

 

[Evil E-Lex]

Die SSD (eine 512 GB zum Testen, auf die Zorin installiert werden sollte) habe ich dann, nachdem ich die Zorin-Installation abgebrochen hatte, aus dem Laptop wieder ausgebaut.

Diese Information hätte in den Startbeitrag gehört. Und was heißt hier "abgebrochen"? Der Bootloader wird am Ende der Installation geschrieben.

Wenn das nun scheitert, bleibt mir nur der Weg einer Neuinstallation.

Nö. Solche Probleme lassen sich simpel lösen.

In dem Startbeitrag schreibst du:

Nur ein direktes Booten ist nicht mehr möglich.

Was bedeutet das? In der von dir angehängten Datei gibt es zunächst keinen Hinweis darauf, dass Mint ein Problem mit dem Booten hätte. Das sieht soweit alles sauber aus.

 

[Habicht]

In der von dir angehängten Datei gibt es zunächst keinen Hinweis darauf, dass Mint ein Problem mit dem Booten hätte. Das sieht soweit alles sauber aus.

Hmmm, also mir fällt folgendes auf:

blkid (filtered): ______________________________________________________________

NAME   FSTYPE      UUID                                 PARTUUID                             LABEL                  PARTLABEL
sda                                                                                                               
├─sda1 vfat        47B0-C74C                            3fd1ba65-01                                               
├─sda2 ext4        ef7e12f6-6fb3-4ee0-aaa4-75e2c5d79159 3fd1ba65-02                                               
├─sda3 crypto_LUKS 17ef22bd-903a-4b46-82be-f13fc6c8ad99 3fd1ba65-03                                               
└─sda4

und dann in der Ausgabe von efibootmgr folgendes

Boot0004* Ubuntu    HD(1,MBR,0x3fd1ba65,0x800,0xf4800)/File(\EFI\ubuntu\shimx64.efi)

zum einen steht da MBR und des weiteren fehlt die PARTUUID der sda1, also der Efi-Partition.

Da scheinen die Aussagen bzgl. der Zorin-Installation nicht zu stimmen - Zorin hat bereits irgend was in den NVRAM geschrieben, wurde aber nicht beendet - Stichwort: keine PARTUUID der Efi-Partition vorhanden.

Nachtrag: eine Alternative zu Supergrub2 wäre noch die Chroot-Methode via Livesystem - das wäre jetzt erst mal meine Empfehlung, vor allem, weil es ja bereits vorhanden ist.

 

[Evil E-Lex]

Bei MBR gibt es keine PARTUUID, deswegen fehlt die. Die Booteinträge sehen bei MBR-Boot über UEFI daher auch anders aus als bei GPT-Datenträgern.

Der Booteintrag

Boot0004* Ubuntu    HD(1,MBR,0x3fd1ba65,0x800,0xf4800)/File(\EFI\ubuntu\shimx64.efi)

verweist auf die erste Partition HD(1, dort auf den MBR mit der Signatur 0x3fd1ba65 bei Start-LBA 0x800. Geladen wird die Datei \EFI\ubuntu\shimx64.efi. Hierzu gibt es auch die Grub-Configdatei /efi/ubuntu/grub.cfg

Hier sucht GRUB mittels search.fs_uuid die Partition mit der UUID ef7e12f6-6fb3-4ee0-aaa4-75e2c5d79159. Das ist die ext4-Partiton /dev/sda2. Der Root-Hint root hd0,msdos2 ist nur ein Hinweis.

/dev/sda2 wiederum enthält eine weitere GRUB-Konfiguration in der Datei /grub/grub.cfg
Dort befinden sich zwei Einträge:

Linux Mint 22.3 MATE   eb884dd6-0a2f-4e4e-b698-d6c67685dd09
UEFI Firmware Settings   uefi-firmware

Der erste Eintrag ist der interessante und verweist auf ein Mint mit einer bis hier unbekannten PartUUID, wahrscheinlich ist das die PartUUID des Dateisystems im LUKS-Container.

Grundsätzlich sieht die Kette: EFI-Booteintrag -> /dev/sda1 -> /dev/sda2 -> Root-Partition im LUKS-Container nicht falsch aus.

Allerdings gebe ich für alle meine Ausführungen zu bedenken, dass dieses grottenschlechte Boot-Repair-Utility von Mint in der Textdatei nicht die vollständigen Configfiles zeigt, sondern nur Teile davon und zwar immer dann, wenn in der Überschrift (filtered) steht. Das ist natürlich hochgradig unsinnig und erschwert die Fehlersuche enorm.

 

[Habicht]

Im MBR gibt es keine shimx.64.efi - seh dir mal den ganzen Pfad an, das passt einfach nicht. Des weiteren, wenn du dir die Partitionstabelle anschaust, das ist ne GPT und für einen MBR benötigst du dafür eine kleine Extra-Partition für den Bios-Grub, die gibt es aber nicht.

Was bootrepair anbelangt, stimme ich dir zu, das Teil taugt einfach nichts.

 

[Evil E-Lex]

/dev/sda ist glasklar ein MBR-Datenträger. Schau dir mal die Ausgabe von parted -lm an:
sda:2000GB:scsi:512:4096:msdos:ATA CT2000MX500SSD1:;

Da wird schlicht der UEFI-Grub statt von einem GPT-Datenträger von einem MBR-Datenträger gestartet. Unüblich aber möglich.

 

[Habicht]

Hast recht, ist zwar gut versteckt aber ich habs gefunden - das ist alles ein totaler mischmasch, aber jetzt wo du es sagst meine ich, dass ich dieses "Feature" von Mint mal irgend wo gelesen habe.

Aber war das jetzt ne UEFI-Installation oder eine Legacy-Installation?

Wie auch immer, ich klinke mich aus und empfehle eine saubere Neuinstallation.

 

[Evil E-Lex]

Aber war das jetzt ne UEFI-Installation oder eine Legacy-Installation?

Das ist ne gute Frage. Die vorliegenden Daten beantworten sie nicht.

 

[Habicht]

Wegen dem shim und dem esp-Flag tendiere ich ja zur UEFI-Installation - aber da passt halt die sda1 nicht dazu. Kann natürlich auch sein, dass das von BootRepair verhunzt wurde.

 

[mkossmann]

Vorraussetzung für den UEFI-Boot ist eine Partition mit der Kennung UEFI-Systempartition. Und diese Kennung ist auch beim MBR-Partionsschema definiert (EF). Das man Windows im UEFI-mode nur von GPT-Partitionen booten kann ist eine Einschränkung des Windows-Bootloaders.
Da beide Distributionen als Ubuntu-Derivate ihre EFI-Binaries unter .../EFI/ubuntu installieren und somit der Installationsversuch von ZORIN die MINT Varianten dort überschrieben haben können könnte auch zu Problemen führen

 

[santander]

Also, danke für euer Engagement. Auch wenn mich das jetzt nicht direkt weiterbringt.

Ich habe jetzt einen Rettungsversuch mit Boot-Repair gewagt, allerdings ohne Erfolg.
Die LUKS-Partition mit dem Betriebssystem ist noch einbindbar. Es mangelt also nur an den Startdateien.
Ich habe noch eine SSD mit einem lauffähigen Linux-Mint 22.3 drauf, von dem ich jetzt hier aus schreibe.

Frage:
Könnte ich nicht einfach die ganzen nötigen Startdateien von Mint aus mit einem Dateimanager (mit Admin-Rechten) 1:1 rüberkopieren von der lauffähigen Mint-Installation auf die nicht lauffähige. Dann einfach die UUID abändern, und alles müsste doch wieder laufen?
Umkopieren würde ich sie von einer Installations-DVD von Mint aus, sodaß keine Sperren wirksam wären.


Also ich meine diese Dateien:



Und dann einfach in den umkopierten Dateien einfach die UUID anpassen. - Geht sowas?

Die UUID ist aber sehr oft in den Dateien genannt. Müsste ich evtl. nur eine abändern? Und wenn ja, in welchem Verzeichnis genau?

 

[Evil E-Lex]

Du bist einen Schritt zu weit. Du schreibst nur "startet nicht". Das hilft halt überhaupt nicht weiter. Was passiert genau? Kommst du nicht in GRUB oder startet GRUB das OS und es bricht mit Kernel Panic ab? Was passiert, wenn du mittels F-Tasten das Bootmenü aufrufst und Ubuntu auswählst?

Zu deinen Ideen: Das ist alles Quatsch, so funktioniert das nicht.

 

[Garmor]

Wie schon mehrfach geschrieben: https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#chroot-Methode

 

[santander]

Du bist einen Schritt zu weit. Du schreibst nur "startet nicht". Das hilft halt überhaupt nicht weiter. Was passiert genau? Kommst du nicht in GRUB oder startet GRUB das OS und es bricht mit Kernel Panic ab?

Bildschirm bleibt schwarz und es erscheint letztlich die Kommandozeile:

error: Unknown filesystem
entering rescue mode
grub_rescue>

Was passiert, wenn du mittels F-Tasten das Bootmenü aufrufst und Ubuntu auswählst?

Habe ich noch nicht ausprobiert. Der Ubuntu-Eintrag war aber schon immer drin (keine Ahnung, wie das ins BIOS jemals gelangt ist). Hat glaube ich keine Bedeutung. Werde es aber demnächst einmal ausprobieren.

Zu deinen Ideen: Das ist alles Quatsch, so funktioniert das nicht.

Ja, kann sein.

------------------------------------------------------------------------------------------------------------------------------------

Update:
Breaking News!!!

Was passiert, wenn du mittels F-Tasten das Bootmenü aufrufst und Ubuntu auswählst?

Zu meiner Überraschung: Er bootet dann wieder ganz normal die verschlüsselte Linux-Mint-Partition! 🙄

Alles gut! Danke für den Tipp!

Ich dachte, dieser "Ubuntu"-Eintrag im Boot-Menü des BIOS wäre irgendetwas altes, deshalb habe ich ihm keine Bedeutung beigemessen. Zumal da auch noch MX-Linux als Eintrag im Bootmenü ist. Und das ist nun wirklich schon ewig nicht mehr existent. (Sorry, bin halt definitiv kein Experte und mit der Linux-Befehlszeile werde ich immer auf Kriegsfuß stehen.)

Nächstes Mal, wenn ich wieder ein Betriebssystem installieren will, werde ich definitiv die zweite Festplatte ausbauen. Schon um mir solch einen Ärger zu ersparen.

 

[mkossmann]

Den ubuntu Eintrag gibt es weil Mint ein ubuntu Derivat ist.
Wenn du jetzt wieder in dein System kommst kannst du mit efibootmgr den ubuntu Eintrag wieder als default eintragen

 

[santander]

Die Bootreihenfolge kann man doch auch im UEFI ("neuer" Begriff für BIOS, wieder was gelernt) einstellen, was ich getan habe. Also, der Bootprozess passt nun wieder ohne irgendetwas auswählen zu müssen.