Update-initramfs: pigz: abort: write error on <stdout> (No space left on device) + Amorçage

Support Debian
, , , ,
Tags: #<Tag:0x00007f2c9b5b4db0> #<Tag:0x00007f2c9b5b4c20> #<Tag:0x00007f2c9b5b4a90> #<Tag:0x00007f2c9b5b49a0> #<Tag:0x00007f2c9b787b88>
#1

Bonjour,

Je voulais mettre à jour ma buster headless (en ssh).

...
23,6 Mo réceptionnés en 18s (1 289 ko/s)                                       
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
62 paquets peuvent être mis à jour. Exécutez « apt list --upgradable » pour les voir.
N: Le dépôt « http://ftp2.fr.debian.org/debian buster InRelease » a modifié sa valeur « Version » de « 10.3 » à « 10.4 »
root@n40l:~# apt upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les NOUVEAUX paquets suivants seront installés :
  linux-headers-4.19.0-9-amd64 linux-headers-4.19.0-9-common
  linux-image-4.19.0-9-amd64
Les paquets suivants seront mis à jour :
  apt apt-transport-https apt-utils base-files bind9-host cups cups-bsd
  cups-client cups-common cups-core-drivers cups-daemon cups-ipp-utils
  cups-ppdc cups-server-common distro-info-data dnsutils dtv-scan-tables fuse
  intel-microcode iputils-ping libapt-inst2.0 libapt-pkg5.0 libbind9-161
  libcups2 libcups2-dev libcupsimage2 libcupsimage2-dev
  libdatetime-timezone-perl libdns-export1104 libdns1104 libfuse2
  libgnutls-openssl27 libgnutls30 libirs161 libisc-export1100 libisc1100
  libisccc161 libisccfg163 liblwres161 libnss-systemd libpam-systemd
  libpango-1.0-0 libpango1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0
  libpangoxft-1.0-0 libsystemd0 libudev-dev libudev1 linux-compiler-gcc-8-x86
  linux-headers-amd64 linux-image-amd64 linux-kbuild-4.19 linux-libc-dev
  postfix postfix-sqlite systemd systemd-sysv tzdata udev wpasupplicant
  xdg-utils
62 mis à jour, 3 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 86,3 Mo dans les archives.
Après cette opération, 331 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o

