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

[santander]

Hi!

Habe seit gestern folgendes Problem: Ursprünglich wollte ich auf meiner zweiten intern verbauten SSD eine Installation von Linux Zorin zum Ausprobieren installieren.

Zorin hat dabei aber nach Drücken auf "Installieren" scheinbar den GRUB-Bootloader der Haupt-SSD (SSD #1) auf der mein Linux-Mint liegt, zerschossen. Ich war der Annahme, dass Zorin bei der Installation erst fragt, wo es das BS hininstallieren soll. Stattdessen legte es denke ich einfach los, und zerschoss den GRUB-Bootloader von Mint.

Die Linux-Mint-Installation ist mit LUKS verschlüsselt. Ich kann über eine Live-DVD auch noch die Betriebssystempartition einbinden, und auf die Daten zugreifen. Nur ein direktes Booten ist nicht mehr möglich. Daher denke iche, dass es ist nur eine (relative) Kleinigkeit ist, das System wieder zum Laufen zu bringen.

Ich habe nun von der Mint Installations-DVD das Tool Boot-Repair gestartet. Die KI meint, ich solle da besser nicht auf "reparieren" gehen, weil das Programm da die Verschlüsselung falsch versteht.

Deswegen möchte ich jetzt euch "echte Menschen mit Hirn & Verstand" sicherheitshalber fragen, ob ich nicht doch einfach auf Empfohlene Reparatur klicken kann.



Das Boot-Info-File, das Boot-Repair ausgegeben hat, habe ich zur Analyse hier angehängt.

Wie groß sind wohl die Chancen, dass es danach wieder einwandfrei funktioniert? - Momentan trau' ich mich nicht, darauf zu klicken. Wenn 's nicht klappt, hätte ich mindestens einen halben Tag Arbeit zum Neuaufsetzen des BS.

Bin erst vor 3 Wochen komplett auf Mint von Ubuntu Mate umgestiegen, nachdem Mate von Version zu Version immer schlechter wurde, und nun nicht 'mal mehr das teilweise Verschlüsseln einer SSD mit Crypt-Setup erlaubt (wurde herausgenommen; bei Mint hingegen funktioniert dies noch).

 

[Sensei21]

Hi,

erstmal Daten sichern, wer weiß was mit dem Luks Header oder der Partition passieren kann, wenn die Reparatur-Skripte Fehler beinhalten oder nicht mit Verschlüsselungen umgehen können

Wenn der Luks Header weg ist, sind die Daten unwiederbringlich futsch - also vorsichtig

 

[netzwanze]

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.

 

[@mo]

Boot-Repair

Klassisches Verschlimmbesserungs Tool. Kann klappen, kann in die Hose gehen.
Für das Boot Info Script brauchbar, vom Rest besser die Finger lassen.

 

[Habicht]

Zeig mal bitte aus Zorin heraus die Terminalausgabe von

efibootmgr

 

[Evil E-Lex]

Habe seit gestern folgendes Problem: Ursprünglich wollte ich auf meiner zweiten intern verbauten SSD eine Installation von Linux Zorin zum Ausprobieren installieren.

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.

@Habicht
Steht in der angehängten Textdatei. Da efibootmgr nur UEFI-Variablen ausliest ist es egal, ob der Befehl aus einem installierten System oder einer Live-OS-Umgebung ausgeführt wird.

BootCurrent: 000A
Timeout: 1 seconds
BootOrder: 000A,0000,0004,0008,0001,0005,0006
Boot0000* Hard Drive    BBS(HD,,0x0)
Boot0001* CD/DVD Drive    BBS(CDROM,,0x0)P2: MATSHITA DVD-RAM UJ8C1    .
Boot0004* Ubuntu    HD(1,MBR,0x3fd1ba65,0x800,0xf4800)/File(\EFI\ubuntu\shimx64.efi)
Boot0005*     HD(1,GPT,5a95de64-dc4d-4333-80a6-75e1f2ebb289,0x800,0x100000)/File()
Boot0006*     HD(1,GPT,5a95de64-dc4d-4333-80a6-75e1f2ebb289,0x800,0x100000)/File()
Boot0008* MX19    HD(1,GPT,aeb41d01-5bc1-4f01-9fee-b0939142fea5,0x800,0x80000)/File(\EFI\MX19\grubx64.efi)
Boot000a* UEFI:  PHILIPS USB PMAP    PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(3,0)/HD(2,MBR,0x217ab2aa,0x7520000,0x10000)

 

[Habicht]

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

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?

Also, bitte wie gehabt und angefordert, die Ausgabe bitte aus Zorin heraus und nicht vom Live-System.

Nachtrag: die Abfrage aus Zorin heraus würde dann auch noch die Antwort darauf liefern, ob Zorin evtl. im Legacy-Modus installiert wurde.

Nachtrag 2: und wenn wir dann schon mal dabei sind, dann bitte, ebenfalls aus Zorin heraus, bitte auch die Ausgabe von

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

zeigen

 

[Evil E-Lex]

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

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?

Guck mal ganz unten. Da steht der Boot Stick. Und Mint wird vermutlich das Ubuntu sein. Da sich UEFI-Variablen nicht magisch ändern, ist es völlig egal, womit man sich die anzeigen lässt.

 

[Habicht]

Hmmm, also 000a und 000A sind nicht das gleiche - und ob sich hinter dem "Ubuntu" nun das Mint oder das Zorin verbirgt, wissen wir auch nicht.
Vor allem aber, wo ist das Zorin wenn es sich nicht hinter dem "Ubuntu" versteckt.

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.
Mir jedenfalls reicht es nicht und darum bitte ich um die angefragten Infos aus Zorin heraus.

 

[mkossmann]

Hmmm, also 000a und 000A sind nicht das gleiche

In diesem Fall schon : Die Zahl 10 in hexadezimal Darstellung

 

[@mo]

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

Ja, das ist ein Eintrag den Zorin üblicherweise generiert!

 

[areiland]

den Zorin üblicherweise generiert!

Echt jetzt? Den generiert auch Mint:

 

[Habicht]

In diesem Fall schon : Die Zahl 10 in hexadezimal Darstellung

Ich hab das noch nie mit Kleinbuchstaben gesehen - aber gut, selbst wenn dem so ist, dann fehlt da immer noch das Zorin in der Liste.
Daraus ergeben sich meines Erachtens 2 Möglichkeiten - entweder ist Zorin im Legacy-Modus installiert oder aber Zorin meldet sich wohl auch als Ubuntu und hat den Minteintrag überschrieben.

Ist wohl die Crux von 2 unausgereiften Systemen, deren Entwickler nicht mal so eine Banalität wie einen eigenen Distri-Namen erstellen können.

 

[@mo]

Echt jetzt? Den generiert auch Mint.

Ja! Eben beide Ubuntu basiert!

 

[areiland]

Das heißt halt auch, dass man gar nicht sagen kann, ob dieser Eintrag von Zorin oder Mint generiert wurde.

 

[@mo]

Ist wohl die Crux von 2 unausgereiften Systemen, deren Entwickler nicht mal so eine Banalität wie einen eigenen Distri-Namen erstellen können.

Andernfalls müssten sie halt eine eigene Secureboot Kette erstellen. Aber das ist ja bääh. Da bedient man sich lieber beim "bösen" Ubuntu um seiner Kundschaft was bieten zu können.

 

[Habicht]

Das heißt halt auch, dass man gar nicht sagen kann, ob dieser Eintrag von Zorin oder Mint generiert wurde.

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.

 

[@mo]

Wobei das installierte Mint aber kein LMDAE sein sollte. Das generiert den Eintrag nicht.

 

[Habicht]

Du meinst LMDE?

Aber nochmals zum Thema: sollte Zorin einfach nur den Mint-Eintrag überschrieben haben, dann sollte mit einem banalen

sudo update-grub

das Mint im Grub-Menü von Zorin auftauchen, ggf. muss man vorher halt noch os-prober im Zorin frei schalten.

 

[@mo]

Du meinst LMDE?

Du kennst LMDA nicht? O.K., ich auch nicht!
Klar, LMDE!