> Vielleicht sollten die Debian-Entwickler die Open-Source-Idee einmal von der anderen Seite sehen und sich den erforderlichen Code bei Ubuntu besorgen.
Ist erst mal die Frage zu klären, ob der "erforderliche Code" überhaupt mit dem Debian-Gesellschaftsvertrag kompatibel ist. Die Ubuntu/Canonical-Lösung wurde von der FSF hart kritisiert.
ich habe mich da getäuscht. Der Bootloader hat eine BSD-Lizenz. Ich dachte es gäbe von dieser Seite Probleme mit der Ubuntu-Lösung.
> Zudem geht es in dem Artikel nur um UEFI und nicht um SecureBoot. Im FSF Whitepaper wird die Lizenz des Bootloaders kritisiert - unabhängig von SecureBoot.
Da Debian aber vermutlich in Hinblick auf ScureBoot einen anderen Weg als Ubuntu gehen wird, tippe ich generell auf eine eigene Bootloader-Lösung.
Im FSF Whitepaper wird die Lizenz des Bootloaders kritisiert - unabhängig von SecureBoot.
Das Whitepaper hat mit dem Artikel aber rein gar nichts zu tun. Michael Kofler hat nur die UEFI-Tauglichkeit verschiedener Distributionen getestet und festgestellt, dass das kommende Debian 7 noch nicht per UEFI booten kann.
Dabei kam dann auch der Vorschlag seinerseits, dass Debian die Ubuntu-Lösung einfach übernehmen könnte, denn Ubuntu bootet schon auf UEFI-Rechnern.
Von Idiotenpfleger am Sa, 21. Juli 2012 um 11:56 #
ich tippe auch auf eine Debian-eigene Bootloader-Lösung, weil man schon aus menschlichen Gründen, wie Stolz und Überheblichkeit, keinen Code von Ubuntu nehmen kann. Wie soll man sonst auch weiterhin den Vorwurf aufrecht erhalten, dass Ubuntu sein eigenes Süppchen kocht und immer inkompatibel ist?
Ach in dem Zusammehang fällt mir noch ein:
Zitat aus dem Artikel: "Um andere Distributionen kümmert sich Fedora übrigens nicht, das GRUB-Menü enthält nur Fedora-Einträge."
Freiheit? Contribution? Kompatibilität?
Ist schon okay, @Fedora&Red Hat People. Immer fein two-faced und mit zweierlei oder besser noch dreierlei Maß messen...
Von 01010101010110 am So, 22. Juli 2012 um 07:12 #
Ubuntucode wird schon längst von Debian übernommen. Gerade dann, wenn der gleiche Maintainer das gleiche Paket für Ubuntu und Debian betreut: Schließlich wäre es ja etwas merkwürdig, wenn man seinem eigenen Code nicht trauen würde.
Ich mache das dann immer so: Ich lege mir zwei Internetidentitäten an, dann kann ich - zusammen mit anderen - immer mit mir selber streiten. Cool, nicht wahr? Nein, also das Debian-Paket ist o.k. Aber das gleiche bzw. etwas neuere Ubuntupaket, nö, das geht auf gar keinen Fall.
Also ich verstehe sowieso nicht, warum nicht die anderen Linux-Derrivate sich Schlüssel von ubuntu gegen eine Lizenzgebühr holen.
Bin sicher Mark Shuttleworth verschenkt gerne gegen eine Gebühr von 50-100€ Lizenzschlüssel.
Seine Idee, dass die Mainboardhersteller entscheiden sollen, welches OS aufs Mainboard darf gefällt mir besser als die M$ -Methode Schlüssel an alle verkaufen zu wollen.
Lösung: M$ erhält Lizenzschlüssel und Ubuntu bekommt gratis Einen und lizensiert dann an Andere.
Der Käufer entscheidet, weil das betreffende Mainboard mit dem Kauf sein Eigentum wird. Verhält sich ein Mainboardhersteller anders, löst das eine sofortige Pflicht zur Rücknahme aus, insofern der Kunde das möchte. Es sei denn, das Mainboard ist ausdrücklich z.B. mit einem Hinweis wie etwa "Nur mit Windows 8 ohne weiteres Gefrickel verwendbar" verkauft worden.
Ich habe einen Dell Laptop und bei dem kann ich im Setup zwischen BIOS und EFI Modus wählen. Kann mir jemand mal plausibel erklären, welchen Vorteil ich davon habe, hier EFI zu wählen? SecureBoot kann man dabei ja erstmal aussen vor lassen.
Hier ist eine Übersicht, vielleicht hilft dir die weiter: Difference Between EFI and BIOS Letztendlich läuft es darauf hinaus, dass EFI sich eher wie ein minimalst OS verhält (z. B. GUI, Maus-Support, 32 Bit / 64 Bit, ... - das sollen jetzt aber keine herausragenden Features eines OS sein!).
Hast du überhaupt ein echtes uefi? Meist das das nur ein aufgebohrtes Bios mit uefi-Erweiterung. Das wird auch die nächste Zeit (2 Jahre) wohl auch noch so bleiben.
In meinen Augen wird das ganze derzeit alles zu heiß gekocht. Die nächsten 1 bis 2 Jahre wird immer noch ein klassisches Bios vorhanden sein. Die Entwickler müssen die Distributionen drauf auslegen und müssen jetzt handeln. Dem Nutzer kann es aber vorerst egal sein. Auch ist mir kein innovativer Mainboardhersteller bekannt, der es bei solchen Dingen eilig hat. Zu dem Zeitpunkt, an dem es nur noch uefi gibt, werden auch die großen Distributionen damit klar kommen. Secure Boot ist eine Nuss für sich, die es knacken gilt. Aber ob es lohnt sich derart den Kopf darüber zu zerbrechen ist auch fraglich.
Zu uefi gehört auch das GPT Partitionsschema für Festplatten. Das Booten von GPT-Platten ist unter einem reinen BIOS nur ein "Kann" aber kein "Muss". Da aber alle aktuellen System eigentlich uefi mit Bios Kompatibilitätslayer sind, booten die auch von GPT.
GRUB 2 kann, wenn es als EFI-Binary hinterlegt ist prinzipbedingt keine Betriebssysteme im "BIOS" mode booten. Was wirklich passiert ist, dass über das Hilfsprogramm os-prober andere Linux (eigentlich auch BSD, Windows im nicht UEFI mode) Installationen gefunden werden. Sollte eine Distribution aus was für Gründen auch immer nicht gefunden werden ist das ein Bug von os-prober und sollte dort reported werden (meist ist ne Korrektur ziemlich einfach). Die grub.cfg wird hierbei mit Hilfe von
grub-mkconfig -o /boot/grub/grub.cfg
erzeugt, das funktioniert eigentlich überall, wo GRUB2 verwendet wird, ist os-prober verfügbar werden die gefundenen Systeme mit eingetragen. Unter Debian oder Ubuntu gibts ein kleines Script names
update-grub
wo genau diesen Befehl aufruft. Hierbei werden die Scripte unter /etc/grub.d geparst zur erzeugung der Konfig. Alle anderen Distributionen, welche GRUB2 einsetzen könn(t)en ebenfalls os-prober verwenden.
Hierbei werden die Kernel direkt aus den Linux Partitionen geparst, wenn diese gebootet werden schaltet GRUB nicht etwa in den "BIOS" Mode zurück, nein das System bleibt im UEFI Mode. Es ist wichtig zu erwähnen, dass aktuelle Boards nur UEFI im 64 bit mode unterstützen. Bootet man trotzdem ein 32 bit Linux system ist es nicht unwahrscheinlich, dass nicht viel funktioniert. ACPI kann dann schon mal komplett fehlen, so dass man die Kiste nicht ausschalten kann bzw. nur 1 CPU Kern aktiv ist. Auch ist es unmöglich per Chainloader Win ohne UEFI zu booten (UEFI Windows Installationen findet os-prober nicht, dazu müsste die EFI Partition geparst werden und dort das EFI Binary gefunden werden, was aber nicht passiert).
Linux UEFI Stub
Auf etwas wo überhaupt nicht eingangen wird ist die Möglichkeit Linux Kernel direkt als EFI-Binary zu starten, entweder über eine EFI Shell, über einen direkten UEFI Eintrag mit Hilfe von efibootmgr oder mit einem ganz simplen EFI Bootloader wie gummiboot (die Konfigfiles sind wirklich nicht schwer zu schreiben, orientieren sind an GRUB 1 von der Syntax). Hierbei muss der Kernel (+ Initrd) in der EFI Boot Parition sein, auf Linux Partitionen kann mit dieser Variante nicht zugriffen werden. Dies funktioniert normalerweise erst ab Kernel 3.3, aber Debian Wheezy hat die nötigen Backports für 3.2 integriert - genauso wie die letzten Kanotix Releases. Bootet man ohne GRUB kann man durchaus bis zu 5-6 Sekunden einsparen.
UEFI Bugs
Dummerweise gibts immer wieder UEFI Bugs, die bei bestimmen Boards auftreten aber von den Support Abteilungen der Hersteller einfach ignoriert werden. Im dümmsten Falle kann man sein System komplett lahmlegen mit efibootmgr, so dass nur eine Neuprogrammierung des Firmware Chips hilft. Das is bei Desktop Boards oft nicht ganz so tragisch, wenn dieser gesockelt ist - aber bei Laptops kann das durchaus ziemlich nervtötend werden. Grundsätzlich gilt: Man sollte es tunlichst vermeiden mit efibootmgr -B Einträge zu löschen, welche vom Setup selbst hinzugefügt wurden und nicht durch die Installation eines Betriebssystems oder eigener Tests.
Viel wichtiger, da Distributions-unabhängig: Selbst wenn das Booten per EFI gelingt, hat man noch längst nicht alles geschafft. Wenn man per EFI bootet, machen nämlich dann gerne Treiber, insbesondere für die Grafikkarte, Probleme, da einige einfach davon ausgehen, dass ein Grafikkarten-BIOS da ist. Bekanntestes Beispiel dürfte wohl der NVidia-Blob sein, bei dem dann einfach alles schwarz bleibt bis man rebootet. Startet man dann die selbe Installation über das emulierte BIOS, geht natürlich alles, dann auch das Grafikkarten-BIOS geladen wird. Gibt also nicht nur für die Distributionen eine Menge Arbeit.
Und du hast das wirklich selbst probiert? Also ich kann dir versichern, dass nvidia + fglrx mit uefi funktioniert. Ich rede jetzt von "standard" Boards und nicht von nem Mac, sowas habe ich nicht.
Ja, habe ich. Sehr viel Zeit mit verschwendet, bis ich gemerkt habe, dass alles geht, wenn ich mit BIOS-Emulation boote. Dann raugefunden, dass sich der Treiber aus dem VESA-BIOS Informationen holen will, das ja dann nicht da ist…
Ja, habe ich. Sehr viel Zeit mit verschwendet, bis ich gemerkt habe, dass alles geht, wenn ich mit BIOS-Emulation boote. Dann raugefunden, dass sich der Treiber aus dem VESA-BIOS Informationen holen will, das ja dann nicht da ist…
ich versteh die ganze Aufregung nicht! Genauso wenig seh ich, dass die Distri-Hersteller etwas tun müssen.
Einzig und allein die Endnutzer/Käufer von Boards oder Komplett-Computern müssen darauf beharren, dass diese Signatur-Prüfung - also "secure" - deaktivierbar ist. Ansonsten einfach den Kauf verweigern und ggf. dem Hersteller noch eine nette Mail schreiben, wie gerne man doch gekauft hätte wenn .....
So werde ich es handhaben.
Ich bin sicher, dass ein jeder Hersteller auf Kauf-Verweigerung reagieren wird, wenn genügend Absatz wegbricht.
In dem Artikel geht es nur um die UEFI-Tauglichkeit von ein paar Distributionen und nicht um SecureBoot.
Zudem interessiert es 99% der Käufer eines Komplett-PCs überhaupt nicht, ob man SecureBoot nun deaktivieren kann oder nicht. Die nehmen einfach das vorinstallierte System (Am Besten noch mit all dem Müll an Demoversionen) und kümmern sich nicht um irgendwelche politischen und ideologischen Dinge.
Hauptsache der Rechner fährt fehlerfrei hoch und man kann Facebook benutzen.
Also man sollte mal klarstellen, dass nicht jeder, der eine eigene Distribution hat oder daran mitarbeitet überhaupt Testhardware hat. Was Secure Boot angeht gibt es genau ein s1156 Board von Intel wo man mit eigenen Keys zum testen ausstatten könnte. Billig ist es auch nicht gerade dafür, dass es für die Vorgänger CPU Generation ist. Dann gäbs noch ein Komplettsystem für 500€. Also wer soviel Geld übrig hat sich das zu kaufen nur zum testen soll es tun. Inzwischen könnte man natürlich auch mit einer Virtuellen Maschine arbeiten, aber da MS zumindest für x86 vorgesehen hat, dass es nur eine Zertifizierung gibt, wenn man Secure Boot abschalten können muss sehe ich dies nicht als primäres Problem an.
Was mich vielmehr nervt sind Hersteller, die UEFI Probleme ignorieren, wenn man diese reportet und Linux als Betriebssystem angibt - und das mit ganz simplen Beispielen, nur halt für das "falsche" OS. Würden diese behoben werden könnte man einfach sagen, mach ein Firmware update und dann wird alles wie gewünscht funktionieren, aber ist halt nicht so. Zudem hab ich z. B. auch nur Zugriff auf wenige Boards, bzw. kann evtl. mit ein paar Systemen testen, welche andere User haben, die sich für UEFI und dessen Vorteile sich interessieren.
Natürlich könnte eine grössere Distribution sich mehr Boards beschaffen zum testen, vielleicht sogar kostenlos, je nach Einfluss halt. Für kleinere gibts da durchaus ein Beschaffungsproblem, wobei es halt langsam kritisch wird, wenn man KEINE Test durchführt und wohl spätestens ab Weihnachten jeder PC per default mit UEFI startet. Man sollte spätestens bis verstanden haben, was geht und wo Probleme öfters auftreten - ohne ein System zu schrotten.
Da fehlt aber noch gentoo, damit funktioniert es auf jeden fall
Und dann noch Arch, Slackware, ... usw. Es ging scheinbar um deb / rpm Systeme. Ja, auch da fehlen noch welche ... oh man.
> Vielleicht sollten die Debian-Entwickler die Open-Source-Idee einmal von der anderen Seite sehen und sich den erforderlichen Code bei Ubuntu besorgen.
Ist erst mal die Frage zu klären, ob der "erforderliche Code" überhaupt mit dem Debian-Gesellschaftsvertrag kompatibel ist. Die Ubuntu/Canonical-Lösung wurde von der FSF hart kritisiert.
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web
http://tanguy.ortolo.eu/blog/article51/
also die sagen es geht !
Debian =! FSF
Zudem geht es in dem Artikel nur um UEFI und nicht um SecureBoot.
ich habe mich da getäuscht. Der Bootloader hat eine BSD-Lizenz. Ich dachte es gäbe von dieser Seite Probleme mit der Ubuntu-Lösung.
> Zudem geht es in dem Artikel nur um UEFI und nicht um SecureBoot.
Im FSF Whitepaper wird die Lizenz des Bootloaders kritisiert - unabhängig von SecureBoot.
Da Debian aber vermutlich in Hinblick auf ScureBoot einen anderen Weg als Ubuntu gehen wird, tippe ich generell auf eine eigene Bootloader-Lösung.
Dabei kam dann auch der Vorschlag seinerseits, dass Debian die Ubuntu-Lösung einfach übernehmen könnte, denn Ubuntu bootet schon auf UEFI-Rechnern.
ich tippe auch auf eine Debian-eigene Bootloader-Lösung, weil man schon aus menschlichen Gründen, wie Stolz und Überheblichkeit, keinen Code von Ubuntu nehmen kann. Wie soll man sonst auch weiterhin den Vorwurf aufrecht erhalten, dass Ubuntu sein eigenes Süppchen kocht und immer inkompatibel ist?
Ach in dem Zusammehang fällt mir noch ein:
Zitat aus dem Artikel: "Um andere Distributionen kümmert sich Fedora übrigens nicht, das GRUB-Menü enthält nur Fedora-Einträge."
Freiheit? Contribution? Kompatibilität?
Ist schon okay, @Fedora&Red Hat People. Immer fein two-faced und mit zweierlei oder besser noch dreierlei Maß messen...
Ubuntucode wird schon längst von Debian übernommen. Gerade dann, wenn der gleiche Maintainer das gleiche Paket für Ubuntu und Debian betreut: Schließlich wäre es ja etwas merkwürdig, wenn man seinem eigenen Code nicht trauen würde.
Ich mache das dann immer so: Ich lege mir zwei Internetidentitäten an, dann kann ich - zusammen mit anderen - immer mit mir selber streiten. Cool, nicht wahr?
Nein, also das Debian-Paket ist o.k. Aber das gleiche bzw. etwas neuere Ubuntupaket, nö, das geht auf gar keinen Fall.
Also ich verstehe sowieso nicht, warum nicht die anderen Linux-Derrivate sich Schlüssel von ubuntu gegen eine Lizenzgebühr holen.
Bin sicher Mark Shuttleworth verschenkt gerne gegen eine Gebühr von 50-100€ Lizenzschlüssel.
Seine Idee, dass die Mainboardhersteller entscheiden sollen, welches OS aufs Mainboard darf gefällt mir besser als die M$ -Methode Schlüssel an alle verkaufen zu wollen.
Lösung: M$ erhält Lizenzschlüssel und Ubuntu bekommt gratis Einen und lizensiert dann an Andere.
Damit wäre allen geholfen.
Der Käufer entscheidet, weil das betreffende Mainboard mit dem Kauf sein Eigentum wird.
Verhält sich ein Mainboardhersteller anders, löst das eine sofortige Pflicht zur Rücknahme aus, insofern der Kunde das möchte. Es sei denn, das Mainboard ist ausdrücklich z.B. mit einem Hinweis wie etwa "Nur mit Windows 8 ohne weiteres Gefrickel verwendbar" verkauft worden.
Ich habe einen Dell Laptop und bei dem kann ich im Setup zwischen BIOS und EFI Modus wählen.
Kann mir jemand mal plausibel erklären, welchen Vorteil ich davon habe, hier EFI zu wählen? SecureBoot kann man dabei ja erstmal aussen vor lassen.
Hier ist eine Übersicht, vielleicht hilft dir die weiter: Difference Between EFI and BIOS Letztendlich läuft es darauf hinaus, dass EFI sich eher wie ein minimalst OS verhält (z. B. GUI, Maus-Support, 32 Bit / 64 Bit, ... - das sollen jetzt aber keine herausragenden Features eines OS sein!).
hat EFI etwas mit UEFI zu tun?
hatte letzens auf ein neues Notebook Ubuntu12.04 und openSuse12.1 installiert.
Ubuntu ging nicht zu booten nach der installation, musste via boot_repair grub reparieren damit es ging,
openSuse ging problemlos.
beide Live CDs wurden von USB Stick gebootee.
diese Erfahrung wiederspricht etwas dem im Artikel beschreibenen verhalten.
was hab ich von UEFI?
wenn ich es im BIOS deaktiviere, merk ich irgendwie keinen Unterschied
Hast du überhaupt ein echtes uefi? Meist das das nur ein aufgebohrtes Bios mit uefi-Erweiterung. Das wird auch die nächste Zeit (2 Jahre) wohl auch noch so bleiben.
https://www.elektronik-kompendium.de/sites/com/0901081.htm
In meinen Augen wird das ganze derzeit alles zu heiß gekocht. Die nächsten 1 bis 2 Jahre wird immer noch ein klassisches Bios vorhanden sein. Die Entwickler müssen die Distributionen drauf auslegen und müssen jetzt handeln. Dem Nutzer kann es aber vorerst egal sein. Auch ist mir kein innovativer Mainboardhersteller bekannt, der es bei solchen Dingen eilig hat. Zu dem Zeitpunkt, an dem es nur noch uefi gibt, werden auch die großen Distributionen damit klar kommen. Secure Boot ist eine Nuss für sich, die es knacken gilt. Aber ob es lohnt sich derart den Kopf darüber zu zerbrechen ist auch fraglich.
Zu uefi gehört auch das GPT Partitionsschema für Festplatten.
Das Booten von GPT-Platten ist unter einem reinen BIOS nur ein "Kann" aber kein "Muss". Da aber alle aktuellen System eigentlich uefi mit Bios Kompatibilitätslayer sind, booten die auch von GPT.
Bye
Thorsten
http://mjg59.dreamwidth.org/8035.html
GRUB 2 kann, wenn es als EFI-Binary hinterlegt ist prinzipbedingt keine Betriebssysteme im "BIOS" mode booten. Was wirklich passiert ist, dass über das Hilfsprogramm os-prober andere Linux (eigentlich auch BSD, Windows im nicht UEFI mode) Installationen gefunden werden. Sollte eine Distribution aus was für Gründen auch immer nicht gefunden werden ist das ein Bug von os-prober und sollte dort reported werden (meist ist ne Korrektur ziemlich einfach). Die grub.cfg wird hierbei mit Hilfe von
grub-mkconfig -o /boot/grub/grub.cfg
erzeugt, das funktioniert eigentlich überall, wo GRUB2 verwendet wird, ist os-prober verfügbar werden die gefundenen Systeme mit eingetragen. Unter Debian oder Ubuntu gibts ein kleines Script names
update-grub
wo genau diesen Befehl aufruft. Hierbei werden die Scripte unter /etc/grub.d geparst zur erzeugung der Konfig. Alle anderen Distributionen, welche GRUB2 einsetzen könn(t)en ebenfalls os-prober verwenden.
Hierbei werden die Kernel direkt aus den Linux Partitionen geparst, wenn diese gebootet werden schaltet GRUB nicht etwa in den "BIOS" Mode zurück, nein das System bleibt im UEFI Mode. Es ist wichtig zu erwähnen, dass aktuelle Boards nur UEFI im 64 bit mode unterstützen. Bootet man trotzdem ein 32 bit Linux system ist es nicht unwahrscheinlich, dass nicht viel funktioniert. ACPI kann dann schon mal komplett fehlen, so dass man die Kiste nicht ausschalten kann bzw. nur 1 CPU Kern aktiv ist. Auch ist es unmöglich per Chainloader Win ohne UEFI zu booten (UEFI Windows Installationen findet os-prober nicht, dazu müsste die EFI Partition geparst werden und dort das EFI Binary gefunden werden, was aber nicht passiert).
Linux UEFI Stub
Auf etwas wo überhaupt nicht eingangen wird ist die Möglichkeit Linux Kernel direkt als EFI-Binary zu starten, entweder über eine EFI Shell, über einen direkten UEFI Eintrag mit Hilfe von efibootmgr oder mit einem ganz simplen EFI Bootloader wie gummiboot (die Konfigfiles sind wirklich nicht schwer zu schreiben, orientieren sind an GRUB 1 von der Syntax). Hierbei muss der Kernel (+ Initrd) in der EFI Boot Parition sein, auf Linux Partitionen kann mit dieser Variante nicht zugriffen werden. Dies funktioniert normalerweise erst ab Kernel 3.3, aber Debian Wheezy hat die nötigen Backports für 3.2 integriert - genauso wie die letzten Kanotix Releases. Bootet man ohne GRUB kann man durchaus bis zu 5-6 Sekunden einsparen.
UEFI Bugs
Dummerweise gibts immer wieder UEFI Bugs, die bei bestimmen Boards auftreten aber von den Support Abteilungen der Hersteller einfach ignoriert werden. Im dümmsten Falle kann man sein System komplett lahmlegen mit efibootmgr, so dass nur eine Neuprogrammierung des Firmware Chips hilft. Das is bei Desktop Boards oft nicht ganz so tragisch, wenn dieser gesockelt ist - aber bei Laptops kann das durchaus ziemlich nervtötend werden. Grundsätzlich gilt: Man sollte es tunlichst vermeiden mit efibootmgr -B Einträge zu löschen, welche vom Setup selbst hinzugefügt wurden und nicht durch die Installation eines Betriebssystems oder eigener Tests.
Vielen Dank für den informativen Thread
Viel wichtiger, da Distributions-unabhängig: Selbst wenn das Booten per EFI gelingt, hat man noch längst nicht alles geschafft. Wenn man per EFI bootet, machen nämlich dann gerne Treiber, insbesondere für die Grafikkarte, Probleme, da einige einfach davon ausgehen, dass ein Grafikkarten-BIOS da ist. Bekanntestes Beispiel dürfte wohl der NVidia-Blob sein, bei dem dann einfach alles schwarz bleibt bis man rebootet. Startet man dann die selbe Installation über das emulierte BIOS, geht natürlich alles, dann auch das Grafikkarten-BIOS geladen wird. Gibt also nicht nur für die Distributionen eine Menge Arbeit.
Und du hast das wirklich selbst probiert? Also ich kann dir versichern, dass nvidia + fglrx mit uefi funktioniert. Ich rede jetzt von "standard" Boards und nicht von nem Mac, sowas habe ich nicht.
Ja, habe ich. Sehr viel Zeit mit verschwendet, bis ich gemerkt habe, dass alles geht, wenn ich mit BIOS-Emulation boote. Dann raugefunden, dass sich der Treiber aus dem VESA-BIOS Informationen holen will, das ja dann nicht da ist…
Ja, habe ich. Sehr viel Zeit mit verschwendet, bis ich gemerkt habe, dass alles geht, wenn ich mit BIOS-Emulation boote. Dann raugefunden, dass sich der Treiber aus dem VESA-BIOS Informationen holen will, das ja dann nicht da ist…
Hallo,
ich versteh die ganze Aufregung nicht! Genauso wenig seh ich, dass die Distri-Hersteller etwas tun müssen.
Einzig und allein die Endnutzer/Käufer von Boards oder Komplett-Computern müssen darauf beharren, dass diese Signatur-Prüfung - also "secure" - deaktivierbar ist. Ansonsten einfach den Kauf verweigern und ggf. dem Hersteller noch eine nette Mail schreiben, wie gerne man doch gekauft hätte wenn .....
So werde ich es handhaben.
Ich bin sicher, dass ein jeder Hersteller auf Kauf-Verweigerung reagieren wird, wenn genügend Absatz wegbricht.
Gruß,
Hayati
Nochmal zum Mitschreiben:
In dem Artikel geht es nur um die UEFI-Tauglichkeit von ein paar Distributionen und nicht um SecureBoot.
Zudem interessiert es 99% der Käufer eines Komplett-PCs überhaupt nicht, ob man SecureBoot nun deaktivieren kann oder nicht. Die nehmen einfach das vorinstallierte System (Am Besten noch mit all dem Müll an Demoversionen) und kümmern sich nicht um irgendwelche politischen und ideologischen Dinge.
Hauptsache der Rechner fährt fehlerfrei hoch und man kann Facebook benutzen.
Habe nur ich das Gefühl ? Die Distributoren haben alle dem
EFI Treiben zugesehen und merken jetzt erst, hey, irgendwie
ist das alles sch....
Also man sollte mal klarstellen, dass nicht jeder, der eine eigene Distribution hat oder daran mitarbeitet überhaupt Testhardware hat. Was Secure Boot angeht gibt es genau ein s1156 Board von Intel wo man mit eigenen Keys zum testen ausstatten könnte. Billig ist es auch nicht gerade dafür, dass es für die Vorgänger CPU Generation ist. Dann gäbs noch ein Komplettsystem für 500€. Also wer soviel Geld übrig hat sich das zu kaufen nur zum testen soll es tun. Inzwischen könnte man natürlich auch mit einer Virtuellen Maschine arbeiten, aber da MS zumindest für x86 vorgesehen hat, dass es nur eine Zertifizierung gibt, wenn man Secure Boot abschalten können muss sehe ich dies nicht als primäres Problem an.
Was mich vielmehr nervt sind Hersteller, die UEFI Probleme ignorieren, wenn man diese reportet und Linux als Betriebssystem angibt - und das mit ganz simplen Beispielen, nur halt für das "falsche" OS. Würden diese behoben werden könnte man einfach sagen, mach ein Firmware update und dann wird alles wie gewünscht funktionieren, aber ist halt nicht so. Zudem hab ich z. B. auch nur Zugriff auf wenige Boards, bzw. kann evtl. mit ein paar Systemen testen, welche andere User haben, die sich für UEFI und dessen Vorteile sich interessieren.
Natürlich könnte eine grössere Distribution sich mehr Boards beschaffen zum testen, vielleicht sogar kostenlos, je nach Einfluss halt. Für kleinere gibts da durchaus ein Beschaffungsproblem, wobei es halt langsam kritisch wird, wenn man KEINE Test durchführt und wohl spätestens ab Weihnachten jeder PC per default mit UEFI startet. Man sollte spätestens bis verstanden haben, was geht und wo Probleme öfters auftreten - ohne ein System zu schrotten.