...
Paramétrage de linux-image-4.19.0-9-amd64 (4.19.118-2+deb10u1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.19.0-8-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.19.0-8-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-4.19.0-9-amd64
I: /initrd.img is now a symlink to boot/initrd.img-4.19.0-9-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64
/etc/kernel/postinst.d/zz-update-grub:
Création du fichier de configuration GRUB…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-4.19.0-9-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-9-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-8-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-8-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-6-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-6-amd64
fait
...

Et je me retrouve à la fin avec :

...
Traitement des actions différées (« triggers ») pour libc-bin (2.28-10) ...
Traitement des actions différées (« triggers ») pour rsyslog (8.1901.0-1) ...
Traitement des actions différées (« triggers ») pour systemd (241-7~deb10u4) ...
Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
Traitement des actions différées (« triggers ») pour ntp (1:4.2.8p12+dfsg-4) ...
Traitement des actions différées (« triggers ») pour dbus (1.12.16-1) ...
Traitement des actions différées (« triggers ») pour install-info (6.5.0.dfsg.1-4+b1) ...
Traitement des actions différées (« triggers ») pour doc-base (0.10.8) ...
Traitement de 1 fichier de documentation modifié…
Traitement des actions différées (« triggers ») pour initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64
pigz: abort: write error on <stdout> (No space left on device)
E: mkinitramfs failure cpio 141 pigz 28
update-initramfs: failed for /boot/initrd.img-4.19.0-9-amd64 with 1.
dpkg: erreur de traitement du paquet initramfs-tools (--configure) :
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@n40l:~#

Je suis étonné de ne pas avoir eu assez de place sur la sortie standard (<stdout>) ??
J’ai à mon avis assez de place dans mon volume logique monté sur /boot

root@n40l:~# df -h
Sys. de fichiers       Taille Utilisé Dispo Uti% Monté sur
udev                     3,8G       0  3,8G   0% /dev
tmpfs                    786M    9,1M  777M   2% /run
/dev/mapper/vg0-racine    15G    4,1G  9,8G  30% /
/dev/mapper/vg0-usr       20G    2,9G   16G  16% /usr
tmpfs                    3,9G       0  3,9G   0% /dev/shm
tmpfs                    5,0M       0  5,0M   0% /run/lock
tmpfs                    3,9G       0  3,9G   0% /sys/fs/cgroup
/dev/mapper/vg0-opt       15G     40M   15G   1% /opt
/dev/mapper/vg0-src       15G    920M   13G   7% /usr/src
/dev/mapper/vg0-root     128G     89G   37G  71% /root
/dev/mapper/vg0-var       30G     11G   18G  39% /var
/dev/mapper/vg0-home     1,2T    1,1T   75G  94% /home
/dev/mapper/vg0-boot     236M    201M   23M  90% /boot
/dev/mapper/vg0-plex      14T     13T  271G  98% /plex
tmpfs                    786M       0  786M   0% /run/user/0
tmpfs                    786M       0  786M   0% /run/user/1000
root@n40l:~# ls -lh /boot/initrd.img-4.19.0-9-amd64 
-rw-r--r-- 1 root root 55M juin  16 04:34 /boot/initrd.img-4.19.0-9-amd64
root@n40l:~# 

root@n40l:~# ls /boot/ -lh
total 188M
-rw-r--r-- 1 root root 202K nov.  11  2019 config-4.19.0-6-amd64
-rw-r--r-- 1 root root 202K avril 27 07:05 config-4.19.0-8-amd64
-rw-r--r-- 1 root root 202K juin   7 17:42 config-4.19.0-9-amd64
drwxr-xr-x 5 root root 1,0K juin  16 04:34 grub
-rw-r--r-- 1 root root  54M janv. 21 03:38 initrd.img-4.19.0-6-amd64
-rw-r--r-- 1 root root  55M mai    7 20:42 initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 root root  55M juin  16 04:34 initrd.img-4.19.0-9-amd64
drwx------ 2 root root  12K août   8  2015 lost+found
-rw-r--r-- 1 root root 3,3M nov.  11  2019 System.map-4.19.0-6-amd64
-rw-r--r-- 1 root root 3,3M avril 27 07:05 System.map-4.19.0-8-amd64
-rw-r--r-- 1 root root 3,3M juin   7 17:42 System.map-4.19.0-9-amd64
-rw-r--r-- 1 root root 5,1M nov.  11  2019 vmlinuz-4.19.0-6-amd64
-rw-r--r-- 1 root root 5,1M avril 27 07:05 vmlinuz-4.19.0-8-amd64
-rw-r--r-- 1 root root 5,1M juin   7 17:42 vmlinuz-4.19.0-9-amd64
root@n40l:~#

Que s’est il donc passé ?
Pourquoi deux fois
update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64 ?

Le noyau 4.19.0-9-amd64 pose-t’il des problèmes ?
Comment je peux reprendre le fil de ma mise à jour ?
Sans casser le système :confused:

Je n’ai rien tenté, je suis connecté en ssh à mon NAS avec la situation décrite.
Merci de bien vouloir m’aider svp :slight_smile:

#2 
root@n40l:~# cd /boot
root@n40l:/boot# rm -iv config-4.19.0-6-amd64 initrd.img-4.19.0-6-amd64 System.map-4.19.0-6-amd64 vmlinuz-4.19.0-6-amd64
rm : supprimer 'config-4.19.0-6-amd64' du type fichier ? o
'config-4.19.0-6-amd64' supprimé
rm : supprimer 'initrd.img-4.19.0-6-amd64' du type fichier ? o
'initrd.img-4.19.0-6-amd64' supprimé
rm : supprimer 'System.map-4.19.0-6-amd64' du type fichier ? o
'System.map-4.19.0-6-amd64' supprimé
rm : supprimer 'vmlinuz-4.19.0-6-amd64' du type fichier ? o
'vmlinuz-4.19.0-6-amd64' supprimé
root@n40l:/boot# apt -s upgrade 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  linux-headers-4.19.0-6-amd64 linux-headers-4.19.0-6-common linux-image-4.19.0-6-amd64
Veuillez utiliser « apt autoremove » pour les supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Conf initramfs-tools (0.133+deb10u1 Debian:10.4/stable [all])
root@n40l:/boot# apt upgrade 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  linux-headers-4.19.0-6-amd64 linux-headers-4.19.0-6-common linux-image-4.19.0-6-amd64
Veuillez utiliser « apt autoremove » pour les supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
Paramétrage de initramfs-tools (0.133+deb10u1) ...
update-initramfs: deferring update (trigger activated)
Traitement des actions différées (« triggers ») pour initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64
root@n40l:/boot# apt -s -f install
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  linux-headers-4.19.0-6-amd64 linux-headers-4.19.0-6-common linux-image-4.19.0-6-amd64
Veuillez utiliser « apt autoremove » pour les supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
root@n40l:/boot# dpkg --audit
root@n40l:/boot#

Il manquait un peu de place dans /boot apparemment :wink:
Même si il est petit, c’est la première fois que je vois ce comportement.
Il va falloir penser à augmenter la taille du volume logique vg0-boot

root@n40l:~# grub-mkconfig -o /boot/grub/grub.cfg
Création du fichier de configuration GRUB…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-4.19.0-9-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-9-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-8-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-8-amd64
fait
root@n40l:~#
#3 
root@n40l:~# apt autoremove
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
  linux-headers-4.19.0-6-amd64 linux-headers-4.19.0-6-common linux-image-4.19.0-6-amd64
0 mis à jour, 0 nouvellement installés, 3 à enlever et 0 non mis à jour.
Après cette opération, 324 Mo d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 191798 fichiers et répertoires déjà installés.)
Suppression de linux-headers-4.19.0-6-amd64 (4.19.67-2+deb10u2) ...
Suppression de linux-headers-4.19.0-6-common (4.19.67-2+deb10u2) ...
Suppression de linux-image-4.19.0-6-amd64 (4.19.67-2+deb10u2) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-4.19.0-6-amd64
/etc/kernel/postrm.d/zz-update-grub:
Création du fichier de configuration GRUB…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-4.19.0-9-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-9-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-8-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-8-amd64
fait
root@n40l:~#

