Hi RapaNui,
bitte möglichst auf Kommentare im Quelltext verzichten. Für Hinweise gibt es die Hinweisbox oder auch Expertenbox.
Gruss Lasall
Ehemalige
Anmeldungsdatum: Beiträge: 7723 |
Hi RapaNui, bitte möglichst auf Kommentare im Quelltext verzichten. Für Hinweise gibt es die Hinweisbox oder auch Expertenbox. Gruss Lasall |
Anmeldungsdatum: Beiträge: 3271 |
Nochmal zur Klarstellung: ich habe die Kommandos auf einem realen System benutzt (ThinkPad X220). Die Fragestellung ob man die Partition angeben muss, werde ich noch prüfen – extra für Euch mach ich eine Testplatte in die Ultrabay 😉. Grundsätzlich bin ich das Ansicht, dass virtuelle Testsysteme eine valide und oftmals wesentlich effizientere Alternative zu physischen Systemen sind. In der professionellen IT kommt man schon lange nicht mehr ohne aus; extrem hardwarebezogene Tests natürlich ausgenommen. Daher schau ich mir dasselbe Szenario auch nochmal unter Virtualbox an und vergleiche. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1925 Wohnort: Penco / Chile |
Danke linrunner für Deine weitere Mithilfe. Ich sehe das mit dem virt. System genauso, egal ob installiert, virtuell oder von Live, alle drei Systeme greifen auf den "realen" NVRAM des EFI-Board zu. Im Endeffekt ist das aber eine Entscheidung des Wikiteams. Nochmals zu Deiner verkürzten Form des Befehls: Den könnte man sogar noch stärker verkürzen, u.a. durch Nutzung der Kurzoptionen, ich sehe darin aber keinen Vorteil. a) Die Beispiele sollen eben Beispiele liefern und nicht nur eine verkürzte Form eines Standartaufrufs darstellen. Man soll sie interpretieren und nachvollziehen können, daher auch die erweiterte Erklärung danach. Ich sehe das Wiki eben nicht nur als schnellen Befehlslieferant für das Supporten. b) Wenn Du im Netz nach diesem Befehl suchst bekommst Du fast ausschließlich diese lange Form vorgeschlagen. Daher auch meine Langform, um nicht zu viel Verwirrung zu stiften. Ja, es gibt hardcodierte Standartwerte (z.B. elilo, /dev/sda, 1. Part.) auf die man verzichten kann, aber das sollte jeder selber aus den Beispielen erkennen und für sich umsetzten können - copy&paste ist auch so möglich.
Ich wusste erst garnicht was Du damit meintest - jetzt mittlerweile ja. Das sollte eigtl. weniger ein interner Kommentar sein als eine vorläufige Hilfestellung für mich, da ich noch weiter nach efivars geforscht habe (und dann vergessen zu löschen). Also es sieht so aus, dass die aktuellen Kernelversionen bei einem EFI-Boot dieses Modul autom. laden. Erstellet wurde es von wohl bei Dell Copyright (C) 2001,2003,2004 Dell <Matt_Domsch@dell.com> Dieses Modul stellte die Variablen des NVRAM mittels dem virt. Kernelfilesystem SysFS zur Verfügung. http://lkml.org/lkml/2011/7/21/368 Das laden des Moduls ist daher nicht mehr zwingend, daher die Umstellung des 1. Hinweises. Ist es nicht geladen erfolgt ein Hinweis darauf.
|
Anmeldungsdatum: Beiträge: 3271 |
So, da bin ich wieder. Zuallerst muss der Loader richtig grubx64.efi statt falsch grubx86.efi heißen, ich hab's gleich korrigiert bevor sich das noch festsetzt. Resultat des Tests (physische HW): --disk, --part müssen angegeben werden, sofern nicht die Defaults passen. Mein minimales Kommando war sudo efibootmgr --create --disk /dev/sda --part 4 --label "Uu-Wiki-Test" --loader '\EFI\ubuntu\grubx64.efi' Virtuell hab ich heute keine Lust mehr zu ... 😉 EDITH: sowohl auf meinem Test- als auch auf dem Produktivsystem (beide 12.04) gibt es das Modul efivars nicht
und das liegt daran, dass das Modul fest einkompiliert wird per
ansonsten würde da "m" stehen. Geprüft für Oneiric- und Precise-Kernel, alles ältere dürfte eh nicht interessieren. Fazit: nimm efivars ganz raus. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1925 Wohnort: Penco / Chile |
Danke, aber leider hast Du die Kommandozeile vergessen ☹ - habs geändert. (Da ich mir nicht sicher war, hatte ich die Einleitung dazu mit ..., hier mit dem Namen
Wird wohl auch nicht mehr nötig sein, das es ja im realen 😉 System getestet wurde.
Stimmt also mit meiner Aussage im obigen Post überein - Relikt aus den Anfängen zu efibootmgr. |
Anmeldungsdatum: Beiträge: 5106 |
|
Anmeldungsdatum: Beiträge: 5106 |
Ich dachte eigentlich, dass das die Plattform angibt, meine das auch schon so gelesen zu haben, habe es selbst aber noch nicht verifziert. Gruß, Martin |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1925 Wohnort: Penco / Chile |
Die Angabe der Bootoption gehört sicherlich dorthin. Das folgende ist zwar aus dem gelöschten Teil (wir hatte uns wohl überschnitten), aber ich möchte darauf nochmals kurz eingehen
Auf https://help.ubuntu.com/community/UEFIBooting oder auch im Forenbereich bei http://ubuntuforums.org wird immer mal wieder auf efivars verwiesen. Da ich nicht weiß seid welcher Kernelversion das integriert ist habe ich es im Hinweistext in (KLAMMERN) gesetzt. Wenn denn eine Fehlermeldung ausgegeben wird, so lautet sie: Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables. Try 'modprobe efivars' as root. Diese beeinhaltet natürlich nicht nur einen Hinweis auf efivars, sondern auch auf ein evtl. nicht gemountetes procfs oder ein sysfs. Letzeres ist erst seid der Kernelversion 2.6.31 (ab 2.6.34 funktionell) integriert. Man muss also verschiedene Sachen im Hinterkopf behalten, wenn man auf diese Fehlermeldung stösst.
Der kann wohl verschiedene Namen haben, je Plattform und/oder je Installationsart (theoretisch kann man den auch nach Wahl umbenennen). Hier geht man von [MOUNTPOINT]/efi/boot/ als bootx64.efi aus, wie aber am Ende der Installer, genauer der grub-mkimage, das Image erzeugt bzw. benennt kann ich Dir leider nicht sagen (auch nicht, ob es sich dann um ein portables Image oder ein fest verdrahtetes handelt) . Da man auch zukünftige Änderungen am Namen nicht ausschließen kann, hatte ich eben dieses Beispiel mit In diesem Beispiel wird ein neuer Eintrag für einen Bootloader, hier mit dem Namen grubx86.efi, im NVRAM des EFI hinterlegt: - nun geändert auf grubx64.efi - eingeleitet. Das "hier mit dem Namen" sollte eigtl. auf den im Beispiel genutzten Namen hinweisen (nicht unbedingt der wirklich genutze) |
Anmeldungsdatum: Beiträge: 3271 |
Du hältst aber hartnäckig an Dingen fest die für Ubuntu nicht gelten: efivars ist auch in Natty und sogar in Lucid(!) fest einkompiliert → bitte weg damit! 😀 @Newubunti: \EFI\ubuntu\grubx64.efi ist nunmal der Bootloader den die Ubuntu-Installation automatisch erzeugt (@RapaNui: sollte im Artikel erwähnt werden). Daher ist das hier genau richtig als Beispiel. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1925 Wohnort: Penco / Chile |
Es geht nicht um die Hartnäckigkeit, sondern darum dass ich es nicht weiß/wußte und mich daher auf die engl. Seite von/zu Ubuntu bezogen habe. Es wird immer gefordert, möglichst alle noch gültigen Ubuntus abzudecken und das habe ich versucht (Hardy-Server noch bis Apr. 2013). Es war nur ein Hinweis und damit dürfte dieses Thema wohl erledigt sein 😉
Newubunti hat sich dazu noch nicht gemeldet, aber ich denke er wird sagen "Das gehört dann in die Installation unter Grub" und da bin ich seiner Meinung. Hier im Artikel wird das PGM selbst beschrieben und ist auf die derzeit aktuelle Situation in den Beispielen abgestellt. Danke für Deine Mithilfe und die Klärungen |
Anmeldungsdatum: Beiträge: 3271 |
Vielleicht sollte man genau das noch klarstellen: efibootmgr erzeugt nur einen Verweis im NVRAM auf einen bereits anderweitig installierten Bootloader. Leider fehlt EFI ja noch in GRUB 2/Installation. ps. der Hardy-Kernel kennt gar kein CONFIG_EFI_VARS ... 😛 |
(Themenstarter)
Anmeldungsdatum: Beiträge: 1925 Wohnort: Penco / Chile |
Vorschläge? Der Eingangstext geht da evtl. nicht klar genug drauf ein
Danke! |
Anmeldungsdatum: Beiträge: 5106 |
Das habe ich bisher auch schon gemerkt, nur habe ich das bis jetzt ausschließlich mit der amd64-CD gestestet. Von daher sprach das noch nicht gegen das, was ich bis dahin gelesen hatte. Mir ist gerade eben erst aufgefallen, dass die Ubuntu-x86-CD gar keine Hybrid-CD ist. Ob die sich auf andere Weise - eventuell mit Kernel-Optionen so starten lässt, weiß ich noch nicht. Ich habe gar nichts gegen \EFI\ubuntu\grubx64.efi. Es war ja nur eine Anmerkung meinerseits, dass ich das bisher so gelesen hatte. Was man liest, muss ja nicht stimmen, weil es häufig von anderen Distributionen stammt oder einer vom anderen ohne weiteres Hinterfragen übernimmt. Übrigens muss noch die Voraussetzung Nr. 2 aus dem Artikel.
Eine Frage noch an linrunner: Ist es bei Dir auch so, dass Du unter VB zwar scheinbar richtig in das NVRAM schreiben kannst, die Einträge im Bootmenü von VB aber nicht auftauchen und sie auch efibootmgr nach einem Neustart nicht mehr listet? Das wäre nämlich noch ein wichtiger Hinweis, zumal ich selbige Situation auch schon auf einem Thinkcenter-PC hatte. Im Moment weiß ich noch nicht, wie man überprüfen kann, dass die Einträge auch tatsächlich im NVRAM ankommen bzw. vom EFI verarbeitet werden. Gruß, Martin |
Anmeldungsdatum: Beiträge: 3271 |
Du brauchst nicht weiter nachforschen, UEFI ist ausschließlich mit 64bit möglich. Ich empfehle übrigens wärmstens(!) als Lektüre den exzellenten UEFI-Artikel von Thorsten Leemhuis in c't 11/2012 S. 174, der leider nicht kostenlos online verfügbar ist, sonst hätte er in den Linkabschnitt gehört. Virtuell hab ich noch nicht getestet, bin derzeit mehr mit dem kommenden Release von TLP beschäftigt ... Im übrigen bin ich der Meinung dass der Artikel mal langsam aus der Baustelle geschubst werden sollte! ☺ An Feinheiten kann man immer noch feilen. |
Anmeldungsdatum: Beiträge: 5106 |
Ich kenne den Artikel. Da steht aber hinsichtlich Was man noch in den Artikel schreiben könnte ist, dass der Pfad zur EFI-System-Partition im NVRAM per sog. "unique GUID" gesetzt wird. Das einzige Tool, dass ich bis jetzt kenne, dass diese Anzeigen kann, ist (s)gdisk. D.h. ein Eintrag funktioniert nur solange, solange man die gleiche ESP verwendet. Wird die EFI-System-Partition bei einer Neuinstallation neu angelegt, dann funktioniert der NVRAM-Eintrag nicht mehr. Dann habe ich noch einen Fehler übersehen: Im ersten Absatz muss es heißen:
Wenn man nämlich nur GRUB-EFI nachträglich installiert, so wird Gruß, Martin |