Wenn ich nicht im EFI Mode starte kann ich EFI nicht bearbeiten, es kommt eine Fehlermeldung.
Das Prozedere ist mir bekannt, hatte auch schon im Bios Mode gebootet, da war das so.
Aber danke für deinen Post/Hinweis.
Hallo
Ich habe vergessen die Fehlermeldung zu posten wenn das System nicht startet. Möglicherweise sagt das jemand was, oder hat einen Befehl für der hilft für grub rescue:
Error: Symbol 'grub_debug_maloc not found
grub rescue>
Ich habe da noch was gefunden was mich nachdenklich macht, es könnte tatsächlich bei mir so gewesen sein: Legacy-BIOS-Modus statt im UEFI-Modus
Oh that would be bad… really bad… thinking This error: as i remember displays often when someone installed grub in efi mode first and then “to repair it”, one installed (maybe be accident) grub in BIOS mode. Grub tries to write the MBR at the beginning and that could indeed destroy the first partition @maxemilian . I guess you have to recreate the efi partition, correct the UUID at /etc/fstab, chroot and reinstall grub in efi mode like @Aragorn has described above.
Wenn das zutrifft, wie kann man eine efi-Partition neu erstellen ??
Das hier soll die Lösung sein, aber ich weis nicht ob ich das schaffe:
soll ich das testen 
?
Habe das soeben getestet und scheint zu funktionieren… ich habe nur noch nicht heraus gefunden woher /efi/EFI/boot/bootx64.efi kommt … ist irgendwas wie ein fallback aber womit wurde es generiert?
Danke das du noch dabei bist.
Wenn du dir sicher bist könntest du vielleicht den Ablauf und die Befehle aufzeigen bitte? Ich weis nicht genau was der Mensch da beschreibt.
Der Beitrag ist ja englisch und ich musste das über google-translate eindeutschen.
So wie das auf der Seite beschrieben ist, verstehe ich es nicht.
Ich will mich hier gar nicht groß einmischen, hatte ja selber grad Grub Probleme …
Aber nur zum Verständnis: Du hast also 2 ssd von denen du wechselweise startest, bzw. die andere freischaltest.
Auf welcher ist denn dann Grub installiert? Auf beiden? Und wo ist deine efi Partition? Auch jeweils auf beiden?
Hallo Tariin, klar kanns du dich einmischen
Ich zitiere mich mal selbst, bei einem so langen Beitrag kann das schon mal untergehen.
Seltsam. Hab ja EOS Cinnamon neu installiert, und das ist die Ausgabe von efibootmgr.
Kein endeavouros Eintrag wie nach der Reparatur, siehe unten.
Diese SSD hier mit dem neu installiertem EOS Cinnamon startet auch nach Wechsel der SSD wieder:
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002,0003,0004
Boot0001* UEFI OS HD(1,GPT,bae82a72-827e-aa44-a115-dffba9a8a00d,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0002* Hard Drive BBS(HD,,0x0)
Das ist die reparierte Version die einmalig startet und nach wechsel der SSD nicht mehr.
Zur Erinnerung, der erste booteintrag wird dann entfernt und sieht dann genau so aus wie mein neu installiertes EOS.
Nur startet es dann nicht mehr. Dasselbe gilt für mein Manjaro.
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0006,0008
Boot0000* endeavouros HD(1,GPT,ecfca5e5-ce65-f244-a0ba-1aef5d53bdfc,0x1000,0x96000)/File(\EFI\ENDEAVOUROS\GRUBX64.EFI)
Boot0006* UEFI OS HD(1,GPT,ecfca5e5-ce65-f244-a0ba-1aef5d53bdfc,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0008* Hard Drive BBS(HD,,0x0)
Hinweis
Nach dem Eintrag Boot0002 Hard Drive steht noch eine sehr lange Ziffernfolge, die habe ich weggelassen.
Irgendwie scheint das Mainboard Bios/Uefi sich an dem Eintrag zu stören und löscht den dann nach dem Wechsel. Und dann geht natürlich nichts mehr.
Ich überlege grade ob ich den UEFI OS Eintrag bei der Reparatur löschen kann/soll?
Was kann passieren ?
Mir ist Einiges noch immer nicht ganz einleuchtend was mit dem grub Update einher gekommen ist…
Ich habe den Eindruck das irgendetwas nicht ganz in ordnung ist mit der Art und Weise wie grub-install einen Eintrag in der Firmware erstellt… Könnte auch sein da ses gar nicht mehr nötig ist das so zu tun.
Ich meine ich kann ohne Problem von den UEFI OS Einträgen booten und die Einträge die mit grub-install geschrieben werden erscheinen zusätzlich und bereiten Probleme …
Ich habe nur noch nicht heraus gefunden wie der zusätzliche Fallback Eintrag / Ordner erstellt wird… kann sein Calamares tut das ich sehe das nicht in meinen Arch installationen…
Trotz dem habe ich einfach die ESP fat32 efi partition neu formatiert und danach einfach die UUID in der fstzab angepasst, meine kernels neu installiert und grub-install ausgeführt konnte damit booten (von da schreibe ich gerade)
Alternativ-Vorschlag @LaGGGer:
Wie wäre es denn, wenn Du, anstatt die beiden SSD’s wechselweise auszuschalten, bzw. zu aktivieren, wenn Du erstmal beide aktiviert lässt?
So können sie sich ggs. “sehen”. - Dann darf aber nur eine der beiden Distros das os-prober-script ausführen (s.o.).
Dazu müsstest Du außerdem die fstab in beiden Distros um die Einträge der jeweils anderen Distro ergänzen.
Mich dünkt, so könntest Du das Problem mit Deinem UEFI-Bios jedenfalls umgehen (welches jedesmal den zuvor gebooteten Eintrag löscht). - Apropos, hast Du mal nach einem Update auf der Herstellerseite geguckt?
Schon getestet, die “reparierte” fährt danach nicht mehr hoch. Es stört normalerweise nicht wenn ich das bei “unreparierten” Systemen mache. Eine SSD drängelt sich dann vor und bootet.
Oder ich nehme den efi-bootmanager, bei meinem Mainboard muss ich dazu F8 drücken und kann das System meiner Wahl hochfahren.
Ich will das eigentlich nicht, aber es passier schon mal das ich vergesse eine SSD auszuschalten.
Hat aber keine Nachteile.
Danke für den Vorschlag, aber nein, ich denke das bringt nichts. Ging ja vorher auch ohne.
Ist bei beiden jetzt deaktiviert, daran liegt es auch nicht.
Gibt keins, habe sogar mal das Bios resettet, hat nix gebracht. Habe vor 3 Monaten ein neues Bios aufgespielt und habe erst später gemerkt das fastboot und Secure Boot aktiviert war.
Das System hat trotzdem weiterhin problemlos gebootet. Beides ist mittlerweile deaktiviert.
Aber so langsam weis ich nicht mehr weiter. Wir drehen uns im Kreis. Mittlerweile Habe ich den alten Zustand fast wieder hergestellt, eine neue Installation auf einer neuen SSD.
Mit dem “alten”, fehlerhaften System kann ich ja ein wenig experimentieren. Ich werde den UEFI OS eintrag löschen und schauen was passiert. Den String werde ich in einer Textdatei speichern und kann den ja notfalls wieder eintragen.
Sorry wenn ich wein wenig gereizt wirke, aber langsam nervt mich das. Ihr wollt alle helfen, vielen Dank dafür. Aber es funktioniert nicht.
Frustrierend das ganze.
Sorry für Deinen Gemütszustand…
Was ich Dir eigentlich sagen wollte ist:
Mit dem Bios und 2mal Linux funktioniert das so nicht (mehr). Mag es mit den neuen Kernels zusammenhängen, oder dem (alten) Bios, oder beiden.
Den potentiellen Lösungsweg habe ich Dir versucht zu zeigen.
najaa, aber die Einträge im Grub Menü holt sich Grub ja aus /boot/grub/grub.cfg
Diese wird ja durch grub-mkconfig aus etc/default/grub und etc/grub.d/* generiert.
Zudem braucht ja jede SSD zumindest eine eigene efi Partition sowie einen Ordner boot der die Konfiguration enthält. Wenn du also immer eine stromlos schaltest müsste ja alles doppelt sein, bzw. grub müsste auf beiden Platten installiert sein.
Und wenn du ein Systemupgrade machst und die andere SSD ist stromlos dann trägt er durch os-prober ja auch nur die Systeme ein die er findet.
Doch es funktioniert. Ich habe EOS und Manjaro neu aufgesetzt, alles gut. Keine Probleme, so wie ich es will. Habe noch eine SSD mit Ubuntu, MX-linux, LinuxMint. Alle "vertragen sich, kein efi eintrag wird gelöscht.
Es geht nur nicht wen ich efi/grub repariert habe.
Entweder läuft bei der Reperatur etwas falsch oder mein Bios erkennt einen fehlerhaften Eintrag wo keiner ist.
Genau. Grub ist auf beiden SSD’s installiert. Die Systeme sind vollkommen autark und jedes kann ohne das andere starten.
os-prober ist nicht aktiv.
Das freut mich für Dich!
Du hast das schon gelesen oder ?:
Das heißt also, ich kann nur hoffen das ich so einen Fehler wie beim Update von EndeavourOS nie wieder bekomme.
Weil … reparieren geht ja nicht, ich muss dann neu installieren!
Was soll dann die ganze Anleitung wie ich mein Grub/efi reparieren kann? Das ist doch eine farce, jedenfalls für mein System.
Das kann es doch nicht sein. Bin ich der einzige der so ein System hat?
Diejenigen, die Grub wegen dem Update reparieren mussten, sollen doch mal nachsehen ob ein Eintrag mit endeavouros im efibootmgr zu sehen ist:
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0006,0008
Boot0000* endeavouros HD(1,GPT,ecfca5e5-ce65-f244-a0ba-1aef5d53bdfc,0x1000,0x96000)/File(\EFI\ENDEAVOUROS\GRUBX64.EFI)
Boot0006* UEFI OS HD(1,GPT,ecfca5e5-ce65-f244-a0ba-1aef5d53bdfc,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0008* Hard Drive BBS(HD,,0x0)
Und so sieht das bei einer Neuinstallation von EndeavourOs aus, also ohne Reparatur.
Hier fehlt der Eintrag mit endeavouros, keine Probleme mit dem System:
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002,0003,0004
Boot0001* UEFI OS HD(1,GPT,bae82a72-827e-aa44-a115-dffba9a8a00d,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0002* Hard Drive BBS(HD,,0x0)
Durch die Reparatur kommt ein neuer Eintrag hinzu:
Boot0000* endeavouros HD(1,GPT,ecfca5e5-ce65-f244-a0ba-1aef5d53bdfc,0x1000,0x96000)/File(\EFI\ENDEAVOUROS\GRUBX64.EFI)
Dieser Eintrag mit endeavouros wird beim Wechsel des Systems immer (warscheinlich vom Bios des Mainboardes) gelöscht.
-
Ich betone es nochmal, das passiert bei einer Neuinstallation NICHT!
-
Der der Booteintrag mit endeavouros existiert bei einer Neuinstallation NICHT!
Irgendwo ist da der Fehler, aber erklären kann ich es nicht. Das ist nicht meine Welt.
Ich kann nur beobachten und aufzeigen, aber das wars dann schon. Den Fehler beheben können nur diejenigen, die sich mit der Materie auskennen.
Ich übersetzte mal etwas für Dich, vllt. hilft es Dir,
Folgende Textauszüge aus diesem Link:
https://endeavouros.com/news/full-transparency-on-the-grub-issue/
Übersetzung der Abschnitte, die ich für relevant halte in Deinem Fall (ich mag mich da auch irren):
Summary
Das Problem
Nach dem Update auf grub 2.06.r322 berichteten viele Benutzer, dass ihre Rechner nicht mehr booten oder direkt in das BIOS oder ein anderes Betriebssystem booten konnten.
Was hat das Problem verursacht?
Beginnend mit diesem Commit hat grub einen Aufruf für fwsetup --is-supported in
/etc/grub.d/30_uefi-firmwareeingeführt. Wenn die Version von grub, die Sie über den Befehlgrub-installinstalliert haben, diesen Befehl nicht unterstützte, führte dies zu einem Fehlverhalten von grub.Wie kommt es, dass nicht alle davon betroffen waren?
Vor der neuesten Version registrierte grub den
fwsetup-Befehl nur, wenn die Unterstützung erkannt wurde. Wenn Ihr Rechner Unterstützung erkannt hätte, wäre derfwsetup-Befehl registriert worden und der Fehler wäre nicht aufgetreten.Wie geht es weiter mit dem grub-Paket?
Gemäß dem Fehlerbericht 1 wird Arch eine Version des Pakets ohne diesen Commit erstellen, während es mit grub upstream zusammenarbeitet, um die nächsten Schritte zu bestimmen.
Mein Ratschluss, nachdem ich länger reflektiert habe könnte u.U. für Dich darin liegen, das Grubpaket zu downgraden… zu der Version vor der Einführung des neuen fwsetp-Aufrufs, der oben beschrieben wird.
Wenn Arch den Fehler behoben hat und den fwsetup-Aufruf in der bestehenden Version zukünftig zurückgenommen hat, dann könntest Du grub wieder aktualisieren.
Falls Du den Weg gehen möchtest:
-
Zur Auswahl der älteren Versionen von grub gelangst Du hier.
-
Zum Verfahren, wie man Pakete downgraden kann, siehe bitte hier nach.
Danke für den Hinweis. Mir ist noch eingefallen das ich auch mal rEFInd getestet habe, ein alternativer UEFI boot Manager.
Selbst dieser wurde von meinem Bios gekillt. Ob es dann was nützt wenn ich Grub downgrade?!
Ich denke, wie ich schon mal erwähnt habe, das meine komplette boot Partition neu erstellt werden müsste, um den Fehler wegzubekommen.
joekamprad hat das schon mal angegangen, kam aber auch nicht weiter.
Ich bin jetzt soweit, das, wenn mein Bootmanager spinnt, muss ich das System neu aufsetzen.
Ich werde das noch mal mit einem Ubuntu System testen, wenn hier auch die Grub Reparatur versagt, ist es eindeutig das Bios.
Ich melde mich dann wieder.
Diese Logik ist leider so nicht ganz richtig, denn Du scheinst mir da etwas zu “vermischen”, was nicht zusammengehört @LaGGGer.
Es handel sich beim Arch Linux grub um ein pre-release (siehe “Latest News” auf der Seite), das von anderen Distros bisher meist gar nicht eingesetzt wird, zur Zeit. Arch Linux ist da schneller dabei mit neuesten Paketversionen als viele andere.
Ich denke, weil das mit Arch-Updates des Pakets grub bei Dir nicht funktioniert, wäre ein downgrade von grub für Dich und Dein Bios ein möglicher Lösungsweg, der auch von anderen Distros bislang gegangen wird, denn sie benutzen die 4 letzten, neuen Grub-Pakete gar nicht erst, jedenfals nicht, ohne den Aufruf fwsetup --is-supported aus ihrer eigenen Grub-Version wegzulassen.
Nur noch mal, zur Klärung des Sachverhalts, denn mit Ubuntu sollte es wahrscheinlich klappen wie früher. Habe bei Debian basierten Distros jedenfalls noch keine Beschwerden zum Thema grub-update gelesen.
Edit:
Das gilt auch für Arch-Pakete, die Manjaro als Basis benutzt. Dazwischen können machmal Jahre und etliche Kilometer liegen, wenn Du verstehst, was ich meine…