EFI Partition geschrottet? Firefox Passwörter retten

[PonJoe58]

@McBain86
Hast du noch einen anderen PC, oder Smartphone, auf dem du mit Firefox arbeitest?
Und synchronisierst du zwischen den Geräten?

 

[McBain86]

Ok, beide Befehle wurden ausgeführt. Es hat leider nicht geholfen. Nach dem Neustart ist kein neuer Boot-Eintrag im UEFI aufgetaucht. Ich werde Fedora neuinstallieren.

@Kuristina ich werde das so probieren.
@Franky4Finger's vielen Dank für deine Unterstützung.

Euch allen einen schönen Abend noch.

@PonJoe58 Smartphone ja, aber keine Synchro. Vielleicht sollte ich das machen. Danke.

 

[empower]

du musst natürlich aufpassen ob das wirklich dein firefox profilordner ist. bei flatpack ist er wo anders

 

[Kuristina]

Den Pfad hatte er selber genannt, deshalb gehe ich von einer normalen Installation aus.

 

[Volvo480]

....Ach Mist, hatte ich noch schreiben sollen: das UEFI war nach dem Starten wieder komlett auf default settings eingestellt. AHCI Modus ist wieder ausgewählt.

@McBain86
Ich bin kein Linux Experte, aber eventuell gibt es einen Zusammenhang: war vor dem Malheur/dem reset der BIOS Einstellungen ggf. im BIOS die Einstellung für CSM auf enabled und ist jetzt nach dem reset auf disabled bzw. war CSM vorher auf disabled und jetzt auf enabled?

Im BIOS den CSM Wert einmal umstellen und den Start des alten Fedora versuchen... ggf. aber erst die Antwort eines Linux Experten abwarten. Oder es ist egal weil schon neu installiert wurde...

 

