Latence du noyau au démarrage

Bonjour à tou.te.s :D !

Récemment j'ai ouvert le fil suivant : Convertir partition depuis support GPT en MBR pour isoler en p2v un système Debian problématique sur une machine physique afin de l'éprouver en machine virtuelle (ici avec Qemu/KVM/libvirt).

J'avais presque mené à terme ce projet, mais il restait un problème de latence au démarrage que je viens de résoudre.

=> célébration, problème résolu :D !

Je propose de vous faire un retour ici.

----

Au démarrage il y avait environ 30s où il ne se passait rien. Le curseur blanc clignotait sur fond noir. Juste après venaient toutes les écritures ininterrompues de systemd avant d'arriver sur l'accueillant.

J'ai fait un audit sur l'activité après amorçage et j'ai constaté que c'était le noyau qui générait cette latence.
 

$ systemd-analyze
Startup finished in 33.781s (kernel) + 4.069s (userspace) = 37.851s 
graphical.target reached after 4.040s in userspace.

$ systemd-analyze plot > analyse.svg

J'avais ouvert le fichier SVG généré (ristretto sait le faire) et sans zoom, on voyait une longue barre en gris en haut de 33s ...

... et on pouvait constater que cette barre était relative au noyau :

J'ai alors demandé à @mamiemando de l'aide pour révéler l'activité du noyau (voir dans le fil dessus) mais les propositions simples n'ont pas abouties.

Remarque : le fameux "RTFM" ne m'a pas beaucoup aidé jusqu'à présent car quand je me lance dans la lecture d'un manuel (man, info, help), je me sens noyé dans sa compréhension, le sens des phrases et souvent je ne comprends pas ou je mésinterprête (j'ai un multi-handicap sensoriel et mnésique). Pour moi ces rédacteurs s'adressent uniquement à des personnes qui les comprennent et rarement je les comprends. De fait, je suis contraint de rechercher différentes documentations et approches, pour mieux cerner les tenants et les aboutissants. C'est aussi pour ça que je ne me réfère pas à ces manuels pour sourcer mes démarches.

Après m'être documenté sur l'analyse du démarrage Linux (Analyze Linux startup performance), j'ai vu qu'il y avait un prérequis (Understanding systemd at startup on Linux) que j'ai également parcouru et à la rubrique Exploring Linux startup with systemd il était question de modifier le fichier grub.cfg pour enlever la directive quiet de manière à afficher les messages d'amorçage ce qui m'a fait réaliser qu'ils pouvaient être cachés par défaut et que je ne me souciais pas du fait qu'il y avait dans les distributions actuelles, cette pratique de cacher ces messages.

Je l'ai donc supprimé de /etc/default/grub et ai appliqué la modification avec update-grub.

Au prochain amorçage, j'ai vu que l'écran était d'avantage verbeux avant les affichages de systemd et qu'il bloquait sur une action qui se répétait : "running /scripts/local-block"

Cette page Solving the Running /scripts/local-block loop while booting in Linux a mis en évidence le problème : l'amorçage Linux a besoin de connaître l'identifiant unique (UUID) du fichier d'échange (mémoire SWAP) qu'il essaye de monter

Ça a fait tilt dans ma tête ! Le SWAP du disque GPT était dans une partition dédiée (et non dans un fichier du système) qui n'avait pas été clonée. J'avais bien supprimé son montage depuis /etc/fstab (je rappelle que le SWAP n'est pas obligatoire, surtout en virtualisation), mais je m'étais arrêté là.

Attention : à partir d'ici, je ne suis pas sûr de tout comprendre, donc si des experts passent par là, n'hésitez pas à corriger ...

En effet, depuis /etc/initramfs-tools/conf.d/resume (de mémoire, qui sert entre autre pour la veille), il y avait bien un lien vers le SWAP, je l'ai alors désactivé en commentant la ligne (la précéder par #).

Dans mon cas, une fois modifiée :

$ cat /etc/initramfs-tools/conf.d/resume
#RESUME=UUID=80f3d2a0-e416-49d1-b5d9-1dd5fb089e22

Mais ce n'était pas tout, après le chargement du noyau, le SWAP est aussi utilisé par l'archive initrd.img qui charge le système de fichier initramfs permettant de monter le système de fichiers racine (source et aussi ici).

Comme le lien vers le SWAP est intégré "en dur" dans l'archive, il faut mettre à jour pour la régénérer :

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-23-amd64

Note : cette mise à jour est entre autre impactée par le fichier resume indiqué dessus, j'ai pu le constater car en réactivant la ligne et en remettant à jour, j'ai pu constater le problème initial

=> il n'y a désormais pas cette latence de 30s au démarrage :D

En espérant que ça puisse servir à d'autres ...

Avec adelphité,

lnj

Linux / Firefox 115.0