staging.inyokaproject.org

Ich habe nun mal Ubuntu-64 16.04.1 ganz normal installiert, und dabei das Herunterladen von Aktualisierungen deaktiviert. Interessanterweise wurde dabei GRUB 2.04 installiert. Ubiquity hat sich also entgegen meiner Voreinstellung die neueste GRUB-Version aus dem Netz geholt, statt die vom Live-Medium. Weder 16.04 noch 18.04 in der 32-Bit-Version lässt sich damit starten: "Kernel does not support 64 bit cpu"

$ apt policy grub-efi
grub-efi:
  Installiert:           (keine)
  Installationskandidat: 2.02~beta2-36ubuntu3.32
  Versionstabelle:
     2.02~beta2-36ubuntu3.32 500
        500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
     2.02~beta2-36ubuntu3.27 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     2.02~beta2-36ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

$ apt policy grub-efi-amd64*
grub-efi-amd64-bin:
  Installiert:           2.04-1ubuntu44.1.2
  Installationskandidat: 2.04-1ubuntu44.1.2
  Versionstabelle:
 *** 2.04-1ubuntu44.1.2 500
        500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.02~beta2-36ubuntu3.27 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     2.02~beta2-36ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
grub-efi-amd64-dbg:
  Installiert:           (keine)
  Installationskandidat: 2.04-1ubuntu44.1.2
  Versionstabelle:
     2.04-1ubuntu44.1.2 500
        500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
     2.02~beta2-36ubuntu3.27 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     2.02~beta2-36ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
grub-efi-amd64:
  Installiert:           2.04-1ubuntu44.1.2
  Installationskandidat: 2.04-1ubuntu44.1.2
  Versionstabelle:
 *** 2.04-1ubuntu44.1.2 500
        500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.02~beta2-36ubuntu3.27 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     2.02~beta2-36ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
grub-efi-amd64-signed:
  Installiert:           1.167~16.04.6+2.04-1ubuntu44.1.2
  Installationskandidat: 1.167~16.04.6+2.04-1ubuntu44.1.2
  Versionstabelle:
 *** 1.167~16.04.6+2.04-1ubuntu44.1.2 500
        500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.66.27+2.02~beta2-36ubuntu3.27 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     1.66+2.02~beta2-36ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

Ich werde das dann jetzt noch mal mit herausgezogenem Netzwerkkabel probieren.

EDIT: Wie ich nun feststelle, wurde dabei auch der für 16.04 aktuellste Firefox V88 installiert, also auch entgegen meiner Voreinstellung aus dem Netz gezogen.

Ich habe nun nochmal Ubuntu-64 16.04.1 ganz normal installiert, und dabei das Netzwerkkabel herausgezogen. Jetzt sieht die Sache besser aus:

$ apt policy grub-efi
grub-efi:
  Installiert:           (keine)
  Installationskandidat: (keine)
  Versionstabelle:

$ apt policy grub-efi-amd64*
grub-efi-amd64-bin:
  Installiert:           2.02~beta2-36ubuntu3.1
  Installationskandidat: 2.02~beta2-36ubuntu3.1
  Versionstabelle:
 *** 2.02~beta2-36ubuntu3.1 100
        100 /var/lib/dpkg/status
grub-efi-amd64:
  Installiert:           2.02~beta2-36ubuntu3.1
  Installationskandidat: 2.02~beta2-36ubuntu3.1
  Versionstabelle:
 *** 2.02~beta2-36ubuntu3.1 100
        100 /var/lib/dpkg/status
grub-efi-amd64-signed:
  Installiert:           1.66.1+2.02~beta2-36ubuntu3.1
  Installationskandidat: 1.66.1+2.02~beta2-36ubuntu3.1
  Versionstabelle:
 *** 1.66.1+2.02~beta2-36ubuntu3.1 100
        100 /var/lib/dpkg/status

Mit dem so installierten GRUB startet nun auch die 32-Bit 16.04.1 Installation. Die 32-Bit 18.04.1 Installation bleibt immer noch beim (initramfs)-Prompt hängen. Ich werde es nochmal neu mit ubiquity -b und ohne Netzwerkkabel installieren, vielleicht klappt's ja dann.

Damit die jetzige Konstellation auch weiter funktioniert, sollte ich GRUB nun wohl auf 2.02 pinnen.

Da standardmäßig \EFI\UBUNTU\SHIMX64.EFI statt \EFI\UBUNTU\GRUBX64.EFI in das NVRAM eingetragen wird, könnte auch die Version von shim wichtig sein:

$ apt policy shim*
shim-signed:
  Installiert:           1.17~16.04.1+0.8-0ubuntu2
  Installationskandidat: 1.17~16.04.1+0.8-0ubuntu2
  Versionstabelle:
 *** 1.17~16.04.1+0.8-0ubuntu2 100
        100 /var/lib/dpkg/status
shim:
  Installiert:           0.8-0ubuntu2
  Installationskandidat: 0.8-0ubuntu2
  Versionstabelle:
 *** 0.8-0ubuntu2 100
        100 /var/lib/dpkg/status

Bei unseren bisherigen Überlegungen haben wir ja immer nur auf die Version von grub-efi geschaut. Das war wohl falsch, denn die Version von grub-efi-amd64* ist entscheidend.

Hej UlfZibis,

UlfZibis schrieb:

... Damit die jetzige Konstellation auch weiter funktioniert, sollte ich GRUB nun wohl auf 2.02 pinnen.

was bitte willst Du bei einem stand-alone grub "pinnen" ❓

