RapaNui
(Themenstarter)
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
Eingangstext überarbeitet, hier: Grub durch Ubuntu erstzt; 1x mehr NVRAM geschrieben. Hinweistext überarbeitet, u.a. "unique GUID" und Werkseinstellung Hinweis:Das System muss im (U)EFI-Modus gestarted sein, dies kann man z.B. am eingebundenen, virtuellen Verzeichnis /sys/firmware/efi/vars erkennen. Die Verknüpfung des NVRAM-Eintrags mit der EFI-System-Partition (ESP) erfolgt über sog. "unique GUID" (siehe auch sgdisk -i / -G). Wird diese GUID verändert, z.B. durch eine Neuanlage der ESP, dann müssen die Einträge neu bearbeitet werden - dies gilt auch beim Zurücksetzten des EFI-Boards auf die Werkseinstellungen (Default).
Somit wäre der Artikel fertig und kann ins Wiki
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
IMO würde sich --verbose noch gut als Beispiel machen, weil man das doch unter Umständen häufiger brauchen wird, um im Zusammenhang mit sgdisk -i zu verifizieren, ob der erzeugte bzw. der angezeigte Eintrag auch wirklich auf eine aktuell vorhandene Partition verweist. Dann gefallen mir noch zwei Punkte nicht:
gpt Erzwinge das Schreiben bei ungültigen PMBR analog GPT
Da habe ich erst mal überhaupt nicht kappiert, was das heißen soll. In der Manpage steht:
Force disk with invalid PMBR to be treated as GPT
Das würde ich besser so übersetzen: Erzwingt den unter --disk angegebenen Datenträger auch dann als GPT-Datenträger zu behandeln, wenn der Protectiv MBR ungültig ist. Der zweite - für den kannst Du im Prinzip nichts:
--wirte-signature Schreiben einer eindeutigen Signatur in den MBR (sofern benötigt)
Das ist an sich korrekt übersetzt, allerdings weiß damit kein Mensch was das für eine Signatur ist, wohin die genau geschrieben wird im MBR und für was sie genau gebraucht wird oder in welchen Situationen. Diesbezüglich habe ich noch nicht nachgeforscht. Ich weiß auch, dass man das häufig im Netz in Anleitungen findet, aber es ist nie erklärt für was und es drängt sich der Verdacht auf, dass das einfach der eine vom anderen übernommen hat und man es in aller Regel wohl nicht benötigt. Und dann noch ein Fehler, der sich aus der Änderung weiter oben ergeben hat: Beim letzten Beispiel ganz am Ende:
Der Bootloader liegt im eingebundenen Verzeichnis /boot/efi/ im Unterverzeichis EFI/ubuntu/ unter dem Namen grubx64.efi
Würde ich so schreiben: Der Bootloader liegt auf der ESP im Verzeichnis \EFI\ubuntu unter dem Namen grubx64.efi.
Gruß,
Martin EDIT:
"Eintrag" im ersten Absatz ergänzt.
|
RapaNui
(Themenstarter)
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
Newubunti schrieb: IMO würde sich --verbose noch gut als Beispiel machen, ...
Dazu wäre dann linrunner gefragt, da ich bereits schrieb, hab kein EFI und einfach was aus dem Netz kopieren möchte ich nicht. Er könnte dann das Bsp. auch selbst zusätzlich einbauen - hab ja im Eingangspost den Artikel generell zum editieren freigegeben. Vielleicht wär dabei auch eine Gegenüberstellung von ls /sys/firmaware/efi/vars zu efibootmgr -v ganz gut.
Erzwingt den unter --disk angegebenen Datenträger auch dann als GPT-Datenträger zu behandeln, wenn der Protectiv MBR ungültig ist.
Hört sich besser an und ist eingebaut.
--wirte-signature Schreiben einer eindeutigen Signatur in den MBR (sofern benötigt)
Das ist an sich korrekt übersetzt, allerdings weiß damit kein Mensch was das für eine Signatur ist, wohin die genau geschrieben wird im MBR und für was sie genau gebraucht wird oder in welchen Situationen.
Bei welchen Fällen der MBR nicht korrekt aufgebaut ist/wird kann ich nicht sagen. Zu Signatur & MBR fällt mir spontan ein a) MBR-Signatur (0xAA55) und b) die Disk-Signatur (seit Windows 2000). Soweit ich das System GPT verstanden habe, interessieren dabei die Einträge (zumind. ab 0x01B8) nicht und die kann ich ± beliebig befüllen, eben auch mit fehlerhaften Einträgen. "if needed" interpretiere ich im Mom. so: MBR (Protective MBR) - dass eine interne Prüfung der Signatur durchgeführt wird und nur beim Fehlen/bei Fehlern wird sie erzeugt/geschrieben. Da eben keine Infos darüber existieren würde ich die Option nicht einfach unter den Tisch fallen lassen (nur damit man ein kurzes Kommando erhält - Fehlervermeidung/-korrektur). Der Bootloader liegt auf der ESP im Verzeichnis \EFI\ubuntu unter dem Namen grubx64.efi.
Mir liegt schon an dem Hinweis auf die /boot/efi, daher hab ichs mal so geschrieben:
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
RapaNui schrieb: Newubunti schrieb: IMO würde sich --verbose noch gut als Beispiel machen, ...
Dazu wäre dann linrunner gefragt,
Ich habe das mal erledigt. Kritik willkommen! Außerdem habe ich noch den Abschnitt "Bekannte Probleme" hinzugefügt und einen Link. Die kurz skizzierte Lösung kann man unter Umständen noch verkürzen, weil es eigentlich nicht direkt hier her gehört sondern thematisch eher nach Installation. Ob es sich da einbauen lässt, ohne Nutzer zu verwirren weiß ich jetzt aber noch nicht. Daran arbeite ich gerade. Der Bootloader liegt auf der ESP im Verzeichnis \EFI\ubuntu unter dem Namen grubx64.efi.
Mir liegt schon an dem Hinweis auf die /boot/efi, daher hab ichs mal so geschrieben:
Das stimmt aber nur, wenn man das System noch starten kann. Man wird aber zu efibootmgr häufiger greifen, wenn man Ubuntu nicht starten kann und dann läuft es von einem Live-Medium. Das mit dem vorangestellten /boot/efi/ kann dann aber durchaus auch zur Verwirrung beitragen. Letztlich kommt es doch bei efibootmgr darauf an, wie der anzugebende Pfad lauten muss und nicht wo der im funktionierenden System eingehängt ist. Ich würde diese Information im Artikel Grundlagen zur Partitionierung unterbringen, den ich auch gerade bearbeite. Da passt es besser hin oder/und vielleicht auch bei Verzeichnisstruktur. Gruß,
Martin
|
RapaNui
(Themenstarter)
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
Jetzt haben wir aber 2x Listen, 1x am Anfang ohne -v und 1x am Ende der Beispiele mit -v . (Kleinigkeit dabei, unschön aber nicht tragisch ist für mich, dass die Auflistungen nun nicht mehr zueinander passen) Meine Vorschläge dazu:
Man könnte den Abschnitt entsprechend unterteilen. Der Titel Detailierte Analyse von Booteinträgen gefällt mir auch nicht sonderlich. Das Programm listet i.d.F. nur auf, die Analyse macht der Mensch, der das ließt. Man hätte eben auch ein ls /sys/firmware/efi als Muster zeigen können, um dann selbst analysieren zu können, welcher der Einträge ins leere läuft. Vorschlag dazu - hab meine Vorstellung mal eingebaut (Dein Teil liegt ja noch in der Rev.):
Listen aller Einträge
Mittels der Option --verbose werden die Einträge in erweiterter Form dargestellt. Dabei sollte man bei Problemen besonders auf die angezeigten GUIDs achten. Stimmen diese nicht überein bzw. sind falsch (im Bsp. an den letzten beiden Einträge dargestellt), dann kann man sie zwar über das EFI-Menue auswählen, aber das entsprechende System startet nicht.
sudo efibootmgr --verbose
Beispiel
... Musterauflistung der Ausgabe ...
Bei Umstimmigkeiten kann man diese Auflistung noch mit der Ausgabe von ls /sys/firmware/efi/vars/
...evtl. Musterausgabe zu ls ...
bzw.
Bei Umstimmigkeiten kann man die eindeutige (unique) GUID für den richtigen EFI-Eintrag zur ESP mittels sgdisk -i (benötigt weitere Angaben) ermitteln. Die fehlerhaften Einträge können dann mit efibootmgr gelöscht und notwendige Zusatzeinträge vorgenommen werden. Das ergibt mMn ebenfalls einen aussagefähigen Text, ist aber deutlich kürzer und die Hinweisbox kann entfallen (wir schreiben ja über efibootmgr und da brauch ich keine Hinweisbox, die darauf hinweist, dass man mit diesem Proggi ändern kann).
Bekannte ProblemeIn der Praxis gibt es derzeit Systeme - meist solche von OEM-Herstellern - bei denen das Setzen der Einträge zunächst korrekt zu funktionieren scheint. Die Einträge werden so lange das System noch läuft mittels efibootmgr gelistet. Bei einem Neustart erscheinen sie dann aber nicht im EFI-Boot-Menü und auch efibootmgr listet sie dann nicht mehr. In einem solchen Fall kann man Ubuntu dann nicht über das Boot-Menü starten. Hat man keinen anderen Boot-Manager auf dem System installiert, der vom EFI unterstützt wird, dann kann man Ubuntu alternativ wie gewohnt im BIOS-Modus installieren. Dabei ist darauf zu achten, dass auf einem GPT-Datenträger dann eine BIOS-Boot-Partition eingerichtet werden muss.
Verstehe ich anscheinend wieder mal falsch und verwirrt mich hier im Artikel ein wenig (darum erstmal weg bzw. in der Rev.). Der erste Teil spricht, so wie er da steht, eine Gewährleistung an - dann bring ich das Teil eben wieder zurück. Der zweite Teil ist für Nichtwissende ebenfalls verwirrend. Dabei wird die Standartinstallation, meist Windows, außen vor gelassen und evtl. Umsteiger verärgert (Motto: Linux macht alles richtig nur der OEM-Hersteller und/oder Windows machen etwas falsch) Man kann das System dann zwar im BIOS-Mode starten, aber ... BIOS-Boot-Partition... Das wissen wir und wir wissen wie man das regeln könnte, aber es ist doch einiges mehr an Aufwand (Live, Partitionierung, Grub installieren). Dann wäre es schon interessanter, ob und wie ich mit einer Live dies wieder gerade biegen kann - zumindest. USB-Start sollte noch funktionieren. Auch könnte man sich eine EFI-Shell besorgen (funktioniert auch von USB-Stick) und das System darüber starten und reparieren - aber das ist ein eigenes Thema. Edit: Hab den Vorschlag bereits eingebaut und den obigen Text angeglichen.
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
Ich hab mal ein paar Kleinigkeiten glattgefeilt. Der Abschnitt zum Langformat ist mir zu wenig konkret, es wird nicht erwähnt wo in der Auflistung denn die GUIDs zu finden sind. Hier ist übrigens die Ausgabe von meinem X220:
BootCurrent: 0019
Timeout: 0 seconds
BootOrder: 0019,001A,0006,0007,0008,0009,000A,000B,000C,000D,000E,000F,0010,0011,0012,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot0004 ME Configuration Menu
Boot0005 Rescue and Recovery
Boot0006 USB CD 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba7a55
Boot0007 USB FDD 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009471e49
Boot0008* ATAPI CD0 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471857a35401
Boot0009* ATA HDD2 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f702
Boot000A* ATA HDD0 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f700
Boot000B* ATA HDD1 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f701
Boot000C* USB HDD 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50303
Boot000D PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3303
Boot000E ATAPI CD1 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35603
Boot000F ATAPI CD2 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35604
Boot0010 Other CD 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35606
Boot0011 ATA HDD3 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f803
Boot0012 ATA HDD4 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f804
Boot0013 Other HDD 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f806
Boot0014* IDER BOOT CDROM ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot0015* IDER BOOT Floppy ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0016* ATA HDD 030a2400d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab1f6
Boot0017* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a554
Boot0018* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3703
Boot0019* Ubuntu HD(1,800,32000,a44dc908-e0d1-4df5-903f-a8db5f6f66b3)File(\EFI\ubuntu\grubx64.efi)
Boot001A* Ubuntu [Test] HD(4,df6609e,2fbe1,773a0059-be41-4828-944a-32217f941c95)File(\EFI\ubuntu\grubx64.efi)
Die unterscheidet sich doch deutlich vom Beispiel im Artikel. Von dem Abschnitt "Bekannte Probleme" halte ich nicht soviel. Man muss nicht mit dem Murks den einzelne Boardhersteller bauen den unbedarften User verunsichern. Es gibt ohnehin schon viele zu viele Warnhinweise im Wiki.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
RapaNui schrieb: Man hätte eben auch ein ls /sys/firmware/efi als Muster zeigen können, um dann selbst analysieren zu können, welcher der Einträge ins leere läuft.
Da hatte ich vergessen im vorhergehenden Post drauf zu antworten: In ls /sys/firmware/efi werden die Einträge nicht direkt so gelistet, wie Du Dir das vielleicht vorstellst. IMO sieht das für mich so aus, als würden dort nur Schnittstellen(addressen?) oder so etwas ähnliches gelistet. Hier mal die Ausgabe zu meiner Musterausgabe im Artikel: BackgroundClear-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0006-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0007-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0008-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0009-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000A-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000B-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000C-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000D-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000E-8be4df61-93ca-11d2-aa0d-00e098032b8c
boot-args-7c436110-ab2a-4bbb-a880-fe41995c9f82
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
del_var
ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
FirmwareFeatures-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14
FirmwareFeaturesMask-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
MTC-eb704011-1402-11d3-8e77-00a0c969723b
new_var
NvVars-964e5b22-6459-11d2-8e39-00a0c969723b
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1
VBOX_CONSOLE_VAR-b53865fd-b76c-4433-9e85-c0cadf65aab8
Wie Du siehst, bringt das zur Analyse hinsichtlich efibootmgr nichts. Die Änderungen hinsichtlich --verbose sind von meiner Seite aus ok. Ich würde nur das "unique" nicht in Klammern setzen, weil es eben in der sgdisk-Listung zwei GUIDs gibt und es dort die "unique" ist. Gibt es noch andere Tools, die diese unique GUID listen? Dass der Abschnitt "Bekannte Probleme" noch nicht der Weisheit letzter Schluss war, kann ich durchaus nachvollziehen, aber an sich drin bleiben sollte er schon. Ob das ein Gewährleistungsfall oder was auch immer ist, spielt überhaupt keine Rolle. Fakt ist, dass es Systeme gibt - und so eines hatte ich schon vor mir - die mit efibootmgr nicht können bzw. wo es nichts tatsächlich am NVRAM ändert. Ob das an efibootmgr oder an der EFI-Implementierung liegt, weiß ich nicht. Aber es ist doch wichtig zu erwähnen, weil andernfalls der Eindruck erweckt wird, als funktioniere efibootmgr immer. Das ist aber momentan nicht der Fall. Wie gesagt, man kann den Abschnitt besser formulieren, kein Problem, aber hilfreich ist er dennoch. Was die Abhilfe-Schilderung in dem Abschnitt anbelangt: Die ist nur solange unverständlich oder zu kurz, wie es dazu im Wiki noch keine Informationen gibt, daran arbeite ich aber im Moment. Die Problematik ist eben über mehrere bestehende Artikel im Wiki zu verteilen, was nicht so ganz einfach ist. linrunner schrieb: Von dem Abschnitt "Bekannte Probleme" halte ich nicht soviel. Man muss nicht mit dem Murks den einzelne Boardhersteller bauen den unbedarften User verunsichern. Es gibt ohnehin schon viele zu viele Warnhinweise im Wiki.
Wenn der unbedarfte Nutzer aber genau so ein Murks-System vor sich hat? Woher weißt Du, wieviele Systeme das betrifft? EFI ist in der Praxis auf Desktops noch neu und OEM-Hersteller testen häufig nur auf Windows-Kompatibilität. Wegen mir schreibt man halt so etwas wie: Im Einzelfall kann es vorkommen, dass... Aber warum man das Problem nicht erwähnen soll, ist mir ein Rätsel. Da kann ein unbedarfter Nutzer nämlich Tage mit verplempern. Ich habe Ubuntu bisher auf zwei Systemen im EFI-Modus installiert und eines von den beiden hatte genau dieses Problem. Natürlich kann das Zufall sein, aber immerhin handelte es sich dabei um ein LENOVO und die haben ja unter Linux generell einen guten Ruf. Schon BIOS-Implementierungen waren/sind von Hersteller zu Hersteller sehr unterschiedlich. Ich wüßte zunächst mal nicht, warum sich das bei EFI nun ändern soll. efibootmgr funktioniert eben nicht autark, sondern nur im Zusammenspiel mit dem EFI. Man kann auch nicht davon ausgehen, dass ein Tool, dass von Dell entwickelt wurde - AFAIK - auf allen anderen Systemen anstandslos funktioniert. Im übrigen ist es auch so, dass der unbedarfte Anwender auf einem problemfreien EFI-System sich mit efibootmgr nicht herumplagen muss, weil auf solch einem System der Eintrag automatisch während der Ubuntu-Installation gesetzt wird. In der Regel muss man ihn dann noch als Standard-Eintrag setzen, wenn man das so haben will, was aber auch im EFI selbst erledigt werden kann. Gruß,
Martin
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
Was ich oben noch vergessen habe: ich votiere nach wie vor dafür diese beiden Optionen aus dem Befehlsbeispiel herauszunehmen:
Den Inhalt von /sys/firmware/efi/vars auszubreiten fände ich nicht so sinnvoll. Das Ziel des Artikel war doch efibootmgr als Benutzerschnittstelle zu EFI zu beschreiben, oder? Newubunti schrieb: Wegen mir schreibt man halt so etwas wie:
Im Einzelfall kann es vorkommen, dass...
Find ich besser. Nur bitte nicht mit einer roten Warnbox den Artikel zerhacken. Newubunti schrieb: Natürlich kann das Zufall sein, aber immerhin handelte es sich dabei um ein LENOVO und die haben ja unter Linux generell einen guten Ruf.
Den guten Ruf haben von jeher die ThinkPad-Baureihen, bei den restlichen ist es nichts weiter als ein (mitunter fatales) Mißverständnis. Kannst ja mal nach der Community suchen die die Nicht-ThinkPads linux-seitig unterstützt. Viel Spaß dabei. Newubunti schrieb: Im übrigen ist es auch so, dass der unbedarfte Anwender auf einem problemfreien EFI-System sich mit efibootmgr nicht herumplagen muss, weil auf solch einem System der Eintrag automatisch während der Ubuntu-Installation gesetzt wird. In der Regel muss man ihn dann noch als Standard-Eintrag setzen, wenn man das so haben will, was aber auch im EFI selbst erledigt werden kann.
Ich sehe die Zielgruppe des Artikels durchaus beim "unbedarften Anwender" der einen Spezialfall (Dualboot o.ä.) einrichten möchte.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
linrunner schrieb: Was ich oben noch vergessen habe: ich votiere nach wie vor dafür diese beiden Optionen aus dem Befehlsbeispiel herauszunehmen:
+1! Zumal die Optionen ja in der Tabelle oben drin stehen und damit nicht gänzlich unter den Tisch fallen. Außerdem gibt es ja noch die manpage. Dass die das nicht verständlich erklärt, kann ja keiner von uns ändern. Ich stehe auch auf dem Standpunkt, dass man erst mal nur die Aktionen aufführt, die man auch tatsächlich zum Erreichen des Ziel braucht. Wenn dann jemand beim Durcharbeiten nicht zum Erfolg kommt, kann man ihm immer noch auf eine andere Optione verweisen und kann dann am Einzelfall auch ableiten, wie sie dort gewirkt hat und bei welchem Problem - zumindest im Idealfall. So ist es mehr nach dem Motto, viel hilft viel, was allenfalls noch ok wäre, wenn man genau erklären könnte, was da genau passiert.
Den Inhalt von /sys/firmware/efi/vars auszubreiten fände ich nicht so sinnvoll. Das Ziel des Artikel war doch efibootmgr als Benutzerschnittstelle zu EFI zu beschreiben, oder?
+1! Newubunti schrieb: Wegen mir schreibt man halt so etwas wie:
Im Einzelfall kann es vorkommen, dass...
Find ich besser. Nur bitte nicht mit einer roten Warnbox den Artikel zerhacken.
Das hatte ich auch gar nicht gemacht es war einfach nur ein Abschnitt am Ende, für die die alles erfolgreich bis dahin durchgearbeitet haben: http://wiki.ubuntuusers.de/Baustelle/efibootmgr?rev=460382
Newubunti schrieb: Natürlich kann das Zufall sein, aber immerhin handelte es sich dabei um ein LENOVO und die haben ja unter Linux generell einen guten Ruf.
Den guten Ruf haben von jeher die ThinkPad-Baureihen, bei den restlichen ist es nichts weiter als ein (mitunter fatales) Mißverständnis. Kannst ja mal nach der Community suchen die die Nicht-ThinkPads linux-seitig unterstützt. Viel Spaß dabei.
Das spielt ja auch letztlich keine Rolle. Wie gesagt, bei OEM-Systemen befürchte ich, dass es da noch die ein oder andere "böse" Überraschung geben wird. Wer da letztlich der Hersteller ist, spielt keine Rolle. Und wie gesagt ich kann ja noch nicht mal 100% sagen, dass es alleine am EFI liegt. Kann ja auch an efibootmgr selbst liegen.
Newubunti schrieb: Im übrigen ist es auch so, dass der unbedarfte Anwender auf einem problemfreien EFI-System sich mit efibootmgr nicht herumplagen muss, weil auf solch einem System der Eintrag automatisch während der Ubuntu-Installation gesetzt wird. In der Regel muss man ihn dann noch als Standard-Eintrag setzen, wenn man das so haben will, was aber auch im EFI selbst erledigt werden kann.
Ich sehe die Zielgruppe des Artikels durchaus beim "unbedarften Anwender" der einen Spezialfall (Dualboot o.ä.) einrichten möchte.
Das ist ja alles richtig, aber deswegen darf am Ende doch stehen, dass es Fälle gibt, wo das alles nichts bringt und das man dann eben zu alternativen Vorgehensweisen greift. Ich wüsste halt nicht, wo es thematisch sonst besser passen würde. Es ist nun mal ein NVRAM-Problem und ein extra Artikel NVRAM wäre ja wohl ein bisschen übertrieben. Ich würde übrigens von der Reihenfolge her, das --create -Beispiel an den Anfang setzen. Das wird man wohl am häufigsten nutzen und sollte im Normalfall zum Ziel führen. Gruß,
Martin
|
RapaNui
(Themenstarter)
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
Danke linrunner für die Überarbeitung (mein deutsch wird immer schlechter, sorry) linrunner schrieb: Ich hatte dazu meine Gedanken ausgebreitet 😉, hänge aber absolut nicht an diesen beiden Optionen in den Beispielen. Newubunti Da hatte ich vergessen im vorhergehenden Post drauf zu antworten: In ls /sys/firmware/efi ...
Das war als Hinweis auf falsche GUID gemeint, da eben die GUID auch bei ls gelistet wird. Mir ist z.Zt. kein weiteres Programm bekannt (außer hexdump), das die unique GUID anlistet. Das unique im Text in Klammern steht entstand aus dem Versuch des einheitlichen Textgebrauchs (nur Hinweis zu gdisk) Probleme
Ich bin nicht grundsätzlich dagegen einen Problemfälleteil aufzunehmen, wenn es dafür Lösungen gibt. Eine Lösung i.d.F. nutze EFI nicht und installiere eine andere Form find ich nur nicht so glücklich. Da es Probleme mit den verschiedenen Boards geben kann, finde ich die Idee von linrunner besser, es in eine Hinweisbox (am Anfang?) des Artikels einzubauen. Newubunti schrieb:
Ich würde übrigens von der Reihenfolge her, das --create -Beispiel an den Anfang setzen. Das wird man wohl am häufigsten nutzen und sollte im Normalfall zum Ziel führen.
Auch das ist Ansichtsache, zeigt man erst ein paar kurze Gebrauchsmöglichkeiten oder geht man direkt in die Vollen.
Da ihr zwei Euch nun so stark einbringt, ziehe ich mich ein wenig auf den Beobachterposten zurück und überlasse Euch die weiteren Änderungen. Danke für die Mitarbeit
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Ich habe jetzt mal "Bekannte Probleme" wieder rein und dabei versucht etwas zu entschärfen. Ansonsten habe ich die Hinweisbox am Anfang versucht auf das wesentliche zu straffen. Ich finde es nämlich nicht gut, wenn da zu viel in engen Raum gepresst wird. Dann habe ich noch den doppelten Backslash raus, weil es mit einfachem genauso funktioniert. Sonst noch ein paar - IMO - Verbesserungen innerhalb der Tabelle. Gruß,
Martin
|
RapaNui
(Themenstarter)
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
Newubunti schrieb: Sonst noch ein paar - IMO - Verbesserungen innerhalb der Tabelle.
Wie versprochen nehme ich keine Änderungen mehr vor:
Deine internen Verlinkungen auf "gelöscht" und "Neueinträge" sind tot, Kodierungsfehler? Im Fließtext soll lt. Wiki-Syntax der Name des Programms nicht mehr gesondert hervorgehoben werden. Auch wenn Programme oft den gleichen Namen wie ein Paket haben, werden sie im Fließtext unformatiert gelassen:
Bei Problemen, (Details siehe <Link>) , da fehlt wohl noch ein Link, so kommt das nie ins Wiki.
Nochmals meine Frage zu Reparatur/Create NVRAM ⇐> Live: Ist das möglich und wenn ja, sollte das nicht kurz Erwähnung finden? Macht evtl. noch einer der folgenden Links Sinn?
EDIT 1 an Beide: Hab gerade mal ein wenig in den Bootoptionen zum Kernel gelesen uns so langsam schließt sich der Kreis zu den Parametern --gpt und --write-signatur:
Dem Kernel kann die Option gpt mitgegeben werden 829 gpt [EFI] Forces disk with valid GPT signature but
830 invalid Protective MBR to be treated as GPT. entspricht wohl der Option bei efiboomgr - GPT-Signatur: EFI PART (45h 46h 49h 20h 50h 41h 52h 54h) bei Offset 0x200. Die Option --write-signatur bei efibootmgr schreibt demnach, bei Erkennung einer ungültigen Signatur, diese Signatur neu (Da spielen dann wohl auch die Kerneloption efi/noefi/acpi_rsdp=/add_efi_memmap mit hinein, evtl. beim Support die /proc/cmdline mit kontrollieren).
EDIT 2:
Newubunti schrieb:
Gibt es noch andere Tools, die diese unique GUID listen?
Ich für meinen Teil habe das in das Skript lsdisk ab 014.2 nun eingebaut.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
RapaNui schrieb: Newubunti schrieb: Sonst noch ein paar - IMO - Verbesserungen innerhalb der Tabelle.
Wie versprochen nehme ich keine Änderungen mehr vor:
Die funktioniert AFIAK erst, wenn der Artikel aus der Baustelle verschoben ist.
Im Fließtext soll lt. Wiki-Syntax der Name des Programms nicht mehr gesondert hervorgehoben werden. Auch wenn Programme oft den gleichen Namen wie ein Paket haben, werden sie im Fließtext unformatiert gelassen:
Ah, danke, da war ich mir nicht sicher. Habe es wieder entsprechend geändert.
Ja, der Link fehlt noch, weil die Info bis jetzt im Wiki noch nicht untergebracht ist. Ich wollte nur deutlich machen, dass da noch ein Link hinkommt, weil aus der Kurzbeschreibung der Laie ja nicht schlau wird.
Nochmals meine Frage zu Reparatur/Create NVRAM ⇐> Live: Ist das möglich und wenn ja, sollte das nicht kurz Erwähnung finden?
Kannst Du bitte genauer beschreiben, worauf Du hinaus willst?
Macht evtl. noch einer der folgenden Links Sinn?
Das oder zumindest die dahinter liegende Problematik gehört für mich direkt hier ins Wiki. (siehe Baustelle EFI-Installation Erfahrungsberichte)
Die übrigen Links beziehen sich, soweit ich das auf die Schnelle überblicke, alle auf die EFI-Shell. Zur EFI-Shell könnte man eventuell einen eigenen Artikel anlegen. Allerdings zeigt mir die Erfahrung mit den zwei bisherigen realen Systemen auf den ich Ubuntu-EFI ausprobiert habe, dass man von der Shell - was die Bootkonfiguration anbelangt nicht zu viel erwarten sollte. Denn das EFI-Programm (bcfg), dass es noch erlauben würde, doch noch an der Bootkonfiguration zu schrauben, war auf beiden Systemen nicht vorhanden. Auf alle Fälle wäre "EFI-Shell" ein eigenes Thema, sofern man feststellt, dass die Shell für Ubuntu irgendwie nützlich sein kann. Die Shells die ich vom USB-Stick nachladen konnte, enthielten bcfg auch nicht. Eine der Shells, die im Arch-Wiki genannt wurde, war wiederum auf keinem der beiden Systeme lauffähig. Gibt es noch andere Tools, die diese unique GUID listen?
Ich für meinen Teil habe das in das Skript lsdisk ab 014.2 nun eingebaut.
Ich hatte vor allem deswegen gefragt, weil ich wissen wollte ob die relevante GUID in den Programmen - sofern es verschiedene gäbe - immer gleich benannt sind oder ob es unterschiedlich benannt wird - dann müsste man gegebenenfalls darauf hinweisen. Zum Ausprobieren Deines Tools lsdisk hatte ich bisher noch keine Zeit. Gruß,
Martin
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
RapaNui schrieb: Nochmals meine Frage zu Reparatur/Create NVRAM ⇐> Live: Ist das möglich und wenn ja, sollte das nicht kurz Erwähnung finden?
Falls damit gemeint ist, ob efibootmgr von einem Livesystem aus funktioniert: die Antwort lautet ja. Wir hatten oben ja schon festgestellt, dass es auch ohne gemountete ESP geht.
|
RapaNui
(Themenstarter)
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
linrunner schrieb: RapaNui schrieb: Nochmals meine Frage zu Reparatur/Create NVRAM ⇐> Live: Ist das möglich und wenn ja, sollte das nicht kurz Erwähnung finden?
Falls damit gemeint ist, ob efibootmgr von einem Livesystem aus funktioniert: die Antwort lautet ja. Wir hatten oben ja schon festgestellt, dass es auch ohne gemountete ESP geht.
Die Frage dazu lautet: Sollte man darauf nicht hinweisen, z.B. In der Einleitung - hab es nun so hinterlegt: efibootmgr ist ein Linuxprogramm um die Konfiguration des (U)EFI‐Bootmanagers im NVRAM zu verändern. Neben dem Auflisten können EFI-Boot-Einträge eingerichtet, vorhandene entfernt oder die Bootreihenfolge festgelegt werden. Diese Änderungen können mit einem installierten Desktop oder von einem Live-System(Live-CD/Live-USB) erfolgen, sofern dieses im EFI-Modus gestarted und efibootmgr installiert wurde. Ubuntu legt bei einer EFI-Installation alle erforderlichen Einträge an, so dass keine manuellen Nacharbeiten erforderlich sein sollten.
Newubunti schrieb: RapaNui schrieb: Newubunti schrieb:
Die funktioniert AFIAK erst, wenn der Artikel aus der Baustelle verschoben ist.
Der Sprung zu einem artikelinternen Anker funktioniert immer. Hab es korrigiert.
Dann sollte der Artikel jetzt fertig sein.
|