staging.inyokaproject.org

Hallo,

Ich habe nun beides, Ubuntu-32 und Ubuntu-64, installiert. Das Ubuntu-32 startet über das auf dem Ubuntu-64 konfigurierte GRUB. Ich überlege nun, ob ich nun die GRUB-Konfigurationsdateien von dem Ubuntu-64 auf das Ubuntu-32 verschieben kann, um die Ubuntu-64-Installation wieder löschen zu können. Damit Ubuntu-32 dann erfolgreich bootet, müsste ich doch eigentlich nur den Eintrag search.fs_uuid in /boot/efi/EFI/ubuntu/grub.cfg anpassen.

Hat da jemand Hinweise, was da sonst vielleicht noch zu beachten wäre?

dass 32-Bit-Systeme im UEFI-Modus laufen, wäre mir neu → zeig mal bitte die kompletten Ausgaben von

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
sudo parted --list
lsb_release -a
uname -rm 

jeweils in nem Codeblock

Ich habe hier noch etwas geschrieben, was deine Frage vielleicht auch beantwortet respektive eine andere Herangehensweise aufzeigt, da ich diese Diskussion erst im Nachhinein gesehen habe.

apt-ghetto schrieb:

Ich habe hier noch etwas geschrieben, was deine Frage vielleicht auch beantwortet respektive eine andere Herangehensweise aufzeigt,

ah ok, ich hatte den Thread zwar gesehen, aber anhand des Thementitels noch nicht konkret mit dieser Frage hier in Verbindung gebracht.

Ein vorhandener "Efi-Grub" erkennt also ein 32-Bit-System und lässt es auch starten - hab ich das richtig verstanden?

So ganz bekomm ich das noch nicht zusammen, dafür braucht es noch ein paar mehr Infos - jedenfalls, spannende Frage, ob man dem UEFI ein 64-Bit-System vorgaukeln kann und dann ein 32-Bit zu benutzen.

Da fällt mir spontan der von black_tencate erwähnte stand-alone-bootloader ein, was allerdings bisher, soweit ich weiß, noch nicht für UEFI getestet wurde.

UlfZibis schrieb:

.... Damit Ubuntu-32 dann erfolgreich bootet, müsste ich doch eigentlich nur den Eintrag search.fs_uuid in /boot/efi/EFI/ubuntu/grub.cfg anpassen.

ich bezweifle, dass das ein update-grub überlebt und du brauchst ja trotzdem einen grubx64.efi → ein relativ ungefährlicher Versuch wäre auch noch, wenn du für das 32-Bit mal einen eigenen Eintrag im UEFI erstellst, dann könntest du damit "rumspielen", ohne dein 64-Bit-System zu gefährden.

Frieder108 schrieb:

Ein vorhandener "Efi-Grub" erkennt also ein 32-Bit-System und lässt es auch starten - hab ich das richtig verstanden?

Das hat nichts mit Grub zu tun. So wie ich es verstanden habe, lädt EFISTUB direkt den Kernel und nicht mehr den Bootloader, der dann den Kernel laden würde.

So ganz bekomm ich das noch nicht zusammen, dafür braucht es noch ein paar mehr Infos - jedenfalls, spannende Frage, ob man dem UEFI ein 64-Bit-System vorgaukeln kann und dann ein 32-Bit zu benutzen.

So wie ich das ganze verstehe, hat es nichts mit 32-/64-bit zu tun, sondern eher damit, dass beide Kernel EFI-tauglich kompiliert wurden, damit sie direkt vom UEFI geladen werden können.

Allerdings muss ich auch dazu sagen, dass ich weder die Zeit noch entsprechende Testgeräte habe, um da herum zu spielen. Bin aber natürlich gespannt, ob und was UlfZibis herausfindet.

Hej Frieder,

OT

Frieder108 schrieb:

... Da fällt mir spontan der von black_tencate erwähnte stand-alone-bootloader ein, was allerdings bisher, soweit ich weiß, noch nicht für UEFI getestet wurde.

wenn ich denn dereinst mal im Besitz eines EFI Rechners sein sollte, teste ich bestimmt mal das hier aus dem ArchWiki. (ist ja auch auf meiner B-Seite verlinkt.)

/OT

Gruß black tencate

black_tencate schrieb:

Hej Frieder,

hei ☺

wenn ich denn dereinst mal im Besitz eines EFI Rechners sein sollte, teste ich bestimmt mal das hier aus dem ArchWiki.

👍

Gruß black tencate

Grüßle

Frieder

Frieder108 schrieb:

dass 32-Bit-Systeme im UEFI-Modus laufen, wäre mir neu → zeig mal bitte die kompletten Ausgaben von