Falls es denn dereinst – hoffentlich (für Dich) vor endgültigem EOL solch einer Ubuntuversion – mal funktionieren sollte, könnte vielleicht die Sicherung der ESP nützlich sein; oder das Bewahren des zum Erfolg geführt habenden Verfahrens und der Softwarebestandteile.

Gruß black tencate

black_tencate schrieb:

was bitte willst Du bei einem stand-alone grub "pinnen" ❓

Ich bin doch jetzt bei einem ganz normal installierten Ubuntu-64 16.04.1, nur zu dem Zweck, damit ich mit dessen GRUB die 32-Bit-Version starten kann. Ich denke aber, dass auch für die Installation eines stand-alone GRUB mit dem 16.04.1 Live-Medium das Pinnen ausschlaggebend sein könnte, bevor grub-efi bzw. grub-efi-amd64 bzw. grub-efi-amd64-signed installiert wird.

Falls es denn dereinst – hoffentlich (für Dich) vor endgültigem EOL solch einer Ubuntuversion – mal funktionieren sollte, könnte vielleicht die Sicherung der ESP nützlich sein; oder das Bewahren des zum Erfolg geführt habenden Verfahrens und der Softwarebestandteile.

Sicher eine gute Idee. 👍
Und ich geb' ja gerne zu, dass das zum jetzigen Zeitpunkt nahe an sinnfrei grenzt, doch mein "Basteltrieb" ist gerade stärker.

Da standardmäßig \EFI\UBUNTU\SHIMX64.EFI statt \EFI\UBUNTU\GRUBX64.EFI in das NVRAM eingetragen wird, könnte auch die Version von shim wichtig sein:

$ apt policy shim*
shim-signed:
  Installiert:           1.17~16.04.1+0.8-0ubuntu2
  Installationskandidat: 1.17~16.04.1+0.8-0ubuntu2
  Versionstabelle:
 *** 1.17~16.04.1+0.8-0ubuntu2 100
        100 /var/lib/dpkg/status
shim:
  Installiert:           0.8-0ubuntu2
  Installationskandidat: 0.8-0ubuntu2
  Versionstabelle:
 *** 0.8-0ubuntu2 100
        100 /var/lib/dpkg/status

EDIT: Und was auch interessant ist, dass es auf focal-updates wieder eine 32-Bit-Version gibt: https://packages.ubuntu.com/focal-updates/grub-efi-amd64

Hej UlfZibis,

also, ich fasse mal zusammen:

Du willst mit einem stand-alone grub auf einem EFI/GPT System ein 32-bit Ubuntu starten, dazu hast Du EWMS auf einen Stick geschrieben, die menuentry angepaßt und vom Stick gebootet

• UlfZibis schrieb:

... EDIT: Jipee, das funktioniert tatsächlich.

Auch Windows und mein geliebtes noch installiertes Ubuntu-32_18.04 auf der Festplatte starten damit.

Aufgabe erfüllt, thread gelöst!

Nun möchtest du aber diesen stand-alone grub auf der internen Platte "unterbringen" (was so nicht funktioniert mit EWMS). Also zeige ich Dir auf, wie Du einen stand-alone grub auf die vorhandene GPT Platte installieren sollst. → 9272371. Auch das habe ich Wort für Wort belegt!

UlfZibis schrieb:

...dass auch für die Installation eines stand-alone GRUB mit dem 16.04.1 Live-Medium das Pinnen ausschlaggebend sein könnte, bevor grub-efi bzw. grub-efi-amd64 bzw. grub-efi-amd64-signed installiert wird.

1. mach, was Du willst! Ich habe 16.04.6 iso verwendet!

2. in dem Livesystem muß grub-efi nachinstalliert werden, wie sonst willst du einen Befehl

   sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/boot-efi

   ausführen? Also, was willst Du da pinnen?

3. ich habe gezeigt, daß kein Eintrag im NVRAM angelegt werden muß, es reicht der ohnehin vorhandene für die Platte (auf welcher sich die ESP befindet).

Und ich geb' ja gerne zu, dass das zum jetzigen Zeitpunkt nahe an sinnfrei grenzt, doch mein "Basteltrieb" ist gerade stärker.

sinnfrei …=d'accord!

Da standardmäßig \EFI\UBUNTU\SHIMX64.EFI statt \EFI\UBUNTU\GRUBX64.EFI in das NVRAM eingetragen wird, könnte auch die Version von shim wichtig sein

nicht mit o.g.Befehl für einen stand-alone grub.

Und btw., die Jungs von GNUGrub haben den "Schuldigen" in den verwendeten kernel verlagert, das hat mit grub nichts zu tun.

Gruß black tencate

black_tencate schrieb:

also, ich fasse mal zusammen:

Gute Idee!

Du willst mit einem stand-alone grub auf einem EFI/GPT System ein 32-bit Ubuntu starten, dazu hast Du EWMS auf einen Stick geschrieben, die menuentry angepaßt und vom Stick gebootet

Dass das vom EWMS-Stick aus funktioniert war nur ein Zwischenziel. Ziel ist ein stand-alone GRUB auf der internen Platte.

• UlfZibis schrieb:

Auch Windows und mein geliebtes noch installiertes Ubuntu-32_18.04 auf der Festplatte starten damit.

Aufgabe erfüllt, thread gelöst!

Das hatte ich später revidiert → 9273049 Nun habe ich Lubuntu-32_18.04.1 auf der internen Platte nochmal neu installiert, und zwar ohne Internetzugriff, damit wirklich nur die pure 18.04.1 installiert wird. Dieses wird nun vom EWMS-Stick endlich erfolgreich gestartet.
Dennoch ist die gestellte Aufgabe damit noch nicht erfüllt, denn es soll ja vor allem von der internen Platte aus funktionieren.

