Beiträge von lush

    Matthew Garrett hat in seinem Blog beschrieben, wie Distributionen durch
    die Arbeit von Fedora und openSUSE das Secure-Boot-Problem lösen
    können.


    »UEFI Secure Boot« ist eine Funktion kommender PCs, die von
    Microsoft von den Herstellern gefordert wird, die das Windows-8-Logo erhalten
    wollen. Ist sie eingeschaltet, so lädt das BIOS nur Komponenten, die
    eine gültige kryptografische Signatur tragen. Dazu müssen im BIOS
    Schlüssel hinterlegt sein. Auf PCs wird Secure Boot über das BIOS
    abschaltbar sein, auch die Schlüssel sind änderbar. Dennoch ist es das
    Ziel der meisten Linux-Distributionen, auf allen Rechnern lauffähig zu
    sein, ohne dass BIOS-Einstellungen geändert werden müssen.Matthew Garrett von Fedora hatte schon Anfang Juni beschrieben, wie Fedora die Situation handhaben will. Laut seinem aktuellen Blog-Eintrag
    hat der Plan immer noch weitgehend Bestand. Dieser Plan besteht darin,
    einen kleinen Bootloader namens Shim einzusetzen, der den
    Fedora-Schlüssel enthält. Dieser Bootloader soll von Microsoft signiert
    werden, was die Bootfähigkeit in allen PCs sicherstellt, die den
    Microsoft-Schlüssel im BIOS enthalten - das werden voraussichtlich so
    gut wie alle sein.
    Das Signieren des Bootloaders schlägt einmalig
    mit knapp 100 US-Dollar zu Buche und stellt damit für Fedora kein
    Problem dar. Für kleinere Distributionen ist es hingegen keine Lösung.
    Diese Distributionen haben nach Garrett mehrere Optionen. Sie können von
    den Benutzern verlangen, Secure Boot zu deaktivieren, was nicht ideal
    und wegen der nicht standardisierten Oberfläche auch nicht für jeden
    einfach ist. Sie könnten die Benutzer auch auffordern, die Schlüssel aus
    dem BIOS zu löschen, womit der Rechner in den Setup-Modus gebracht
    wird, und dann neue Schlüssel anlegen. Auch das ist nicht einfach.
    Die
    beste Alternative scheint die Verwendung eines signierten Bootloaders
    zu sein, der eine eigene Schlüsseldatenbank verwaltet, eine Idee, die
    von Opensuse
    entwickelt wurde. Der Bootloader kann seine Schlüsselverwaltung frei
    implementieren, auch das Laden von Schlüsseln vom Dateisystem
    ermöglichen und vieles mehr. Zudem wäre die Oberfläche für die
    Schlüsselverwaltung einheitlich im Gegensatz zu den Implementierungen im
    UEFI-BIOS.
    Garrett hat jetzt den Code von Opensuse in seinen eigenen Bootloader Shim
    integriert, wobei er noch kleinere Änderungen vornahm. Die wichtigste
    davon betrifft das Verhalten, wenn er einen nachgeordneten Bootloader
    findet, dessen Schlüssel er nicht kennt. Statt einfach den Ladevorgang
    abzubrechen, erscheint eine Oberfläche, die es ermöglicht, eine
    Schlüsseldatei zu laden. Der Nachteil dieses Verfahrens besteht für
    andere Distributionen lediglich darin, dass sie die unmodifizierte
    Binärdatei des Fedora-Bootloaders übernehmen müssen. Dies könnte für
    einige Distributionen wie Debian aus prinzipiellen Gründen unakzeptabel
    sein, für einige andere jedoch eine willkommene Verbesserung.


    Aus: Pro-Linux

    Höchstwahrscheinlich liegt der Fehler in einer Konfigurationsdatei deines Home-Ordners:
    Beispielsweise hier:

    Code
    .kde4


    du könntest versuchen diesen Ordner umzubenennen und dich anschließend als User X einloggen:

    Code
    mv ~/.kde4/ ~/.kde4.old


    Falls das umbenennen nicht reicht, könntest du entweder:

    • Weiter nach der Fehlkonfiguration suchen
    • Den neuen User verwenden :)

    auch in dem Wissen, dass es nervt, melde ich mich noch mal mit meinen Beschwerden.

    Du nervst natürlich nicht ;)
    Wenn jemand von deinen Problemen genervt wäre, müsste er ja trotzdem nicht antworten :D


    Nun könnte ich noch meinen alten user-Account löschen und hätte dann den schwarzen Zauber ganz aus der Welt, sprich aus dem Rechner verbannt ????

    Ich bin mir nicht ganz sicher ob ich verstehe was genau du vorhast.
    Also:
    Du hast/hattest ein Problem mit einem User X.
    Dann hast du stattdessen einen neuen User Y angelegt (und die automatische Anmeldung deaktiviert), mit dem diese(s) Problem(e) nun "gelöst" waren.


    Dann hast du, warum auch immer, dein System neu installiert und wieder denselben User X angelegt.
    Jetzt hast du das Problem wieder.


    Ist das soweit richtig ?


    Wenn ja:
    Hast du bei deiner Neuinstallation deine letzte /home-Partition einfach wieder übernommen ?
    Hatte dein alter User X einen eigenen /home/X Ordner, oder wurde dieser beispielsweise durch das Löschen des Users entfernt ?


    Falls der Ordner bereits aus der letzten Installation existiert, liegt das Problem wirklich daran.
    Also würde das Problem, durch Anlegen eines neuen User, gelöst sein.

    Die Oktoberausgabe von »freiesMagazin« ist mit Nachrichten und Artikeln
    über freie Software erschienen. Die Schwerpunkte der Ausgabe 10/2012:
    RAW-Bildbearbeitung, ein LanguageTool-Tutorial und Datensicherung mit
    storeBackup.


    64 Seiten im Querformat mit Artikeln, News, Leserbriefen und mehr.


    Themen:

    • RAW-Bildverarbeitung unter Linux
    • Datensicherung mit storeBackup
    • Creative Commons
    • LanguageTool-Tutorial – Teil I: Einfache XML-Regeln
    • Taskwarrior - What's next? (Teil 3)
    • Redis – Suchen und Sortieren
    • Rezension: Ubuntu 12.04 für Ein- und Umsteiger
    • Rezension: Android 4 – Apps entwickeln mit dem Android SDK

    Das Magazin kann in verschiedenen Formaten vom Server des Projektes heruntergeladen werden.

    Aus: Pro-Linux