Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
EFI will nicht booten...
22 views
Skip to first unread message
Sieghard Schicktanz
Apr 9, 2012, 3:53:54 PM4/9/12
to
Hallo,
jetzt hat's mich wohl auch erwischt. Meine alte Maschine geht so langsam
"aus dem Leim", und ich hab' mir als Ersatz was neues beschafft. Statt wie
bisher "traditionelles" BIOS, P-ATA, SCSI und serielle und parallele Ports
mit (U)EFI, S-ATA und vielen USB-Anschlüssen (aber eine serielle
Schnitstelle ist doch immer noch "versteckt" drauf;).
Alles eigentlich kein Problem (bis auf die Platte, da mußte ich mir auch
ein neue leisten), aber jetzt muß das alte System auf die neue Kiste drauf.
Erste Hürde war, überhaupt was ans Laufen zu bringen, was ich aber mit
einem USB-Stick - gleich mit GPT eingerichtet, damit das auch gleich in
neuester Version läuft - fertgigebracht habe. Damit konnte ich dann die
Platte partitionieren und mit einer noch etwas reduzierten Kopie des
laufenden Systems (32 bit) einrichten,
Dann den Boot-Lader installiert - muß da ja grub2 sein, bisher hatte ich
den "alten" grub - und für den neuen 64-Bit-Prozessor eingerichtet. Ging
alles recht problemlos, und nachdem ich mir eine EFI-Shell besorgt hatte
(warum sind die Dinger eigentlich so versteckt?) und auf der dafür
erstellten EFI-System-Partition alles untergbracht, konnte ich die auch
schön starten und von der aus den grub laden und das System booten.
So, blieb(e) noch der letzte Schritt, die ganze Geschichte so einzurichten,
daß das System gleich nach dem Einschalten hochkommt.
Und da kommt's mir jetzt hoch - _NISCHT_ funktioniert da!
Weder geht der efibootmanager vom Linux, der findet einfach die EFI-
Variablen nicht, weil das "efivars"_Modul, das der _dafür_ _fertig_
_vorbereitete_ Kernel enthält, einfach nix anlegt, noch geht eine
Einrichtung über die EFI-Shell, weil _keine_ _einzige_ der Shells, die ich
gefunden habe, und die alle mehr oder weniger gleich sind (Version 2.0) den
dafür überall umfangreich beschriebenen Befehl "bcfg" (wohl für "boot
configuration") enthält!
Was'n _das_ für'n Mist?
Ich hab' zwar den - momentan für mich sehr unangenehmen - Verdacht, daß der
ganze Krams nur geht, wenn _alles_, BIOS, Boot-Lader, System-Kern und
System-Umgebung, vollständig 64-bittig ist - nur, wieso _gibt_ es dann den
ganzen Kram für ein 32-Bit-System überhaupt?
Oder mach' ich nur was primitives falsch, hab' was übersehen, oder nur die
passende Shell nicht gefunden? Hier komm' ich einfach nicht weiter...
(Immer über den Umweg des BIOS und Aufruf der EFI-Shell booten zu müssen
ist ja nicht so eine schöne Aussicht...)
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
jetzt hat's mich wohl auch erwischt. Meine alte Maschine geht so langsam
"aus dem Leim", und ich hab' mir als Ersatz was neues beschafft. Statt wie
bisher "traditionelles" BIOS, P-ATA, SCSI und serielle und parallele Ports
mit (U)EFI, S-ATA und vielen USB-Anschlüssen (aber eine serielle
Schnitstelle ist doch immer noch "versteckt" drauf;).
Alles eigentlich kein Problem (bis auf die Platte, da mußte ich mir auch
ein neue leisten), aber jetzt muß das alte System auf die neue Kiste drauf.
Erste Hürde war, überhaupt was ans Laufen zu bringen, was ich aber mit
einem USB-Stick - gleich mit GPT eingerichtet, damit das auch gleich in
neuester Version läuft - fertgigebracht habe. Damit konnte ich dann die
Platte partitionieren und mit einer noch etwas reduzierten Kopie des
laufenden Systems (32 bit) einrichten,
Dann den Boot-Lader installiert - muß da ja grub2 sein, bisher hatte ich
den "alten" grub - und für den neuen 64-Bit-Prozessor eingerichtet. Ging
alles recht problemlos, und nachdem ich mir eine EFI-Shell besorgt hatte
(warum sind die Dinger eigentlich so versteckt?) und auf der dafür
erstellten EFI-System-Partition alles untergbracht, konnte ich die auch
schön starten und von der aus den grub laden und das System booten.
So, blieb(e) noch der letzte Schritt, die ganze Geschichte so einzurichten,
daß das System gleich nach dem Einschalten hochkommt.
Und da kommt's mir jetzt hoch - _NISCHT_ funktioniert da!
Weder geht der efibootmanager vom Linux, der findet einfach die EFI-
Variablen nicht, weil das "efivars"_Modul, das der _dafür_ _fertig_
_vorbereitete_ Kernel enthält, einfach nix anlegt, noch geht eine
Einrichtung über die EFI-Shell, weil _keine_ _einzige_ der Shells, die ich
gefunden habe, und die alle mehr oder weniger gleich sind (Version 2.0) den
dafür überall umfangreich beschriebenen Befehl "bcfg" (wohl für "boot
configuration") enthält!
Was'n _das_ für'n Mist?
Ich hab' zwar den - momentan für mich sehr unangenehmen - Verdacht, daß der
ganze Krams nur geht, wenn _alles_, BIOS, Boot-Lader, System-Kern und
System-Umgebung, vollständig 64-bittig ist - nur, wieso _gibt_ es dann den
ganzen Kram für ein 32-Bit-System überhaupt?
Oder mach' ich nur was primitives falsch, hab' was übersehen, oder nur die
passende Shell nicht gefunden? Hier komm' ich einfach nicht weiter...
(Immer über den Umweg des BIOS und Aufruf der EFI-Shell booten zu müssen
ist ja nicht so eine schöne Aussicht...)
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Message has been deleted
Sieghard Schicktanz
Apr 9, 2012, 8:13:10 PM4/9/12
to
Hallo Marcus,
Du schriebst am Mon, 09 Apr 2012 23:18:21 +0200:
> > Damit konnte ich dann die Platte partitionieren und mit einer noch
> > etwas reduzierten Kopie des laufenden Systems (32 bit) einrichten,
>
> Du hättest nebenbei auch einfach nur die alte Platte einhängen
> können. Efi Kisten gehen dann normalerweise automatisch in den
> Emulationsmodus und spielen „BIOS“.
Ja, das wollte ich ja genau nicht. Davon abgesehen läuft die alte Platte
noch mit dem alten System auf der alten Maschine. Deren Prozessor hat nur
ein kleines Wärmeproblem, wohl weil ein paar Kondensatoren in der
Stromversorgung der "Hut hochgegangen" ist.
> Mit neuen Kerneln braucht man AFAIK nicht mal mehr unbedingt einen
> Bootloader. Den Kernel kann man jetzt ja auch mit EFI- statt BIOS-Code
> dran backen und dann kann EFI den Kernel wohl auch direkt starten. Muß
> ich bei Gelegenheit wohl mal ausprobieren.
Und ich wollte eigentlich "endlich" mal einen Distributionskernel nehmen,
nachdem ich mir hier schon einiges anhören mußte, weil ich mir den immer
selber gebaut hatte... (bisher wegen der seriellen Schnittstellen, die der
neue jetzt auch von der Distribution her bedienen könnte.)
> Normal nimmt einem Grub das alles ab, wenn man das erstmalig
> installiert. Dann meldet sich das selbst bei Efi entsprechend an
> bzw. ruft efibootmgr selber auf.
Weder das erstere noch das letztere. Wenn das erstere gegangen wäre, hätte
die Kiste booten müssen - es gab keinen Fehler, nichtmal bei der Auswahl
des 64-Bit-grub zur Installation. Und warum wird der überhaupt angeboten,
wenn man ihn mit dem System, unter dem er installiert werden soll, garnicht
funktionieren _kann_?
Und wenn dabei der efibootmanager aufgerufen worden wäre, hätte ich doch
wohl wenigstens dessen Fehlermeldung sehen müssen?
> > Variablen nicht, weil das "efivars"_Modul, das der _dafür_ _fertig_
> > _vorbereitete_ Kernel enthält, einfach nix anlegt,
>
> Dann liegt hier Dein Problem. Das muß vorhanden sein und funktionieren,
> damit efibootmgr grub in der Firmware anmelden kann. Sonst weiß Efi
> einfach nichts von Deinem grub und startet den nat. nicht.
Ja, so sehe ich das auch. Nur sehe ich _keinen_ Hinweis, _warum_ das nicht
gehen sollte, sogar das Modul wird ohne Fehler geladen. Kernel-Version ist
übrigens 3.2.7 - funktioniert das damit etwa noch nicht? Eine 3.3 wäre auch
vorhanden...
> > gleich sind (Version 2.0) den dafür überall umfangreich beschriebenen
> > Befehl "bcfg" (wohl für "boot configuration") enthält!
>
> Haben die auch normal nicht. Du darfst nicht vergessen, die meiste Doku
"Eigentlich", habe ich geschrieben gefunden, sollte der bei der Version 2
vorhanden sein.
> im Netz bezieht sich auf alte Itanium Schüsseln in Serverkaliber. Da sah
> das meist etwas anders aus.
Aber wahrscheinlich ist die - überall zu findende - Dokumentation eben
_nicht_ für PC-Anwendungen. D.h. die EFI-Shell ist dafür praktisch nutzlos
- was will man mit _noch einer_ Software, die einem alles mögliche
anbietet, was man nicht braucht, aber die benötigte Funktion nicht enthält.
Der grub funktioniert wenigstens soweit, daß er das System richtig startet
- er wird nur nicht vom BIOS direkt angeworfen. Er ließe sich sogar als
EFI-Shell starten, wenn das BIOS nur _überhaupt_ was von der platte starten
wollte.
> Firmware und Bootcode/Kernel müssen in Sachen Bitformat immer
> übereinstimmen.
Zumindest für den Kernel scheint das nicht zuzutreffen, siehe letzten
Absatz - der Übergang Bootcode -> Kernel funktioniert. Nur das "initiale"
Starten _überhaupt_ eines plattenresidenten Programms funktioniert eben
nicht. Der müßte ja offenbar irgendwo eingetragen werden, und dafür gibt es
_nichts_ an Mitteln, was funktionierte.
> Wenn Du einen 32 bittigen Kernel am Start hast, ist nat. klar, warum Du
> auf die Nase fällst. Das geht schlicht nicht.
Doch, das _geht_ ja. Nur eben nicht automatisch.
> amd64 Kernel nehmen. Dann sollten efivars verfügbar sein und Du kannst
> grub bei efi mittels efibootmgr anmelden.
Ja. scheint mir auch so. Aber dann muß die Geschichte noch einige Zeit
warten. Für eine Komplettumstellung fehlt mir derzeit einfach die Zeit.
Und _nur_ den Kernel umstellen scheint nicht recht unterstützt zu sein,
da muß ich auch noch weiter suchen.
> Rein theoretisch müßte man jetzt auch wie gesagt einfach den Kernel in
> der Systempartition abwerfen und direkt da rein booten können.
Sehr theoretisch, das. Müßte sich dazu nicht der Kernel als EFI-Programm
"tarnen"?
Aber ich denke, daß es eher weniger daran liegt, daß die EFI-Verarbeitung
nicht funktioniert, sondern daran, daß dieses EFI-Glump einfach so
überkandidelt daherkommt, daß es nichtmal ein Werkzeug enthält, einen ganz
normalen funktionierenden Boot-Lader auf einer GPT-partitionierten Platte
als Boot-Lader anzumelden.
_Da_ scheint der Hund im Pfeffer zu liegen...
(Oder war das ein Hase, ist ja schließlich Ostern;=)
Du schriebst am Mon, 09 Apr 2012 23:18:21 +0200:
> > Damit konnte ich dann die Platte partitionieren und mit einer noch
> > etwas reduzierten Kopie des laufenden Systems (32 bit) einrichten,
>
> können. Efi Kisten gehen dann normalerweise automatisch in den
> Emulationsmodus und spielen „BIOS“.
Ja, das wollte ich ja genau nicht. Davon abgesehen läuft die alte Platte
noch mit dem alten System auf der alten Maschine. Deren Prozessor hat nur
ein kleines Wärmeproblem, wohl weil ein paar Kondensatoren in der
Stromversorgung der "Hut hochgegangen" ist.
> Mit neuen Kerneln braucht man AFAIK nicht mal mehr unbedingt einen
> Bootloader. Den Kernel kann man jetzt ja auch mit EFI- statt BIOS-Code
> dran backen und dann kann EFI den Kernel wohl auch direkt starten. Muß
> ich bei Gelegenheit wohl mal ausprobieren.
Und ich wollte eigentlich "endlich" mal einen Distributionskernel nehmen,
nachdem ich mir hier schon einiges anhören mußte, weil ich mir den immer
selber gebaut hatte... (bisher wegen der seriellen Schnittstellen, die der
neue jetzt auch von der Distribution her bedienen könnte.)
> Normal nimmt einem Grub das alles ab, wenn man das erstmalig
> installiert. Dann meldet sich das selbst bei Efi entsprechend an
> bzw. ruft efibootmgr selber auf.
Weder das erstere noch das letztere. Wenn das erstere gegangen wäre, hätte
die Kiste booten müssen - es gab keinen Fehler, nichtmal bei der Auswahl
des 64-Bit-grub zur Installation. Und warum wird der überhaupt angeboten,
wenn man ihn mit dem System, unter dem er installiert werden soll, garnicht
funktionieren _kann_?
Und wenn dabei der efibootmanager aufgerufen worden wäre, hätte ich doch
wohl wenigstens dessen Fehlermeldung sehen müssen?
> > Variablen nicht, weil das "efivars"_Modul, das der _dafür_ _fertig_
> > _vorbereitete_ Kernel enthält, einfach nix anlegt,
>
> damit efibootmgr grub in der Firmware anmelden kann. Sonst weiß Efi
> einfach nichts von Deinem grub und startet den nat. nicht.
Ja, so sehe ich das auch. Nur sehe ich _keinen_ Hinweis, _warum_ das nicht
gehen sollte, sogar das Modul wird ohne Fehler geladen. Kernel-Version ist
übrigens 3.2.7 - funktioniert das damit etwa noch nicht? Eine 3.3 wäre auch
vorhanden...
> > gleich sind (Version 2.0) den dafür überall umfangreich beschriebenen
> > Befehl "bcfg" (wohl für "boot configuration") enthält!
>
"Eigentlich", habe ich geschrieben gefunden, sollte der bei der Version 2
vorhanden sein.
> im Netz bezieht sich auf alte Itanium Schüsseln in Serverkaliber. Da sah
> das meist etwas anders aus.
Aber wahrscheinlich ist die - überall zu findende - Dokumentation eben
_nicht_ für PC-Anwendungen. D.h. die EFI-Shell ist dafür praktisch nutzlos
- was will man mit _noch einer_ Software, die einem alles mögliche
anbietet, was man nicht braucht, aber die benötigte Funktion nicht enthält.
Der grub funktioniert wenigstens soweit, daß er das System richtig startet
- er wird nur nicht vom BIOS direkt angeworfen. Er ließe sich sogar als
EFI-Shell starten, wenn das BIOS nur _überhaupt_ was von der platte starten
wollte.
> Firmware und Bootcode/Kernel müssen in Sachen Bitformat immer
> übereinstimmen.
Zumindest für den Kernel scheint das nicht zuzutreffen, siehe letzten
Absatz - der Übergang Bootcode -> Kernel funktioniert. Nur das "initiale"
Starten _überhaupt_ eines plattenresidenten Programms funktioniert eben
nicht. Der müßte ja offenbar irgendwo eingetragen werden, und dafür gibt es
_nichts_ an Mitteln, was funktionierte.
> Wenn Du einen 32 bittigen Kernel am Start hast, ist nat. klar, warum Du
> auf die Nase fällst. Das geht schlicht nicht.
Doch, das _geht_ ja. Nur eben nicht automatisch.
> amd64 Kernel nehmen. Dann sollten efivars verfügbar sein und Du kannst
> grub bei efi mittels efibootmgr anmelden.
Ja. scheint mir auch so. Aber dann muß die Geschichte noch einige Zeit
warten. Für eine Komplettumstellung fehlt mir derzeit einfach die Zeit.
Und _nur_ den Kernel umstellen scheint nicht recht unterstützt zu sein,
da muß ich auch noch weiter suchen.
> Rein theoretisch müßte man jetzt auch wie gesagt einfach den Kernel in
> der Systempartition abwerfen und direkt da rein booten können.
Sehr theoretisch, das. Müßte sich dazu nicht der Kernel als EFI-Programm
"tarnen"?
Aber ich denke, daß es eher weniger daran liegt, daß die EFI-Verarbeitung
nicht funktioniert, sondern daran, daß dieses EFI-Glump einfach so
überkandidelt daherkommt, daß es nichtmal ein Werkzeug enthält, einen ganz
normalen funktionierenden Boot-Lader auf einer GPT-partitionierten Platte
als Boot-Lader anzumelden.
_Da_ scheint der Hund im Pfeffer zu liegen...
(Oder war das ein Hase, ist ja schließlich Ostern;=)
Joseph Terner
Apr 10, 2012, 7:17:47 AM4/10/12
to
On Mon, 09 Apr 2012 21:53:54 +0200, Sieghard Schicktanz wrote:
> So, blieb(e) noch der letzte Schritt, die ganze Geschichte so einzurichten,
> daß das System gleich nach dem Einschalten hochkommt.
> Und da kommt's mir jetzt hoch - _NISCHT_ funktioniert da!
>
> Weder geht der efibootmanager vom Linux, der findet einfach die EFI-
> Variablen nicht, weil das "efivars"_Modul, das der _dafür_ _fertig_
> _vorbereitete_ Kernel enthält, einfach nix anlegt, noch geht eine
> Einrichtung über die EFI-Shell, weil _keine_ _einzige_ der Shells, die ich
> gefunden habe, und die alle mehr oder weniger gleich sind (Version 2.0) den
> dafür überall umfangreich beschriebenen Befehl "bcfg" (wohl für "boot
> configuration") enthält!
>
> Was'n _das_ für'n Mist?
Der Sinn hinter UEFI ist, Dich beim Booten von Linux zu behindern.
> So, blieb(e) noch der letzte Schritt, die ganze Geschichte so einzurichten,
> daß das System gleich nach dem Einschalten hochkommt.
> Und da kommt's mir jetzt hoch - _NISCHT_ funktioniert da!
>
> Weder geht der efibootmanager vom Linux, der findet einfach die EFI-
> Variablen nicht, weil das "efivars"_Modul, das der _dafür_ _fertig_
> _vorbereitete_ Kernel enthält, einfach nix anlegt, noch geht eine
> Einrichtung über die EFI-Shell, weil _keine_ _einzige_ der Shells, die ich
> gefunden habe, und die alle mehr oder weniger gleich sind (Version 2.0) den
> dafür überall umfangreich beschriebenen Befehl "bcfg" (wohl für "boot
> configuration") enthält!
>
> Was'n _das_ für'n Mist?
Weißt Du schon, wofür ACPI explizit erfunden wurde?
ciao, Joseph
Message has been deleted
Sieghard Schicktanz
Apr 10, 2012, 3:14:35 PM4/10/12
to
Hallo Marcus,
Du schriebst am Tue, 10 Apr 2012 17:02:35 +0200:
> > Auswahl des 64-Bit-grub zur Installation. Und warum wird der überhaupt
> > angeboten, wenn man ihn mit dem System, unter dem er installiert werden
^^^^^^^er (gnrfzg(c))
Naja, eine Fehlermeldung eines nicht so ganz unwesentlichen Teils der
Aktion (efibootmanager) sollte wohl nicht ohne weiteres unterdrückt werden?
Sie kommt auch, wenn man das "einfach so" aufruft, dann will der nämlich
die BIOS-Version installieren. Wie das eben brave Anhänger des mächtigen
Monopolisten tun sollen. :-( ];-[=]
> mit grub kämpfen müssen, weil da die Doku nicht wirklich toll ist.
Mit der grub-Dokumentation habe ich nicht so sehr viele Probleme gehabt,
wenn auch die Beschreibung von grub-install mehr Löcher als Information
aufweist. Unter aller Sau ist allerdings die "Dokumentation" des
efibootmanagers - die ist eher nicht vorhanden, grade mal die Auflistung
der Optionen, und die Hinweise auf die intel-Machwerke führen eher in die
Irre, als daß sie helfen könnten.
> Trick war dann bei meinem speziellen Problem, grub einfach ohne jeden
> weiteren Paramter aufzurufen und wunderbarerweise hat der dann alles
> automatisch richtig gemacht - sobald man ihn aus einem laufenden System
Du hast das aber auch bei einem 64-Bit-System gemacht (ich habe Deine
Ausführungen gelesen). Ich habe noch ein 32-Bit-System, da scheint das
nicht zu klappen, obwohl irgendwelche hirnverbrannte Dödel (sorry...)
sowohl den grub _für_ _dieses_ System in 32 Bit _für_ ein 64-Bit-BIOS
anbieten, als auch den efibootmanager (32-bittig).
> im EFI Modus installiert. Ist so ein kleines Henne/Ei Problem und die
> Doku hängt Ewigkeiten hinter EFI hinterher.
Und ist an wesentlichen Stellen einfach irreführend, weil für ganz andere
Konfigurationen vorgesehen.
> >> Firmware und Bootcode/Kernel müssen in Sachen Bitformat immer
> >> übereinstimmen.
> >
> > Zumindest für den Kernel scheint das nicht zuzutreffen, siehe letzten
> > Absatz - der Übergang Bootcode -> Kernel funktioniert. Nur das
> > "initiale" Starten _überhaupt_ eines plattenresidenten Programms
> > funktioniert eben nicht.
>
> Logisch. Dafür muß der Bootloader bei Efi halt angemeldet sein. Anmelden
> geht aber nur bei einem 64 bittigen UEFI mit efibootmgr unter einem 64
> bittigen Kernel. Solange Du den nicht hast, geht es ganz einfach nicht.
Es könnte auch mit einem EFI-Programm gehen, schließlich laufen die ja
anstandslos. Warum gibt es das eigentlich nicht? So kompliziert kann das
doch auch nicht sein - angeblich ist EFI doch standardisiert?
> > Der müßte ja offenbar irgendwo eingetragen werden, und dafür gibt
> > es _nichts_ an Mitteln, was funktionierte.
>
> Doch, efibootmgr funktioniert. Dazu muß aber der Kernel von der
> bitbreite her zu Efi passen, damit das funktioniert.
Eben, und damit gibt es _nichts_ was auf meinem System funktionierte.
> Daß es startet ist klar. Efi kann alles booten, was überhaupt auf der
> CPU läuft. Ich meinte damit nat. mit der Anmeldung des Bootmanagers
> fällst Du auf die Nase.
Das hab' ich gemerkt. Und ich hab' auch gemerkt, daß das _Absicht_ sein muß
- es _gibt_ ja Möglichkeiten, die sogar in der Shell vorgesehen sind - sie
sind nur in _den_ Shells, die für PCs zur Verfügung stehen _ausgebaut_.
Und die Linuxer lassen sich das gefallen, daß man ihnen auf der Nase
'rumtanzt.
> Nur Kernel geht. Ich hab meine ganze Kiste ja komplett von BIOS auf EFI
Sollte, ja, aber anscheinend nicht mit Distributionsunterstützung. Da werd'
ich wohl auch noch basteln müssen. Was das wieder Zeit kostet... :-(
> Im Grunde brauchst Du aber nur einen einmal funktionierendes efibootmgr,
...
> EFI System in 64 Bit für finden und auf ein Bootmedium packen.
So hatte ich das auch gedacht. Werd' ich mir wohl ein aktuelles grml oder
sowas 'runterladen müssen (das wär' sicher auch anderweitig brauchbar).
[Kernel direkt]
> dranpappen, so daß ein normales BIOS den einfach booten kann. Das gibt
> es schon immer, damit man z.B. früher direkt den Kernel von Floppy
Wurde das nicht vor einiger Zeit zugunsten eines externen Boot-Laders
aufgegeben? Aktuelle Kernel sollen doch nicht nur wegen der Größe nicht
mehr von Floppy (oder CD o.ä.) starten können, sondern brauchen LILO oder
grub dazu.
> starten konnte, wo kein Platz für Bootloader und ähnlichen Luxus war.
> Mit EFI sieht das nicht anders aus. Dann hängt eben ein entsprechendes
> EFI-Stub davor.
Das ginge dann natürlich. Wäre sowieso der sinnvollere Weg - das ganze
Geraffel mit demBIOS ist eigentlich völliger Unsinn, jede Menge Software in
der Maschine, die praktisch nie benutzt wird.
Eigentlich würd's reichen, einen minimalen Lader in einen kleinen Speicher
auf der Karte zu packen, der bei Auslieferung einen USB-Stick oder sowas
booten kann, von dem aus man dann einen anderen oder weiteren _kleinen_
Lader installiert, der das gewünschte Boot-Medium lädt - und auch da
erstmal nur einen minimalen Lader, der dann in der bisherigen Art
schrittweise die ganze Maschine hochfährt.
So wird's ja auch bei den ARMs gemacht, da sitzt der initiale Minimal-Lader
oft sogar in einem prozessorinternen (Flash-) ROM, so daß nichtmal ein
zusätzliches Bauelement anfällt. Die dicken intel- (und AMD-) Prozessoren
dagegen, die schon für die Speicherverwaltung mehr Transistoren (und
Leistung) verbraten als ein ganzer ARM-Prozessor, haben nichtmal ein
eingebautes Boot-ROM. (Naja, bei den internen Temperaturen würde das wohl
auch zu schnell "flüchten"... ];-> )
> > dieses EFI-Glump einfach so überkandidelt daherkommt, daß es nichtmal
> > ein Werkzeug enthält, einen ganz normalen funktionierenden Boot-Lader
> > auf einer GPT-partitionierten Platte als Boot-Lader anzumelden.
>
> Du redest von Consumerkisten. Die sind für Windows und Leute gedacht,
> die gerade mal mit der Maus 'ok' anklicken können. Da sind dann auch gar
Solche Leute brauchen aber keine dicken Prozessoren mit vier "Kernen" und
mehr und allem möglichen anderen Krimskrams.
Aber klar, das ist so wie bei den Autos - die Kiste muß riesengroß sein,
hunderte PS haben (damit sie schneller in die Botanik fligen, dann ist der
Entsorgungseffekt besser) und möglichst viele "Gadgets" eingebaut haben,
vor denen sioe dann nicht mehr zum Aufpassen aufs Fahren kommen und mal
schnell den Gehsteig abräumen oder ein paar Bäume ummmähen.
Ersetzt man Auto mit CPU, PS mit GHz und Kiist mit Speicher, ist das fast
direkt für "Consumer"-Computer zu lesen...
Und, bitte schön, _was_ sollen _die_ dann eigentlich mit dem EFI-Geraffel?
Die _sehen_ das doch nichtmal. Rausgeschissenes Geld und Aufwand.
> keine Shells dabei, mit denen sich die Leute dann womöglich noch die
> Kiste kaputtspielen und die dem Support am Telefon im Mumbai dann auch
> noch Kopfschmerzen bereiten.
Oooch - _der_ Support ist diesen "Nutzern" doch richtig gut angepasst. ];->
> Kaufst Du Dir einen richtigen Rechner aus der Serverecke, sieht das auch
> gleich schon wieder ganz anders aus.
Nnnjaa - aber halt nicht meinem "Geldbeutel"...
Davon abgesehen wüßte ich jetzt nichtmal, wo man was "aus der Serverecke"
als kleiner Programmierer überhaupt herkriegen könnte, unabhängig vom Preis.
> Der Hase. Und der liegt da, weil wie immer: You get what you pay for.
Nee, _das_ stimmt ja schon lange nicht mehr. Du zahlst immer öfter für
Sachen, die Du nie nutzen kannst, weil die andere kriegen. Manchmal kriegst
Du dafür Sachen (fast( umsonst, die Du eigentlich garnicht haben willst.
Die "Globalisierung" im Verein mit dem internet haben's möglich gemacht.
Aber _das_ ist ein anderes, weites Feld...
Du schriebst am Tue, 10 Apr 2012 17:02:35 +0200:
> > Auswahl des 64-Bit-grub zur Installation. Und warum wird der überhaupt
> > angeboten, wenn man ihn mit dem System, unter dem er installiert werden
> > soll, garnicht funktionieren _kann_? Und wenn dabei der efibootmanager
> > aufgerufen worden wäre, hätte ich doch wohl wenigstens dessen
> > Fehlermeldung sehen müssen?
> Nein. Ich bin selbst auf den ganzen Kram am Anfang reingefallen und hab
> > aufgerufen worden wäre, hätte ich doch wohl wenigstens dessen
> > Fehlermeldung sehen müssen?
Naja, eine Fehlermeldung eines nicht so ganz unwesentlichen Teils der
Aktion (efibootmanager) sollte wohl nicht ohne weiteres unterdrückt werden?
Sie kommt auch, wenn man das "einfach so" aufruft, dann will der nämlich
die BIOS-Version installieren. Wie das eben brave Anhänger des mächtigen
Monopolisten tun sollen. :-( ];-[=]
> mit grub kämpfen müssen, weil da die Doku nicht wirklich toll ist.
Mit der grub-Dokumentation habe ich nicht so sehr viele Probleme gehabt,
wenn auch die Beschreibung von grub-install mehr Löcher als Information
aufweist. Unter aller Sau ist allerdings die "Dokumentation" des
efibootmanagers - die ist eher nicht vorhanden, grade mal die Auflistung
der Optionen, und die Hinweise auf die intel-Machwerke führen eher in die
Irre, als daß sie helfen könnten.
> Trick war dann bei meinem speziellen Problem, grub einfach ohne jeden
> weiteren Paramter aufzurufen und wunderbarerweise hat der dann alles
> automatisch richtig gemacht - sobald man ihn aus einem laufenden System
Du hast das aber auch bei einem 64-Bit-System gemacht (ich habe Deine
Ausführungen gelesen). Ich habe noch ein 32-Bit-System, da scheint das
nicht zu klappen, obwohl irgendwelche hirnverbrannte Dödel (sorry...)
sowohl den grub _für_ _dieses_ System in 32 Bit _für_ ein 64-Bit-BIOS
anbieten, als auch den efibootmanager (32-bittig).
> im EFI Modus installiert. Ist so ein kleines Henne/Ei Problem und die
> Doku hängt Ewigkeiten hinter EFI hinterher.
Und ist an wesentlichen Stellen einfach irreführend, weil für ganz andere
Konfigurationen vorgesehen.
> >> Firmware und Bootcode/Kernel müssen in Sachen Bitformat immer
> >> übereinstimmen.
> >
> > Zumindest für den Kernel scheint das nicht zuzutreffen, siehe letzten
> > Absatz - der Übergang Bootcode -> Kernel funktioniert. Nur das
> > "initiale" Starten _überhaupt_ eines plattenresidenten Programms
> > funktioniert eben nicht.
>
> geht aber nur bei einem 64 bittigen UEFI mit efibootmgr unter einem 64
> bittigen Kernel. Solange Du den nicht hast, geht es ganz einfach nicht.
Es könnte auch mit einem EFI-Programm gehen, schließlich laufen die ja
anstandslos. Warum gibt es das eigentlich nicht? So kompliziert kann das
doch auch nicht sein - angeblich ist EFI doch standardisiert?
> > Der müßte ja offenbar irgendwo eingetragen werden, und dafür gibt
> > es _nichts_ an Mitteln, was funktionierte.
>
> bitbreite her zu Efi passen, damit das funktioniert.
Eben, und damit gibt es _nichts_ was auf meinem System funktionierte.
> Daß es startet ist klar. Efi kann alles booten, was überhaupt auf der
> CPU läuft. Ich meinte damit nat. mit der Anmeldung des Bootmanagers
> fällst Du auf die Nase.
Das hab' ich gemerkt. Und ich hab' auch gemerkt, daß das _Absicht_ sein muß
- es _gibt_ ja Möglichkeiten, die sogar in der Shell vorgesehen sind - sie
sind nur in _den_ Shells, die für PCs zur Verfügung stehen _ausgebaut_.
Und die Linuxer lassen sich das gefallen, daß man ihnen auf der Nase
'rumtanzt.
> Nur Kernel geht. Ich hab meine ganze Kiste ja komplett von BIOS auf EFI
Sollte, ja, aber anscheinend nicht mit Distributionsunterstützung. Da werd'
ich wohl auch noch basteln müssen. Was das wieder Zeit kostet... :-(
> Im Grunde brauchst Du aber nur einen einmal funktionierendes efibootmgr,
...
> EFI System in 64 Bit für finden und auf ein Bootmedium packen.
So hatte ich das auch gedacht. Werd' ich mir wohl ein aktuelles grml oder
sowas 'runterladen müssen (das wär' sicher auch anderweitig brauchbar).
[Kernel direkt]
> > Sehr theoretisch, das. Müßte sich dazu nicht der Kernel als
> > EFI-Programm "tarnen"?
>
> Wieso tarnen? Der traditionelle Kernel hat ja einen BIOS-Stub vorne
> > EFI-Programm "tarnen"?
>
> dranpappen, so daß ein normales BIOS den einfach booten kann. Das gibt
> es schon immer, damit man z.B. früher direkt den Kernel von Floppy
Wurde das nicht vor einiger Zeit zugunsten eines externen Boot-Laders
aufgegeben? Aktuelle Kernel sollen doch nicht nur wegen der Größe nicht
mehr von Floppy (oder CD o.ä.) starten können, sondern brauchen LILO oder
grub dazu.
> starten konnte, wo kein Platz für Bootloader und ähnlichen Luxus war.
> Mit EFI sieht das nicht anders aus. Dann hängt eben ein entsprechendes
> EFI-Stub davor.
Das ginge dann natürlich. Wäre sowieso der sinnvollere Weg - das ganze
Geraffel mit demBIOS ist eigentlich völliger Unsinn, jede Menge Software in
der Maschine, die praktisch nie benutzt wird.
Eigentlich würd's reichen, einen minimalen Lader in einen kleinen Speicher
auf der Karte zu packen, der bei Auslieferung einen USB-Stick oder sowas
booten kann, von dem aus man dann einen anderen oder weiteren _kleinen_
Lader installiert, der das gewünschte Boot-Medium lädt - und auch da
erstmal nur einen minimalen Lader, der dann in der bisherigen Art
schrittweise die ganze Maschine hochfährt.
So wird's ja auch bei den ARMs gemacht, da sitzt der initiale Minimal-Lader
oft sogar in einem prozessorinternen (Flash-) ROM, so daß nichtmal ein
zusätzliches Bauelement anfällt. Die dicken intel- (und AMD-) Prozessoren
dagegen, die schon für die Speicherverwaltung mehr Transistoren (und
Leistung) verbraten als ein ganzer ARM-Prozessor, haben nichtmal ein
eingebautes Boot-ROM. (Naja, bei den internen Temperaturen würde das wohl
auch zu schnell "flüchten"... ];-> )
> > dieses EFI-Glump einfach so überkandidelt daherkommt, daß es nichtmal
> > ein Werkzeug enthält, einen ganz normalen funktionierenden Boot-Lader
> > auf einer GPT-partitionierten Platte als Boot-Lader anzumelden.
>
> die gerade mal mit der Maus 'ok' anklicken können. Da sind dann auch gar
Solche Leute brauchen aber keine dicken Prozessoren mit vier "Kernen" und
mehr und allem möglichen anderen Krimskrams.
Aber klar, das ist so wie bei den Autos - die Kiste muß riesengroß sein,
hunderte PS haben (damit sie schneller in die Botanik fligen, dann ist der
Entsorgungseffekt besser) und möglichst viele "Gadgets" eingebaut haben,
vor denen sioe dann nicht mehr zum Aufpassen aufs Fahren kommen und mal
schnell den Gehsteig abräumen oder ein paar Bäume ummmähen.
Ersetzt man Auto mit CPU, PS mit GHz und Kiist mit Speicher, ist das fast
direkt für "Consumer"-Computer zu lesen...
Und, bitte schön, _was_ sollen _die_ dann eigentlich mit dem EFI-Geraffel?
Die _sehen_ das doch nichtmal. Rausgeschissenes Geld und Aufwand.
> keine Shells dabei, mit denen sich die Leute dann womöglich noch die
> Kiste kaputtspielen und die dem Support am Telefon im Mumbai dann auch
> noch Kopfschmerzen bereiten.
Oooch - _der_ Support ist diesen "Nutzern" doch richtig gut angepasst. ];->
> Kaufst Du Dir einen richtigen Rechner aus der Serverecke, sieht das auch
> gleich schon wieder ganz anders aus.
Nnnjaa - aber halt nicht meinem "Geldbeutel"...
Davon abgesehen wüßte ich jetzt nichtmal, wo man was "aus der Serverecke"
als kleiner Programmierer überhaupt herkriegen könnte, unabhängig vom Preis.
> Der Hase. Und der liegt da, weil wie immer: You get what you pay for.
Nee, _das_ stimmt ja schon lange nicht mehr. Du zahlst immer öfter für
Sachen, die Du nie nutzen kannst, weil die andere kriegen. Manchmal kriegst
Du dafür Sachen (fast( umsonst, die Du eigentlich garnicht haben willst.
Die "Globalisierung" im Verein mit dem internet haben's möglich gemacht.
Aber _das_ ist ein anderes, weites Feld...
Message has been deleted
Andreas Hartmann
Apr 11, 2012, 4:22:28 AM4/11/12
to
Marcus Jodorf schrieb:
> Sieghard Schicktanz <Sieghard....@schs.de> schrieb:
[...]
>> Aber klar, das ist so wie bei den Autos - die Kiste muß riesengroß
>> sein, hunderte PS haben (damit sie schneller in die Botanik fligen,
>> dann ist der Entsorgungseffekt besser) und möglichst viele "Gadgets"
>> eingebaut haben, vor denen sioe dann nicht mehr zum Aufpassen aufs
>> Fahren kommen und mal schnell den Gehsteig abräumen oder ein paar
>> Bäume ummmähen.
>
> Du hast seltsame Vorurteile bzw. einfach eine sehr schräge Weltsicht.
Naja, ich versuche seinen Einwurf mal konstruktiv :-) aufzugreifen,
jedoch mit anderem Blickwinkel. Nicht aus Usersicht, sondern aus
Herstellersicht.
Vergegenwärtigt man sich, daß [U]EFI eigentlich schon einen Bart hat,
ist die Frage schon erlaubt, warum plötzlich jetzt UEFI im Consumermarkt
hoch kommt. Dem unbedarften User dürfte es ziemlich egal sein, der
Sicherheitsinteressierte dürfte ein neues Feature (Secure Boot - seit
UEFI 2.3.1) verlockend finden, dem richtig Bedarften und an seinem
Eigentum Interessierten dürfte das konkret angestrebte Handling dieses
Secure Boot-Features gar nicht schmecken - dafür vermutlich M$ und den
Hardwareherstellern um so mehr, weil sie endlich (!) die Möglichkeit
bekommen, die Kisten zu vernageln, um damit ein festes Bundle Hardware /
Software zu erstellen, dessen Einsatz / Verwendungszweck / Lifecycle
vollständig unter die Kontrolle des Keyeigentümers gestellt ist / werden
kann. Was das in letzter Konsequenz bedeutet, brauche ich ja hier
hoffentlich nicht weiter auszuführen.
Derzeit erzwingt M$ die Nichtabschaltbarkeit dieses Features seitens der
Hersteller "nur" bei ARM-basierten Geräten, bei der x86-Architektur wird
es dann nachgeschoben im Rahmen einer Salamitaktik (letzteres stellt
meine Meinung dar).
Gruß,
Andreas
> Sieghard Schicktanz <Sieghard....@schs.de> schrieb:
[...]
>> Aber klar, das ist so wie bei den Autos - die Kiste muß riesengroß
>> sein, hunderte PS haben (damit sie schneller in die Botanik fligen,
>> dann ist der Entsorgungseffekt besser) und möglichst viele "Gadgets"
>> eingebaut haben, vor denen sioe dann nicht mehr zum Aufpassen aufs
>> Fahren kommen und mal schnell den Gehsteig abräumen oder ein paar
>> Bäume ummmähen.
>
>
>> Ersetzt man Auto mit CPU, PS mit GHz und Kiist mit Speicher, ist das
>> fast direkt für "Consumer"-Computer zu lesen... Und, bitte schön,
>> _was_ sollen _die_ dann eigentlich mit dem EFI-Geraffel? Die _sehen_
>> das doch nichtmal. Rausgeschissenes Geld und Aufwand.
>
> Hat man Dich zufällig schon mal als seltsam oder verschroben bezeichnet?
>> Ersetzt man Auto mit CPU, PS mit GHz und Kiist mit Speicher, ist das
>> fast direkt für "Consumer"-Computer zu lesen... Und, bitte schön,
>> _was_ sollen _die_ dann eigentlich mit dem EFI-Geraffel? Die _sehen_
>> das doch nichtmal. Rausgeschissenes Geld und Aufwand.
>
Naja, ich versuche seinen Einwurf mal konstruktiv :-) aufzugreifen,
jedoch mit anderem Blickwinkel. Nicht aus Usersicht, sondern aus
Herstellersicht.
Vergegenwärtigt man sich, daß [U]EFI eigentlich schon einen Bart hat,
ist die Frage schon erlaubt, warum plötzlich jetzt UEFI im Consumermarkt
hoch kommt. Dem unbedarften User dürfte es ziemlich egal sein, der
Sicherheitsinteressierte dürfte ein neues Feature (Secure Boot - seit
UEFI 2.3.1) verlockend finden, dem richtig Bedarften und an seinem
Eigentum Interessierten dürfte das konkret angestrebte Handling dieses
Secure Boot-Features gar nicht schmecken - dafür vermutlich M$ und den
Hardwareherstellern um so mehr, weil sie endlich (!) die Möglichkeit
bekommen, die Kisten zu vernageln, um damit ein festes Bundle Hardware /
Software zu erstellen, dessen Einsatz / Verwendungszweck / Lifecycle
vollständig unter die Kontrolle des Keyeigentümers gestellt ist / werden
kann. Was das in letzter Konsequenz bedeutet, brauche ich ja hier
hoffentlich nicht weiter auszuführen.
Derzeit erzwingt M$ die Nichtabschaltbarkeit dieses Features seitens der
Hersteller "nur" bei ARM-basierten Geräten, bei der x86-Architektur wird
es dann nachgeschoben im Rahmen einer Salamitaktik (letzteres stellt
meine Meinung dar).
Gruß,
Andreas
Message has been deleted
Sieghard Schicktanz
Apr 11, 2012, 2:00:45 PM4/11/12
to
Hallo Marcus,
Du schriebst am Wed, 11 Apr 2012 17:17:19 +0200:
> > ist die Frage schon erlaubt, warum plötzlich jetzt UEFI im
> > Consumermarkt hoch kommt.
>
> Das 2,2 TB Limit von MBR Schemata dürfte da eine Rolle spielen.
Als Ausrede mit Sicherheit. Aber es hätte sicher auch andere Möglichkeiten
gegeben, leider nicht "in house". Und da schlägt wohl das NIH-Syndrom zu...
> 32 bit Partitionstabellen und 32 bit Firmware bei heutigen 64 bit CPUs
> und Plattengrößen sind auch einfach anachronistisch.
Naklar - größer, schneller, weiter...
In einer der Beschreibungen zu UEFI stand z.B., daß man bitteschön eine
_mindestens_ 400MByte große Partition dafür anlegen "müßte". Für die paar
Bytes, die der ganze Kram braucht, fast ein halbes Gigabyte verschleudern -
_das_ ist zeitgemäß!
> Und BIOS ist einfach grottig. Ich bin da früher mit PCI Karten schon in
> Konflikte gerannt und wenn ich mir anschaue, wieviele Komponenten so
Na, und was ist mit dem EFI-Geraffel? In welcher Hinsicht hilft Dir das?
Sag' jetzt nicht, daß das "universelle" Treiber zur Verfüguing stellte -
tut es doch nicht. Es _könnte_, im Prinzip. Aber da kommt schon wieder das
_wirklich_ universelle NIH-Syndrom: Hersteller Alpha hat einen UEFI-Treiber
für ein verbreitetes Gerät gebaut und stellt den zur Verfügung (natürlich
nicht den Source). Hersteller Berta meint, da müßte aber die Funktion
"blinkenlights" anders arbeiten, deswegen ist der unbrauchbar und wird mit
einem eigenen Treiber überfahren. Hersteller Castor - na, Du weißt wohl,
wie das weitergeht.
> manches Board heute mitbringt, fragt man sich schon länger, wann einem
> das alles um die Ohren fliegt.
Na, und was ist mit dem EFI-Geraffel? In welcher Hinsicht hilft Dir das?
> > Sicherheitsinteressierte dürfte ein neues Feature (Secure Boot - seit
> > UEFI 2.3.1) verlockend finden
>
> Sehr zweischneidiges Schwert. Einerseits setzt das etwas um, was sich
> viele schon immer gewünscht haben - andererseits hat man damit nat. das
> Mißbrauchspotential seitens gewisser Hersteller.
Genau. Und _das_ wird mit Sicherheit ausgenutzt.
> Aber grundsätzlich ist die Idee einer vernünftigen universellen Firmware
> ja gar nicht mal schlecht. Ob das jetzt ausgerechnet so wie bei EFI sein
Doch, die Idee _ist_ schlecht. Das hat schon beim PC nicht geklappt - das
BIOS sollte das doch bieten. Es ging für die ersten paar Versionen von Dos
einigermaßen, "lediglich" der Treiber für die serielle Schnittstelle was
dermaßen grauslig, daß da jeder seinen eigenen schrieb (ich mir auch).
Dann kamen der '286, der '386, und das BIOS war nur noch zum Laden des
Bootsektors brauchbar.
Und da willst Du für diese hochkomplexen Geräte, die PCs inzwischen sind,
_noch_ _mehr_ Funktionen in der Firmware?
> Ist ja im Grunde auch nur das, was man schon seit Urzeiten von
> OpenFirmware usw. kennt, mal in die PC Welt übertragen. Also absolut
> nichts Neues. Gab es eben früher nur bei den teuren Workstations, so daß
> das Normalos kaum zu sehen bekommen haben.
Bei den Workstations war die Geschichte aber auch eher auf Wartung und
Fehlersuche ausgelegt, und das auch noch evtl. als Fernwartung.
Gut, EFI könnte das auch, mit einer passenden Shell (die, die ich gefunden
habe, haben zwar dahingehend vielversprechende Programme, die aber eher
nicht funktionieren) - aber eben _nicht_ in Firmware.
Ich finde immer noch, daß ein Minimal-Lader im "ROM", modifizierbar mit
einer mitgelieferten Wartungssoftware auf einem Datenträger, eine bessere
Lösung wäre. Da könnte dann sogar eine "DAU"-Version gebaut werden, die
alles automatisch erkennt und einrichtet, ohne daß ein riesiger Flash-
Speicher eingebaut werden müßte.
> Die Technik ist nun mal vorhanden. Wie sie eingesetzt wird, entscheiden
> wie bei so vielen Sachen letztlich die Kunden oder der Gesetzgeber.
Wäre schön, wenn das so wäre. Es wird aber eher so laufen wie bei PCI/PCIe,
USB oder den "schönen" Breitbildschirmen: die Hersteller bauen einfach nix
anderes ein, weil ihnen dieser Kram von den "Monopolisten" diktiert wird,
und alle anderen Möglichkeiten fallen damit unter den Tisch, wo sie unter
dem Teppich verschwinden...
Du schriebst am Wed, 11 Apr 2012 17:17:19 +0200:
> > ist die Frage schon erlaubt, warum plötzlich jetzt UEFI im
> > Consumermarkt hoch kommt.
>
Als Ausrede mit Sicherheit. Aber es hätte sicher auch andere Möglichkeiten
gegeben, leider nicht "in house". Und da schlägt wohl das NIH-Syndrom zu...
> 32 bit Partitionstabellen und 32 bit Firmware bei heutigen 64 bit CPUs
> und Plattengrößen sind auch einfach anachronistisch.
Naklar - größer, schneller, weiter...
In einer der Beschreibungen zu UEFI stand z.B., daß man bitteschön eine
_mindestens_ 400MByte große Partition dafür anlegen "müßte". Für die paar
Bytes, die der ganze Kram braucht, fast ein halbes Gigabyte verschleudern -
_das_ ist zeitgemäß!
> Und BIOS ist einfach grottig. Ich bin da früher mit PCI Karten schon in
> Konflikte gerannt und wenn ich mir anschaue, wieviele Komponenten so
Na, und was ist mit dem EFI-Geraffel? In welcher Hinsicht hilft Dir das?
Sag' jetzt nicht, daß das "universelle" Treiber zur Verfüguing stellte -
tut es doch nicht. Es _könnte_, im Prinzip. Aber da kommt schon wieder das
_wirklich_ universelle NIH-Syndrom: Hersteller Alpha hat einen UEFI-Treiber
für ein verbreitetes Gerät gebaut und stellt den zur Verfügung (natürlich
nicht den Source). Hersteller Berta meint, da müßte aber die Funktion
"blinkenlights" anders arbeiten, deswegen ist der unbrauchbar und wird mit
einem eigenen Treiber überfahren. Hersteller Castor - na, Du weißt wohl,
wie das weitergeht.
> manches Board heute mitbringt, fragt man sich schon länger, wann einem
> das alles um die Ohren fliegt.
Na, und was ist mit dem EFI-Geraffel? In welcher Hinsicht hilft Dir das?
> > Sicherheitsinteressierte dürfte ein neues Feature (Secure Boot - seit
> > UEFI 2.3.1) verlockend finden
>
> viele schon immer gewünscht haben - andererseits hat man damit nat. das
> Mißbrauchspotential seitens gewisser Hersteller.
Genau. Und _das_ wird mit Sicherheit ausgenutzt.
> Aber grundsätzlich ist die Idee einer vernünftigen universellen Firmware
> ja gar nicht mal schlecht. Ob das jetzt ausgerechnet so wie bei EFI sein
Doch, die Idee _ist_ schlecht. Das hat schon beim PC nicht geklappt - das
BIOS sollte das doch bieten. Es ging für die ersten paar Versionen von Dos
einigermaßen, "lediglich" der Treiber für die serielle Schnittstelle was
dermaßen grauslig, daß da jeder seinen eigenen schrieb (ich mir auch).
Dann kamen der '286, der '386, und das BIOS war nur noch zum Laden des
Bootsektors brauchbar.
Und da willst Du für diese hochkomplexen Geräte, die PCs inzwischen sind,
_noch_ _mehr_ Funktionen in der Firmware?
> Ist ja im Grunde auch nur das, was man schon seit Urzeiten von
> OpenFirmware usw. kennt, mal in die PC Welt übertragen. Also absolut
> nichts Neues. Gab es eben früher nur bei den teuren Workstations, so daß
> das Normalos kaum zu sehen bekommen haben.
Bei den Workstations war die Geschichte aber auch eher auf Wartung und
Fehlersuche ausgelegt, und das auch noch evtl. als Fernwartung.
Gut, EFI könnte das auch, mit einer passenden Shell (die, die ich gefunden
habe, haben zwar dahingehend vielversprechende Programme, die aber eher
nicht funktionieren) - aber eben _nicht_ in Firmware.
Ich finde immer noch, daß ein Minimal-Lader im "ROM", modifizierbar mit
einer mitgelieferten Wartungssoftware auf einem Datenträger, eine bessere
Lösung wäre. Da könnte dann sogar eine "DAU"-Version gebaut werden, die
alles automatisch erkennt und einrichtet, ohne daß ein riesiger Flash-
Speicher eingebaut werden müßte.
> Die Technik ist nun mal vorhanden. Wie sie eingesetzt wird, entscheiden
> wie bei so vielen Sachen letztlich die Kunden oder der Gesetzgeber.
Wäre schön, wenn das so wäre. Es wird aber eher so laufen wie bei PCI/PCIe,
USB oder den "schönen" Breitbildschirmen: die Hersteller bauen einfach nix
anderes ein, weil ihnen dieser Kram von den "Monopolisten" diktiert wird,
und alle anderen Möglichkeiten fallen damit unter den Tisch, wo sie unter
dem Teppich verschwinden...
Hermann Jurksch
Apr 11, 2012, 1:12:00 PM4/11/12
to
tr...@killfile.de wrote:
>> Derzeit erzwingt M$ die Nichtabschaltbarkeit dieses Features seitens
>> der Hersteller "nur" bei ARM-basierten Geräten, bei der x86-Architektur
>> wird es dann nachgeschoben im Rahmen einer Salamitaktik (letzteres
>> stellt meine Meinung dar).
>> Derzeit erzwingt M$ die Nichtabschaltbarkeit dieses Features seitens
>> der Hersteller "nur" bei ARM-basierten Geräten, bei der x86-Architektur
>> wird es dann nachgeschoben im Rahmen einer Salamitaktik (letzteres
>> stellt meine Meinung dar).
> Die Technik ist nun mal vorhanden. Wie sie eingesetzt wird, entscheiden
> wie bei so vielen Sachen letztlich die Kunden oder der Gesetzgeber.
Dann sieht es traurig aus, denn die große Mehrzahl der Kunden würde sich
> wie bei so vielen Sachen letztlich die Kunden oder der Gesetzgeber.
über ein völlig vernageltes System sogar freuen, das gefühlte Sicherheit
bietet. Nur dürfte man in der Anfangsphase gewisse Programme, die zu
Urheberrechtsverletzungen eingesetzt werden können, keinen Restriktionen
unterwerfen, bis es keine Alternative zu einem DRM-UEFI mehr gibt.
Hilfe vom Gesetzgeber ist auch nicht zu erwarten, da Rechner unter
Kontrolle der Hersteller viel besser überwachbar sind.
MfG
Hermann
Sieghard Schicktanz
Apr 11, 2012, 2:52:47 PM4/11/12
to
Hallo Marcus,
Du schriebst am Wed, 11 Apr 2012 03:03:51 +0200:
> > sowohl den grub _für_ _dieses_ System in 32 Bit _für_ ein 64-Bit-BIOS
> Es gibt wie gesagt durchaus so komische Hardware, wo man sowas braucht.
Das sollte in der Kombination eigentlich garnicht funktionieren können, so
wie Du das dargestellt hast. Naja, tut es ja auch nicht richtig.
> > Es könnte auch mit einem EFI-Programm gehen, schließlich laufen die ja
...
> Es hat aber nun mal noch keiner eine frei EFI shell geschrieben, die das
> kann. Ich werde das nicht machen, Du machst es nicht und solange es
Na, das habe ich durchaus schon in Erwägung gezogen, wenn sonst nix zu
finden wäre - der Source vom efibootmanager ist ja verfügbar, einen EFI-
Bytecode-Compiler gibt's auch (ich weiß allerdings nicht, ob frei
erhältlich) - damit sollte man sowas doch bauen können.
> Hast Du halt das falsche System für den Zweck ;-)
Du meinst, Schadenfreude ist die reinste Freude? Ja, glaub' ich Dir ];->
> Kernelpaket einwerfen. Zum Beispiel dpkg -i linux-image-blah-amd64.deb
> und fertig.
Sorry, tut nicht. No Debian here. Muß ich anders machen. Gestern hab' ich
mir ein 64bit-grml 'runtergeladen - mal sehen...
> > Eigentlich würd's reichen, einen minimalen Lader in einen kleinen
> > Speicher auf der Karte zu packen, der bei Auslieferung einen USB-Stick
...
> Wär's eine wirklich gute Idee, würde man es vermutlich einfacher
> machen. Offenbar macht es aber nicht.
Werden gute Ideen wirklich immer umgesetzt? Ich bin da bisserl skeptisch...
> > Solche Leute brauchen aber keine dicken Prozessoren mit vier "Kernen"
> > und mehr und allem möglichen anderen Krimskrams
>
> Unsinn. Das sind immer die reinen Anwender, die die dicken Kisten
> brauchen.
Ja, klar. Die den ganzen Tag EMails und New-Postings schreiben (nee,
letzteres eher nicht, die hängen da eher mit ihrem Browser in allen
möglichen Foren) und sich in "sozialen Netzwerken" entblößen^Wergehen.
> brauchen. Das sind z.B. die Leute, die mit Gigabytes an Mediendateien
> rumhampeln und da nie genug Leistung haben können. Oder Physiker die
> Simulationen fahren, usw.
Letztere haben dazu Rechenzentren mit deren Spezialisten zur Verfügung,
> Als Admin bin ich dagegen z.B. schon mit dem Standard-Core i5 im Büro
> ziemlich übermotorisiert, aber es gibt ja praktisch nichts kleineres
Na, ich brauch' meine Kiste auch bloß zum Arbeiten - da ist der 4-Kerner
auch großartiger "Overkill". Eigentlich reicht mir meine alte Kiste immer
noch, und das nach 10 Jahren, die sie in ähnlicher Form in Betrieb ist
(mit ein paar Austauschteilen;).
> > Fahren kommen und mal schnell den Gehsteig abräumen oder ein paar
> > Bäume ummmähen.
>
Pampa" vor einiger Zeit: 500PS-SUV schießt durch ein paar Bäume und schlägt
dabei den Insassen die Köpfe ein. Dabei war das nichtmal ein richtig
gefährliches Straßenstück, nur bisserl unübersichtlich.
> Hat man Dich zufällig schon mal als seltsam oder verschroben bezeichnet?
Nee, eigentlich nicht - aber ich weiß selber, daß ich nicht grade im
"Mainstream" liege. Aber gut daß Du das sagst, da weiß ich wenigstens, daß
der Kurs stimmt. ;-)
> > Davon abgesehen wüßte ich jetzt nichtmal, wo man was "aus der
> > Serverecke" als kleiner Programmierer überhaupt herkriegen könnte,
> > unabhängig vom Preis.
>
> HP, Dell, IBM, etc., pp.
Liegen mir nicht. Ich _will_ auch keinen Mercedes fahren.
> Die verkaufen einem das Zeug ganz einfach, wenn man danach fragt. Ich
> hab hier z.B. einen schnuckeligen kleinen Dual-Hexacore-Xeon von Dell
Dell ist doch schon Consumer, HP inzwischen auch. Gut, "Besseres" gibt's von
denen auch, zu überproportional höheren Preisen. IBM ist doch nur noch
Vertrieb oder "Mainframe".
> letztens noch in Gang gebracht, der von der Firmwareseite her durchaus
> komfortabel herkommt. Dazu noch ein DRAC (remote access controller mit
Ich bin aber kein Administrator, sondern Software"produzent", und mein
Rechenzentrum besteht aus einem Desktop-PC und einem Notebook, das für die
Inbetriebnahmen herhalten muß.
> > Nee, _das_ stimmt ja schon lange nicht mehr. Du zahlst immer öfter für
> > Sachen, die Du nie nutzen kannst, weil die andere kriegen. Manchmal
...
> das nennt sich Fatalismus, falls ich recht erinnere.
Nee, das ist _wieder_ eine andere Schiene.
Du schriebst am Wed, 11 Apr 2012 03:03:51 +0200:
> > sowohl den grub _für_ _dieses_ System in 32 Bit _für_ ein 64-Bit-BIOS
Das sollte in der Kombination eigentlich garnicht funktionieren können, so
wie Du das dargestellt hast. Naja, tut es ja auch nicht richtig.
> > Es könnte auch mit einem EFI-Programm gehen, schließlich laufen die ja
> Es hat aber nun mal noch keiner eine frei EFI shell geschrieben, die das
> kann. Ich werde das nicht machen, Du machst es nicht und solange es
Na, das habe ich durchaus schon in Erwägung gezogen, wenn sonst nix zu
finden wäre - der Source vom efibootmanager ist ja verfügbar, einen EFI-
Bytecode-Compiler gibt's auch (ich weiß allerdings nicht, ob frei
erhältlich) - damit sollte man sowas doch bauen können.
> Hast Du halt das falsche System für den Zweck ;-)
Du meinst, Schadenfreude ist die reinste Freude? Ja, glaub' ich Dir ];->
> Kernelpaket einwerfen. Zum Beispiel dpkg -i linux-image-blah-amd64.deb
> und fertig.
Sorry, tut nicht. No Debian here. Muß ich anders machen. Gestern hab' ich
mir ein 64bit-grml 'runtergeladen - mal sehen...
> > Eigentlich würd's reichen, einen minimalen Lader in einen kleinen
> > Speicher auf der Karte zu packen, der bei Auslieferung einen USB-Stick
> Wär's eine wirklich gute Idee, würde man es vermutlich einfacher
> machen. Offenbar macht es aber nicht.
Werden gute Ideen wirklich immer umgesetzt? Ich bin da bisserl skeptisch...
> > Solche Leute brauchen aber keine dicken Prozessoren mit vier "Kernen"
> > und mehr und allem möglichen anderen Krimskrams
>
> brauchen.
Ja, klar. Die den ganzen Tag EMails und New-Postings schreiben (nee,
letzteres eher nicht, die hängen da eher mit ihrem Browser in allen
möglichen Foren) und sich in "sozialen Netzwerken" entblößen^Wergehen.
> brauchen. Das sind z.B. die Leute, die mit Gigabytes an Mediendateien
> rumhampeln und da nie genug Leistung haben können. Oder Physiker die
> Simulationen fahren, usw.
Letztere haben dazu Rechenzentren mit deren Spezialisten zur Verfügung,
> Als Admin bin ich dagegen z.B. schon mit dem Standard-Core i5 im Büro
> ziemlich übermotorisiert, aber es gibt ja praktisch nichts kleineres
Na, ich brauch' meine Kiste auch bloß zum Arbeiten - da ist der 4-Kerner
auch großartiger "Overkill". Eigentlich reicht mir meine alte Kiste immer
noch, und das nach 10 Jahren, die sie in ähnlicher Form in Betrieb ist
(mit ein paar Austauschteilen;).
> > Fahren kommen und mal schnell den Gehsteig abräumen oder ein paar
> > Bäume ummmähen.
>
> Du hast seltsame Vorurteile bzw. einfach eine sehr schräge Weltsicht.
Nur Erfahrungen - sowas kommt "öfters" vor. Sogar hier bei uns "in der
Pampa" vor einiger Zeit: 500PS-SUV schießt durch ein paar Bäume und schlägt
dabei den Insassen die Köpfe ein. Dabei war das nichtmal ein richtig
gefährliches Straßenstück, nur bisserl unübersichtlich.
> Hat man Dich zufällig schon mal als seltsam oder verschroben bezeichnet?
"Mainstream" liege. Aber gut daß Du das sagst, da weiß ich wenigstens, daß
der Kurs stimmt. ;-)
> > Davon abgesehen wüßte ich jetzt nichtmal, wo man was "aus der
> > Serverecke" als kleiner Programmierer überhaupt herkriegen könnte,
> > unabhängig vom Preis.
>
Liegen mir nicht. Ich _will_ auch keinen Mercedes fahren.
> Die verkaufen einem das Zeug ganz einfach, wenn man danach fragt. Ich
> hab hier z.B. einen schnuckeligen kleinen Dual-Hexacore-Xeon von Dell
Dell ist doch schon Consumer, HP inzwischen auch. Gut, "Besseres" gibt's von
denen auch, zu überproportional höheren Preisen. IBM ist doch nur noch
Vertrieb oder "Mainframe".
> letztens noch in Gang gebracht, der von der Firmwareseite her durchaus
> komfortabel herkommt. Dazu noch ein DRAC (remote access controller mit
Ich bin aber kein Administrator, sondern Software"produzent", und mein
Rechenzentrum besteht aus einem Desktop-PC und einem Notebook, das für die
Inbetriebnahmen herhalten muß.
> > Nee, _das_ stimmt ja schon lange nicht mehr. Du zahlst immer öfter für
> > Sachen, die Du nie nutzen kannst, weil die andere kriegen. Manchmal
> das nennt sich Fatalismus, falls ich recht erinnere.
Nee, das ist _wieder_ eine andere Schiene.
Sieghard Schicktanz
Apr 14, 2012, 5:15:55 PM4/14/12
to
Na also - es geht ja doch.
Wenn auch mit Hängen und Würgen und hinterlistigen Tricks, jetzt habe ich
doch einen Eintrag für des EFI-Boot-Gewürge hingekriegt.
Grundsätzlich: es geht _nicht_, wenn irgendwas noch 32-bittiges dabei ist,
bei einem 64-Bit-EFI-Board den Eintrag zu machen. Auch nicht mit Linux.
Ich hatte mir dazu das neueste (64-Bit-) grml besorgt.
Weil ich kein SATA-CD-Laufwerk habe, auf USB-Stick kopiert. Ausporbiert,
läuft einwandfrei.
Dann zunächst normal gebootet versucht, das Platten-System einzutragen.
Geht nicht, weil der Stick im "legacy"-Modus gebootet wird, und da kein EFI
vorhanden ist. Nein, es gibt nichtmal die Variablen, das Modul "efivars"
funktioniert da einfach nicht, auch wenn es ohne Fehlermeldung (!) geladen
wird.
Dann den Kernel rauskopiert und mein System damit gebootet. grub-install
gemacht, genau analysiert, was abläuft. Alles schien in Ordnung, es _wurde_
(nach einiger Sucherei) mit den richtigen Angaben auch der efibootmantscher
aufgerufen, mit plausiblen (und tatsächlich auch richtigen) Argumenten.
Nur: es ging nicht.
Diesmal _waren_ die EFI-Variablen mit dem Modul da, der efibootmanager
schien auch richtig zu laufen, aber es gab keinen Eintrag.
D.h. _nur_ ein 32-Bit-Kernel reicht _nicht_.
So, wie krieg' ich jetzt ein 64-Bit-System mit EFI-Boot ans Laufen, wenn
der Stick das nicht macht?
Idee: ich hab' ja noch eine Swap-Partition (für's Überwintern [hibernate]),
die ließe sich ja temporär zweckentfremden. Also swap ausschalten, grml-ISO
auf Partition kopieren, schauen ob das EFI-Zeugs die Partition findet.
"Natürlich" nicht.
Also tiefer gebohrt: Partition gemountet (Linux kann das ja ohne Problem)
und EFI-Boot von der "ISO"-Partition auf die EFI-Partition geschaufelt.
Booten in die EFI-Shell, grml-grub gestartet - es kommt tatsächlich ein
Menü, wenn auch nicht so schön grafisch mit Hintergrundbild wie direkt,
aber mit den richtigen Einträgen. grml gestartet, Kernel wird geladen,
sucht sein System - und findet das tatsächlich, obwohl die Partition wo
ganz anders liegt. grml läuft.
So, jetzt das weitere wie gehabt: EFI-Variablen mit Modul zugänglich
machen, efibootmanager mit dem Aufruf starten, der vorher vom grub-install
vergeblich gemacht wurde. Läuft ohne Fehler und - gibt erstmals "Laut",
eine Liste der gemachten Einträge. EFI-Variablen unter /sys inspiziert: es
existiert tatsächlich ein neuer Eintrag!
Also: Reboot. Einfach laufen lassen, sollte ja den EFI-grub starten, der
vorher von der Shell aus lief. Und es funktioniert!
Also Fazit: Es ist _unbedingt_ nötig, daß _alle_ Programme, die beim
Einrichten eines EFI-Boots direkt mit EFI zu tun haben, mit der _gleichen_
Architektur gebaut sind wie das EFI-Zeugs selber.
Alles, was _nicht_ direkt mit EFI arbeitet, kann auch anders laufen, also
wie bei mir das Installieren des grub in die EFI-Partition mit 32-Bit-
Programmen, soweit es nicht den Botte-Eintrag bei EFI betrifft. _Dieser_
Schritt _muß_ mit einem _vollständig_ 64-bittigen System gemacht werden!
(Daß ich mir bei dne Tests des EFI-Zeugs mit EFI-eigenen Programmen auch
mal total "abgeschossen" habe, so daß es nicht mal mehr in die
EInstellungen starten konnte und ich das NVRAM löschen mußte, möchte ich
nur am Rande erwähnen. Das Zeug ist eben schon zu komplex, als daß es noch
wirklich zuverlässig sein könnte. Glücklicherweise hat das Board eine
entsprechende Einrichtung, wenn das nicht vorgesehen wäre oder die
EFI-Variablen sogar in einem EEPROM abgelegt wären, wär' hier "Ende der
Fahnenstange" gewesen - sozusagen Hardware-Defekt durch Software-Fehler...)
Wenn auch mit Hängen und Würgen und hinterlistigen Tricks, jetzt habe ich
doch einen Eintrag für des EFI-Boot-Gewürge hingekriegt.
Grundsätzlich: es geht _nicht_, wenn irgendwas noch 32-bittiges dabei ist,
bei einem 64-Bit-EFI-Board den Eintrag zu machen. Auch nicht mit Linux.
Ich hatte mir dazu das neueste (64-Bit-) grml besorgt.
Weil ich kein SATA-CD-Laufwerk habe, auf USB-Stick kopiert. Ausporbiert,
läuft einwandfrei.
Dann zunächst normal gebootet versucht, das Platten-System einzutragen.
Geht nicht, weil der Stick im "legacy"-Modus gebootet wird, und da kein EFI
vorhanden ist. Nein, es gibt nichtmal die Variablen, das Modul "efivars"
funktioniert da einfach nicht, auch wenn es ohne Fehlermeldung (!) geladen
wird.
Dann den Kernel rauskopiert und mein System damit gebootet. grub-install
gemacht, genau analysiert, was abläuft. Alles schien in Ordnung, es _wurde_
(nach einiger Sucherei) mit den richtigen Angaben auch der efibootmantscher
aufgerufen, mit plausiblen (und tatsächlich auch richtigen) Argumenten.
Nur: es ging nicht.
Diesmal _waren_ die EFI-Variablen mit dem Modul da, der efibootmanager
schien auch richtig zu laufen, aber es gab keinen Eintrag.
D.h. _nur_ ein 32-Bit-Kernel reicht _nicht_.
So, wie krieg' ich jetzt ein 64-Bit-System mit EFI-Boot ans Laufen, wenn
der Stick das nicht macht?
Idee: ich hab' ja noch eine Swap-Partition (für's Überwintern [hibernate]),
die ließe sich ja temporär zweckentfremden. Also swap ausschalten, grml-ISO
auf Partition kopieren, schauen ob das EFI-Zeugs die Partition findet.
"Natürlich" nicht.
Also tiefer gebohrt: Partition gemountet (Linux kann das ja ohne Problem)
und EFI-Boot von der "ISO"-Partition auf die EFI-Partition geschaufelt.
Booten in die EFI-Shell, grml-grub gestartet - es kommt tatsächlich ein
Menü, wenn auch nicht so schön grafisch mit Hintergrundbild wie direkt,
aber mit den richtigen Einträgen. grml gestartet, Kernel wird geladen,
sucht sein System - und findet das tatsächlich, obwohl die Partition wo
ganz anders liegt. grml läuft.
So, jetzt das weitere wie gehabt: EFI-Variablen mit Modul zugänglich
machen, efibootmanager mit dem Aufruf starten, der vorher vom grub-install
vergeblich gemacht wurde. Läuft ohne Fehler und - gibt erstmals "Laut",
eine Liste der gemachten Einträge. EFI-Variablen unter /sys inspiziert: es
existiert tatsächlich ein neuer Eintrag!
Also: Reboot. Einfach laufen lassen, sollte ja den EFI-grub starten, der
vorher von der Shell aus lief. Und es funktioniert!
Also Fazit: Es ist _unbedingt_ nötig, daß _alle_ Programme, die beim
Einrichten eines EFI-Boots direkt mit EFI zu tun haben, mit der _gleichen_
Architektur gebaut sind wie das EFI-Zeugs selber.
Alles, was _nicht_ direkt mit EFI arbeitet, kann auch anders laufen, also
wie bei mir das Installieren des grub in die EFI-Partition mit 32-Bit-
Programmen, soweit es nicht den Botte-Eintrag bei EFI betrifft. _Dieser_
Schritt _muß_ mit einem _vollständig_ 64-bittigen System gemacht werden!
(Daß ich mir bei dne Tests des EFI-Zeugs mit EFI-eigenen Programmen auch
mal total "abgeschossen" habe, so daß es nicht mal mehr in die
EInstellungen starten konnte und ich das NVRAM löschen mußte, möchte ich
nur am Rande erwähnen. Das Zeug ist eben schon zu komplex, als daß es noch
wirklich zuverlässig sein könnte. Glücklicherweise hat das Board eine
entsprechende Einrichtung, wenn das nicht vorgesehen wäre oder die
EFI-Variablen sogar in einem EEPROM abgelegt wären, wär' hier "Ende der
Fahnenstange" gewesen - sozusagen Hardware-Defekt durch Software-Fehler...)
Andreas Hartmann
Apr 15, 2012, 5:31:01 AM4/15/12
to
Hallo Sieghard,
Sieghard Schicktanz schrieb:
Gratulation! Ist aber nicht weiter verwunderlich, wenn man sich Linus zu
dem Thema reinzieht [1].
Aber das Ganze hat auch was Positives: Du bist jetzt um Einiges
schlauer, da Du Dich im Detail mit der Thematik auseinandersetzen durftest.
Gruß,
Andreas
[1] http://thread.gmane.org/gmane.linux.kernel/1058560/focus%3D1152467
Sieghard Schicktanz schrieb:
> Na also - es geht ja doch.
[Gewürge nach eigener Einschätzung :-)]
Gratulation! Ist aber nicht weiter verwunderlich, wenn man sich Linus zu
dem Thema reinzieht [1].
Aber das Ganze hat auch was Positives: Du bist jetzt um Einiges
schlauer, da Du Dich im Detail mit der Thematik auseinandersetzen durftest.
Gruß,
Andreas
[1] http://thread.gmane.org/gmane.linux.kernel/1058560/focus%3D1152467
Sieghard Schicktanz
Apr 15, 2012, 1:17:08 PM4/15/12
to
Hallo Andreas,
Du schriebst am Sun, 15 Apr 2012 11:31:01 +0200:
> [Gewürge nach eigener Einschätzung :-)]
>
> Gratulation! Ist aber nicht weiter verwunderlich, wenn man sich Linus zu
> dem Thema reinzieht [1].
Danke, aber sowas kann ich einfacher haben - als Software-Entwickler für
Anlagen- und Gerätesteuerungen ist das im "Berufsbild" inbegriffen.
> Aber das Ganze hat auch was Positives: Du bist jetzt um Einiges
> schlauer, da Du Dich im Detail mit der Thematik auseinandersetzen
> durftest.
Was meinst Du eigentlich, _warum_ ich das überhaupt soweit durchgezogen
habe? Nur aus "Spaß an der Freud'"? Nee, _das_ sicher nicht, sondern eben
_weil_ ich lernen wollte, was da alles abläuft und wie man dem beikommen
kann.
Und das Bild, das sich daraus ergibt, ist leider äußerst traurig: Gängelei
an allen Ecken und Enden, und auch die sonst doch immer so "aufmüpfigen"
Linuxer trotte(l)n brav an der Kette mit...
Ich muß - wenn ich in ein paar Wochen, nebenher, die Kiste endlich "fertig"
eingerichtet hab' - wohl doch mal schauen, ob man da nicht dasselbe, was
der völlig überkandidelt so benamste "efibootmanager" macht, nicht mit ein
paar Konsolbefehlen oder einem kleinen Skriptchen genauso erledigen kann.
_Eigentlich_ sollten die Möglichkeiten des "efivars"-Moduls ausreichen.
Das direkt in ein EFI-Programm zu "gießen" hab' ich aber - eben wegen dem
Modul, das die Hauptarbeit zu machen scheint - erstmal wieder aufgegeben...
Du schriebst am Sun, 15 Apr 2012 11:31:01 +0200:
> [Gewürge nach eigener Einschätzung :-)]
>
> Gratulation! Ist aber nicht weiter verwunderlich, wenn man sich Linus zu
> dem Thema reinzieht [1].
Anlagen- und Gerätesteuerungen ist das im "Berufsbild" inbegriffen.
> Aber das Ganze hat auch was Positives: Du bist jetzt um Einiges
> schlauer, da Du Dich im Detail mit der Thematik auseinandersetzen
> durftest.
habe? Nur aus "Spaß an der Freud'"? Nee, _das_ sicher nicht, sondern eben
_weil_ ich lernen wollte, was da alles abläuft und wie man dem beikommen
kann.
Und das Bild, das sich daraus ergibt, ist leider äußerst traurig: Gängelei
an allen Ecken und Enden, und auch die sonst doch immer so "aufmüpfigen"
Linuxer trotte(l)n brav an der Kette mit...
Ich muß - wenn ich in ein paar Wochen, nebenher, die Kiste endlich "fertig"
eingerichtet hab' - wohl doch mal schauen, ob man da nicht dasselbe, was
der völlig überkandidelt so benamste "efibootmanager" macht, nicht mit ein
paar Konsolbefehlen oder einem kleinen Skriptchen genauso erledigen kann.
_Eigentlich_ sollten die Möglichkeiten des "efivars"-Moduls ausreichen.
Das direkt in ein EFI-Programm zu "gießen" hab' ich aber - eben wegen dem
Modul, das die Hauptarbeit zu machen scheint - erstmal wieder aufgegeben...
Andreas Hartmann
Apr 15, 2012, 3:55:29 PM4/15/12
to
Hallo Sieghard,
Sieghard Schicktanz schrieb:
[EFI]
Sieghard Schicktanz schrieb:
> Und das Bild, das sich daraus ergibt, ist leider äußerst traurig: Gängelei
> an allen Ecken und Enden, und auch die sonst doch immer so "aufmüpfigen"
> Linuxer trotte(l)n brav an der Kette mit...
tun?), bald nicht mehr. Die Linuxer haben doch schlußendlich im
Desktop-Markt nichts zu melden. Die Musik spielt woanders. Da müßte
schon die europäische Politik einspringen.
Gruß,
Andreas
Sieghard Schicktanz
Apr 15, 2012, 6:54:35 PM4/15/12
to
Hallo Andreas,
Du schriebst am Sun, 15 Apr 2012 21:55:29 +0200:
> [EFI]
MS allein, da mischt ja eigentlich intel federführend mit. Man muß halt
hoffen, daß die den Markt für Linux nicht verlieren wollen - und der ist
nicht so klein, wie er vom Schreibtisch (Desktop) aus aussieht. Da ist in
der letzten Zeit einiges "nachgewachsen" in der Industrie, wo sich MS eher
'rausgehalten hat (war ihnen wohl zu kompliziert). Seit WinCE ist da nicht
viel gelaufen, XP embedded findet sich nicht so häufig, wohl wegen der
Anforderungen, und erst W8 soll wieder "embeddable" werden, was aber noch
ein, zwei Jahre dauern wird. Inzwischen müssen aber die Geräte gebaut
werden und laufen, bleibt also - neben den teuren Spezialsystemen - nur
Linux.
> tun?), bald nicht mehr. Die Linuxer haben doch schlußendlich im
> Desktop-Markt nichts zu melden. Die Musik spielt woanders. Da müßte
Richtig, die Musik spielt woanders, und das gefällt MS auch nicht. Aber
wenn die den Desktop-Markt vernageln (wollen), riskieren sie u.U., anderswo
komplett 'rauszufallen. Und auch bei den Desktöppen sind die Benutzer
allmählich die "Zicken" leid, die ihnen der Marktführer mit jeder neuen
Systemgeneration bietet.
> schon die europäische Politik einspringen.
Naja, wo _die_ hinspringt... wennde 'nen großen Pott voll $$ oder EUR
hinstellst, vielleicht. Da müßte schon ganz Europa geschlossen vor der Tür
stehen, oder besser die schon eingetreten haben...
Du schriebst am Sun, 15 Apr 2012 21:55:29 +0200:
> [EFI]
> > "aufmüpfigen" Linuxer trotte(l)n brav an der Kette mit...
>
> Falls M$ den Deckel irgendwann zu macht (warum sollten sie das nicht
> tun?), bald nicht mehr.
Nee, dann überhaupt nicht mehr. Allerdings ist EFI glücklicherweise nicht
>
> Falls M$ den Deckel irgendwann zu macht (warum sollten sie das nicht
> tun?), bald nicht mehr.
MS allein, da mischt ja eigentlich intel federführend mit. Man muß halt
hoffen, daß die den Markt für Linux nicht verlieren wollen - und der ist
nicht so klein, wie er vom Schreibtisch (Desktop) aus aussieht. Da ist in
der letzten Zeit einiges "nachgewachsen" in der Industrie, wo sich MS eher
'rausgehalten hat (war ihnen wohl zu kompliziert). Seit WinCE ist da nicht
viel gelaufen, XP embedded findet sich nicht so häufig, wohl wegen der
Anforderungen, und erst W8 soll wieder "embeddable" werden, was aber noch
ein, zwei Jahre dauern wird. Inzwischen müssen aber die Geräte gebaut
werden und laufen, bleibt also - neben den teuren Spezialsystemen - nur
Linux.
> tun?), bald nicht mehr. Die Linuxer haben doch schlußendlich im
> Desktop-Markt nichts zu melden. Die Musik spielt woanders. Da müßte
wenn die den Desktop-Markt vernageln (wollen), riskieren sie u.U., anderswo
komplett 'rauszufallen. Und auch bei den Desktöppen sind die Benutzer
allmählich die "Zicken" leid, die ihnen der Marktführer mit jeder neuen
Systemgeneration bietet.
> schon die europäische Politik einspringen.
hinstellst, vielleicht. Da müßte schon ganz Europa geschlossen vor der Tür
stehen, oder besser die schon eingetreten haben...
0 new messages