apt autoremove aurait pu se charger de supprimer
les éléments de mon noyau 4.19.0-6-amd64 sous /boot et de refaire la configuration de Grub.
Je connais mal les automatismes de Debian.

root@n40l:~# dpkg -S /boot/config-4.19.0-8-amd64 /boot/System.map-4.19.0-8-amd64
linux-image-4.19.0-8-amd64: /boot/config-4.19.0-8-amd64
linux-image-4.19.0-8-amd64: /boot/System.map-4.19.0-8-amd64
root@n40l:~#
#4

Oui, mais uniquement après l’installation du nouveau noyau car autoremove conserve les deux derniers noyaux. Il faut donc prévoir l’espace pour installer, mettre à jour et reconstruire l’initramfs d’au moins 3 noyaux. Ne pas oublier que la mise à jour d’un fichier nécessite autant d’espace libre que la taille du fichier, l’ancienne et la nouvelle versions devant coexister transitoirement pendant la mise à jour afin de pouvoir restaurer l’ancienne version au cas où la mise en place de la nouvelle version échouerait pour une raison ou une autre.

L’initramfs a tendance à beaucoup grossir avec les versions, d’autant plus si on y inclut plymouth (splash screen) qui force l’inclusion des modules pilotes graphiques et de tous les firmwares installés dont ils peuvent avoir besoin. On peut le faire maigrir en remplaçant MODULES=most par MODULES=dep dans /etc/initramfs-tools/initramfs.conf avant de reconstruire les initramfs pour n’inclure que les pilotes liés au matériel présent, au prix de la portabilité sur d’autres matériels donc. Cette option est aussi disponible dans la reconfiguration du paquet initramfs-tools.

dpkg-reconfigure initramfs-tools

Voire carrément le supprimer et transférer son contenu dans le volume logique racine qui ne manque pas d’espace si GRUB sait le gérer. Je ne vois pas l’intérêt de mettre /boot dans un volume logique séparé du même groupe de volumes. Dans une partition simple hors de LVM ou dans un autre groupe de volumes, d’accord. Mais pourquoi dans le même groupe de volumes ?

