staging.inyokaproject.org

Hallo,

ich habe auf einem bestehenden System nachträglich 20.04 installiert und versäumt, ubiquity -b zu verwenden. So wurde nun der GRUB des Hauptsystems 18.04 überschrieben. Selbst wenn ich das mit dem GRUB von 18.04 wieder überschreibe, wird bei jedem Update von 20.04 das dann wieder überschrieben. Das möchte ich verhindern. Wie kann ich das konfigurieren, bzw. welches Paket muss ich dafür deinstallieren, also um den gleichen Zustand zu bekommen, als hätte ich mit ubiquity -b installiert?

Ich will also generell nur über das GRUB der 18.04-Installation und dessen Menü den Rechner booten.

Hej UlfZibis,

ich vermute mal, es handelt sich um den "legacy" Bootmodus? Wenn ja, dann bootest Du in das O/S, dessen grub Du "entfernen" willst und führst eing grub 2/Reparatur aus mit Ziel sdxy (PartitionsBootRecord) statt in den MBR.

Im Falle eines EFI Modus schau mal EFI Nachbearbeitung (Abschnitt „Zusaetzliches-Bootverzeichnis-erstellen“).

Gruß black tencate

Es handelt sich hier um ein EFI-System, und genau genommen um eine Universal stand-alone grub für BIOS und EFI auf USB flashkey und internen HDD und SSD-Installation, die ich über die 18.04-Instanz administriere. Diese Möglichkeit ist nun durch das Überinstallieren von GRUB aus 20.04 zerstört.

Ich kann das natürlich über den Start von 18-04 über chroot wieder reparieren, doch beim nächsten GRUB-Update in 20.04 wird dann wieder der gleiche Unfall passieren.

Der Weg über ein zusätzliches Bootverzeichnis wäre ein hässlicher Workaround. Lieber wäre mir deshalb, dass die 20.04-Instanz daran gehindert wird, GRUB überhaupt zu installieren, so wie das mittels einer Installation per ubiquity -b der Fall wäre.

Um genau zu sein, der Unfall ist durch die Aktualisierung von 20.04 entstanden, was hier schon länger installiert ist. Ich hätte da aufpassen müssen, dass ich GRUB in der Liste der Aktualisierungsverwaltung manuell deaktiviere.

Ich habe hier mehrere Ubuntu-Versionen drauf. Bei denen, wo ich mit ubiquity -b installiert hatte, muss ich da nicht aufpassen, denn die Installation von GRUB wird dann automatisch verhindert. Diesen Luxus hätte ich nun gerne auch bei der 20.04-Instanz.

Hej UlfZibis,

UlfZibis schrieb:

... Der Weg über ein zusätzliches Bootverzeichnis wäre ein hässlicher Workaround.

wie kommst Du auf so eine Aussage? Genau wie bei CSM mit dem grub-install /dev/sdxy wird eben im EFI der Ort für grub verändert, wo er keinen "Schaden" mehr anrichten kann. Ob das auch mit einem deinstall von grub-efi und entsprechendem pinging klappt, habe ich noch nie probiert.

Außerdem, ein EWMS ist doch einfachst zu reparieren, auch wenn das als lästig empfunden wird.

Gruß black tencate

black_tencate schrieb:

Hej UlfZibis,

UlfZibis schrieb:

... Der Weg über ein zusätzliches Bootverzeichnis wäre ein hässlicher Workaround.

wie kommst Du auf so eine Aussage? Genau wie bei CSM mit dem grub-install /dev/sdxy wird eben im EFI der Ort für grub verändert, wo er keinen "Schaden" mehr anrichten kann. Ob das auch mit einem deinstall von grub-efi und entsprechendem pinging klappt, habe ich noch nie probiert.

Einfach weil ich das Ergebnis von ubiquity -b eleganter und geradliniger finde, nur leider weiß ich nicht, wie man diese dadurch entstandene Konfiguration nachträglich herstellen kann. Wenn ich mich richtig erinnere, führte die Umlenkung in einen NVRAM-Eintrag ader auch zu Problemen, welche weiß ich nicht mehr.

Außerdem, ein EWMS ist doch einfachst zu reparieren, auch wenn das als lästig empfunden wird.

Ja es ist tatsächlich lästig, das nach jedem Update immer wieder tun zu müssen, zumal meine EWMS-Konfiguration auch ein bisschen tricky ist.

UlfZibis schrieb:

[…] welches Paket muss ich dafür deinstallieren, also um den gleichen Zustand zu bekommen, als hätte ich mit ubiquity -b installiert?

Es müssen zuerst die Pakete shim und os-prober entfernt werden und danach alle Pakete mit grub im Namen in der richtigen Reihenfolge. Die richtige Reihenfolge ist experimentell zu ermitteln: Wenn die Deinstallation eines Grub-Pakets die Installation eines anderen Grub erfordert, ist man auf dem falschen Weg. Irgendwann wird auch die Entfernung eines Pakets mit desktop im Namen als erforderlich gemeldet. Dann sollte man innehalten, nachdenken und nachforschen und wissen, was man tut.

