Création initramfs pour systemd ( /usr non dans racine )

Support Debian
#1

J’ai voulu tenter de mettre à jour une deuxième machine powerPC (IBM P630) de wheezy en jessie. D’expérience avec la première, je me doutais que je serais obligé d’utiliser le vieux noyau de wheezy ( vmlinux-3.2.0-4-powerpc64 ).

Effectivement, le noyau vmlinux-3.16.0-4-powerpc64 se plante. Je redémarre sur l’ancien, je vois des fsck à la console plus des messages d’erreurs bizarres. (le tout au sous-sol dans un bruit d’enfer et une température bien fraîche :grin: )
Après m’être identifié sur la console 1, je m’aperçoit que /usr n’était pas monté, ce qui a entraîné l’échec du démarrage de le plupart des services (dont ssh , ntp, nfs, cron, atd, …)

Revenu au bureau, je constate sur la machine qui démarre en hessie/systemd avec le vieux noyau que le initrd.img-3.2.0-4-powerpc64 associé fait plus de 14Mo, alors que sur la machine à problème c’est une taille de 3859 Ko.

Avec systemd il est supposé qu’on peut monter /usr très tôt dans la séquence de démarrage.

Ma question : que faut-il faire pour avoir un initramfs qui monte /usr suffisamment tôt (pour satisfaire les exigences de Monsieur systemd ) ?

Comme je dois noter la commande exacte sur un papier avant d’aller la taper sur la console dans la salle machines au sous-sol, il me faut quelque chose de très précis. Et pour redémarrer le bouzin il y en a bien pour un quart d’heure :grin:

Merci d’avance

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.
Bureau Veritas

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

#2

pour creer initramfs il faut utiliser update-initramfs

pour ton cas voir s’il faut des options spéciales

http://man.he.net/man8/update-initramfs

#3

C’est bien ce que j’ai tenté. Le fichier généré dépasse à peine les 4Mo.

Sur ces machines, j’avais fait un partitionnement à l’ancienne, avec des partitions petites.

Exemple sur la machine halc10 qui démarre sur le noyau oldstable ( jessie 8.5 )

fp2x@halc10:/etc$ df -hT | fgrep -v tmpfs
Sys. de fichiers              Type     Taille Utilisé Dispo Uti% Monté sur
/dev/sdd3                     ext3       756M    408M  310M  57% /
/dev/sdd5                     ext3       5,7G    2,9G  2,5G  54% /usr
/dev/sdd1                     ext2       192M     81M  101M  45% /boot
/dev/sdd6                     ext3       2,8G    2,3G  381M  86% /var
/dev/sdd7                     ext3       756M     17M  717M   3% /tmp
/dev/sdd9                     ext3       7,5G    5,8G  1,6G  80% /home
/dev/mapper/data_vg-homex_lv  xfs        120G     72G   49G  60% /homex
/dev/mapper/homes_vg-homes_lv ext3       250G    135G  111G  55% /homea
fp2x@halc10:/etc$

Et je vois en cherchant sur internet qu’avoir /var séparé peut aussi poser problème (du genre on veut démonter var et ce con de journald veut écrire dans /var/log/journal ).

Je commence à comprendre les fils de messages à rallonge sur debian-devel au moment de l’introduction de systemd.

Le plus énervant est (après le update-initramfs ) de faire

sudo /sbin/reboot

et d’attendre, attendre uune minute sans rien à l’écran. Donc Ctrl-C et on verra demain.

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
« Je préfère le vin d’ici à l’au-delà »
Pierre Dac

#4

C’est petit. /etc/initramfs-tools/initramfs.conf contiendrait-il “MODULES=dep” au lieu de “MODULES=most” ?

Cela n’a rien à voir avec systemd. Les développeurs de systemd n’ont fait que prendre acte du fait que dans certaines situations /usr doit être disponible très tôt, avant l’exécution des scripts d’init, donc avant la lecture de /etc/fstab. Par exemple parce que certaines actions déclenchées par udev (qui démarre avant l’activation des montages définis dans /etc/fstab) peuvent avoir besoin de fichiers situés dans /usr. Deux solutions : ne plus séparer /usr de la racine ou bien le monter très tôt. C’est l’initramfs qui est censé monter /usr si nécessaire.

Un peu de lecture : https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Normalement rien. L’initramfs généré par le paquet initramfs-tools de Jessie le fait. L’initramfs a-t-il bien été regénéré depuis la migration (vérifier la date) ?
La ligne concernant /usr dans /etc/fstab est-elle correcte ? Même si l’initramfs n’a pas monté /usr, le script d’init qui traite /etc/fstab aurait dû le faire.

Encore une fois, ce n’est pas nouveau ni spécifique à systemd. syslog et compagnie en faisaient autant.

#5

Ouf ! En forçant un un arrêt par un appui prolongé sur le tout petit bouton qui fait office d’interrupteur, j’ai pu redémarrer sur le noyau oldstable. Et cette fois-ci /usr a été monté vite fait bien fait :smile:

A propos de initrd.img

petit, mais costaud (car suffisant)

fp2x@halc9:~$ ls -lApst /boot/initrd.img-*
4362 -rw-r--r-- 1 root root 4448027 juin  15 18:47 /boot/initrd.img-3.2.0-4-powerpc64
4725 -rw-r--r-- 1 root root 4817314 juin  15 18:47 /boot/initrd.img-3.16.0-4-powerpc64
fp2x@halc9:~$ fgrep  MODULES /etc/initramfs-tools/initramfs.conf
# MODULES: [ most | netboot | dep | list ]
MODULES=most
fp2x@halc9:~$

Sur ces machines, il n’y a que le noyau qui est en 64bits, tous les binaires de l’espace utilisateur sont en 32bits.

A propos du montage de /usr au démarrage, que faut-il faire ?

Vous avez entièrement raison. Je pense que le problème que j’ai eu hier soir est dû au fait qu’en plus des montages nécessaires le système était en fait occupé à faire des fsck des systèmes de fichiers. (machine up depuis lundi 9 novembre 2015 )

En tout cas, un grand merci à Pascal Hambourg pour ses remarques toujours aussi pertinentes.

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.
Bureau Veritas
Département Recherche, le département de l’excellence technique.

Fier d’être depuis 40 ans au service de Bureau Veritas, branche Marine & Offshore

« C’est terrible d’allonger la vie en prolongeant seulement la vieillesse. »
– Professeur Choron