Nun möchtest du aber diesen stand-alone grub auf der internen Platte "unterbringen" (was so nicht funktioniert mit EWMS). Also zeige ich Dir auf, wie Du einen stand-alone grub auf die vorhandene GPT Platte installieren sollst. → 9272371. Auch das habe ich Wort für Wort belegt!

Genau!

UlfZibis schrieb:

...dass auch für die Installation eines stand-alone GRUB mit dem 16.04.1 Live-Medium das Pinnen ausschlaggebend sein könnte, bevor grub-efi bzw. grub-efi-amd64 bzw. grub-efi-amd64-signed installiert wird.

1. mach, was Du willst! Ich habe 16.04.6 iso verwendet!

Interessant, ich arbeite mich langsam vor.

1. in dem Livesystem muß grub-efi nachinstalliert werden, ... Also, was willst Du da pinnen?

Genau dieses Paket bzw. noch viel wichtiger die davon abhängigen: grub-efi-amd64-*. Das Ergebnis werde ich bald präsentieren.

1. ich habe gezeigt, daß kein Eintrag im NVRAM angelegt werden muß, es reicht der ohnehin vorhandene für die Platte (auf welcher sich die ESP befindet).

Nicht, wenn der vorhandene auf z.B. \EFI\UBUNTU\SHIMX64.EFI verweist.

Da standardmäßig \EFI\UBUNTU\SHIMX64.EFI statt \EFI\UBUNTU\GRUBX64.EFI in das NVRAM eingetragen wird, könnte auch die Version von shim wichtig sein

nicht mit o.g.Befehl für einen stand-alone grub.

Aber das bezog sich auf die hilfsweise interne Installation von Ubuntu-64 16.04.1 . Und vom stand-alone grub wird auch kein \EFI\UBUNTU \GRUBX64.EFI sondern \boot\grub\x86_64-efi \grub.efi eingetragen.

Und btw., die Jungs von GNUGrub haben den "Schuldigen" in den verwendeten kernel verlagert, das hat mit grub nichts zu tun.

Diese Behauptung ist für mich noch diskutabel, siehe: https://lists.gnu.org/archive/html/help-grub/2021-09/msg00016.html

UlfZibis schrieb:

Da standardmäßig \EFI\UBUNTU\SHIMX64.EFI statt \EFI\UBUNTU\GRUBX64.EFI in das NVRAM eingetragen wird, könnte auch die Version von shim wichtig sein

nicht mit o.g.Befehl für einen stand-alone grub.

Aber das bezog sich auf die hilfsweise interne Installation von Ubuntu-64 16.04.1 . Und vom stand-alone grub wird auch kein \EFI\UBUNTU \GRUBX64.EFI sondern \boot\grub\x86_64-efi \grub.efi eingetragen.

Und genau das hat mich ja am Anfang völlig irritiert:

• Dein stand-alone grub installiert \EFI\BOOT\BOOTX64.EFI und \EFI\BOOT\grub.cfg, legt aber im NVRAM den Startpfad auf \boot\grub\x86_64-efi\grub.efi.

• Ubuntu aber installiert standardmäßig \EFI\UBUNTU\GRUBX64.EFI und legt im NVRAM den Startpfad genau dort hin.

Hej UlfZibis,

UlfZibis schrieb:

...

• Dein stand-alone grub installiert \EFI\BOOT\BOOTX64.EFI und \EFI\BOOT\grub.cfg,

das ist irgendwie schon ansatzweise gedanklich bei Dir falsch

1. nicht der stand-alone grub macht etwas, sondern der Befehl

   sudo grub-instal --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/wasauchimmer 

2. der legt dann genau 2 Verzeichnisse auf der ESP an, "BOOT" und "wasauchimmer"

3. die \EFI\BOOT\grub.cfg richtigerweise <ESP>/wasauchimmer/ ▶ grub ◀ /grub.cfg wird nach dem install-Befehl händisch erzeugt.

Zitat aus Wiki

legt aber im NVRAM den Startpfad auf \boot\grub\x86_64-efi\grub.efi.

1. für EFI

   • die esp (/dev/sdd2) Partition einhängen nach /mnt, nach Gebrauch aushängen.

   • im LiveSystem ist grub-efi nachzuinstallieren

   • grub installieren

     sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/boot 

   • mit einem Texteditor eine Datei grub.cfg anlegen und unter /mnt/boot/grub speichern

/Zitat aus Wiki

...legt aber im NVRAM den Startpfad auf \boot\grub\x86_64-efi\grub.efi.

wieder falsch
Zitat aus Wiki

Installation¶

Zunächst wird für ein wie oben beschrieben installierten stand-alone grub ein neuer Booteintrag im nvram angelegt

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\boot\\grub\\x86_64-efi\\grub.efi # X und Y entsprechend anpassen 

/Zitat aus Wiki

• Ubuntu aber installiert standardmäßig \EFI\UBUNTU\GRUBX64.EFI und legt im NVRAM den Startpfad genau dort hin.

was hat jetzt – zum x-ten Mal – Ubuntu, richtigerweise ubiquity mit sudo grub-install... zu tun? NIX! (← Hubert von Goisern "Drawig" Min 4:30/4:35)

Gruß black tencate

black_tencate schrieb:

Mit:

• Dein stand-alone grub installiert \EFI\BOOT\BOOTX64.EFI und \EFI\BOOT\grub.cfg,

meinte ich genau diesen:

1. nicht der stand-alone grub macht etwas, sondern der Befehl

   sudo grub-instal --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/wasauchimmer 

als Teil des Gesamtkonstrukts "stand-alone grub".

