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.

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.

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.