Snap-Packages unter Gentoo nutzen

Einer der großen Vorteile von Snap-Packages ist es, dass diese im Gegensatz zu „klassischen“ Paketen nicht nur unter einer Linux-Distribution ausgeführt werden können, sondern ohne weitere Anpassung mit einer Vielzahl an Distributionen kompatibel sind. Viele Distributionen bringen den für den Snap-Support erforderlichen snapd-Daemon bereits mit.

Auch unter Gentoo können Snap-Packages genutzt werden. Selbst der Paketbau mit snapcraft und multipass bzw. LXD funktioniert.

Mehr lesen „Snap-Packages unter Gentoo nutzen“

Ein offizielles Kernel-Paket für Gentoo?

Im Gegensatz zu anderen Distributionen laufen Kernel-Installationen und -Updates unter Gentoo ein wenig anders ab. Während bei anderen Distributionen neue Kernel-Versionen einfach über die Paketverwaltung installiert werden, liefert Gentoo lediglich den Kernel-Quelltext aus. Der Benutzer kompiliert und installiert den Kernel anschließend manuell in einem zweiten Schritt. Das will Gentoo-Entwickler Michał Górny jetzt mit einem offiziellen Gentoo-Kernel ändern.

Mehr lesen „Ein offizielles Kernel-Paket für Gentoo?“

Gentoo: Portage auf Git umstellen

Standardmäßig verwendet Gentoo zur Verteilung des Portage-Tree das rsync-Protokoll. Für die Übertragung bzw. Synchronisation vieler kleiner Dateien ist das Protokoll auch gut geeignet und funktioniert stabil.

Diese Methode hat jedoch einen Nachteil. Um die Integrität der heruntergeladenen Dateien zu überprüfen, sind diese via OpenGPG signiert. Der eigentliche Download erfolgt zunächst in ein „Quarantäneverzeichnis“, dann erfolgt eine Signaturprüfung. Erst, wenn die Signaturen validiert wurden, wird der lokale Portage Tree entsprechend aktualisiert. Der Nachteil hierbei ist, dass die Signaturprüfung (gerade auf weniger performanten Systemen) verhältnismäßig langsam ist – ich habe hier schon Update-Zeiten von mehreren Minuten gesehen.

Glücklicherweise kann man portage anweisen, für die Aktualisierung des Portage Tree statt rsync auch git zu verwenden.

Mehr lesen „Gentoo: Portage auf Git umstellen“

Gentoo: Neue Kernel-Dateinamen für genkernel

Kurz notiert – eben wurde mir der folgende News-Eintrag in die Gentoo-News gespült.

  Title                     Genkernel 4 changed default filenames
  Author                    Thomas Deutschmann <$censored$@gentoo.org>
  Posted                    2019-12-30
  Revision                  1

To be consistent with kernel's own naming which allows for easier
matching of kernel/initramfs with kernel files (/lib/modules),
genkernel 4 changed default kernel and initramfs filename:

    kernel-genkernel-%%ARCH%%-%%KV%%      -> vmlinuz-%%KV%%
    System.map-genkernel-%%ARCH%%-%%KV%%  -> System.map-%%KV%%
    initramfs-genkernel-%%ARCH%%-%%KV%%   -> initramfs-%%KV%%.img

Note that in genkernel 4, filenames are fully customizable and that
$ARCH value is now part of $KV value by default.

All bootloaders and utilities like sys-apps/kexec-tools available in
Gentoo repository support the new naming schema.

However, due to lexical ordering, the default boot entry in your boot
manager could still point to last kernel built with genkernel before
that name change, resulting in booting old kernel when not paying
attention on boot.

Berücksicht dies also ggf. bei eurer Bootloader-Konfiguration, sofern ihr genkernel 4.x verwendet.

Gentoo: syslog-ng hängt während des Bootvorgangs

Bereits mehrfach habe ich (hauptsächlich auf „performanteren“ Systemen) festgestellt, dass auf meinen Gentoo-Systemen der Logging-Dienst syslog-ng während des Bootvorgangs (scheinbar) ewig hängenbleibt. Kurioserweise lässt sich der Bootvorgang in solchen Fällen mit mehreren (zufälligen) Tastendrücken wieder anstoßen.

Wie unter anderem dieser Bug-Report (zwar von Debian, ich vermute hier jedoch einen Zusammenhang zu SysV-init bzw. OpenRC) zeigt, liegt die Ursache für die Start-Verzögerung daran, dass syslog-ng zum Starten verhältnismäßig viele Zufallsdaten benötigt. Da der zur Erzeugung der Zufallsdaten benötigte Entropie-Pool zum Boot-Zeitpunkt noch verhältnismäßig „leer“ ist, können die Zufallsdaten nicht schnell genug erzeugt werden.

Abhilfe schafft hier der haveged-Daemon, der Zufallszahlen über das HAVEGE-Verfahren erzeugt. Die Arbeitsweise von haveged wird in der zugehörigen Manpage erläutert. Vereinfacht gesagt wird zur Erzeugung der Zufallsdaten das „Hintergrundrauschen“ der CPU ausgenutzt.

In meinen Tests ließen sich die Boot-Zeiten mit haveged stets auf ein normales Maß reduzieren. Die Installation ist dabei sehr simpel, eine weitere Konfiguration ist nicht erforderlich:

emerge sys-apps/haveged
rc-update add haveged boot

Fertig.