1. der legt dann genau 2 Verzeichnisse auf der ESP an, "BOOT" und "wasauchimmer"

Nein, sondern \EFI\BOOT und \wasauchimmer
... und dass der Inhalt von \EFI\BOOT für den Start von stand-alone grub gar keine Verwendung findet, hat mich halt anfangs "irritiert". Mehr wollte ich nicht anmerken.

1. die \EFI\BOOT\grub.cfg

Die wurde bei mir automatisch angelegt, durch genau obigen Befehl.

richtigerweise

Nein, zusätzlicherweise:

<ESP>/wasauchimmer/ ▶ grub ◀ /grub.cfg wird nach dem install-Befehl händisch erzeugt.

Nichts gegenteiliges habe ich behauptet.

Zitat aus Wiki

legt aber im NVRAM den Startpfad auf \boot\grub\x86_64-efi\grub.efi. ### Das ist kein Zitat aus dem Wiki. ###

1. für EFI

   • die esp (/dev/sdd2) Partition einhängen nach /mnt, nach Gebrauch aushängen.

   • im LiveSystem ist grub-efi nachzuinstallieren

   • grub installieren

     sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/boot 

   • mit einem Texteditor eine Datei grub.cfg anlegen und unter /mnt/boot/grub speichern

/Zitat aus Wiki

...legt aber im NVRAM den Startpfad auf \boot\grub\x86_64-efi\grub.efi.

wieder falsch

Auch hier war damit genau folgender Befehl (und nicht obiger):

Zitat aus Wiki

Installation¶

Zunächst wird für ein wie oben beschrieben installierten stand-alone grub ein neuer Booteintrag im nvram angelegt

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\boot\\grub\\x86_64-efi\\grub.efi # X und Y entsprechend anpassen 

/Zitat aus Wiki

als Teil des Konstrukts "im PC als stand-alone grub" gemeint.

• Ubuntu aber installiert standardmäßig \EFI\UBUNTU\GRUBX64.EFI und legt im NVRAM den Startpfad genau dort hin.

was hat jetzt – zum x-ten Mal – Ubuntu, richtigerweise ubiquity mit sudo grub-install... zu tun? NIX!

Ob es miteinander zu tun hat, weiß ich nicht, aber sudo grub-install macht ohne weitere Optionen (im installierten System) genau dasselbe wie Ubuntus ubiquity. Und mit den weiter oben angegebenen Optionen erzeugt der erste "Befehl" von "stand-alone grub" (zumindest vom Live-System aus) genau das, was ich angegeben hatte, und ohne einen Startpfad ins NVRAM zu schreiben, weshalb das mit dem 2. von Dir zitierten "Befehl" manuell nachgeholt werden muss.

So, ich bin nun etwas schlauer geworden ...

Auf dem Ubuntu 16.04.1 Installationsmedium sind die Pakete grub-efi-amd64* in Version 2.02~beta2-36ubuntu3.1.
Damit (egal ob als stand-alone oder Normal-Installation) lassen sich alle 32-Bit-Versionen (16.04.1, 16.04.7_ESM, 18.04.1 und 18.04.6) von Ubuntu prima starten.

Will ich aber zumindest die letzte Sicherheitsaktualisierung (ohne "optionale" Updates) aus xenial-security haben (und auf 2.02* bleiben), muss ich im Live-System eine Internet-Verbindung herstellen und xenial-updates pinnen mit:

Package: grub*
Pin: release a=*-updates
Pin-Priority: -1

Package: grub*
Pin: version 2.02*
Pin-Priority: 1000

Package: grub*signed
Pin: version *+2.02*
Pin-Priority: 1000

Dann bekomme ich Version 2.02~beta2-36ubuntu3.27.
Damit (egal ob als stand-alone oder Normal-Installation) bleibt GRUB beim Versuch ein 32-Bit Ubuntu (mit ubiquity -b installiert) zu starten mit leerem Bildschirm hängen. (In einem Fall auch mit "Initiale RAM-disk wird geladen ...".)

Auf dem Ubuntu 18.04.4 Installationsmedium sind die Pakete grub-efi-amd64* in Version 2.02-2ubuntu8.14.
Auch damit (egal ob als stand-alone oder Normal-Installation) lassen sich alle 32-Bit-Versionen von Ubuntu prima starten.

Da sich hier die Versionen von bionic-security und bionic-updates nicht unterscheiden, macht APT-Pinning hier keinen Unterschied und mit hergestellter Internet-Verbindung bekomme ich: 2.04-1ubuntu44.1.2.
Damit (egal ob als stand-alone oder Normal-Installation) bleibt GRUB dann beim Versuch ein 32-Bit Ubuntu (mit ubiquity -b installiert) zu starten mit "kernel doesn't support 64-bit CPUs" hängen.

Wie es sich mit Ubuntu 18.06.4 oder gar Ubuntu 20.04.1 verhält, habe ich nicht getestet.

UlfZibis schrieb:

[…] grub-efi-amd64* […] 2.04-1ubuntu44.1.2 […] beim Versuch ein 32-Bit Ubuntu (mit ubiquity -b installiert) zu starten mit "kernel doesn't support 64-bit CPUs" hängen.

Toll, damit hast Du einen Bug gefunden, den Du sofort an die Paket-Betreuer melden solltest, denn nach

https://packages.ubuntu.com/search?suite=default&section=all&arch=any&keywords=grub-efi&searchon=names

sollte dieses Paket für die Architekturen amd64 und i386 (auf die Du ja offenbar großen Wert legst) funktionieren.

Wie es sich mit Ubuntu 18.06.4 oder gar Ubuntu 20.04.1 verhält, habe ich nicht getestet.

