Seit Installation von Leap 15.4 kann ich Tumbleweed nicht mehr booten

Hinweis: In dem Thema Seit Installation von Leap 15.4 kann ich Tumbleweed nicht mehr booten gibt es 14 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Hallo Alero,

    vielen Dank für die Links. So ganz ist mir die Sache aber nach wie vor nicht klar, bzw. eigentlich überhaupt nicht. Was genau ist der Sinn dieser sbat-policy-Variable? Also wie wirkt sich das genau aus? Und was passiert, wenn ich die lösche (bzw. ihren Inhalt), also welche Konsequenzen hätte das?

    Hat insbesondere jede Distriubution für ihre Shim-Version da eine eigene policy, oder eine policy für alle Shim-Bootloader dieser Welt?
    Nochmal konkret: wenn ich die von sterun in #7 vorgeschlagene Vorgehenswseise in meiner Fedora-Installation durchführen würde:

    - hilft mir das hier weiter?

    - welche Konsequenzen könnte das ggf. haben?

    Beste Grüße, Diophant

    Für den Inhalt des Beitrages 306204 haftet ausdrücklich der jeweilige Autor: Diophant

    So tief stehe ich leider nicht in der Materie das ich dir da helfen könnte. Dazu ist die Materie zu komplex. Sry ...

    Zitat von Alero

    So tief stehe ich leider nicht in der Materie das ich dir da helfen könnte. Dazu ist die Materie zu komplex. Sry ...

    Geht mir auch so → eigentlich geh ich ja davon aus, dass in rund 90% aller Anfragen dieser Art das Problem vor dem Monitor sitzt (ist nicht böse gemeint) → aber mal davon ausgehend, dass hier das Problem nicht vor dem Monitor sitzt, würde ich dann doch eher auf Suse verzichten, als irgend welche unabwägbare "Spielchen" mit dem UEFI zu versuchen.


    Und wenn es dann doch bitte ein weiteres Linux neben Fedora sein soll - Debian hatte ich bereits erwähnt (ja Alero, natürlich Bookworm) ;) → eine weitere Alternative wäre dann natürlich noch Arch → sind aber halt beides Community-Projekte ohne ne große Firma dahinter → und ja, es gibt genau aus diesem Grund Argumente dafür dass ich Tumbleweed benutze → es ist das "stabilste" Rolling "auf dem Markt" → bei Arch und Debian (ab testing aufwärts) muss man sich mehr rein hängen.


    Allen gemein ist, dass man mit der Konsole arbeiten muss → und um es rund zu machen → es fehlen bisher sämtliche angeforderten Konsolenabfragen (die sind durchaus auch mit Fedora verfügbar) und zumindest meinerseits waren das immer nur Anfragen zur bestehenden Hardware.


    Und wie schon mal erwähnt - zu 90 % sitzt das problem vor dem Monitor. 😇😇

    Für den Inhalt des Beitrages 306206 haftet ausdrücklich der jeweilige Autor: Feli

    Hallo Feli,


    ich sage es jetzt nochmal: Secure-Boot auszuschalten ist bei uns nicht diskutabel. Das kann man mal für eine einzelne Aktion deaktivieren, das wäre nicht das Problem. Aber es geht damit los, dass Windows 11 ohne überhaupt nicht funktioniert.

    Aus dem gleichen Grund helfen mir Tipps für weitere Distributionen nicht weiter. Falls es nicht bekannt ist: im August 2022 hat Microsoft per Windows-Update eine UEFI.dbx-Datei ausgerollt, mit der mehr als 100 Linux-Distributionen (bzw. deren Grub-Bootloader) auf die Forbidden-List im dbx-Schlüssel des UEFI gelandet sind. Die lassen sich bei eingeschaltetem Secure-Boot dann einfach nicht mehr booten, das kann man auch nicht so einfach rückgängig machen. Da gehören bspw. auch Arch-Linux und Manjaro dazu, aber verrückterweise auch CentOS von Red Hat (obwohl es Fedora nicht betrifft). Und davon ist unser PC nun einmal betroffen.

    Debian und Ubuntu (und damit auch Linux Mint) sind zwar nicht betroffen, um die mache ich aber bei einem Szenario wie beschrieben traditionell einen Bogen: beim letzten Versuch (vor einigen Jahren) war es nämlich in allen drei Fällen so, dass trotz dem Anlegen einer eigenen EFI-Partition auf der jeweils eigenen Festplatte die Installer der genannten Distros zur Sicherheit Grub gleich auch noch in die EFI-Partition von Windows geschrieben haben (wo dieser dann den Windows-Bootloader verdrängt). Und da ich ein zwangsläufiges Auswählen des OS per Grub eben nicht möchte (auch das ist nicht diskutabel), scheiden die aus. Insofern ist so wie es aussieht openSUSE meine einzige Alternative (wenn ich nicht nach der Installation manuell in der EFI-Partition von Windows herumschrauben möchte). Kurz: das ist ein Produktivsystem und solche Experimente sind schon aus Zeitgründen nicht drin.


    Wenn du jetzt meinst, dass das Problem vor dem Bildschirm sitzt, nur weil man sich mit den technischen Details von UEFI/Secure-Boot nicht auskennt, dann ist das so. Aber dass die eine Version einer bekannten Linux-Distribution die andere Version auf die beschriebene Art und Weise torpediert, das ist in meinen Augen schon auch ein starkes Stück, und das kann man auch mit vertieften Kenntnissen der Materie in meinen Augen nicht vorhersehen.


    Beste Grüße, Diophant

    Für den Inhalt des Beitrages 306208 haftet ausdrücklich der jeweilige Autor: Diophant

    Zitat von Diophant

    Wenn du jetzt meinst, dass das Problem vor dem Bildschirm sitzt, …

    Das ist ziemlich naheliegend - wenn ich schon lese, dass für jedes System eine eigene Efi-Partition angelegt wird, rollen sich mir die Zehennägel auf.


    Eine Efi-Partition für alle Systeme ist eigentlich der Standard - aber gut, lassen wir es sein, du bist m.E. überhaupt nicht an einer Lösung interessiert, egal was man vorschlägt, es kommt immer eine Ausrede - du hast bis heute noch keine einzige Frage beantwortet.


    Als ich dir einen Lösungsvorschlag für das Ändern der Bootreihenfolge durch Tumbleweed angeboten habe, gab es plötzlich kein Tumbleweed mehr → und jetzt kommst du mit irgend welchen kruden Argumenten wie Debian schreibt in die Efi-Partition von Windows, daher.


    Das war mein letzter Beitrag zu deinem "Problemchen".


    Grüße, Feli

    Für den Inhalt des Beitrages 306213 haftet ausdrücklich der jeweilige Autor: Feli