Ich mache so etwas mit Synaptic.

Ich hatte kürzlich ein ähnliches Problem. Bei mir hat es schon ausgereicht, den fstab-Eintrag der EFI-Partition in demjenigen System ("Sekundärinstallation") zu entfernen, das die EFI-Partition in Ruhe lassen soll.

Viele Grüße, Jan

UlfZibis schrieb:

black_tencate schrieb:

UlfZibis schrieb:

Der Weg über ein zusätzliches Bootverzeichnis wäre ein hässlicher Workaround.

wie kommst Du auf so eine Aussage? Genau wie bei CSM mit dem grub-install /dev/sdxy wird eben im EFI der Ort für grub verändert, wo er keinen "Schaden" mehr anrichten kann.

... Wenn ich mich richtig erinnere, führte die Umlenkung in einen NVRAM-Eintrag ader auch zu Problemen, welche weiß ich nicht mehr.

Hab's wieder gefunden. Hier in der Expertenbox ist das Problem beschrieben: https://wiki.ubuntuusers.de/EFI_Nachbearbeitung/#Systeme-mit-secure-boot
Und hier auch: https://forum.ubuntuusers.de/post/8667388/

kB schrieb:

UlfZibis schrieb:

[…] welches Paket muss ich dafür deinstallieren, also um den gleichen Zustand zu bekommen, als hätte ich mit ubiquity -b installiert?

Es müssen zuerst die Pakete shim und os-prober entfernt werden und danach alle Pakete mit grub im Namen in der richtigen Reihenfolge.

Es sieht so aus, als wenn das hier reicht:

