ubuntuusers.de

Hej UlfZibis,

UlfZibis schrieb:

...Das dürfte aber dann spätestens bei der Nächsten Aktualisierung von GRUB oder eines Kernels dann doch automatisch passieren...

natürlich nicht, wie kommst Du darauf? Ich fahre seit je her einen stand-alone grub mit Distris, entweder mit "grub im MBR", oder per "ubiquity -b", der grub-MBR ist ausschließlich durch den stand-alone grub 'besetzt'.

Gruß black tencate

Hallo UlfZibis,

Normalerweise gibt es doch keine 32-bit Version von Ubuntu (Gnome) 18.04. Ist es möglich die grub Pakete danach einfach zu deinstallieren ?

Also wenn ich Pakete in Synaptik sperre, werden diese bei mir nicht aktualisiert. Auch werden sie nicht in der Aktualisierungsverwaltung angezeigt. Ich darf nur nicht ein:

sudo apt-get update & upgrade

im Terminal machen.

PS: Ich meinte die grub-efi-ia32. Hast du auch mal versucht den Eintrag in den NVRAM per Terminal mit dem Programm wo man ermitteln kann ob der Rechner EFI bzw. BIOS kann zu setzen.

Gruss Lidux

black_tencate schrieb:

...entweder mit "grub im MBR"

Oops, ich wollte natürlich sage PBR

Gruß black tencate

Hej black_tencate,

black_tencate schrieb:

UlfZibis schrieb:

...Das dürfte aber dann spätestens bei der Nächsten Aktualisierung von GRUB oder eines Kernels dann doch automatisch passieren...

natürlich nicht, wie kommst Du darauf? Ich fahre seit je her einen stand-alone grub mit Distris, entweder mit "grub im MBR", oder per "ubiquity -b", der grub-MBR ist ausschließlich durch den stand-alone grub 'besetzt'.

Ich hab' das jetzt mal mit dem neu aufgesetzten BIOS-Rechner probiert. Die Aktualisierung, zumindest per Synaptic, installiert zwar die die GRUB-Pakete wieder, fragt mich dann aber ob und wo (sda/MBR oder sda9/PBR) ich GRUB installiert haben möchte. wenn ich das überspringe, wird GRUB tatsächlich nicht installiert. Ich hoffe, dass das dann über die normalen Aktualisierungen auch so geht. Auf dem EFI-Rechner ist das aber leider nicht so. Möglicherweise hat sich das System irgendwo den Ort gemerkt, wo beim ersten Mal von sudo apt-get install grub-efi-amd64-signed && grub-install GRUB installiert wurde, und installiert deswegen ohne Rückfrage. Hat jemand eine Idee, wo das System sich das merkt, dann könnte ich das ja da löschen?

Lidux schrieb:

Normalerweise gibt es doch keine 32-bit Version von Ubuntu (Gnome) 18.04. Ist es möglich die grub Pakete danach einfach zu deinstallieren ?

Klar geht das, sie werden aber mittels Aktualisierungen immer wieder neu installiert.

Also wenn ich Pakete in Synaptik sperre, werden diese bei mir nicht aktualisiert. Auch werden sie nicht in der Aktualisierungsverwaltung angezeigt.

Bei mir schon.

Ich darf nur nicht ein:

sudo apt-get update & upgrade

im Terminal machen.

Was nutzt mir das, wenn die normalen Aktualisierungen das dann doch automatisch tun?

PS: Ich meinte die grub-efi-ia32.

Das geht nicht auf dem 64-Bit-EFI-BIOS.

Hast du auch mal versucht den Eintrag in den NVRAM per Terminal mit dem Programm wo man ermitteln kann ob der Rechner EFI bzw. BIOS kann zu setzen.

Siehe 1650337.

Hallo UlfZibis,

Mit efibootmgr kann man doch Einträge in dem NVRAM erzeugen. Außerdem gibt es doch eine Distribution wo im Live Modus ein Starten einer 32-bit Version möglich ist. Vielleicht findest du da in der Datenstruktur eine Lösung .....

PS: Ist bei deinem Rechner im EFI ... das EFI only oder der der mixed Mode eingestellt ?