Au passage, je pourrais poser la même question concernant /usr et /root.

Edit : concernant /usr seulement. Séparer /root de la racine est une aberration dans tous les cas, je ne vois pas une seule raison dans aucune circonstance pour faire cela.

2 J'aime
#5

Bonjour et Merci @PascalHambourg

Il s’agit de mon premier découpage LVM ; Un travail d’amateur un peu éclairé.
Il date de début août 2015 si j’en crois la datation de /lost+found
Il fonctionne bien depuis et c’est l’aspect primordial.

Je comprends l’intérêt pour /boot (si GRUB sait le gérer) et pour /root d’avoir leurs contenus dans le volume logique racine ; Pour que /boot ne soit plus limité et pour récupérer potentiellement 37G pour l’ensemble des volumes logiques du groupe vg0.

L’aberration n’est pas dangereuse en l’espèce.
Le cœur a ses raisons…

Je ne vois pas du tout où est le mal d’avoir /usr dans un volume logique du même et unique groupe. Pire, je ne vois aucun intérêt à avoir /usr dans un volume d’un autre groupe ou dans une partition simple hors de LVM.

Quelle est donc la spécificité de /usr pour me prodiguer un tel conseil ?

Je pourrais me contenter de donner un peu à vg0-boot depuis un autre volume peu utilisé.

Réintégrer le contenu de vg0-root dans /root du volume racine demande
une intervention off-line.

Ce n’est peut-être pas le cas pour vg0-boot dans /boot.

Je ne souhaite pas y consacrer du temps pour le moment.
La rustine me prend 5 minutes…

Merci encore pour tes explications.
Je vais y penser.

#6 
root@n40l:~# lvresize --resizefs --size -2G /dev/vg0/opt
Do you want to unmount "/opt" ? [Y|n] y
fsck de util-linux 2.33.1
Opt : 11/983040 fichiers (0.0% non contigus), 104705/3932160 blocs
resize2fs 1.44.5 (15-Dec-2018)
En train de redimensionner le système de fichiers sur /dev/mapper/vg0-opt à 3407872 (4k) blocs.
Le système de fichiers sur /dev/mapper/vg0-opt a maintenant une taille de 3407872 blocs (4k).

  Size of logical volume vg0/opt changed from 15,00 GiB (3840 extents) to 13,00 GiB (3328 extents).
  Logical volume vg0/opt successfully resized.
root@n40l:~# mount /opt
mount: /opt: /dev/mapper/vg0-opt déjà monté sur /opt.
root@n40l:~#

root@n40l:~# vgdisplay 
  --- Volume group ---
  VG Name               vg0
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  92
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                10
  Open LV               10
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               14,55 TiB
  PE Size               4,00 MiB
  Total PE              3815317
  Alloc PE / Size       3814805 / 14,55 TiB
  Free  PE / Size       512 / 2,00 GiB
  VG UUID               Y9yEul-we4Q-edFp-fXcr-2n3q-8QBp-kLcfVC
   

root@n40l:~# lvresize --resizefs --size +500M /dev/vg0/boot
  Size of logical volume vg0/boot changed from 252,00 MiB (63 extents) to 752,00 MiB (188 extents).
  Logical volume vg0/boot successfully resized.
resize2fs 1.44.5 (15-Dec-2018)
Le système de fichiers de /dev/mapper/vg0-boot est monté sur /boot ; le changement de taille doit être effectué en ligne
old_desc_blocks = 1, new_desc_blocks = 3
Le système de fichiers sur /dev/mapper/vg0-boot a maintenant une taille de 770048 blocs (1k).

root@n40l:~#