Möglicherweise ist dieser Bug aber schon bekannt und nur in Bionic (dem letzten noch unterstützten Ubuntu-Betriebssystem mit 32-Bit Unterstützung) noch nicht behoben, denn bei den entsprechenden Paketen aus focal-updates gibt es die Versionen 44.2 für amd64 und 44 für i386 und für 21.04 und 21.10 gibt es wieder Pakete für beide Architekturen.

Damit lautet die Empfehlung für diesen Artikel vermutlich: „Wenn man 32-Bit booten will, nehme man nicht den GRUB aus Ubuntu 18.04 oder 20.04“

Wahrscheinlich ist aber in 2021 der bessere Rat: „Man verwende bei PC kein 32-Bit-System mehr.“ (Bei anderen Hardware-Architekturen sieht das momentan noch anders aus; https://lwn.net/Articles/838807/)

UlfZibis schrieb:

Wie es sich mit Ubuntu 18.06.4 oder gar Ubuntu 20.04.1 verhält, habe ich nicht getestet.

Oops, ich meinte natürlich 18.04.6.

UlfZibis schrieb:

... Nein, sondern \EFI\BOOT und \wasauchimmer

haste natürlich recht!

... und dass der Inhalt von \EFI\BOOT für den Start von stand-alone grub gar keine Verwendung findet

dem ist nicht so, grub.cfg in <ESP>/efi/boot ist der "Wegweiser" für die grub.cfg in <ESP>/wasauchimmer/grub/…

blacktencate@T520-BB:~$ sudo parted -l
...
Modell: SMI USB DISK (scsi)
Festplatte  /dev/sde:  4010MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 1      1049kB  4010MB  4009MB  primary  fat32


blacktencate@T520-BB:~$ sudo mount /dev/sde1 /mnt
blacktencate@T520-BB:~$ cat /mnt/efi/boot/grub.cfg
search.fs_uuid A380-2FAA root hd4,msdos1 
set prefix=($root)'/wasauchimmer/grub'
configfile $prefix/grub.cfg
blacktencate@T520-BB:~$ lsblk -f /dev/sde
NAME   FSTYPE LABEL       UUID                                 MOUNTPOINT
sde                                                            
└─sde1 vfat   MULTISYSTEM A380-2FAA                            /mnt
blacktencate@T520-BB:~$ 

kB schrieb:

... sollte dieses Paket für die Architekturen amd64 und i386 (auf die Du ja offenbar großen Wert legst) funktionieren.

ich denke, hier liegt ein Mißverständnis bezüglich der verwendeten Architektur vor,

• es geht darum, mit einer EWMS ein 32-bit Ubuntu zu starten

• bei der Erstellung solch eines Sticks wurde noch nie (jedenfalls von mir nicht) eine 32-bit Architektur verwendet (wozu auch, die gibt 's ja bei Ubuntu 'praktisch' nicht mehr!)

• die 'erzielten' Resultate 32-bit bootet bis in irgendeinen Zustand und kernel doesn't support… haben doch mit grub nichts mehr zu tun.

• ich habe hier gezeigt, daß mit so einer EWMS ein 32-bit Xenial gestartet werden kann

• der TO hat bestätigt, daß ihm damit (nach meinen Vorgaben) auch der Start von Windows/GPT/EFI und 32-bit Ubuntu (geliebtes noch installiertes Ubuntu-32_18.04,was auch immer das sei) gelungen ist.

Obendrein habe ich Unterstützung angeboten, den relevanten Teil eines stand-alone grub in seiner vorhandene Platte zu installieren, wenn er denn die Partitionsinfos dazu liefert (Name,UUID)

black_tencate schrieb:

... und dass der Inhalt von \EFI\BOOT für den Start von stand-alone grub gar keine Verwendung findet

dem ist nicht so, grub.cfg in <ESP>/efi/boot ist der "Wegweiser" für die grub.cfg in <ESP>/wasauchimmer/grub/…

blacktencate@T520-BB:~$ sudo parted -l
...
Modell: SMI USB DISK (scsi)
Festplatte  /dev/sde:  4010MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 1      1049kB  4010MB  4009MB  primary  fat32


blacktencate@T520-BB:~$ sudo mount /dev/sde1 /mnt
blacktencate@T520-BB:~$ cat /mnt/efi/boot/grub.cfg
search.fs_uuid A380-2FAA root hd4,msdos1 
set prefix=($root)'/wasauchimmer/grub'
configfile $prefix/grub.cfg

Und wozu brauchen wir dann den Wegweiser im NVRAM? :

sudo efibootmgr --create --disk /dev/sdX --part Y --label "stand-alone-grub" --loader \\boot\\grub\\x86_64-efi\\grub.efi # X und Y entsprechend anpassen  

black_tencate schrieb:

weil bei der Installation von grub-install die Pfade für z.B. grub.cfg festgelegt sind; sagte ich oben ja bereits. Und natürlich, weil das gar nicht verwendet wird (außer in einem Fallback), ...

Ich würde sagen, der Weg prefix=($root)'/wasauchimmer/grub' → $prefix/grub.cfg findet nur dann (im Regelfall) Verwendung, wenn im NVRAM \EFI\BOOT\BOOTX64.EFI steht.

blacktencate@T520-BB:~$ lsblk -f /dev/sde
NAME   FSTYPE LABEL       UUID                                 MOUNTPOINT
sde                                                            
└─sde1 vfat   MULTISYSTEM A380-2FAA                            /mnt
blacktencate@T520-BB:~$ 

Oops, das weiter oben soll eine /efi/boot/grub.cfg von einer MultiSystem-Installation sein. Bei mir gibt's die nicht:

$ ls -l /media/ich/MULTISYSTEM/EFI/BOOT/
insgesamt 2944
-rw-r--r-- 1 ich ich  621056 Okt 24  2020 bootia32.efi
-rw-r--r-- 1 ich ich 1355736 Okt 24  2020 BOOTx64.EFI
-rw-r--r-- 1 ich ich  993144 Okt 24  2020 grubx64.efi

Und wie und warum hast Du denn da den Pfad /wasauchimmer/grub und dazugehörige grub.cfg und Verzeichnis reingefrickelt?

kB schrieb:

sollte dieses Paket für die Architekturen amd64 und i386 (auf die Du ja offenbar großen Wert legst) funktionieren.

ich denke, hier liegt ein Mißverständnis bezüglich der verwendeten Architektur vor,

• es geht darum, mit einer EWMS ein 32-bit Ubuntu zu starten

Richtig, deshalb ist auf einer 64-Bit-Hardware auch nur ein 64-Bit-GRUB vonnöten.

• bei der Erstellung solch eines Sticks wurde noch nie (jedenfalls von mir nicht) eine 32-bit Architektur verwendet (wozu auch, die gibt 's ja bei Ubuntu 'praktisch' nicht mehr!)

Weshalb Dein System auf einem alten nur 32-Bit-Rechner wohl auch nicht funktioniert. MultiSystem kann das!

• die 'erzielten' Resultate 32-bit bootet bis in irgendeinen Zustand und kernel doesn't support… haben doch mit grub nichts mehr zu tun.

Und warum fallen sie mit unterschiedlichen GRUB-Versionen denn doch unterschiedlich aus?

• ich habe hier gezeigt, daß mit so einer EWMS ein 32-bit Xenial gestartet werden kann

Sie legt aber nur dann noch 32-Bit-Eier, wenn die EWMS (ich wüsste noch immer gerne, wofür die Abkürzung steht, um sie mir besser merken zu können) uralt ist, also ohne aktuelle Sicherheitsupdates erstellt wurde.

• der TO hat bestätigt, daß ihm damit (nach meinen Vorgaben) auch der Start von Windows/GPT/EFI und 32-bit Ubuntu (geliebtes noch installiertes Ubuntu-32_18.04,was auch immer das sei) gelungen ist.

Stimmt!

Obendrein habe ich Unterstützung angeboten, den relevanten Teil eines stand-alone grub in seiner vorhandene Platte zu installieren, wenn er denn die Partitionsinfos dazu liefert (Name,UUID)

Nicht erschrecken, da sind noch ein paar Leichen von meinem Gebastel drauf. Alles jenseits von /dev/sda14 ist irrelevant.

$ sudo parted -l
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  43,0GB  41,8GB  ntfs            Basic data partition          msftdata
 5      43,0GB  47,2GB  4295MB  linux-swap(v1)  SWAP partition 5
 7      47,2GB  60,1GB  12,9GB  ext4            EXT4 partition 7
 8      60,1GB  64,4GB  4295MB  ext4            EXT4 partition 8
 9      64,4GB  77,3GB  12,9GB  ext4            EXT4 partition 9
10      77,3GB  81,6GB  4295MB  ext4            EXT4 partition 10
11      81,6GB  94,5GB  12,9GB  ext4            EXT4 partition 11
12      94,5GB  98,8GB  4295MB  ext4            EXT4 partition 12
13      98,8GB  110GB   10,7GB  ext4            EXT4 partition 13
14      110GB   114GB   4295MB  ext4            EXT4 partition 14
20      199GB   210GB   10,7GB  ext4
21      210GB   215GB   4295MB  ext4
22      215GB   227GB   12,9GB  ext4
23      227GB   232GB   4295MB  ext4
24      286GB   337GB   51,5GB  ntfs                                          msftdata
25      396GB   448GB   51,5GB  ntfs                                          msftdata
15      448GB   452GB   4295MB  ext4            EXT4 partition 15
16      452GB   463GB   10,7GB  ext4            EXT4 partition 16
17      463GB   464GB   1049MB
18      464GB   474GB   10,6GB  ext4            EXT4 partition 18
19      474GB   479GB   4295MB  ext4            EXT4 partition 19
 6      479GB   500GB   21,5GB  ntfs            Basic data partition          versteckt, diag


Modell: Kingston DataTraveler 2.0 (scsi)
Festplatte  /dev/sdb:  31,3GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ       Dateisystem     Flags
 1      1049kB  17,8MB  16,8MB  primary   fat16           esp
 2      17,8MB  19,9MB  2097kB  primary   ntfs
 3      19,9MB  34,6MB  14,7MB  primary
 4      35,7MB  31,3GB  31,3GB  extended
 5      35,7MB  10,8GB  10,7GB  logical   ext4
 6      10,8GB  15,1GB  4294MB  logical   ext4
 7      27,0GB  31,3GB  4294MB  logical   linux-swap(v1)


Modell: ST1000LM 024 HN-M101MBB (scsi)
Festplatte  /dev/sdc:  1000GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ       Dateisystem  Flags
 1      1049kB  43,0GB  42,9GB  primary   fat32        boot, LBA
 4      43,0GB  126GB   82,7GB  extended
 5      43,0GB  57,6GB  14,7GB  logical   ext4
 6      57,6GB  126GB   68,0GB  logical   ntfs
 3      126GB   942GB   816GB   primary   ntfs
 2      952GB   1000GB  48,2GB  primary   ntfs

Interessant ist, dass die MULTISYSTEM-Partition auf /dev/sdc nicht mit "esp" markiert ist, und dennoch tadellos unter UEFI bootet

$ sudo blkid
/dev/sda5: UUID="a16bade4-94d7-4c43-9af5-4704b1ba02aa" TYPE="swap" PARTLABEL="SWAP partition 5" PARTUUID="cf258850-dc28-435e-988b-5d2ea8c42df8"
/dev/sda1: LABEL="SYSTEM" UUID="BC5C-B7DD" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="671281f8-513a-46b7-8cd7-ff6fed6d5eca"
/dev/sda10: LABEL="home_18.04" UUID="f35732d2-8c0b-4e2d-a8c8-39184579b5e7" TYPE="ext4" PARTLABEL="EXT4 partition 10" PARTUUID="a6724b46-741e-4a1e-bdc8-3b0cbe2af5d1"
/dev/sda11: LABEL="Ubuntu-64_16.04" UUID="944662da-df21-471e-b041-082090aaa22e" TYPE="ext4" PARTLABEL="EXT4 partition 11" PARTUUID="3b0fca71-5468-42e7-9dbf-9b0c684103d6"
/dev/sda12: LABEL="home-64_16.04" UUID="3a386e89-3a5e-4e5e-b8d5-d408ba234a01" TYPE="ext4" PARTLABEL="EXT4 partition 12" PARTUUID="4b97cff7-ace6-4bbc-a23b-8e673707ddff"
/dev/sda13: LABEL="Ubuntu_16.04" UUID="c4f2f460-289a-446b-9551-68ea832826f3" TYPE="ext4" PARTLABEL="EXT4 partition 13" PARTUUID="66cd3890-45ea-47e8-a571-e3c1678067df"
/dev/sda14: LABEL="home_16.04" UUID="1bea4072-3250-4d20-b5e1-602d90fe1a64" TYPE="ext4" PARTLABEL="EXT4 partition 14" PARTUUID="9e3377dc-4542-4785-a15c-0dac6592d74b"
/dev/sda15: LABEL="home_18.04" UUID="5a6f21f9-c515-44f9-9eb2-03aab7cf362f" TYPE="ext4" PARTLABEL="EXT4 partition 15" PARTUUID="c14da769-a25b-433b-a9fe-d21f754bdaeb"
/dev/sda16: LABEL="Ubuntu-64_18.04" UUID="f7d30968-f9d1-4d01-904d-de6171a21d35" TYPE="ext4" PARTLABEL="EXT4 partition 16" PARTUUID="84e299f3-e24b-4250-a774-f672921bc2ab"
/dev/sda18: LABEL="Ubuntu-64_20.04" UUID="1738ab81-b694-45d7-a0fe-f48f3edfd365" TYPE="ext4" PARTLABEL="EXT4 partition 18" PARTUUID="3f50aa75-66fd-4cd6-8219-fff6573f0209"
/dev/sda19: LABEL="home-64_20.04" UUID="d87a0e09-bfba-4603-9862-97f4e36977cf" TYPE="ext4" PARTLABEL="EXT4 partition 19" PARTUUID="987d31a2-c727-4a5c-97d1-88c263c68760"
/dev/sda2: LABEL="Recovery" UUID="3C5C0FE55C0F98B2" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="afcadc4b-d094-4fd4-828e-12c41de4ca52"
/dev/sda20: LABEL="Ubuntu_16.04" UUID="3f93ffae-d9b6-4784-9d11-55cd73e74a37" TYPE="ext4" PARTUUID="de2d78e8-0d2a-4c00-881b-0578469b7bf3"
/dev/sda21: LABEL="home_16.04" UUID="8db5ce9f-7dfb-45b8-a6ad-fa6b64548786" TYPE="ext4" PARTUUID="369b3d6d-4b88-4a1b-b846-9406da4fb851"
/dev/sda22: LABEL="Ubuntu-64_16.04" UUID="128c85cf-7bab-4902-81fb-4fdca7aa65c3" TYPE="ext4" PARTUUID="1609e8fe-16bd-4452-ac53-a252949252ac"
/dev/sda23: LABEL="home-64_16.04" UUID="fd2d5698-646f-42af-857b-afb30cb590a4" TYPE="ext4" PARTUUID="d2889296-8877-4182-9bc2-1f81d1611d45"
/dev/sda24: LABEL="Backup" UUID="435A54FF2DA2EF9E" TYPE="ntfs" PTTYPE="dos" PARTUUID="61b1d539-3095-495e-9012-98a59f7a5f9c"
/dev/sda25: LABEL="Sicherung" UUID="5AB717412821EE28" TYPE="ntfs" PARTUUID="c7262ead-ab02-40f4-a5c1-7f3cb89640cb"
/dev/sda4: LABEL="Windows" UUID="A4FA421DFA41EC5C" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="547fb42a-c27c-4058-8cfe-a2294c254a66"
/dev/sda6: LABEL="Restore" UUID="1ECA2114CA20E9AB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="db96c46b-c31a-4e9e-8298-c6cc68a0c879"
/dev/sda7: LABEL="Ubuntu-64_20.04" UUID="82b4acde-4db6-48b0-9d00-a09fb995b330" TYPE="ext4" PARTLABEL="EXT4 partition 7" PARTUUID="c07ff820-e75b-47f5-9652-0751aba5828b"
/dev/sda8: LABEL="home-64_20.04" UUID="10d02154-cdfc-40d6-9395-ca2dd8085975" TYPE="ext4" PARTLABEL="EXT4 partition 8" PARTUUID="88dc8090-1a31-4b6c-83bd-7124a2968ab8"
/dev/sda9: LABEL="Ubuntu_18.04" UUID="ec7ee724-6bed-4ee0-8056-8ecf44bb46b9" TYPE="ext4" PARTLABEL="EXT4 partition 9" PARTUUID="3e7504db-8392-483e-bf38-489eeddea679"
/dev/sdb1: SEC_TYPE="msdos" UUID="682A-DD73" TYPE="vfat" PARTUUID="a705ea26-01"
/dev/sdb2: LABEL="grubcfg-file" UUID="063B94685E1DFBDF" TYPE="ntfs" PARTUUID="a705ea26-02"
/dev/sdb5: LABEL="Ubuntu_16.04" UUID="12242877-0cc0-4f7b-afb0-ffadeca726a0" TYPE="ext4" PARTUUID="a705ea26-05"
/dev/sdb6: LABEL="home_16.04" UUID="31ee2318-0542-4b06-916e-42a182397356" TYPE="ext4" PARTUUID="a705ea26-06"
/dev/sdb7: UUID="4c7ef0ea-c1bc-4769-81ea-0c6ba9d37039" TYPE="swap" PARTUUID="a705ea26-07"
/dev/sdc1: LABEL="MULTISYSTEM" UUID="DF06-2F1D" TYPE="vfat" PARTUUID="17a7f65c-01"
/dev/sdc2: LABEL="STANDARD" UUID="FE14AE0A14ADC64D" TYPE="ntfs" PARTUUID="17a7f65c-02"
/dev/sdc3: LABEL="BACKUP" UUID="8838F90B38F8F8D0" TYPE="ntfs" PARTUUID="17a7f65c-03"
/dev/sdc5: LABEL="Ubuntu_15.04" UUID="9ed20377-73af-4cac-b663-8c47619eb710" TYPE="ext4" PARTUUID="17a7f65c-05"
/dev/sdc6: LABEL="DVDs" UUID="3C321A487982ECE2" TYPE="ntfs" PTTYPE="dos" PARTUUID="17a7f65c-06"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="a50e2ce3-e04e-46e5-bd68-e264417933cb"
/dev/sda17: PARTUUID="b9e956e3-8bc8-4872-97d0-630124a4cfb9"
/dev/sdb3: PARTUUID="a705ea26-03"

(Im folgenden sind die Einträge bzgl. der externen Multisystem-HDD nicht vorhanden, da sie beim Start des Rechners noch nicht dran steckte.)

$ sudo efibootmgr -v
BootCurrent: 0009
Timeout: 1 seconds
BootOrder: 0009,0000,0002,000F,0010,0001
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.}....................
Boot0009* GRUB stand-alone	HD(1,GPT,671281f8-513a-46b7-8cd7-ff6fed6d5eca,0x800,0x32000)/File(\BOOT\GRUB\X86_64-EFI\GRUB.EFI)
Boot000F* UEFI: KingstonDataTraveler 2.00000	PciRoot(0x0)/Pci(0x14,0x0)/USB(4,0)/USB(2,0)/HD(1,MBR,0x38,0x800,0x8000)..BO
Boot0010* UEFI: KingstonDataTraveler 2.00000	PciRoot(0x0)/Pci(0x14,0x0)/USB(4,0)/USB(2,0)/HD(2,MBR,0x38,0x8800,0x1000)..BO

$ sudo cat /boot/efi/boot/grub/grub.cfg

menuentry "EFI-PC" { # dieser Eintrag dient lediglich der schnellen Erkennung, in welchem Modus auf dem Rechner gebootet wurde
	set-root=(hd0,gpt1) # ohne 'gültige' Zeile keine Anzeige
        rmmod tpm  # erforderlich für das Booten mittels loopback 
}
menuentry "Stop" {
	halt
}

menuentry "Windows 8.1 auf Festplatte" {
	insmod part_gpt
	## UUID von EFI-Partition /dev/sda1 :
	search --fs-uuid --set=root BC5C-B7DD
	chainloader /efi/microsoft/boot/bootmgfw.efi
}
menuentry "Menü von Ubuntu-32 16.04 auf USB-Stick" {
	insmod part_msdos
	insmod ext2
	## Ubuntu_16.04 auf dem USB-Stick /dev/sdc5 :
	search --no-floppy --fs-uuid --set=root 12242877-0cc0-4f7b-afb0-ffadeca726a0
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-64 20.04 auf sda7" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root 82b4acde-4db6-48b0-9d00-a09fb995b330
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-32 18.04 auf sda9" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root ec7ee724-6bed-4ee0-8056-8ecf44bb46b9
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-64 16.04 auf sda11" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root 944662da-df21-471e-b041-082090aaa22e
	configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-32 16.04 auf sda13" {
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root c4f2f460-289a-446b-9551-68ea832826f3
	configfile /boot/grub/grub.cfg
}

Leider erscheint dieses stand-alone GRUB noch komplett auf Englisch und die deutschen Umlaute z.B. in "Menü von ..." werden verschluckt. Da muss ich wohl noch weitere insmod ergänzen. Weiß jemand welche?

kB schrieb:

Toll, damit hast Du einen Bug gefunden, den Du sofort an die Paket-Betreuer melden solltest,

Erledigt: 1944385

Damit lautet die Empfehlung für diesen Artikel vermutlich: „Wenn man 32-Bit booten will, nehme man nicht den GRUB aus Ubuntu 18.04 oder 20.04“

Auch 16.04 ESM geht nicht, wenn man das security update durchführt.
Empfehlung deshalb: 9275499

Wahrscheinlich ist aber in 2021 der bessere Rat: „Man verwende bei PC kein 32-Bit-System mehr.“

Hat aber gravierende Nachteile, wenn das NetBook (von 2014) nur 2 GB RAM hat.