4
Dualboot Linux mit BCDEDIT
Hallo,
mit kann ich Grub startbar machen. Manchmal funktioniert das auch, zuverlässig ist es aber erst wenn ich im Bios "restore factory keys" aufgerufen habe. Weil einige Rechner aber ein Bios Passwort benutzen ist das für manche Nutzer keine Lösung um ein System selbst wieder lauffähig zu machen.
Ich suche eine Lösung die auf allen Rechnern funktioniert und ohne Biosänderungen auskommt. Es bringt nichts an meinem Rechner rumzubasteln bis es funktioniert wenn es dann bei anderen Rechnern nicht geht.
Eine alternative Vorgehensweise ist laut Internet folgende:
a: ist die mit mountvol eingebundene EFI Partition
Das funktioniert überhaupt nicht, der Eintrag \EFI\opensuse\shim.efi wird beim Aufruf nicht gefunden.
Eine andere Quelle nennt zusätzlich:
Das bewirkt überhaupt nichts, der Eintrag wird bei mir nicht durchgeführt obwohl der Befehl ausgibt daß er erfolgreich durchgeführt wurde. Laut Internet gibt es Biose die Aktualisierungen nicht zulassen, ob genau dieser Befehl damit gemeint ist weiß ich nicht aber irgendetwas scheint da ja zu sperren und unter WinPE ist es kein Sicherheitsprogramm des Betriebssystems.
Kennt jemand eine garantiert auf allen Rechnern funktionierende Lösung um Grub direkt oder aus dem Windowsstartmenü zu starten?
mit
BCDEDIT /set {bootmgr} path \EFI\opensuse\shim.efiIch suche eine Lösung die auf allen Rechnern funktioniert und ohne Biosänderungen auskommt. Es bringt nichts an meinem Rechner rumzubasteln bis es funktioniert wenn es dann bei anderen Rechnern nicht geht.
Eine alternative Vorgehensweise ist laut Internet folgende:
a: ist die mit mountvol eingebundene EFI Partition
bcdedit /create /d "OpenSuse LEAP 42.1" /application bootsector
bcdedit /set %Bezeichner% device partition=a:
bcdedit /set %Bezeichner% path \EFI\opensuse\shim.efi
bcdedit /displayorder %Bezeichner% /addfirstDas funktioniert überhaupt nicht, der Eintrag \EFI\opensuse\shim.efi wird beim Aufruf nicht gefunden.
Eine andere Quelle nennt zusätzlich:
bcdedit /set {fwbootmgr} displayorder {guid} /addfirstDas bewirkt überhaupt nichts, der Eintrag wird bei mir nicht durchgeführt obwohl der Befehl ausgibt daß er erfolgreich durchgeführt wurde. Laut Internet gibt es Biose die Aktualisierungen nicht zulassen, ob genau dieser Befehl damit gemeint ist weiß ich nicht aber irgendetwas scheint da ja zu sperren und unter WinPE ist es kein Sicherheitsprogramm des Betriebssystems.
Kennt jemand eine garantiert auf allen Rechnern funktionierende Lösung um Grub direkt oder aus dem Windowsstartmenü zu starten?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1528925933
Url: https://administrator.de/forum/dualboot-linux-mit-bcdedit-1528925933.html
Ausgedruckt am: 22.12.2024 um 16:12 Uhr
4 Kommentare
Neuester Kommentar
Moin,
sollte es nicht folgend heißen?
bcdedit /set %Bezeichner% path \EFI\opensuse\grubx64.efi
Dafür aber SecureBoot ausschalten, weitere Infos:
https://en.opensuse.org/openSUSE:UEFI
Viel Erfolg
sollte es nicht folgend heißen?
bcdedit /set %Bezeichner% path \EFI\opensuse\grubx64.efi
Dafür aber SecureBoot ausschalten, weitere Infos:
https://en.opensuse.org/openSUSE:UEFI
Viel Erfolg
Das Script soll hauptsächlich auf Rechnern mit Secure Boot funktionieren, deshalb ist die shim.efi notwendig.
Es kann aber gut sein daß das kein Fehler sondern eine Eigenschaft der Sicherheitsarchitektur des UEFI ist. Hier möchte ich aber sicher sein daß ich nicht irgendeinen Fehler mache.
Es kann aber gut sein daß das kein Fehler sondern eine Eigenschaft der Sicherheitsarchitektur des UEFI ist. Hier möchte ich aber sicher sein daß ich nicht irgendeinen Fehler mache.
Kann auch sein, dass du da nichts falsch machst, sondern Windows manchmal die Einstellung ignoriert...
Guck mal folgenden Artikel an, besonders Punkt 7 und 8
Erfahrungsbericht: Dual-Boot-Installation openSUSE Leap 42.2 und Windows 10
.
Guck mal folgenden Artikel an, besonders Punkt 7 und 8
Erfahrungsbericht: Dual-Boot-Installation openSUSE Leap 42.2 und Windows 10
.
Am Schnellstart liegt es nicht, die Seite kenne ich schon. Es scheint wirklich mit den "factory keys" zusammenzuhängen.