root@n40l:~# df -h
Sys. de fichiers       Taille Utilisé Dispo Uti% Monté sur
udev                     3,8G       0  3,8G   0% /dev
tmpfs                    786M     18M  769M   3% /run
/dev/mapper/vg0-racine    15G    3,9G   11G  28% /
/dev/mapper/vg0-usr       20G    2,9G   16G  16% /usr
tmpfs                    3,9G       0  3,9G   0% /dev/shm
tmpfs                    5,0M       0  5,0M   0% /run/lock
tmpfs                    3,9G       0  3,9G   0% /sys/fs/cgroup
/dev/mapper/vg0-home     1,2T    1,1T   75G  94% /home
/dev/mapper/vg0-src       15G    842M   14G   6% /usr/src
/dev/mapper/vg0-var       30G     11G   18G  39% /var
/dev/mapper/vg0-root     128G     89G   37G  71% /root
/dev/mapper/vg0-boot     721M    139M  549M  21% /boot
/dev/mapper/vg0-plex      14T     13T  271G  98% /plex
tmpfs                    786M       0  786M   0% /run/user/0
tmpfs                    786M       0  786M   0% /run/user/1000
/dev/mapper/vg0-opt       13G     40M   13G   1% /opt
root@n40l:~# 

root@n40l:~# touch /forcefsck
#7

L’intérêt d’avoir le contenu de /boot et /root dans le volume racine, c’est avant tout d’éviter les problèmes que peut causer leur séparation. Il n’y a pas d’intérêt à séparer /boot en dehors de certains cas particuliers liés aux contraintes de l’amorçage. Quant à /root, il est censé faire partie de la racine, comme /etc ou /lib. C’est le répertoire personnel du compte root, et ce n’est pas pour rien s’il est directement à la racine et non dans /home avec les répertoires personnels des utilisateurs normaux : il doit être accessible en toutes circonstances, même en cas d’échec de tous les montages définis dans /etc/fstab, sinon on peut avoir des problèmes pour ouvrir une session root afin de réparer (exemple : connexion SSH par clé stockée dans /root/.ssh).

Il n’y a aucun mal en soi à séparer /usr maintenant qu’il est monté par l’initramfs. Mais il n’y a pas vraiment d’intérêt non plus, sauf si c’est pour le monter en lecture seule. Par contre il y a des inconvénients : complexité accrue, donc risque de dysfonctionnement accru (erreur de montage, espace disque mal réparti…).

Il n’y a pas d’intérêt en soi. Cele peut être imposé par des contraintes liées aux supports de stockage disponibles (pas assez d’espace pour le contenu de /usr sur le support de stockage de la racine par exemple).

Le contenu de /usr doit être disponible dès le lancement de l’init de la racine, avant la prise en compte de /etc/fstab. Cette contrainte a été traitée en faisant monter /usr par l’initramfs juste après le montage de la racine, avant de passer la main à l’init de la racine.

Pourquoi ?
De toute façon dans ton cas il n’est pas question de transférer tout le contenu de /root dans la racine, il est trop volumineux. Apparemment tu l’as utilisé pour stocker je ne sais quoi, ce qui n’est pas son rôle.

#8

Un homme averti en vaut deux.

Alors d’accord !
Je comprends que /root est censé faire partie du volume racine ; tout comme /boot si possible.

L’espace libre dans le volume vg0-plex me permettrait de réaliser une copie transitoire, avant de supprimer les volumes vg0-root et voire aussi vg0-boot, suppression qui me permettrait d’étendre le volume vg0-racine suffisamment pour y intégrer /root et aussi éventuellement /boot.

C’est à faire off-line.
Je n’ai pas le temps en ce moment.

Ces ordinateurs à vapeur de notre époque ne savent pas comprendre ni réfléchir ni ranger et retrouver comme il le faudrait sans me tracasser. C’est dingue non ?

Je fais un peu comme je peux, et comme je veux.
Mon petit big data est en… désordre.

Merci bien Pascal

#9

Bonjour,

Je suis en train de le faire.
J’ai booté sur un CD netinstall amd64 avec la gestion Linux / GNU de mdadm et LVM embarqués.
Avec un écran, un clavier et une souris branchés directement au NAS.

livecd ~ # uname -a
Linux livecd 4.9.76-gentoo-r1 #1 SMP Fri Apr 6 01:30:38 UTC 2018 x86_64 AMD Turion(tm) II Neo N40L Dual-Core Processor AuthenticAMD GNU/Linux
livecd ~ #

C’est une vieille image pas Debian, mais j’ai l’avantage de la connaître.
Elle me procure une session ssh depuis ma Gentoo sur le transportable.

J’ai trouvé de l’aide LVM sur la toile :