ich@ASUS-F200MA:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI
ich@ASUS-F200MA:~$ sudo parted --list
Modell: ATA HGST HTS545050A7 (scsi)
Festplatte  /dev/sda:  500GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name                          Flags
 1      1049kB  106MB   105MB   fat32        EFI system partition          boot, esp
 2      106MB   1050MB  944MB   ntfs         Basic data partition          versteckt, diag
 3      1050MB  1184MB  134MB                Microsoft reserved partition  msftres
 4      1184MB  44,2GB  43,0GB  ntfs         Basic data partition          msftdata
 5      44,2GB  64,2GB  20,0GB  ext4         EXT4 partition 5
 7      64,2GB  66,2GB  2000MB  ext4         EXT4 partition 7
 8      66,2GB  86,2GB  20,0GB  ext4         EXT4 partition 8
 9      86,2GB  88,2GB  2000MB  ext4         EXT4 partition 9
10      88,2GB  387GB   299GB   ntfs         Basic data partition          msftdata
11      387GB   437GB   49,6GB  ntfs         Basic data partition          msftdata
 6      479GB   500GB   21,5GB  ntfs         Basic data partition          versteckt, diag


ich@ASUS-F200MA:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.1 LTS
Release:	16.04
Codename:	xenial
ich@ASUS-F200MA:~$ uname -rm 
4.4.0-47-generic i686

Sieht so aus, dass das Ubuntu-32 auch im EFI-Modus läuft entgegen mancher Annahmen.

Auch dieser Eintrag in der fstab deutet darauf hin:

UUID=BC5C-B7DD  /boot/efi       vfat    umask=0077      0       1

UlfZibis schrieb:

Sieht so aus, dass das Ubuntu-32 auch im EFI-Modus läuft entgegen mancher Annahmen.

ja, tatsächlich - ich dachte auch, dass das nicht geht → darum auch erst mal die diversen Nachfragen. 😉

Hmm, dann würde ich jetzt mal hergehen, und für das 64-Bit-System einen neuen Booteintrag erstellen und dann auch kontrollieren, ob er funtioniert.

Wenn du dann über den neu erstellten Eintrag gestartet hast, ein

sudo update-grub

ausführen, um zu kontrollieren, dass da das 32-Bit-System gelistet wird und dann über diesen Eintrag starten → wenn das auch funzt, dann einfach im 32er System ein

sudo grub-install

anwerfen, die ESP sollte automatisch gefunden werden und den ursprünglichen Eintrag des 64er-Systemes überschreiben.

Sollte das ohne Fehlermeldung durchlaufen, dann neustarten und beten 😀

Sollte bereits beim grub-install ein Fehler kommen, hast du immer noch den selbst erstellten Eintrag im UEFI, um wieder an deine Systeme ranzukommen.

Also soweit meine vielleicht etwas laienhafte Theorie - wünsche gutes Gelingen.

Greetz

Frieder

p.s. ein funtionierendes Livesystem bereit zu halten, schadet nicht, da, wenn was schief läuft, du immer noch via Chroot in die Systeme rein könntest.

Frieder108 schrieb:

Ein vorhandener "Efi-Grub" erkennt also ein 32-Bit-System und lässt es auch starten - hab ich das richtig verstanden?

Ich denke schon, dass es ganau so ist.

So ganz bekomm ich das noch nicht zusammen, dafür braucht es noch ein paar mehr Infos - jedenfalls, spannende Frage, ob man dem UEFI ein 64-Bit-System vorgaukeln kann und dann ein 32-Bit zu benutzen.

Ein 64-Bit-GRUB braucht nichts vorgaukeln, es ist 64-Bit und kann mittels Shim starten, was ihm beliebt.

ich bezweifle, dass das ein update-grub überlebt

Warum, damit wird doch nur die grub.cfg verändert? Richtig spannend wird's erst mit install-grub, was bei einer Ubuntu-Aktualisierung dann auch mal unbemerkt "hintenherum" passieren könnte.

→ ein relativ ungefährlicher Versuch wäre auch noch, wenn du für das 32-Bit mal einen eigenen Eintrag im UEFI erstellst, dann könntest du damit "rumspielen", ohne dein 64-Bit-System zu gefährden.

Ich guck mal, ob ich das hinbekomme.

apt-ghetto schrieb:

Ein vorhandener "Efi-Grub" erkennt also ein 32-Bit-System und lässt es auch starten - hab ich das richtig verstanden?

Das hat nichts mit Grub zu tun. So wie ich es verstanden habe, lädt EFISTUB direkt den Kernel und nicht mehr den Bootloader, der dann den Kernel laden würde.

Wie kommst Du darauf, dass EFISTUB in's Spiel kommt und den Kernel direkt lädt? Ich lade das 32-Bit-Ubuntu im jetzigen Zustand hier über das GRUB-Menü.

So ganz bekomm ich das noch nicht zusammen, dafür braucht es noch ein paar mehr Infos - jedenfalls, spannende Frage, ob man dem UEFI ein 64-Bit-System vorgaukeln kann und dann ein 32-Bit zu benutzen.