[Franky4Finger's]

Ok, beide Befehle wurden ausgeführt. Es hat leider nicht geholfen. Nach dem Neustart ist kein neuer Boot-Eintrag im UEFI aufgetaucht. Ich werde Fedora neuinstallieren.

@Kuristina ich werde das so probieren.
@Franky4Finger's vielen Dank für deine Unterstützung.

Euch allen einen schönen Abend noch.

@PonJoe58 Smartphone ja, aber keine Synchro. Vielleicht sollte ich das machen. Danke.

Ja, schade 😅
Eigentlich hättest du nur noich einen manuellen EFI Boot Eintrag erstellen müssen, dann hätte das System wieder gebootet, alles andere hat ja geklappt und dein System war ja noch intakt.
Fedora ist da ein bisschen eigen, es erstellt den Boot Eintrag nicht immer automatisch, auch wenn die Pakete korrekt installiert wurden.
Aber manchmal ist eine Neuinstallation einfach schneller, vor allem wenn man schon frustriert ist.

Ergänzung (Freitag um 22:01)

@McBain86
Ich bin kein Linux Experte, aber eventuell gibt es einen Zusammenhang: war vor dem Malheur/dem reset der BIOS Einstellungen ggf. im BIOS die Einstellung für CSM auf enabled und ist jetzt nach dem reset auf disabled bzw. war CSM vorher auf disabled und jetzt auf enabled?

Im BIOS den CSM Wert einmal umstellen und den Start des alten Fedora versuchen... ggf. aber erst die Antwort eines Linux Experten abwarten. Oder es ist egal weil schon neu installiert wurde...

Kurze Erklärung für alle, die es interessiert..
Als die Festplatte während des Starts nicht angeschlossen war, hat das UEFI den Boot-Eintrag für Fedora schlicht vergessen. Die Daten auf der Platte waren aber noch alle da. Es war also nur GRUB betroffen, nicht das System selbst.
Er hatte es fast geschafft...

Ergänzung (Freitag um 22:30)

Fun Fact ☝️

Sei froh, dass du keine Archbased Distro benutzt 😅

Secure Boot + Arch = die große Katastrophe.

Das Problem, das du gerade hattest, tritt bei Arch bei jedem Kernel Update auf, im schlimmsten Fall zweimal pro Woche 💪. Dann darfst du zusätzlich noch den neuen Kernel manuell signieren, und bei Dualboot meldet sich Windows BitLocker…

Klar, Secureboot kann man auch einfach deaktivieren, manchmal aber auch nicht.

Aber genau das verschweigen die ganzen Influencer auf YouTube & Co. wenn sie mal wieder Arch/Endeavour/Cachy hypen 😉

Arch + Dualboot? Geht gar nicht!

Leider hat jede Distro ihre Schattenseiten. Die perfekte gibt es leider nicht…

 

[empower]

@McBain86
Ich bin kein Linux Experte, aber eventuell gibt es einen Zusammenhang: war vor dem Malheur/dem reset der BIOS Einstellungen ggf. im BIOS die Einstellung für CSM auf enabled und ist jetzt nach dem reset auf disabled bzw. war CSM vorher auf disabled und jetzt auf enabled?

Im BIOS den CSM Wert einmal umstellen und den Start des alten Fedora versuchen... ggf. aber erst die Antwort eines Linux Experten abwarten. Oder es ist egal weil schon neu installiert wurde...

guter hinweis

 

[Iapetos]

Secure Boot + Arch = die große Katastrophe.

Das Problem, das du gerade hattest, tritt bei Arch bei jedem Kernel Update auf, im schlimmsten Fall zweimal pro Woche 💪. Dann darfst du zusätzlich noch den neuen Kernel manuell signieren, und bei Dualboot meldet sich Windows BitLocker…

Klar, Secureboot kann man auch einfach deaktivieren, manchmal aber auch nicht.

Kann ich nicht nachvollziehen. Benutze neuerdings Arch mit SecureBoot, systemd-boot, UKI, tpm2-decrypt und das läuft sehr geschmeidig, auch und gerade nach Kernel-Upgrades. sbctl signiert den neuen Kernel und den Fallback-Kernel bzw. die UKIs automatisch.

Um komfortabel per chroot hineinzukommen, sollte mal etwas schiefgehen, habe ich mir noch ein ebenfalls mit sbctl signiertes, minimales USI mit mkosi erstellt.

Hier das Tutorial dazu:

https://walian.co.uk/arch-install-w...m2-luks-encryption-unified-kernel-images.html

 

[Donnerkind]

grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
ist mein Board zu alt?
Anhang anzeigen 1704049

Nein, vorher hattest du ja schon EFI-Boot aktiv. Beim BIOS-Reset wurde wohl auch der EFI-Modus deaktiviert. Das Live-System hat deshalb im Legacy-Modus gebootet, und in diesem Modus hat es keinen Zugriff auf EFI-Variablen. Und davon kommt dann die Fehlermeldung in deinem Screenshot.

 

[Franky4Finger's]

Kann ich nicht nachvollziehen. Benutze neuerdings Arch mit SecureBoot, systemd-boot, UKI, tpm2-decrypt und das läuft sehr geschmeidig, auch und gerade nach Kernel-Upgrades. sbctl signiert den neuen Kernel und den Fallback-Kernel bzw. die UKIs automatisch.

Um komfortabel per chroot hineinzukommen, sollte mal etwas schiefgehen, habe ich mir noch ein ebenfalls mit sbctl signiertes, minimales USI mit mkosi erstellt.

Hier das Tutorial dazu:

https://walian.co.uk/arch-install-w...m2-luks-encryption-unified-kernel-images.html

Das ist ja genau mein Punkt 🙂
Für jemanden, der weiß, was UKI, systemd-boot, sbctl, TPM2, mkosi und chroot bedeuten, funktioniert das auch.
Für diesen Personenkreis ist Arch mit Secure Boot absolut machbar, keine Frage.

Aber das ist eben nicht der normale User, von dem hier die Rede ist.
Ein normaler User wird weder UKIs bauen, noch sbctl konfigurieren, noch ein signiertes Fallback Image vorbereiten, nur damit das nächste Kernel Update nicht wieder den Rechner lahmlegt.

Genau da liegt das Problem von Linux auf dem Desktop..
Technisch ist fast alles lösbar, aber oft nur mit Expertenwissen.
Für den normalen User eine unüberwindbare Hürde -> Frustmomente

Und genau deshalb ist Arch + Secure Boot + Dualboot für normale User schlicht nicht realistisch, auch wenn es für erfahrene Nutzer hervorragend funktionieren kann.

 

[Iapetos]

Nunja, die einsteigerfreundlichen Distributionen bieten ebenfalls SecureBoot und automatisches Signieren nach Kernel-Updates an, nur eben auf einfacherem Niveau (meistens ohne UKI) und einmalig manuell aktiviert.

Ich hoffe, dass das nicht zu sehr off topic ist. Generell kann es ja nicht schaden, die Aufmerksamkeit für und das Interesse an der Bootchain hier zu stärken.

 

[Franky4Finger's]

@Iapetos Stimmt, das geht, aber nur, wenn man den vorgesehenen Weg der Distro nutzt.
Einsteiger Distros verstecken Secure Boot (Shim/MOK) weitgehend im Hintergrund, Arch gibt dir volle Kontrolle und damit auch die volle Verantwortung.
Mit GRUB wird Secure Boot schnell nervig, wirklich entspannt wird es bei Arch erst mit systemd-boot plus automatischer Signierung.

Ergänzung (Gestern um 09:39)

Nein, vorher hattest du ja schon EFI-Boot aktiv. Beim BIOS-Reset wurde wohl auch der EFI-Modus deaktiviert. Das Live-System hat deshalb im Legacy-Modus gebootet, und in diesem Modus hat es keinen Zugriff auf EFI-Variablen. Und davon kommt dann die Fehlermeldung in deinem Screenshot.

Der Fehler entstand, weil ich ihm fälschlicherweise den Lösungsweg für ein System ohne Secure Boot vorgeschlagen hatte. Ich wusste es zu dem Zeitpunkt nicht, hätte aber davon ausgehen müssen, weil SB Standard ist bei Fedora. Er hat daraufhin versucht, GRUB 2 unter aktiviertem Secure Boot zu reparieren, und genau das führte zu der Fehlermeldung. Das hatte nichts mit irgendwelchen BIOS Bootmodus Einstellungen zu tun...

 

[Donnerkind]

r hat daraufhin versucht, GRUB 2 unter aktiviertem Secure Boot zu reparieren, und genau das führte zu der Fehlermeldung. Das hatte nichts mit irgendwelchen BIOS Bootmodus Einstellungen zu tun...

Again what learned.

 

[McBain86]

Guten Abend,

Ich bin kein Linux Experte, aber eventuell gibt es einen Zusammenhang: war vor dem Malheur/dem reset der BIOS Einstellungen ggf. im BIOS die Einstellung für CSM auf enabled und ist jetzt nach dem reset auf disabled bzw. war CSM vorher auf disabled und jetzt auf enabled?

Im UEFI konnte ich unter PCI ROM Priority unter Legacy ROM und EFI Compatible ROM wählen. Beide hatten nicht funktioniert.

Genau da liegt das Problem von Linux auf dem Desktop..
Technisch ist fast alles lösbar, aber oft nur mit Expertenwissen.
Für den normalen User eine unüberwindbare Hürde -> Frustmomente

Ja, deswegen hatte ich auch lieber neu installiert, was recht zügig ging.

Nur rasch nebenbei: Solltest du neu installieren, dann kannst du anschließend den ganzen /home/name/.mozilla Ordner wieder vom Backup rüberkopieren, bevor du das erste Mal Firefox startest. Dann hast du alles so, wie es war. Inklusive Passwörter.

Da /home auf einer separaten Partition liegt, hatte ich /home bei der Neuinstallation neu angeben und die Partition ausgewählt ohne Formatierung. Dadurch blieb das /home Verzeichnis unversehrt und auch die persönlichen Daten und Einstellungen von Firefox und Thunderbird waren sofort wieder da. Das hat ausgezeichnet funktioniert.

 

[Kuristina]

Prima.