https://documentation.online.net/fr/dedicated-server/rescue/mount-lvm-partition
http://www.docmirror.net/fr/linux/howto/admin/LVM-HOWTO/ch11.html

Mon miroir RAID6 est ok.

livecd ~ # cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] [linear] [multipath] 
md127 : active raid6 sdc2[6] sde2[5] sdd2[3] sdb2[1] sdf2[4] sda2[0]
      15627540480 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      bitmap: 10/30 pages [40KB], 65536KB chunk

unused devices: <none>
livecd ~ #

Donc je rapatrie dans le volume logique racine /boot, /root et /usr

Je ne donne pas de procédure pour relater mon cas particulier car c’est une source d’erreur et de confusion de suivre à la lettre ; Il vaut mieux potasser la doc sur la toile, les liens et le manuel ;
Et aussi poser des questions.

De plus c’est difficile de tout rédiger en faisant les manipulations avec grand soin.

J’ai adapté le /etc/fstab de la Buster en commentant 3 lignes.
Je m’aperçois que les UUID ne sont pas utilisés pour monter mes volumes logiques.

livecd ~ # egrep ^#\/  /mnt/vg0-racine/etc/fstab 
#/dev/mapper/vg0-boot /boot           ext3    defaults        0  2
#/dev/mapper/vg0-root /root           ext4    defaults        0  2
#/dev/mapper/vg0-usr  /usr            ext4    defaults        0  2
livecd ~ #

Je n’ai pas utilisé de chroot ni changé quoique ce soit dans la configuration du boot ou autre.
J’ai vérifié les droits des répertoires de destination.

Les copies des fichiers prennent beaucoup de temps ; j’ai un gros volume à faire transiter.
Je n’ai pas utilisé ma connexion ssh pour lancer les commandes de copie ; toutes faites en local.

La commande cp est loin d’être élémentaire… J’ai utilisé les simples options -xav
J’espère que ça ira… (je n’ai pas encore compris pour la conservation des liens)
Je l’ai en anglais le man cp… Pas facile.

C’est pour la réintégration de /usr en particulier que je doute de ma copie.

Le petit nouveau shopt -s dotglob est bien utile pour copier les fichiers cachés (voir ici)

J’ai peur de me faire avoir alors je conserve un temps le volume logique vg0-usr.

Bon, c’est presque tout copié et il reste des opérations à faire sur certains volumes logiques.

#10

Je n’ai pas conservé le volume logique vg0-boot après avoir copié son contenu dans /boot
Bien mal m’en a pris.

Grub amorce en mode rescue en disant qu’il ne trouve pas un lvm id ; Celui de l’ex vg0-boot

C’est la galère.

#11

As-tu réinstallé GRUB avec grub-install après avoir démonté le volume logique boot ?
Si non, tu peux démarrer et le faire sans avoir recours à un système externe (live ou installateur en mode rescue) avec l’invite de GRUB.

set prefix=(lvm/vg0-racine)/boot/grub
insmod normal
normal
#12

Bonjour @PascalHambourg

Merci de me répondre et pour ton aide.
Non, je n’ai pas réinstallé Grub avec grub-install.

Je ne pense pas pouvoir faire un grub-install en session live-cd Gentoo.
J’ai opéré en live-cd Gentoo du début à la fin de mes manipulations.

J’aurais dû m’occuper au préalable et sous Buster (en ligne) de tout ce qui concernait :

  • le démontage de vg0-boot de /boot
  • le montage de vg0-boot sur un répertoire /tmp/vg0-boot
  • la copie du contenu de /tmp/vg0-boot vers /boot/
  • dpkg-reconfigure initramfs-tools
  • grub-mkconfig -o /boot/grub/grub.cfg
  • grub-install /dev/sd[abcdef] # à faire un par un

Quoique je comprends maintenant l’intérêt du rescue mode Debian d’un amorçage distinct.
C’est certainement plus prudent de procéder off-line (avec la bonne image).

Donc, j’étais bloqué sur un Grub rescue en mode texte.
Les commandes que tu me donnes lançaient le menu Grub graphique interactif.

J’avais toujours un problème d’id de volume non trouvé quelque soit mon choix dans le menu.
Je ne suis pas assez précis ; le ou les messages disparaissent rapidement pour redonner le menu.