$ sudo apt purge grub-efi-amd64-signed
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
  efibootmgr grub-efi-amd64-bin
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
Die folgenden Pakete werden ENTFERNT:
  grub-efi-amd64-signed*
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 7.188 kB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n] j
(Lese Datenbank ... 213943 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von grub-efi-amd64-signed (1.187.3~20.04.1+2.06-2ubuntu14.1) ...
$ sudo grub-install
i386-pc wird für Ihre Plattform installiert.
grub-install: Fehler: Kein Installationsgerät angegeben.

Damit efibootmgr nicht versehentlich entsorgt wird (den kann man ja evtl. noch gut gebrauchen):

$ sudo apt install efibootmgr
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
efibootmgr ist schon die neueste Version (17-1).
efibootmgr wurde als manuell installiert festgelegt.
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  grub-efi-amd64-bin
Verwenden Sie »sudo apt autoremove«, um es zu entfernen.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Dann noch aufräumen, und wie man sieht wird grub-efi-amd46-signed nicht mehr von einer Aktualisierung erfasst:

$ sudo apt --purge autoremove
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  grub-efi-amd64-bin*
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 10,3 MB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n] j
(Lese Datenbank ... 213934 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von grub-efi-amd64-bin (2.06-2ubuntu14.1) ...
(Lese Datenbank ... 213643 Dateien und Verzeichnisse sind derzeit installiert.)
Löschen der Konfigurationsdateien von grub-efi-amd64-bin (2.06-2ubuntu14.1) ...

$ sudo apt dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Get more security updates through Ubuntu Pro with 'esm-apps' enabled:
  libzmq5 libopenexr24 libsdl2-2.0-0 libmysofa1
Learn more about Ubuntu Pro at https://ubuntu.com/pro
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

shim ist nicht installiert, und os-prober stört wohl auch nicht mehr:

$ dpkg --list shim* os-prober
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name           Version      Architektur  Beschreibung
+++-==============-============-============-==================================>
ii  os-prober      1.74ubuntu2  amd64        utility to detect other OSes on a >
un  shim           <keine>      <keine>      (keine Beschreibung vorhanden)

Danke für den Hinweis ☺

UlfZibis schrieb:

... Wenn ich mich richtig erinnere, führte die Umlenkung in einen NVRAM-Eintrag ader auch zu Problemen, welche weiß ich nicht mehr.

Hab's wieder gefunden. Hier in der Expertenbox ist das Problem beschrieben: https://wiki.ubuntuusers.de/EFI_Nachbearbeitung/#Systeme-mit-secure-boot
Und hier auch: https://forum.ubuntuusers.de/post/8667388/

Statt den NVRAM-Eintrag umzulenken sollte für eine Sekundär-Installation also besser gleich mit ubiquity -b installiert werden. Leider wird darauf im Artikel nicht. hingewiesen.

Zur Sicherheit dann auch noch:

$ sudo apt purge grub-pc grub-pc-bin
[.....]
$ sudo grub-install
grub-install: Fehler: /usr/lib/grub/i386-pc/modinfo.sh existiert nicht. Bitte geben Sie --target oder --directory an.
$ sudo apt dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Get more security updates through Ubuntu Pro with 'esm-apps' enabled:
  libzmq5 libopenexr24 libsdl2-2.0-0 libmysofa1
Learn more about Ubuntu Pro at https://ubuntu.com/pro
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Und nochmal gründlicher:

$ sudo apt purge grub2-common
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  grub2-common*
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 1.341 kB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n] j
(Lese Datenbank ... 213315 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von grub2-common (2.04-1ubuntu26.16) ...
Trigger für install-info (6.7.0.dfsg.2-5) werden verarbeitet ...
Trigger für man-db (2.9.1-1) werden verarbeitet ...
(Lese Datenbank ... 213291 Dateien und Verzeichnisse sind derzeit installiert.)
Löschen der Konfigurationsdateien von grub2-common (2.04-1ubuntu26.16) ...
ich@Asus-X200MA:~$ sudo grub-install
sudo: grub-install: Befehl nicht gefunden
ich@Asus-X200MA:~$ sudo apt dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Get more security updates through Ubuntu Pro with 'esm-apps' enabled:
  libzmq5 libopenexr24 libsdl2-2.0-0 libmysofa1
Learn more about Ubuntu Pro at https://ubuntu.com/pro
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Eine /boot/grub/grub.cfg lässt sich so immer noch erstellen, denn die brauche ich für die EWMS.

$ sudo grub-mkconfig
Quelldatei `/etc/default/grub.d/init-select.cfg'
GRUB-Konfigurationsdatei wird erstellt …
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_dist-name ###

Hej,

UlfZibis schrieb:

...Wenn ich mich richtig erinnere, führte die Umlenkung in einen NVRAM-Eintrag ader auch zu Problemen, welche weiß ich nicht mehr.

ich kann da keine Probleme sehen, Du willst doch gerade, daß das nicht mehr funktioniert! Und wenn kein Verzeichnis Ubuntu (ggf auch noch Boot) mehr anwesend ist in der ESP, dann kann auch die firmware nicht mal eben einen neuen Eintrag im NVRAM generieren. K.A., was ein upgrade der grub Dateien als Stolperfalle findet, wenn Du die grub-efi-amd64 und ggf. weitere deinstalliert (und gepinnt) hast.

Streifenschmerle schrieb:

...Bei mir hat es schon ausgereicht, den fstab-Eintrag der EFI-Partition in demjenigen System ("Sekundärinstallation") zu entfernen, das die EFI-Partition in Ruhe lassen soll.

bestimmt nicht, kannst Du ganz einfach prüfen mit dpkg-reconfigure grub-efi-amd64

Gruß black tencate

black_tencate schrieb:

UlfZibis schrieb:

...Wenn ich mich richtig erinnere, führte die Umlenkung in einen NVRAM-Eintrag aber auch zu Problemen, welche weiß ich nicht mehr.

ich kann da keine Probleme sehen, Du willst doch gerade, daß das nicht mehr funktioniert! Und wenn kein Verzeichnis Ubuntu (ggf auch noch Boot) mehr anwesend ist in der ESP, dann kann auch die firmware nicht mal eben einen neuen Eintrag im NVRAM generieren. K.A., was ein upgrade der grub Dateien als Stolperfalle findet, wenn Du die grub-efi-amd64 und ggf. weitere deinstalliert (und gepinnt) hast.

Wenn man mehrere NVRAM-Einträge anlegt könnte man ja gemäß der UEFI-Logik seine verschiedenen Installationen auch aus dem UEFI-Bootmenü auswählen, und so jedem System seine eigene GRUB-Installation zuordnen (wäre z.B. für mein 32-Bit Ubuntu sehr hilfreich). Das klappt aber nicht, weil im signierten Ubuntu-GRUB immer "EFI\ubuntu" fest verdrahtet drin steht, auch wenn GRUB in ein alternatives EFI-Verzeichnis installiert wird.

Ich muss also ein spezielles GRUB installieren, um alle Systeme booten zu können, und das geht nur über ein Live-System und ist deshalb eine sehr lästige Angelegenheit. Es handelt sich dabei ja um meinen Experimentier-Rechner, der in der Lage sein soll, alles mögliche booten zu können, u.a. auch 32-Bit-OSe.

Um aber nur die durch Aktualisierung verursachte GRUB-Installation in einen ungefährlichen Bereich umzulenken muss ich Dir wohl zustimmen, dass das klappen sollte. Im UEFI-Bootmenü stehen dann halt fehlerhafte nicht nutzbare Einträge, was doch ein bisschen hässlich ist.

Hej UlfZibis,

UlfZibis schrieb:

... Wenn man mehrere NVRAM-Einträge anlegt könnte man ja …

schaust Du → Mehrbootsystem mit 2x Ubuntu, da findest Du den Grund, warum das bei mehreren Ubuntu eben nicht geht! In Verbindung mit anderen wie Debian etc. funktioniert genau das aber durchaus.

Im UEFI-Bootmenü stehen dann halt fehlerhafte nicht nutzbare Einträge, was doch ein bisschen hässlich ist.

wer zwingt Dich, die anzulegen/beizubehalten?

Gruß black tencate