staging.inyokaproject.org

UlfZibis schrieb:

apt-ghetto schrieb:

Möglicherweise könnte deine Anleitung auch bei einem 32-bit UEFI mit 64-bit Kernel nützlich sein?

[...] 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.

Doch, die gibt es.

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.

Wäre schön und praktisch. Dem ist einigen Forenbeiträgen zufolge allerdings nicht so.

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?

Ja.

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.

Du hast mich überzeugt.

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.

Danke für die Recherche. Dann spricht wirklich nichts dagegen, das Paket als optional anzugeben.

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.

Gut.

• 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.

Das mit der fstab finde ich noch wichtig im HowTo.

• --efi-directory /boot/efi ist tatsächlich nicht nötig.

Dann schlage ich sowas wie

grub-install  # Option: --efi-directory /boot/efi  

Falls ein grub-install fehlschlägt, kann man es noch mit der Option --efi-directory /boot/efi versuchen.

vor.

Hallo,

kleine Zwischenbemerkung: wenn alles soweit ist bitte hier posten, dass es fertig ist. Und das "fertig" am besten _nicht_ in einem ellenlangen Post "verstecken".

Gruß, noisefloor

apt-ghetto schrieb:

Doch, die gibt es.

"Nichts ist unmöglich ... Ubuntuuu!"

Wäre schön und praktisch. Dem ist einigen Forenbeiträgen zufolge allerdings nicht so.

Aha, dann könnte diese Anleitung da sicher auch sinngemäß funktionieren, mit --add-architecture i386 und grub-efi-ia32. Wenn das fertige HowTo wieder als Abschnitt von EFI installieren eingefügt ist, könntest Du ja dort in einem weiteren Abschnitt auf die mögliche, aber noch nicht getestete, Übertragbarkeit hinweisen.

Danke für die Recherche. Dann spricht wirklich nichts dagegen, das Paket als optional anzugeben.

Habe nun einen Sicherheitshinweis hinzugefügt, das sollte Potentaten ausreichend auf die Nötigkeit weiterer Recherche hinweisen.

Das mit der fstab finde ich noch wichtig im HowTo.

Das wird nun durch den nun am Ende eingefügten Funktionstest abgedeckt. Wenn da dann was nicht geht, denke ich, ist das dann ein Fall fürs Forum, wenn der Nutzer aufgrund der Fehlermeldungen nicht von selbst auf die Ursache kommt.

• --efi-directory /boot/efi ist tatsächlich nicht nötig.

Dann schlage ich sowas wie

grub-install  # Option: --efi-directory /boot/efi  

Falls ein grub-install fehlschlägt, kann man es noch mit der Option --efi-directory /boot/efi versuchen.

Ich denke, das können wir uns sparen, aber ich habe mal was ergänzt.

UlfZibis schrieb:

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!

Von meiner Seite ist der Abschnitt nun "ready to go" to EFI Installieren 🐸

noisefloor schrieb:

kleine Zwischenbemerkung: wenn alles soweit ist bitte hier posten, dass es fertig ist. Und das "fertig" am besten _nicht_ in einem ellenlangen Post "verstecken".

Oops, übersehen, also von meiner Seite aus:

"fertig"

Hier könnte man dann noch die Einschränkung auf 64-Bit relativieren: https://wiki.ubuntuusers.de/Ubuntu_Installation/#Voraussetzungen

Hallo,

das Howto ist verschoben, Danke für's Erstellen!

Gruß, noisefloor

Hallo,

es ist mehr sinnvoll zu schreiben wie man die Verzeichnis /mnt/boot/efi /mnt/dev /mnt/proc /mnt/sys etc. auch wieder unmounted/aushängt.

Auf einem System ohne Secure boot war es bei mir ausreichend für einen live usb stick den Grub von einer livecd64 bit auf diesen Stick zu schreiben. Natürlich muss der bootparameter von vmlinux.efi auf vmlinux angepasst werden.

Die Partition des efi Bootloaders findet man am besten mit gparted.kleine fat partition. Bei meinem Laptop sda2 um die 300mb. sda1 windows. sda3 +4+5 recovery sda6 ext4 der /.

Wichtig ist es die uuid der installierten linux Partition auf der efi partition auch gegebenenfalls in einer config Datei vom grub bootloader deinzutragen.

Eventuell Paket Konflikt mit grub-gfxpayload grub-pc.

Bezüglich ubiquity -b Es ist zu beacbten, dass die Partition bei meinem erfolgreichen Versuch von ubiquity weder formatiert noch in der Grösse verändert wurde. D.h Dateisystem vorher anlegen, gleiches format anlegen und nicht auf formatieren klicken.

Hallo,

der letzte Test diesen Howtos liegt mehr als 12 Monaten zurück. Bitte in den nächsten Woche erneut testen und das Testdatum eintragen, damit das Howto nicht gem. den Richtlinien für Howtos zwangsarchiviert wird.

