[geklärt] Dauerhafte Änderung im postinst-Skript

[Livingston]

Nmorgn,
ich habe für mein privates Bootstick-Projekt ein kleines Script erstellt, das eine grub.cfg-Datei ohne Rückgriff auf /etc/grub.d/* und /etc/default/grub erstellt. Das ganze funktioniert tadellos, liegt in /usr/local/sbin und heißt myupdate-grub.
Wäre natürlich schön, wenn es bei jedem update des grub-Paketes aufgerufen würde, und auch verhindert werden könnte, dass der reguläre Aufruf von update-grub erfolgt.

Mir schwebt vor, in das postinst-Script reinzugrätschen. Wäre nur die Frage, ob postinst selbst nicht einem Upgrade zum Opfer fällt. Gibt es dafür eine dauerhafte Lösung? Bin ich vielleicht komplett auf dem Holzweg?

Nebenbei: Der Vorgang lässt sich für ein Kernelupdate leicht kontrollieren, indem man /etc/kernel/postinst.d/zz-update-grub entsprechend anpasst. grub stellt aber für sich selbst keine solche Konfigurationsmöglichkeit in /etc zur Verfügung.

[JTH]

Eins der Maintainer-Skripte (postinst und co.) zu überschreiben dürfte nicht möglich sein. Die kommen mit jedem zu installierenden und daher neu entpackten Paket (-update) neu mit. Ich kenne zumindest keine Hooks, um an der Stelle einzugreifen.

Wenn du dir sicher bist, dass dein eigenes update-grub das originale voll vertreten kann, könntest du das letztere einfach ersetzen. Das ginge z.B. in dem du das originale /usr/sbin/update-grub mit dpkg-divert aus dem Weg schiebst, damit es bei Upgrade von grub2-common nicht wieder „repariert“ wird. Dein eigenes update-grub sollte dann auch eben so heißen, ohne my am Anfang. Evtl musst du es noch nach /usr/sbin verlinken, ich bin mir nicht ganz sicher, ob der PATH für Maintainer-Skripte /usr/local/sbin enthält.

[Livingston]

Der Ansatz gefällt mir, insbesondere klingt die man-page vielversprechend:

dpkg-divert is the utility used to set up and update the list of diversions.
File diversions are a way of forcing dpkg(1) not to install a file into its location, but to a diverted location.

Ich werde mal ein wenig rumtüfteln und melde in ein paar Tagen zurück, wie es gelaufen ist.
Danke Dir

[smutbert]

Eine andere Möglichkeit wäre bei der Installation festzulegen, dass grub gar nicht wirklich installiert werden soll (bei grub-pc kann bei der Paketkonfiguration die Geräte auswählen auf die er geschrieben werden soll und bei grub-efi lässt sich die Installation verhindern indem man die EFI System Parttion einfach nicht unter /boo/efi mountet).

Dann kann man grub selbst mit grub-install installieren. Für das Anlegen der grub.cfg ist man dann selbst verantwortlich...
(ich lege in der Situation Menüeinträge an, die den Kernel und die initrd über die per default vorhandenen symbolischen Links zum aktuellen Kernel, /vmlinuz und /initrd.img laden damit ich die grub.cfg nicht bei jedem Kernelupdate anpassen muss)

[Livingston]

Hi, smutbert,
die Multi-Installation löse ich mit der Installation der verschieden grub-xxx-bin-Pakete. Da ist alles drin, wie in Deinem Wiki beschrieben, es wird aber nichts automatisch ausgeführt. Der Vorteil: Man verpasst keine Updates, der Nachteil: Alles muss man selber machen.
Im Moment überlege ich, passend für die ...-bin-Pakete, grub-common und grub-common2 ein Dummy-Paket zusammenzuschrauben, dass nur von entsprechenden Updates getriggert die 3 verschiedenen grub-installs und/oder mein kleines selbstgebautes update-grub anstößt.
Ist jedoch ein Hobby-Projekt, deshalb gibt's hier nur langsamen Fortschritt.

Ich überlege auch, dafür 'nen eigenen Thread aufzumachen, denn das ursprünliche Problem ist mit JTHs Hinweis gelöst und eigentlich möchte ich inzwischen bei der Automatisierung wie oben beschrieben anders ansetzen.

NACHTRAG: apt, dpkg und überhaupt das Debian-Paketformat ermöglichen saubere Lösungen ohne dreckige Hacks. Ist für mich ein netter Anlass, mal in diese Materie einzusteigen. Hab um Paketbau immer einen großen Bogen gemacht. Das darf so nicht weitergehen.

[JTH]

apt, dpkg und überhaupt das Debian-Paketformat ermöglichen saubere Lösungen ohne dreckige Hacks. Ist für mich ein netter Anlass, mal in diese Materie einzusteigen.

Kann ich nur empfehlen, man lernt einiges über die Interna von Debian Und macht sich bei Problemen mit Paketinstallationen weniger Sorgen und weiß besser, sie zu lösen. Bei Fragen immer her damit, ich knobel gerne mit

Im Moment überlege ich, passend für die ...-bin-Pakete, grub-common und grub-common2 ein Dummy-Paket zusammenzuschrauben, dass nur von entsprechenden Updates getriggert die 3 verschiedenen grub-installs und/oder mein kleines selbstgebautes update-grub anstößt.

Zu dpkg-divert kann ich dir noch config-package-dev empfehlen. Das vereinfacht die Integration von dpkg-divert in den Maintainer-Skripten eines Debian-Pakets, das nur zur Konfiguration(smodifikation) da ist.

Es gibt tatsächlich auch dpkg-trigger, die bei Installation des einen Pakets einen (Konfigurations-) Schritt eines anderen (vllt schon installierten) Pakets neu anstoßen (siehe /var/lib/dpkg/info/*.triggers für die Pakete, die das benutzen). Der Mechanismus wird von Grub im Zusammenspiel mit den Kernelpaketen aber leider nicht benutzt.

[…] und eigentlich möchte ich inzwischen bei der Automatisierung wie oben beschrieben anders ansetzen.

Der bei Benutzung von update-grub oder eigentlich grub-mkconfig vorgesehene Weg, das Schreiben der /boot/grub/grub.cfg anzupassen, wäre ja eher ein Bearbeiten der Skriptschnipsel in /etc/grub.d. Dafür könntest du z.B. in einem eigenen Paket die Dateien, die grub-common in /etc/grub.d ablegt, dpkg-diverten (und evtl. auch aus anderen Paketen, siehe apt-file find /etc/grub.d/). Und dann dein jetziges myupdate-grub dort als /etc/grub.d/00_sowieso installieren. Nur so als andere Idee, das irgendwie „sauber“ umzusetzen.

[Livingston]

Bei Fragen immer her damit, ich knobel gerne mit

Da komme ich gerne drauf zurück.

Mein Bootstick-Projekt ist ein idealer Kandidat für alle möglichen Szenarien. Ich fresse mich dabei durch alle möglichen Themen durch, die ich bislang nur stiefmütterlich behandelt habe. Die Paketverwaltung gehört definitiv dazu, und ich bin mir sicher, dass ich irgendwann ein paar Fragen dazu habe.
Danke nochmal für die guten Tipps.