Je me suis donc créé une clef usb avec l’image debian-10.4.0-amd64-netinst.iso
Pour essayer de faire quelque chose en rescue mode Debian :

En reconstruisant le RAID de manière automatique,
Puis en désignant /dev/mapper/vg0-racine comme étant la racine,
Puis en refusant la proposition de monter une prétendue partition boot séparée,
Puis, dans un shell propre à la Buster :

  • montage des volumes logiques nécessaires (j’ai tout monté sauf vg0-home et vg0-plex)
  • option « reconstruire l’amorçage » du menu rescue mode
  • dpkg-reconfigure initramfs-tools (semble en doublon)
  • sauvegarde de /boot/grub/grub.cfg
  • grub-mkconfig -o /boot/grub/grub.cfg
  • grub-install /dev/sd[abcdef] # à faire un par un
  • touch /forcefsck # facultatif
  • redémarrage, accès au bios, retrait de la clef et redémarrage
root@n40l:~# lvs
  LV     VG  Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home   vg0 -wi-ao---- <1,22t                                                    
  opt    vg0 -wi-ao---- 15,00g                                                    
  plex   vg0 -wi-ao---- 13,09t                                                    
  racine vg0 -wi-ao---- 30,00g                                                    
  src    vg0 -wi-ao---- 15,00g                                                    
  swap   vg0 -wi-ao---- 20,00g                                                    
  usr    vg0 -wi-ao---- 20,00g                                                    
  var    vg0 -wi-ao---- 30,00g                                                    
root@n40l:~# 

root@n40l:~# vgdisplay 
  --- Volume group ---
  VG Name               vg0
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  99
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                8
  Open LV               8
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               14,55 TiB
  PE Size               4,00 MiB
  Total PE              3815317
  Alloc PE / Size       3785814 / 14,44 TiB
  Free  PE / Size       29503 / <115,25 GiB
  VG UUID               Y9yEul-we4Q-edFp-fXcr-2n3q-8QBp-kLcfVC
   
root@n40l:~# 

root@n40l:~# mount | grep vg0
/dev/mapper/vg0-racine on / type ext4 (rw,relatime,errors=remount-ro,stripe=384)
/dev/mapper/vg0-usr on /usr type ext4 (rw,relatime,stripe=384)
/dev/mapper/vg0-opt on /opt type ext4 (rw,relatime,stripe=384)
/dev/mapper/vg0-src on /usr/src type ext4 (rw,relatime,stripe=384)
/dev/mapper/vg0-home on /home type ext4 (rw,relatime,stripe=384)
/dev/mapper/vg0-var on /var type ext4 (rw,relatime,stripe=384)
/dev/mapper/vg0-plex on /plex type ext4 (rw,relatime,stripe=384)
root@n40l:~# 

root@n40l:~# df -h | grep -e Sys -e vg0
Sys. de fichiers       Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/vg0-racine    30G    8,3G   20G  30% /
/dev/mapper/vg0-usr       20G    2,9G   16G  16% /usr
/dev/mapper/vg0-opt       15G     40M   15G   1% /opt
/dev/mapper/vg0-src       15G    842M   14G   6% /usr/src
/dev/mapper/vg0-home     1,2T    1,1T   75G  94% /home
/dev/mapper/vg0-var       30G     11G   18G  39% /var
/dev/mapper/vg0-plex      14T     13T  182G  99% /plex
root@n40l:~#
root@n40l:~# df -ih | grep -e Sys -e vg0
Sys. de fichiers       Inœuds IUtil. ILibre IUti% Monté sur
/dev/mapper/vg0-racine   1,9M   158K   1,8M    9% /
/dev/mapper/vg0-usr      1,3M   126K   1,2M   10% /usr
/dev/mapper/vg0-opt      960K     11   960K    1% /opt
/dev/mapper/vg0-src      960K    56K   905K    6% /usr/src
/dev/mapper/vg0-home      77M   146K    77M    1% /home
/dev/mapper/vg0-var      1,9M   332K   1,6M   18% /var
/dev/mapper/vg0-plex      14M   649K    13M    5% /plex
root@n40l:~#

Je garde pour le moment le volume logique vg0-usr.
/root & /boot sont rentrés dans le rang !