So wie ich das ganze verstehe, hat es nichts mit 32-/64-bit zu tun, sondern eher damit, dass beide Kernel EFI-tauglich kompiliert wurden, damit sie direkt vom UEFI geladen werden können.

Wie gesagt, ich lade beide Systeme hier über GRUB.

Bin aber natürlich gespannt, ob und was UlfZibis herausfindet.

Ich auch 😉

UlfZibis schrieb:

apt-ghetto schrieb:

Ein vorhandener "Efi-Grub" erkennt also ein 32-Bit-System und lässt es auch starten - hab ich das richtig verstanden?

Das hat nichts mit Grub zu tun. So wie ich es verstanden habe, lädt EFISTUB direkt den Kernel und nicht mehr den Bootloader, der dann den Kernel laden würde.

Wie kommst Du darauf, dass EFISTUB in's Spiel kommt und den Kernel direkt lädt?

Du hast nicht verstanden, was ich geschrieben habe.

Zeig mal im gestarteten Ubuntu-32 die Ausgabe von

ls /sys/firmware

apt-ghetto schrieb:

Du hast nicht verstanden, was ich geschrieben habe.

Und nun ?

UlfZibis schrieb:

Damit Ubuntu-32 dann erfolgreich bootet, müsste ich doch eigentlich nur den Eintrag search.fs_uuid in /boot/efi/EFI/ubuntu/grub.cfg anpassen.

Den Schritt habe ich nach dem Studieren Eurer Hinweise nun mal gewagt. Vorher noch eine grub.cfg aus dem 32.Bit-Ubuntu heraus erzeugt (die befindet sich dann zunächst auf der 64er-Partition) und in die 32er-Partition kopiert.

Es funktioniert tatsächlich, allerdings werden im GRUB-Menü der Blockgrafikrahmen und sämtliche NICHT-ASCII- durch '?' ersetzt. Das wird sich vermutlich bessern, wenn ich die Ordner fonts, local, themes, x86_64-efi auch noch von der 64er auf die 32er-Partition kopiere. Erstaunlich, dass GRUB überhaupt ohne die Module aus x86_64-efi funktioniert.

EDIT: Ich habe die Ordner nun rüber kopiert, und auch die /boot/grub/grub.cfg auf der 64er gelöscht. So kann ich sicher sein, dass wirklich die grub.cfg und die Module von der 32er-Partition geladen werden.
Ergebnis: GRUB zeigt wieder das korrekte Erscheinungsbild und funktioniert einwandfrei. Theoretisch kann ich also jetzt die 64er-Ubuntu-Partition löschen, und habe eine eine funktionsfähige Ubunt-32-Installation auf meinem EFI-SecureBoot-Netbook. Juhuu !!!

Nun noch eine Frage an die Spezialisten. Wenn nun GRUB mal über die Ubuntu-Aktualisierung erneuert werden sollte muss ich doch den Paketquellen/listen irgendwie beibringen, dass nun 64-Bit Pakete upgedatet werden müssen, und nur diese neu installiert werden müssen. Ich habe ja jetzt die kuriose Situation, in einem 32-Bit-Ubuntu unter /boot/grub/x86_64-efi 64-Bit-Pakete installiert zu haben. Wie könnte ich das bewerkstelligen?

Man kann auch einfach Grub im laufenden System mit der Option --force-extra-removable installieren. Es wird zwar kein Booteintrag erstellt, da kein Zugriff auf die efivars möglich ist, aber es wird eine Grub Startdatei entsprechend dem Vorgehen in EFI Externer-Datenträger nach /boot/efi/EFI/boot installiert. Bei Auswahl der Platte als Bootmedium wird von der EFI-Firmware dieses Datei und damit das 386er System gestartet.

# Die Kommentare hinter der Raute kannst Du beim kopieren natürlich auch weglassen
sudo apt install grub-efi-amd64 # Du hast ein 64bit-EFI, bei einem 32-Bit-EFI wäre ein grub-efi-ia32 erforderlich - die Architektur der zu startenden Installation ist irrelevant
sudo mount /dev/sda1 /boot/efi # wenn die EFI-Partition bereits eingehängt ist, entfällt das natürlich
sudo grub-install --efi-directory /boot/efi --force-extra-removable -no-uefi-secure-boot

Damit sollte Dein System zu starten sein - bei Auswahl der Platte als Bootmedium.

[Edit:]

UlfZibis schrieb:

Theoretisch kann ich also jetzt die 64er-Ubuntu-Partition löschen, und habe eine eine funktionsfähige Ubunt-32-Installation auf meinem EFI-SecureBoot-Netbook. Juhuu !!!

Das bezweifle ich. Bennne mal den Order /boot in der 64er Partition um und versuche zu starten.