UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
Auf Wunsch von apt-ghetto gebe ich hiermit kund, einen neuen Abschnitt hinzugefügt zu haben. Nach meiner Erfahrung ist es für die Installation eines signierten Bootloaders (und signierten Kernels bei 64-Bit Ubuntu) irrelevant, ob das Installationsmedium ohne secure boot gestartet wurde, was z.B. bei Verwendung von MultiSystem erforderlich ist. Die Erklärung unter EFI Installieren (Abschnitt „Information-vor-der-Installation“) kann also weggelassen werden. Auch hier könnte das besser dargestellt werden. Moderiert von noisefloor: In eigene Diskussion ausgelagert, weil eigenes Howto.
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
Auf UEFI-Systemen mit mäßigen Ressourcen kann es vorteilhaft sein, das leichtgewichtigere 32-Bit Ubuntu zu verwenden.
Ich denke, kürzere Links schaden nicht (auch bei den anderen Links). Meiner Meinung nach kann man aber gleich auf den ganzen Satz verzichten, da es eher keine Rolle spielt, weswegen man ein Ubuntu 32-bit im UEFI-Modus installieren möchte. Leider ist dies noch nicht auf normalem Weg möglich
Dies impliziert einerseits, dass es seitens Canonical geplant ist, dass man ein 32-bit Ubuntu auch im EFI-Modus installieren können soll. Das bezweifle ich allerdings, da Canonical sowieso vorhat, keine 32-bit Versionen mehr anzubieten. Andererseits enthält es eine subjektive Wertung, die nicht unbedingt in ein Wiki gehört. Sobald diese abgeschlossen ist, wechselt man wieder in's Terminal.
Du meinst, nachdem man wieder vom Installationsmedium gebootet hat? Oder ist immer noch das gleiche Terminal geöffnet? Oder ein anderes Terminal? Das sollte hier etwas genauer beschrieben sein. Und das Apostroph ist falsch. auf secure boot-Möglichkeit verzichten apt-get install grub-efi-amd64 für secure boot vorbereiten (das geht auch, wenn das Installationsmedium nicht mit secure boot gestartet wurde) dpkg --add-architecture amd64
apt-get update
apt-get install grub-efi-amd64-signed Optional mit Shim-Bootloader: apt-get install shim-signed
Müsste dpkg --add-architecture amd64
apt-get update nicht vor apt-get install <PAKET> ... stehen? Aus welchen Gründen gibst du die Installation von shim-signed als optional an? Als Wikinutzer würde mich das schon interessieren, damit ich entscheiden kann, ob es bei meiner Installation wirklich optional ist.
grub-install --efi-directory /boot/efi
Scheitert ein ? Und wenn ja, würde ich noch einen Satz dazu schreiben, dass man die Option efi-directory zwingend angeben muss. Apropos: Wurde die EFI-System-Partition in die fstab eingetragen? Wann und wo? Grundsätzlich finde ich den Artikel und deine Arbeit nicht schlecht. Allerdings stelle ich mir da schon einige Fragen, die du noch beantworten solltest.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
apt-ghetto schrieb: Grundsätzlich finde ich den Artikel und deine Arbeit nicht schlecht. Allerdings stelle ich mir da schon einige Fragen, die du noch beantworten solltest.
Danke und gerne. Muss jetzt aber erst mal weg und bin in den nächsten Tagen stärker anderweitig beschäftigt ... bitte also um etwas Geduld.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo, habe den Teil in ein eigenes Howto ausgelagert. Hauptgründe: von Stil und Syntax nicht wirklicn wiki-konform der Abschnitt gilt nur für 16.04, der Artikel gilt aber für 16.04, 14.04 und 12.04 - passt nicht. Muss aber passen.
Das Howto ist (noch) in der Baustelle, als kein Stress mit Änderungen. Das Fertigstellungsdatum kann bei Bedarf angepasst werden. @UlfZibis: Und auch für dich gilt nach wie vor das hier! Gruß, noisefloor
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
apt-ghetto schrieb: Auf UEFI-Systemen mit mäßigen Ressourcen kann es vorteilhaft sein, das leichtgewichtigere 32-Bit Ubuntu zu verwenden.
Ich denke, kürzere Links schaden nicht (auch bei den anderen Links).
Dem stimme ich zu. Ich hatte länger darüber nachgedacht, wie ich sie kürzer machen kann, doch ging dabei immer die die genaue Bedeutung verloren. Hast Du da bessere Formulierungen in petto?
Meiner Meinung nach kann man aber gleich auf den ganzen Satz verzichten, da es eher keine Rolle spielt, weswegen man ein Ubuntu 32-bit im UEFI-Modus installieren möchte.
Ich finde schon wichtig, auf den Grund für das Abweichen von der üblichen Empfehlung "64-Bit ist immer besser" hinzuweisen. Erst durch meine im Forumartikel dargestellten Tests kam der "Irrglaube" deutlich zum Vorschein. Ich hätte die Gründe natürlich auch hier aufführen können, doch würden sie bei platzsparender Formulierung das Problem nicht umfassend und ausgewogen genug darstellen. Deshalb finde ich den Verweis auf den ausführlichen Forum-Artikel besser.
Leider ist dies noch nicht auf normalem Weg möglich
Dies impliziert einerseits, dass es seitens Canonical geplant ist, dass man ein 32-bit Ubuntu auch im EFI-Modus installieren können soll.
Das stimmt, deshalb würde ich zustimmen, das "noch" wegzulassen. Andererseits enthält es eine subjektive Wertung, die nicht unbedingt in ein Wiki gehört.
Leider wird "leider" im Wiki sehr häufig verwendet, genauso wie z.B. "besser". Ich finde die Wertung hier deshalb angemessen, auch weil die unbedachte Ressourcen-Verschwendung leider sehr verbreitet ist.
Sobald diese abgeschlossen ist, wechselt man wieder in's Terminal.
Du meinst, nachdem man wieder vom Installationsmedium gebootet hat? Oder ist immer noch das gleiche Terminal geöffnet?
Ich meinte letzteres. Allerdings hatte ich die Installation spät nachts vor dem zu Bett gehen angestoßen, sodass ich am nächsten Morgen einen ausgeschalteten Rechner vorfand. Ob also das Terminal nach dem Installationsprozess noch zugreifbar war, kann ich also nicht genau sagen. Im Grunde dürfte es aber egal sein, man geht wieder in's Terminal, egal ob ein Neustart des Live-Systems dazwischen lag.
Das sollte hier etwas genauer beschrieben sein.
Vorschlag?
Und das Apostroph ist falsch.
Was wäre denn richtig?
Müsste dpkg --add-architecture amd64
apt-get update nicht vor apt-get install <PAKET> ... stehen?
Nein, die zusätzliche Architektur ist nur für grub-efi-amd64-signed und shim-signed nötig, da sie für i386 im Canonical-Repository nicht vorliegen. Explizit geht es um die Installation von grub-efi-amd64:i386, aber grub-efi-amd64-signed:amd64.
Aus welchen Gründen gibst du die Installation von shim-signed als optional an?
Beim 64-Bit Ubuntu 16.04 wird shim immer mitinstalliert, obwohl es für den Start von Ubuntu überflüssig ist. Vielleicht wollte man dem vorsorgen, dass andere exotische OS das shim für den Start möglicherweise zwingend brauchen.
Als Wikinutzer würde mich das schon interessieren, damit ich entscheiden kann, ob es bei meiner Installation wirklich optional ist.
Könnte man erwähnen, doch denke ich, das würde den Artikel hier unnötig aufblähen. Wer über das Fehlen von shim im Zusammenhang mit einem anderen OS scheitert, wird sicher irgendwo Hinweise finden. Wüsstest Du eine passende Beschreibung, die man verlinken könnte?
> grub-install --efi-directory /boot/efi
Scheitert ein ?
Das habe ich nicht ausprobiert, kann sein, dass es nicht nötig ist, vielleicht wird dadurch aber auch der Eintrag der EFI-System-Partition in die fstab erzwungen. Bei meinen Versuchen mit dpkg hatte ich es wohl nicht verwendet, und ob ich da den Eintrag der EFI-System-Partition manuell vorgenommen hatte, weiß ich nicht meht.
Und wenn ja, würde ich noch einen Satz dazu schreiben, dass man die Option efi-directory zwingend angeben muss.
Meinst Du? Im Zweifelsfall schadet sie ja nicht. Anders war es bei dem Vorschlag von lionlizard, wo die zusätzliche Option --force-extra-removable tatsächlich schadete, denn dadurch wurde die ursprüngliche bootx64.efi von Microsoft in EFI\Boot überschrieben. Glücklicherweise hatte ich vorher ein CloneZilla-Backup gemacht.
Apropos: Wurde die EFI-System-Partition in die fstab eingetragen?
Nicht manuell von mir. Wann und wo?
Ich vermute, das wurde automatisch erledigt durch: apt-get install grub-efi-amd64[-signed]
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
UlfZibis schrieb: Auf Wunsch von apt-ghetto gebe ich hiermit kund, einen neuen Abschnitt hinzugefügt zu haben. Nach meiner Erfahrung ist es für die Installation eines signierten Bootloaders (und signierten Kernels bei 64-Bit Ubuntu) irrelevant, ob das Installationsmedium ohne secure boot gestartet wurde, was z.B. bei Verwendung von MultiSystem erforderlich ist. Die Erklärung unter EFI Installieren (Abschnitt „Information-vor-der-Installation“) kann also weggelassen werden. Auch hier könnte das besser dargestellt werden.
Moderiert von noisefloor: In eigene Diskussion ausgelagert, weil eigenes Howto.
Der Hinweis über das überflüssige secure boot während der Installation gehört aber zum Hauptartikel ... und der Hinweis auf einen neuen Abschnitt, der ja jetzt "spurlos" verschwunden ist, also die Existenz eines neuen Aspekts, könnte dort auch nicht schaden.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
noisefloor schrieb: habe den Teil in ein eigenes Howto ausgelagert. Hauptgründe:
Einverstanden, wir arbeiten dran! Hm, in vielen Wiki-Artikeln gibt es Unterabschitte, die nur für bestimmte Versionen passen. Außerdem ist nicht ausgeschlossen, dass der Abschnitt auch auf 14.04 und 12.04 Gültigkeit hat. Das Howto ist (noch) in der Baustelle, als kein Stress mit Änderungen. Das Fertigstellungsdatum kann bei Bedarf angepasst werden.
Gut so. Wird das HowTo denn dann auch noch mit dem Hauptartikel verlinkt? Sonst wird es wohl kaum einer finden, für den in der beschriebenen Ausgangskonstellation Ubuntu 32-Bit statt 64-Bit vorteilhaft wäre. @UlfZibis: Und auch für dich gilt nach wie vor das hier!
Sorry, ich hoffte, mein "Schnellschuss" war schon ausreichend ausgereift.
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
UlfZibis schrieb: apt-ghetto schrieb: Auf UEFI-Systemen mit mäßigen Ressourcen kann es vorteilhaft sein, das leichtgewichtigere 32-Bit Ubuntu zu verwenden.
Ich denke, kürzere Links schaden nicht (auch bei den anderen Links).
Dem stimme ich zu. Ich hatte länger darüber nachgedacht, wie ich sie kürzer machen kann, doch ging dabei immer die die genaue Bedeutung verloren. Hast Du da bessere Formulierungen in petto?
So: "Auf UEFI-Systemen mit mäßigen Ressourcen kann es vorteilhaft sein, das leichtgewichtigere 32-Bit Ubuntu zu verwenden."
Ich finde schon wichtig, auf den Grund für das Abweichen von der üblichen Empfehlung "64-Bit ist immer besser" hinzuweisen.
Du beziehst dich explizit auf den RAM-Verbrauch. Möglicherweise könnte deine Anleitung auch bei einem 32-bit UEFI mit 64-bit Kernel nützlich sein? Kann ich mangels Hardware allerdings nicht testen. Leider ist dies noch nicht auf normalem Weg möglich
Dies impliziert einerseits, dass es seitens Canonical geplant ist, dass man ein 32-bit Ubuntu auch im EFI-Modus installieren können soll.
Das stimmt, deshalb würde ich zustimmen, das "noch" wegzulassen.
Fände ich doch deutlich besser. Andererseits enthält es eine subjektive Wertung, die nicht unbedingt in ein Wiki gehört.
Leider wird "leider" im Wiki sehr häufig verwendet, genauso wie z.B. "besser". Ich finde die Wertung hier deshalb angemessen, auch weil die unbedachte Ressourcen-Verschwendung leider sehr verbreitet ist.
"Dies ist auf normalem Weg nicht möglich" fände ich nach wie vor besser.
|
helsup
Anmeldungsdatum: 1. Mai 2014
Beiträge: 96
|
Hallo zusammen,
schon der Blick auf die Beiträge zum Thema lässt folgendes erkennen: Für User, die Ubuntu aufsetzen möchten und sonst keine IT- Kenntnisse besitzen haben es nicht leicht, sondern schwer.
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
UlfZibis schrieb: Das sollte hier etwas genauer beschrieben sein.
Vorschlag?
"Sobald diese abgeschlossen ist, öffnet man ein Terminal vom Livemedium" oder ähnlich. Und das Apostroph ist falsch.
Was wäre denn richtig?
Ohne Apostroph: "ins" Aus welchen Gründen gibst du die Installation von shim-signed als optional an?
Beim 64-Bit Ubuntu 16.04 wird shim immer mitinstalliert, obwohl es für den Start von Ubuntu überflüssig ist. Vielleicht wollte man dem vorsorgen, dass andere exotische OS das shim für den Start möglicherweise zwingend brauchen.
Also kann man ein Windows{x >= 8 && x ⇐ 10} mit aktiviertem SecureBoot starten ohne shim-signed ? Als Wikinutzer würde mich das schon interessieren, damit ich entscheiden kann, ob es bei meiner Installation wirklich optional ist.
Könnte man erwähnen, doch denke ich, das würde den Artikel hier unnötig aufblähen. Wer über das Fehlen von shim im Zusammenhang mit einem anderen OS scheitert, wird sicher irgendwo Hinweise finden. Wüsstest Du eine passende Beschreibung, die man verlinken könnte?
Derjenige, der solche Hinweise sucht, würde sie sicher gerne in diesem Artikel vorfinden. Und viel grösser wird das Howto dadurch auch nicht. >> grub-install --efi-directory /boot/efi
Scheitert ein ?
Das habe ich nicht ausprobiert, kann sein, dass es nicht nötig ist, vielleicht wird dadurch aber auch der Eintrag der EFI-System-Partition in die fstab erzwungen. Bei meinen Versuchen mit dpkg hatte ich es wohl nicht verwendet, und ob ich da den Eintrag der EFI-System-Partition manuell vorgenommen hatte, weiß ich nicht meht.
Dann probier es einfach aus. Dass Grub die fstab ändert, halte ich für sehr unwahrscheinlich.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo,
Hm, in vielen Wiki-Artikeln gibt es Unterabschitte, die nur für bestimmte Versionen passen.
Völlig korrekt. Aber die beschreibst eine komplette Installation - das ist halt was anderes als so was wie "bis einschließlich Trusty muss man A drücken, aber ab Utopic B".
Außerdem ist nicht ausgeschlossen, dass der Abschnitt auch auf 14.04 und 12.04 Gültigkeit hat.
Aber du weißt es nicht und hast es nicht getestet. Das ist hier der entscheidende und wichtige Unterschied.
Wird das HowTo denn dann auch noch mit dem Hauptartikel verlinkt?
Natürlich - sobald das Howto aus der Baustelle raus ist. Gruß, noisefloor
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
apt-ghetto, wie Du vermutlich schon bemerkt hast, habe ich Deine Vorschläge nun größtenteils eingearbeitet und ein noch paar Formulierungen – wie ich meine – verbessert.
Leider ist dies noch nicht auf normalem Weg möglich
Dies impliziert einerseits, dass es seitens Canonical geplant ist, dass man ein 32-bit Ubuntu auch im EFI-Modus installieren können soll. Das bezweifle ich allerdings, da Canonical sowieso vorhat, keine 32-bit Versionen mehr anzubieten. Andererseits enthält es eine subjektive Wertung, die nicht unbedingt in ein Wiki gehört.
Das es zwischendrin irgendwie komisch aussieht, wenn ein Bug-Link gleich einen ganzen Satz umfasst, habe ich den mal mittels Spiegelpunkt abgesetzt. Wie findest Du das? Eine andere Möglichkeit wäre: Da dies auf normalem Weg nicht möglich ist, wird hier eine Anleitung dafür gegeben. Diese wurde auf einem ...
apt-ghetto schrieb: Und das Apostroph ist falsch.
Was wäre denn richtig?
Ohne Apostroph: "ins"
Aha, die Regel kannte ich noch nicht.
Aus welchen Gründen gibst du die Installation von shim-signed als optional an?
Beim 64-Bit Ubuntu 16.04 wird shim immer mitinstalliert, obwohl es für den Start von Ubuntu überflüssig ist. Vielleicht wollte man dem vorsorgen, dass andere exotische OS das shim für den Start möglicherweise zwingend brauchen.
Also kann man ein Windows{x >= 8 && x ⇐ 10} mit aktiviertem SecureBoot starten ohne shim-signed ?
Ja, bei mir geht das.
Als Wikinutzer würde mich das schon interessieren, damit ich entscheiden kann, ob es bei meiner Installation wirklich optional ist.
Könnte man erwähnen, doch denke ich, das würde den Artikel hier unnötig aufblähen. Wer über das Fehlen von shim im Zusammenhang mit einem anderen OS scheitert, wird sicher irgendwo Hinweise finden. Wüsstest Du eine passende Beschreibung, die man verlinken könnte?
Derjenige, der solche Hinweise sucht, würde sie sicher gerne in diesem Artikel vorfinden. Und viel grösser wird das Howto dadurch auch nicht.
Ich weiß aber nicht wirklich, wann genau man shim braucht, was sollte ich da hin schreiben? Wenn jemand shim braucht, wird er schon wissen warum, ich wollte nur anmerken, wie man es auf elegante Weise gleich mitinstallieren kann, was aber auch im Nachhinein ginge.
Dann probier es einfach aus.
Da verlangst Du echt was von mir. Seit 4 Wochen komme ich kaum noch zu was anderem und müsste das Prozedere jetzt noch mal durchziehen.
Dass Grub die fstab ändert, halte ich für sehr unwahrscheinlich.
Denke ich auch, deshalb vermutete ich ja, dass apt-get install ... das gemacht hat.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
noisefloor schrieb: Hm, in vielen Wiki-Artikeln gibt es Unterabschitte, die nur für bestimmte Versionen passen.
Völlig korrekt. Aber die beschreibst eine komplette Installation - das ist halt was anderes als so was wie "bis einschließlich Trusty muss man A drücken, aber ab Utopic B".
Ich meine, das "bis einschließlich Blah ..." auch ohne das "ab Blupp ..." oder umgekehrt öfters gesehen zu haben.
Außerdem ist nicht ausgeschlossen, dass der Abschnitt auch auf 14.04 und 12.04 Gültigkeit hat.
Aber du weißt es nicht und hast es nicht getestet. Das ist hier der entscheidende und wichtige Unterschied.
Deshalb steht es ja da, und bei Artikeln, wo noch nicht mal das steht, ist das auch nicht wirklich sicher, ob da jedes Detail immer wieder mit allen Versionen durchgetestet wurde. aber gut. hier muss ich mich wohl dem "Hausmeister beugen". 😉 Wird das HowTo denn dann auch noch mit dem Hauptartikel verlinkt?
Natürlich - sobald das Howto aus der Baustelle raus ist.
Fein!
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
UlfZibis schrieb: Das es zwischendrin irgendwie komisch aussieht, wenn ein Bug-Link gleich einen ganzen Satz umfasst, habe ich den mal mittels Spiegelpunkt abgesetzt. Wie findest Du das? Eine andere Möglichkeit wäre: Da dies auf normalem Weg nicht möglich ist, wird hier eine Anleitung dafür gegeben. Diese wurde auf einem ...
"Da dies auf normalem Weg nicht möglich ist, wird hier eine Anleitung dafür gegeben." apt-ghetto schrieb:
Aus welchen Gründen gibst du die Installation von shim-signed als optional an?
Beim 64-Bit Ubuntu 16.04 wird shim immer mitinstalliert, obwohl es für den Start von Ubuntu überflüssig ist. Vielleicht wollte man dem vorsorgen, dass andere exotische OS das shim für den Start möglicherweise zwingend brauchen.
Also kann man ein Windows{x >= 8 && x ⇐ 10} mit aktiviertem SecureBoot starten ohne shim-signed ?
Ja, bei mir geht das.
Gut zu wissen. Als Wikinutzer würde mich das schon interessieren, damit ich entscheiden kann, ob es bei meiner Installation wirklich optional ist.
Könnte man erwähnen, doch denke ich, das würde den Artikel hier unnötig aufblähen. Wer über das Fehlen von shim im Zusammenhang mit einem anderen OS scheitert, wird sicher irgendwo Hinweise finden. Wüsstest Du eine passende Beschreibung, die man verlinken könnte?
Derjenige, der solche Hinweise sucht, würde sie sicher gerne in diesem Artikel vorfinden. Und viel grösser wird das Howto dadurch auch nicht.
Ich weiß aber nicht wirklich, wann genau man shim braucht, was sollte ich da hin schreiben? Wenn jemand shim braucht, wird er schon wissen warum, ich wollte nur anmerken, wie man es auf elegante Weise gleich mitinstallieren kann, was aber auch im Nachhinein ginge.
Ich persönlich würde es einfach installieren und nicht als optional kennzeichnen, auch wenn man es vielleicht nicht braucht. Vielleicht hat jemand vom Wiki-Team einen Rat? Dann probier es einfach aus.
Da verlangst Du echt was von mir. Seit 4 Wochen komme ich kaum noch zu was anderem und müsste das Prozedere jetzt noch mal durchziehen.
Eigentlich musst du ja nur ein Terminal öffnen und grub-install ausführen und schauen, was dabei rauskommt. Dass Grub die fstab ändert, halte ich für sehr unwahrscheinlich.
Denke ich auch, deshalb vermutete ich ja, dass apt-get install ... das gemacht hat.
Meines Wissens wird die fstab bei der Installation angelegt. Danach wird sie nur noch vom Nutzer manuell geändert.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 2726
|
apt-ghetto schrieb: Du beziehst dich explizit auf den RAM-Verbrauch.
Nein, auch darauf, dass 32-Bit Versionen, die Adresszeiger-intensive Datenstrukturen im RAM aufbauen, auch dazu tendieren können, deutlich performanter zu Laufen. wie man an meinen Test-Szenarien mit z.B. dem Firefox sehen kann.
Möglicherweise könnte deine Anleitung auch bei einem 32-bit UEFI mit 64-bit Kernel nützlich sein?
Du meinst, wenn ein solches System mit >4 GiB RAM ausgestattet ist, denn sonst spräche ja nichts dafür, überhaupt einen 64-Bit Kernel zu verwenden. Ich kann mir allerdings kaum vorstellen, dass es Geräte mit 64-Bit-CPU gibt, die nur mit einem 32-Bit UEFI-BIOS bestückt sind. Aber selbst wenn es den von dir genannten Bedarf aus welchen Gründen auch immer geben sollte, würde der 64-Bit-Installer doch sicher erkennen, dass das vorliegende UEFI nur 32-Bit kann, und dann automatisch entsprechend das standardmäßig auch im 64-Bit-Repository vorliegende grub-efi-ia32-Paket installieren. Möglicherweise ist das mittels dem da mitinstallierten mokutil sogar secure boot fähig. apt-ghetto schrieb: "Da dies auf normalem Weg nicht möglich ist, wird hier eine Anleitung dafür gegeben."
Verstehe ich Dich richtig, dass Du lieber einen in den Textfluss eingebetteten Satz statt dem Spiegelpunkt sehen würdest? Den Link würde ich dann aber eher so verkürzen: Da dies auf normalem Weg nicht möglich ist, wird hier eine Anleitung dafür gegeben.
denn der Link verweist ja nicht auf den normalen Weg, sondern auf die Nicht-Möglickeit dessen.
Ich weiß aber nicht wirklich, wann genau man shim braucht, was sollte ich da hin schreiben? Wenn jemand shim braucht, wird er schon wissen warum, ich wollte nur anmerken, wie man es auf elegante Weise gleich mitinstallieren kann, was aber auch im Nachhinein ginge.
Ich persönlich würde es einfach installieren und nicht als optional kennzeichnen, auch wenn man es vielleicht nicht braucht. Vielleicht hat jemand vom Wiki-Team einen Rat?
Gegen das "einfach mal installieren" spricht, dass Shim ja ein UEFI-Sicherheitsmerkmal bricht. Das Ergebnis mit oder ohne wäre jedenfalls verschieden, im Gegensatz zu dem potentiell überflüssigen --efi-directory /boot/efi , das absolut keinen Unterschied macht.
Eigentlich musst du ja nur ein Terminal öffnen und grub-install ausführen und schauen, was dabei rauskommt.
Nicht wirklich, denn die jetzige Installation wurde ja schon mit --efi-directory /boot/efi bespielt, die nachträgliche Wirkung von grub-install daohne könnte evtl. nicht repräsentativ sein. Durch Verschieben und Verkleinern von Partitionen konnte ich Dir zuliebe aber noch ein Plätzchen auf der Festplatte für einen weiteren Test frei machen, ohne die jetzige Installation zerstören zu müssen. So konnte ich dann alle noch offenen Fragen sicher klären:
Nach dem Durchlaufen von ubiquity -b kommt man ohne Neustart mittels "Probieren fortsetzen" wieder in das zuvor geöffnete Terminal, und kann die weiteren Schritte erfolgreich ausführen. Die fstab wird schon durch ubiquity -b mit /dev/sda1 –> /boot/efi konfiguriert. Ich hatte allerdings auch mal den Fall, dass dies nicht so war. Das war vermutlich nach meinem ersten Test, wo ich die Fehlermeldung hatte. Da war die Installation wohl noch nicht vollständig, nachfolgender Start mittels dem GRUB aus der schon bestehenden Ubuntu-64-Bit-Installation war aber möglich, und apt-get upgrade schien alles Fehlende nachgezogen zu haben, hat halt nur nicht die fstab vervollständigt. --efi-directory /boot/efi ist tatsächlich nicht nötig.
|