Gruss Lidux

Lidux schrieb:

Mit efibootmgr kann man doch Einträge in dem NVRAM erzeugen. Außerdem gibt es doch eine Distribution wo im Live Modus ein Starten einer 32-bit Version möglich ist. Vielleicht findest du da in der Datenstruktur eine Lösung .....

Wie der oben angeführte Bug schon sagt, nur 64-Bit-Ubuntu unterstützt das.
Das Live-Medium braucht und installiert ja kein GRUB, wo sollte ich da was finden, was für eine Festinstallation gilt?

PS: Ist bei deinem Rechner im EFI ... das EFI only oder der der mixed Mode eingestellt ?

Ganz genau kann ich das nicht sagen, da das BIOS-Setup da unklar ist. Jedenfalls wird grundsätzlich erst mal EFI verwendet. Schon das darauf original befindliche Windows 8.1 läuft unter EFI, und GRUB und meine Ubuntu-Installationen auch.

Hallo UlfZibis,

Die entsprechende iso vielleicht runterladen, dann entpacken und in einer Ordnerstruktur müsste etwas liegen womit das booten einer 32-bit Version ermöglicht wird.

Du hast doch ein 64-bit Ubuntu ja noch installiert, so dass ein Eintrag für die 32-bit Version erstellt werden könnte.

Gruss Lidux

Hallo zusammen, ich habe jetzt noch mal wieder auf dem 32-Bit EFI-64 Ubuntu 18.04 weiter experimentiert:

$ sudo apt-get purge grub*
[.....]
Die folgenden Pakete werden ENTFERNT:
  grub-common* grub-efi-amd64* grub-gfxpayload-lists* grub-pc* grub-pc-bin*
  grub2-common* os-prober*
[.....]

Ein nachfolgendes sudo apt-get update && sudo apt-get dist-upgrade hat diesmal keinen GRUB nachinstalliert. Komisch, warum war das nicht immer so, oder machen die automatischen Aktualisierungen noch was anderes?

Eine weitere interessante Info ... die Linux-Kernel-Pakete sind abhängig von GRUB:

$ sudo apt-cache rdepends grub-pc
grub-pc
Reverse Depends:
  lupin-support
 |ubiquity
    grub-pc:amd64
 |linux-image-4.15.0-24-lowlatency
    grub-pc:amd64
 |linux-image-4.15.0-24-generic
    grub-pc:amd64
  [.....]

Von daher ist nachvollziehbar, warum GRUB spätestens beim Kernel-Update mit- bzw. wieder neu installiert wird. Warum ein 32-Bit Kernel von einem amd64-Paket abhängig ist, kapiere ich aber nicht.

apt-ghetto schrieb:

In etwa so: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=problemgrub

Auch das habe ich jetzt mal probiert, dafür musste ich zuerst aber wieder grub-efi- installieren:

$ sudo apt-get install grub-efi-amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  grub-common grub-efi-amd64-bin grub2-common os-prober
Vorgeschlagene Pakete:
  multiboot-doc grub-emu xorriso desktop-base
Die folgenden NEUEN Pakete werden installiert:
  grub-common grub-efi-amd64 grub-efi-amd64-bin grub2-common os-prober