Gruß, noisefloor

@ bluedxca93 Leider verstehe ich überhaupt nicht, was Du uns eigentlich sagen willst, und was warum geändert werden sollte.

Ich ziehe zurück. 😉

axt schrieb:

Steht alles geschrieben: Howto/#Archivierung-von-Howtos.

Da soll also stehen, was bluedxca93 meint 😈

@ UlfZibis Mein Test war mit Ubuntu Mate 17.10.

ubiquity ist der installationsasistent von ubuntu. ubuntu wird auf eine Partition installiert.Normalerweise wird diese auch formatiert. Das konnte ubiquity nicht, auf eine leere Partition installieren ging aber.

grub-gfxpayload und grub-pc hindern die Installation des uefi grub

Du mountest vereinfacht gesagt indie Partition Geräteschnittstellen vor dem chroot. Allerdings ist es sinvoll nach dem Arbeiten in dem.chroot diese wieder auszuhängen.

Es ist so das auch da ein chroot ausgeführt wird.

bluedxca93 schrieb:

@ UlfZibis Mein Test war mit Ubuntu Mate 17.10.

Hm, vielleicht ist Ubuntu Mate 17.10 ja ein bisschen anders gestrickt.

ubiquity ist der installationsasistent von ubuntu. ubuntu wird auf eine Partition installiert.Normalerweise wird diese auch formatiert. Das konnte ubiquity nicht, auf eine leere Partition installieren ging aber.

Hast Du denn auch die option -b verwendet? Bei mir ging das ohne Probleme. Ob ich da eine leere Partition verwendet hatte, weiß ich nicht mehr, jedenfalls war sie zumindest formatiert. Ich hatte allerdings die Partitionen schon vorher mit GParted angelegt, und die Installation mit der Variante "Was anderes" vorgenommen. Damit sollte man auch Partitionen sowohl verschieben, in der Größe ändern, löschen, als auch neuanlegen können. Würde mich wundern, wenn die anderen Varianten nicht gehen sollten. Vielleicht ist es aber tatsächlich so, dass die 32-Bit-Live-CD tatsächlich nur ein abgespecktes parted ohne EFI-Werkzeuge zur Verfügung stellt. Dann sollte man im HowTo tatsächlich erwähnen, dass nur die Variante "Was anderes" erfolgreich ist, und die gewünschten Partitionen vorher erstellt werden müssen. Aber eigentlich kann das nicht so sein, denn auf der Live-CD ist ein GParted, das vollumfänglich funktionieren sollte. Wenn ich mich richtig erinnere, hatte ich wahrscheinlich GParted von der Partition-Magic-CD verwendet.

grub-gfxpayload und grub-pc hindern die Installation des uefi grub

apt-get install grub-efi-amd64 hat bei mir grub-gfxpayload und grub-pc automatisch deinstalliert, war das bei Dir nicht so?

Du mountest vereinfacht gesagt indie Partition Geräteschnittstellen vor dem chroot.

Ich verstehe nicht ganz, was Du mir damit sagen willst.

Allerdings ist es sinvoll nach dem Arbeiten in dem.chroot diese wieder auszuhängen.

Da man nach der Verwendung der chroot-Umgebung sofort neustartet, passiert das doch automatisch, ich denke das sollte kein Problem darstellen.

LiveCD manuell remastern Es ist so das auch da ein chroot ausgeführt wird.

Ja nichts dagegen, so kann man es vielleicht auch machen.

@UlfZibis Die Festplattentabelle ist bei mir gpt. Gparted funktioniert problemlos. Dort Partition erstellt. Anschliessend was anderes in ubiquity mit -b ausgewählt. Jetzt kommt das Problem: Verwenden als root Verzeichnis auf der ext4 Partition ankreuzen ohne in ubiquity zu formatieren. Dann läuft das Installationsprogramm in unter 1h normal durch.

ubiquity kann nicht formatieren und danach installieren in diesem Setup. Also vorher formatieren und dann nur auswählen.

grub-gfxpayload und grub-pc wurden bei mir zumindest nicht automatisch deinstalliert.

bluedxca93 schrieb:

Jetzt kommt das Problem: Verwenden als root Verzeichnis auf der ext4 Partition ankreuzen ohne in ubiquity zu formatieren. Dann läuft das Installationsprogramm in unter 1h normal durch.

Meinst Du mit root den Einhängepunkt / oder /root ?

ubiquity kann nicht formatieren und danach installieren in diesem Setup. Also vorher formatieren und dann nur auswählen.

Sieht so aus, als müsste ich da einen Hinweis ergänzen. Hier mal ein Vorschlag:

Deckt sich das mit Deinen Erfahrungen, oder soll ich da noch was ändern?

grub-gfxpayload und grub-pc wurden bei mir zumindest nicht automatisch deinstalliert.

Wie konntest Du denn dann grub-efi-amd64 installieren, wenn grub-gfxpayload und grub-pc das verhindern?