J’ai gagné un peu de Free PE (<115,25 GiB) dans mon groupe vg0.

J’ai réussi à m’en sortir :slight_smile:

#13

Cette commande n’est pas utile. Le contenu de l’initramfs n’a rien à voir avec l’amorçage.

Il y a plus simple : update-grub qui fait la même chose.

J’aurais dû y penser : le fichier grub.cfg référence les noyaux et initramfs par leur position (partition, volume logique…). Il aurait donc fallu entrer dans l’éditeur d’entrée de menu (touche « e ») et modifier les chemins des commandes linux et initrd de la même façon que la variable $prefix (qui dit à GRUB où trouver ses fichiers, mais pas les noyaux).

Parce que le montage de /boot était encore défini dans /etc/fstab. Si c’est toujours le cas, ça va entraîner des erreurs au démarrage.

Pourquoi ?

#14

C’est toi qui m’en a parlé, il faut que je te relise et que je comprenne.

Je croyais devoir utiliser dpkg-reconfigure initramfs-tools après avoir reconfiguré mes volumes logiques (retrait des volumes vg0-root et surtout vg0-boot)

Je croyais que cette commande recréait l’image /boot/initrd.img-uname -r et que cette dernière est chargée à l’amorçage. Je dois confondre avec update-initramfs.

Je pensais qu’il fallait le faire systématiquement.
Je suis mal renseigné sur initramfs et initrd et sur la séquence d’amorçage en particulier.
C’est encore plutôt compliqué…

En rescue mode,
quand et comment doit-t’on recréer une nouvelle image /boot/initrd.img-uname -r ?

Dans quelle circonstance utilise-t’on dpkg-reconfigure initramfs-tools ?

C’est entendu pour l’équivalence d’update-grub
avec grub-mkconfig -o /boot/grub/grub.cfg

J’ai bien essayé mais j’ai vite vu que je ne maîtrisais pas du tout.

La ligne était et est encore commentée :

root@n40l:~# egrep \/boot /etc/fstab 
#/dev/mapper/vg0-boot /boot           ext3    defaults     0 2
root@n40l:~#

Je viens de réintégrer les volumes logiques vg0-usr, vg0-src et vg0-opt sous /usr, /usr/src et /opt du volume logique racine et le rescue mode m’a à nouveau posé la même question à laquelle j’ai encore répondu non.

J’ai l’habitude de planifier parfois une vérification du système de fichiers de cette manière.
Par exemple, après avoir transféré vg0-usr et vg0-src sous /usr et /usr/src du volume logique racine,
il me semble que c’est approprié.

#15

Cela avait seulement pour but de rendre l’initramfs plus compact afin de gagner de l’espace. Mais en fait c’était une mauvaise information : je pensais que cette option était gérée par dpkg-reconfigure, mais apparemment ce n’est pas le cas, la commande ne fait que reconstruire l’initramfs.

C’est bien ça, les deux commandes semblent faire plus ou moins la même chose. Mais l’initramfs n’a pas besoin d’accéder à /boot pour booter, il n’a pas besoin d’être reconstruit si /boot est déplacé d’un volume à un autre. Cela ne concerne que GRUB.

Le firmware de l’ordinateur charge GRUB.
GRUB va chercher ses fichiers (modules, menu) dans ce qui était monté en tant que /boot/grub au moment d’exécuter grub-install
Pour amorcer un noyau, GRUB va chercher les fichiers vmlinuz (noyau) et initrd (initramfs) dans ce qui était monté en tant que /boot au moment d’exécuter update-grub (ou grub-mkconfig).
Le noyau se lance, monte l’initramfs en mémoire et lui passe la main.
L’initramfs vérifie si le swap défini pour l’hibernation contient une image d’hibernation et la restaure, sinon il active et monte la racine et /usr si séparé et passe la main à l’init du système pour la suite.

Quand on veut changer le contenu de l’initramfs, par exemple : blacklister un module qui pose problème, changer le swap utilisé pour l’hibernation, basculer entre compact et complet…

fsck n’est utile qu’avant ou après une manipulation du système de fichiers (redimensionnement par exemple). Là, ce n’est que du transfert de fichiers, du fonctionnement normal. Pas besoin de fsck.

1 J'aime