0 aktualisiert, 5 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 0 B von 3.159 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 18,0 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Vorkonfiguration der Pakete ...
Vormals nicht ausgewähltes Paket grub-common wird gewählt.
(Lese Datenbank ... 192701 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../grub-common_2.02-2ubuntu8_i386.deb ...
Entpacken von grub-common (2.02-2ubuntu8) ...
Vormals nicht ausgewähltes Paket grub2-common wird gewählt.
Vorbereitung zum Entpacken von .../grub2-common_2.02-2ubuntu8_i386.deb ...
Entpacken von grub2-common (2.02-2ubuntu8) ...
Vormals nicht ausgewähltes Paket os-prober wird gewählt.
Vorbereitung zum Entpacken von .../os-prober_1.74ubuntu1_i386.deb ...
Entpacken von os-prober (1.74ubuntu1) ...
Vormals nicht ausgewähltes Paket grub-efi-amd64-bin wird gewählt.
Vorbereitung zum Entpacken von .../grub-efi-amd64-bin_2.02-2ubuntu8_i386.deb ...
Entpacken von grub-efi-amd64-bin (2.02-2ubuntu8) ...
Vormals nicht ausgewähltes Paket grub-efi-amd64 wird gewählt.
Vorbereitung zum Entpacken von .../grub-efi-amd64_2.02-2ubuntu8_i386.deb ...
Entpacken von grub-efi-amd64 (2.02-2ubuntu8) ...
Trigger für ureadahead (0.100.0-20) werden verarbeitet ...
Trigger für install-info (6.5.0.dfsg.1-2) werden verarbeitet ...
grub-common (2.02-2ubuntu8) wird eingerichtet ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Trigger für systemd (237-3ubuntu10) werden verarbeitet ...
Trigger für man-db (2.8.3-2) werden verarbeitet ...
grub-efi-amd64-bin (2.02-2ubuntu8) wird eingerichtet ...
grub2-common (2.02-2ubuntu8) wird eingerichtet ...
os-prober (1.74ubuntu1) wird eingerichtet ...
grub-efi-amd64 (2.02-2ubuntu8) wird eingerichtet ...

Creating config file /etc/default/grub with new version
x86_64-efi wird für Ihre Plattform installiert.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: Fehler: efibootmgr failed to register the boot entry: Datei oder Verzeichnis nicht gefunden.
Failed: grub-install --target=x86_64-efi  
WARNING: Bootloader is not properly installed, system may not be bootable
Trigger für ureadahead (0.100.0-20) werden verarbeitet ...

Wie man sieht, wird dabei schon automatisch grub-install ausgeführt. Leider ist danach dann auch die GRUB-Installation des Erst-Systems Ubuntu-32 16.04 zerstört. Muss also dann mit chroot rein. Mit grub-efi-amd64-signed bekomme ich sogar einen APT-Report. Nachfolgenden Befehl kann man sich also sparen:

$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu-18.04
x86_64-efi wird für Ihre Plattform installiert.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: Fehler: efibootmgr failed to register the boot entry: Datei oder Verzeichnis nicht gefunden.

Aber eigentlich müsstest du herausfinden, wo das bei Ubuntu gesteuert wird. Sonst wird beim nächsten grub-install wieder ins falsche Verzeichnis installiert.

Ich habe mal mittels grep in /etc/ herumgesucht, aber leider nichts finden können.

Lidux schrieb:

Die entsprechende iso vielleicht runterladen, dann entpacken und in einer Ordnerstruktur müsste etwas liegen womit das booten einer 32-bit Version ermöglicht wird.

Auch da habe ich leider nichts finden können.

Du hast doch ein 64-bit Ubuntu ja noch installiert, so dass ein Eintrag für die 32-bit Version erstellt werden könnte.

Das könnte gehen, damit z.B. /boot/efi/EFI/Ubuntu-18.04 anzulegen. Wie man oben sieht, passiert aber schon beim Paket-Installieren der Versuch, ins Standard-Verzeichnis /boot/efi/EFI/Ubuntu zu installieren.

Hallo UlfZibis,

Habe ich dich richtig verstanden für diesen Rechner: Dein Erstsystem ist ein 16.04 (32-bit) auf einem 64-bit Rechner mit einem 32-bit Efi .... das Zweitsystem ein 64-bit System von 18.04 ?

Ich dachte du möchtest auf einem 64-bit Rechner / EFI ein 64-bit System als Erstsystem und ein 32-bit als Zweitsystem.

Gruss Lidux

Lidux schrieb:

Habe ich dich richtig verstanden für diesen Rechner: Dein Erstsystem ist ein 16.04 (32-bit) auf einem 64-bit Rechner mit einem 32-bit Efi .... das Zweitsystem ein 64-bit System von 18.04 ?

Nein, nicht ganz ... Erstsystem ist ein 16.04 (32-bit) auf einem 64-bit Rechner mit einem 64-bit Efi .... das Zweitsystem ein ebenfalls 32-bit System von 18.04.
Alles nach Howto/Installation von 32-Bit Ubuntu auf EFI-System. Sobald sich das Zweitsystem bewähren sollte, kann das Erstsystem runter.

Außerdem gibt es darauf noch ein Windoof 8.1 und ein 16.04 (64-bit), letzteres aber nur als Notlösung, falls mal was nicht geht. Sobald ich sicher bin, dass die 32-Bit-Systeme laufen, kann das auch runter.

Hab' das jetzt nochmal probiert, nachdem ich über das 64-Bit-Ubuntu einen zusätzlichen Eintrag EFI\Ubuntu-18.04 im NVRAM erstellt habe:
UlfZibis schrieb:

 $ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu-18.04
x86_64-efi wird für Ihre Plattform installiert.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: Fehler: efibootmgr failed to register the boot entry: Datei oder Verzeichnis nicht gefunden.

Es kommen immer noch diese Fehlermeldungen, aber die GRUB-Installation des Erstsystems bleibt heile dabei. Bin mal gespannt, wie lange das hält. Der Fehler mit grub-efi-amd64-signed besteht weiterhin. So lässt sich das Zweitsystem nach sudo grub-install && sudo update-grub nun auch über das EFI-Boot-Menü direkt starten, halt nur ohne secure boot.

Aber eigentlich müsstest du herausfinden, wo das bei Ubuntu gesteuert wird. Sonst wird beim nächsten grub-install wieder ins falsche Verzeichnis installiert.

Da bin ich immer noch ratlos.

Hallo UlfZibis,

Wie wurde das W8 eigentlich installiert und startet das überhaupt noch ?

Das (L)ubuntu 18.04 (32 bit) kann mit dem Eintrag im EFI Menue gestartet werden.

Nach meinem Kenntnisstand wird Grub2 bei einer vorhandenen EFI Partition immer dorthin installiert und dann der NVRAM Eintrag erzeugt.

Kannst du bitte noch mal nachsehen wie im EFI dies eingestellt ist (EFI, Mixed Mode etc.)

Gruss Lidux

Hallo UlfZibis,

Einen Booteintrag für den EFI der 32-bit Versionen kannst du bestimmt auch mit dieser Anleitung https://wiki.ubuntuusers.de/efibootmgr/ erstellen ohne Grub2 Zeugs.

Dann kannst du auch gleich aufräumen um die nicht funktionierenden Einträge aus dem NVRAM entfernen.

In dem Hauptartikel ist auch die Möglichkeit aufgelistet von EFI Grub auf BIOS Grub umzusatteln für einzelne Systeme. Das scheint mir aber recht kompliziert zu sein .....

PS: Wichtig ist wahrscheinlich nur die entsprechenden Einstellungen zu SecurBoot und EFI / Mixed Mode / CSM im EFI.

Gruss Lidux

Lidux schrieb:

Wie wurde das W8 eigentlich installiert und startet das überhaupt noch ?

Genau weiß ich das nicht, es ist noch die original Werksinstallation. Es startet jedenfalls noch.

Das (L)ubuntu 18.04 (32 bit) kann mit dem Eintrag im EFI Menue gestartet werden.

Ja, und genauso das Ubuntu 16.04 (32 Bit).

Nach meinem Kenntnisstand wird Grub2 bei einer vorhandenen EFI Partition immer dorthin installiert und dann der NVRAM Eintrag erzeugt.

Letzteres ist bei der 18.04 (32 Bit), zumindest als Zweitsystem, gescheitert. Bei der 16.04 funktionierte es wie in der Anleitung.

Kannst du bitte noch mal nachsehen wie im EFI dies eingestellt ist (EFI, Mixed Mode etc.)

Guck ich nachher mal.

Hier noch das mit Ubuntu-64 16.04 erstellte Listing:

ich@ASUS-F200MA:~$ sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003,0004,0001,0005,0006,0007,0008
Boot0000* Ubuntu
Boot0001* Windows Boot Manager
Boot0002* Windows Boot Manager
Boot0003* Ubuntu-18.04
Boot0004* Ubuntu-64
Boot0005* UEFI: UDISK PDU01_4G 8AI2.0 0.00
Boot0006* UEFI:CD/DVD Drive
Boot0007* UEFI:Removable Device
Boot0008* UEFI:Network Device
ich@ASUS-F200MA:~$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003,0004,0001,0005,0006,0007,0008
Boot0000* Ubuntu	HD(1,GPT,671281f8-513a-46b7-8cd7-ff6fed6d5eca,0x800,0x32000)/File(\EFI\UBUNTU\GRUBX64.EFI)
Boot0001* Windows Boot Manager	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0002* Windows Boot Manager	HD(1,GPT,671281f8-513a-46b7-8cd7-ff6fed6d5eca,0x800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0003* Ubuntu-18.04	HD(1,GPT,671281f8-513a-46b7-8cd7-ff6fed6d5eca,0x800,0x32000)/File(\EFI\Ubuntu-18.04\grubx64.efi)
Boot0004* Ubuntu-64	HD(1,GPT,671281f8-513a-46b7-8cd7-ff6fed6d5eca,0x800,0x32000)/File(\EFI\Ubuntu-64\grubx64.efi)
Boot0005* UEFI: UDISK PDU01_4G 8AI2.0 0.00	PciRoot(0x0)/Pci(0x14,0x0)/USB(4,0)/USB(2,0)/HD(1,MBR,0x92,0x800,0x787800)..BO
Boot0006* UEFI:CD/DVD Drive	BBS(129,,0x0)
Boot0007* UEFI:Removable Device	BBS(130,,0x0)
Boot0008* UEFI:Network Device	BBS(131,,0x0)

Von dem 64-Bit Ubuntu 16.04 aus wird mit

$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu-64

allerdings shimx64.efi eingetragen, welcher ja das secure boot kolportiert. Das habe ich dann repariert mit:

$ sudo efibootmgr -b 4 -B
$ sudo efibootmgr --create-only -b 4 --disk /dev/sda --part 1 --label "Ubuntu-64" --loader \\EFI\\Ubuntu-64\\grubx64.efi
$ sudo efibootmgr -o 0,2,3,4,1,5,6,7,8

Lidux schrieb:

Einen Booteintrag für den EFI der 32-bit Versionen kannst du bestimmt auch mit dieser Anleitung https://wiki.ubuntuusers.de/efibootmgr/ erstellen ohne Grub2 Zeugs.

Ja, aber nur mittels der Nothilfe über des 64-Bit Ubuntu. Und ganz ohne Grub geht's ja auch nicht, man kann ja vom EFI-Bootmenü nicht direkt den Linux-Kernel starten.

Dann kannst du auch gleich aufräumen um die nicht funktionierenden Einträge aus dem NVRAM entfernen.

Genau, sieht man an den Einträgen, die durch das Booten über USB entstanden sind.

Lidux schrieb:

PS: Wichtig ist wahrscheinlich nur die entsprechenden Einstellungen zu SecurBoot und EFI / Mixed Mode / CSM im EFI.

Im BIOS-Setup gibt es keinen Mixed Mode, nur "Launch CSM" [enabled] / [disabled]. letzteres habe ich eingestellt, doch soweit ich mich an früheres forsten im Netz bzgl. des ASUS-F200MA erinnern kann, entspricht das einem Mixed Mode. [enabled] soll dann NUR BIOS-Mode sein. Weiterhin ist secure boot z.Zt. disabled, da ich ja für 18.04 den signed-Typ nicht installieren kann.

EDIT: Hab' jetzt mal spaßeshalber secure boot eingeschaltet. Oh Wunder, er bootet dennoch in alle 3 Ubuntu-Systeme, allerdings etwas schleppender, vermutlich weil im normalen grubx64.efi nicht alle dafür nötigen Module drin sind, die GRUB dann dynamisch nachladen muss, nur booten vom USB-Stick geht dann nicht mehr.

Gruß Ulf

UlfZibis schrieb:

Und ganz ohne Grub geht's ja auch nicht, man kann ja vom EFI-Bootmenü nicht direkt den Linux-Kernel starten.

Doch, mit EFISTUB kann man einen Kernel direkt booten. Unter Ubuntu scheint es auch zu funktionieren ⇒ https://askubuntu.com/questions/510856/how-to-boot-load-the-kernel-using-efi-stub-efistub-loader