[Résolu] agrandissement partition /boot/ & déplacement partition lvm

David5647 · 27-09-2020 11:14:30

Salut!

Depuis quelques temps la taille de ma partition boot est insuffisante pour la mise à jour vers de nouveaux noyaux. (taille réglée par l'installateur)
Je suppose que la taille de ces derniers devient de plus en plus importante à chaque màj et que je devais déjà être ricrac en terme d'espace.
Lors d'une màj, il y a présence de 3 noyau simultanément (les 2 anciens + le nouveau) et ça bloque faute de place sur la partition.
Je suis alors obligé de supprimer le plus ancien noyau à la main.

Je souhaite agrandir ma partition boot, mais la présence d'une partition lvm (racine + home + swap) me pose problème. C'est pour cela que je vous sollicite.

Mise en évidence du problème:
=========================
Tentative de mise à jour:

sudo aptitude full-upgrade 

[sudo] Mot de passe de david : 

Les paquets partiellement installés suivants seront configurés : 

  initramfs-tools 

Aucun paquet ne va être installé, mis à jour ou enlevé.

0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 0 o seront utilisés.

Paramétrage de initramfs-tools (0.139) ...    

update-initramfs: deferring update (trigger activated)

Traitement des actions différées (« triggers ») pour initramfs-tools (0.139) ...

update-initramfs: Generating /boot/initrd.img-5.8.0-2-amd64

gzip: stdout: No space left on device

E: mkinitramfs failure cpio 141 gzip 1

update-initramfs: failed for /boot/initrd.img-5.8.0-2-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

needrestart is being skipped since dpkg has failed

E: Sub-process /usr/bin/dpkg returned an error code (1)

Paramétrage de initramfs-tools (0.139) ...

update-initramfs: deferring update (trigger activated)

Traitement des actions différées (« triggers ») pour initramfs-tools (0.139) ...

update-initramfs: Generating /boot/initrd.img-5.8.0-2-amd64

gzip: stdout: No space left on device

cpio: erreur d'écriture: Relais brisé (pipe)

sort: write failed: 'standard output': Broken pipe

sort: write error

E: mkinitramfs failure cpio 2 gzip 1

update-initramfs: failed for /boot/initrd.img-5.8.0-2-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

effectivement, la partition boot est pleine:

df -h

Sys. de fichiers                   Taille Utilisé Dispo Uti% Monté sur

udev                                 3,9G       0  3,9G   0% /dev

tmpfs                                789M    3,3M  786M   1% /run

/dev/mapper/david--aspire--vg-root    28G     17G  9,5G  64% /

tmpfs                                3,9G     47M  3,9G   2% /dev/shm

tmpfs                                5,0M       0  5,0M   0% /run/lock

tmpfs                                4,0M       0  4,0M   0% /sys/fs/cgroup

/dev/mapper/david--aspire--vg-home   422G    244G  157G  61% /home

/dev/sda2                            237M    221M  3,6M  99% /boot

/dev/sda1                            511M    5,3M  506M   2% /boot/efi

tmpfs                                789M     64K  789M   1% /run/user/1000

Rien d'anormal à priori, présence de 3 noyau comme attendu:

ls -alh /boot/

total 207M

drwxr-xr-x  5 root root 1,0K sept. 27 11:43 .

drwxr-xr-x 18 root root 4,0K sept. 26 10:24 ..

-rw-r--r--  1 root root 225K août  23 15:44 config-5.7.0-3-amd64

-rw-r--r--  1 root root 229K sept.  5 16:52 config-5.8.0-1-amd64

-rw-r--r--  1 root root 229K sept. 19 14:17 config-5.8.0-2-amd64

drwx------  3 root root 4,0K janv.  1  1970 efi

drwxr-xr-x  5 root root 1,0K sept. 27 11:39 grub

-rw-r--r--  1 root root  62M sept. 12 19:36 initrd.img-5.7.0-3-amd64

-rw-r--r--  1 root root  62M sept. 19 08:22 initrd.img-5.8.0-1-amd64

-rw-r--r--  1 root root  62M sept. 26 10:26 initrd.img-5.8.0-2-amd64

drwx------  2 root root  12K juin  25 16:20 lost+found

-rw-r--r--  1 root root 4,1M août  23 15:44 System.map-5.7.0-3-amd64

-rw-r--r--  1 root root   83 sept.  5 16:52 System.map-5.8.0-1-amd64

-rw-r--r--  1 root root   83 sept. 19 14:17 System.map-5.8.0-2-amd64

-rw-r--r--  1 root root 5,4M août  23 15:44 vmlinuz-5.7.0-3-amd64

-rw-r--r--  1 root root 5,5M sept.  5 16:52 vmlinuz-5.8.0-1-amd64

-rw-r--r--  1 root root 5,5M sept. 19 14:17 vmlinuz-5.8.0-2-amd64

Problématique
============

J'ai pu réduire ma partition sda3 en elle même et faire un peu de place en fin de disque :
(976773168-974663680*512)/10**6 = 286 Mo,
mais je ne sais pas comment créer/déplacer l'espace libre à la suite de sda2, faut-il déplacer tout le bloc lvm d'un coup?

fdisk -l

Disque /dev/sda : 465,76 GiB, 500107862016 octets, 976773168 secteurs

Modèle de disque : WDC  WDS500G2B0A

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Type d'étiquette de disque : gpt

Identifiant de disque : 254044D4-2547-475D-A4C1-694D36AE8486

Périphérique   Début       Fin  Secteurs Taille Type

/dev/sda1       2048   1050623   1048576   512M Système EFI

/dev/sda2    1050624   1550335    499712   244M Système de fichiers Linux

/dev/sda3    1550336 976214015 974663680 464,8G LVM Linux

Disque /dev/mapper/david--aspire--vg-root : 27,94 GiB, 29997662208 octets, 58589184 secteurs

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/mapper/david--aspire--vg-swap_1 : 7,92 GiB, 8506048512 octets, 16613376 secteurs

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/mapper/david--aspire--vg-home : 428,89 GiB, 460521996288 octets, 899457024 secteurs

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

bloc à supprimer si la commande n’affiche rien

Dernière modification par David5647 (27-09-2020 15:14:14)

Beta-Pictoris · 27-09-2020 11:33:01

Ce que tu pourrais faire:
Supprimer ta partition /boot.
Augmenter la taille de ta partition efi.
Changer son type pour un système de fichier linux.
La formater avec le bon UUID.
Et la monter en tant que /boot. Normalement, il n'y a rien à faire dans /etc/fstab si tu as utilisé le bon UUID.
Puis recréer une petite partition efi en fin de disque. Moins de 50Mo suffiront.

Personnellement, je ne crée plus de partition /boot depuis longtemps.

Dernière modification par Beta-Pictoris (27-09-2020 11:47:34)

raleur · 27-09-2020 11:54:33

Compliqué. Et il faudra réinstaller GRUB. Plus simple :
- réduire de moitié la partition EFI qui est presque vide
- agrandir la partition /boot par la gauche avec gparted

A moins que la partition LVM soit chiffrée, il n'est pas nécessaire d'avoir une partition /boot séparée. GRUB sait lire LVM.

David5647 a écrit :

Je suppose que la taille de ces derniers devient de plus en plus importante à chaque màj

Un peu. Mais c'est surtout la taille de l'initramfs qui enfle car on y met de plus en plus de choses. Voici deux possibilités pour la réduire :
- modifier /etc/initramfs-tools/initramfs.conf pour n'inclure que les modules (et leurs firmwares) nécessaires au matériel présent
- supprimer plymouth, ça évitera d'inclure les pilotes graphiques et leurs firmwares volumineux dans le cas de radeon/amdgpu

Dernière modification par raleur (27-09-2020 11:57:22)

Beta-Pictoris · 27-09-2020 12:04:41

J'utilise plutôt parted (ou fdisk, gdisk), mais jamais gparted.

Mais est-ce que gparted est capable de réduire et augmenter les partitions par la gauche ?

raleur · 27-09-2020 12:07:58

Oui, et c'est le seul outil capable de le faire que je connais. Ainsi que de déplacer une partition, ce qui revient au même.

David5647 · 27-09-2020 15:13:28

Ok, j'ai opté pour la solution la plus simple : réduire efi et agrandir boot (avec gparted)
l'upgrade a pu se faire, ça ne devrait plus poser de problème à l'avenir. Au pire, non, ma partition lvm n'est pas chiffrée, je pourrais toujours y placer /boot.

J'ai quand même tenté de paramétrer initramfs et ai parcouru brièvement la conf initramfs :

#

# MODULES: [ most | netboot | dep | list ]

#

# most - Add most filesystem and all harddrive drivers.

#

# dep - Try and guess which modules to load.

#

# netboot - Add the base modules, network modules, but skip block devices.

#

# list - Only include modules from the 'additional modules' list

#

MODULES=most

j'ai modifié la ligne en :

MODULES=dep

Après update d'initramfs, je suis passé de 150M à 107M utilisés sur /boot/, pas de problème au démarrage.
Je suppose que l'option list permettrait un paramétrage plus fin, à condition de connaître les modules à charger...

Merci à vous!

Dernière modification par David5647 (27-09-2020 15:13:45)

raleur · 27-09-2020 15:27:23

150 Mo ? df indiquait 221 Mio utilisés.

David5647 a écrit :

Je suppose que l'option list permettrait un paramétrage plus fin

Pas sûr qu'il y ait grand-chose à gagner de ce côté. Tu peux examiner le contenu d'un initramfs avec lsinitramfs.

David5647 · 27-09-2020 15:45:22

raleur a écrit :

150 Mo ? df indiquait 221 Mio utilisés.

J'ai pas lu grand chose la dessus, mais de ce que j'ai pu inférer, le système garde toujours deux noyaux et supprime les plus anciens.
Lors d'une mise à jour, pendant un bref instant, après la mise à jour et avant la suppression du noyau le plus ancien, on se retrouve avec 3 noyaux.
Je suppose que le système avait bien pu le télécharger mais qu'il ne pouvait le décompresser entièrement (de pas grand chose sûrement),
d'où les : "3 x (initrd + wmlinuz + bidulles) ~= 221M" avant, puis les "2 x (initrd + wmlinuz + bidulles) ~= 150M" après résolution. C'est seulement après que j'ai modifié la conf d'initramfs

ps:
avant (MODULES=most):

lsinitramfs /boot/initrd.img-5.8.0-1-amd64  | wc -l

2641

après (MODULES=dep):

lsinitramfs /boot/initrd.img-5.8.0-2-amd64  | wc -l

726

Dernière modification par David5647 (27-09-2020 15:52:45)

Debian-facile

#1 27-09-2020 11:14:30

[Résolu] agrandissement partition /boot/ & déplacement partition lvm

#2 27-09-2020 11:33:01

Re : [Résolu] agrandissement partition /boot/ & déplacement partition lvm

#3 27-09-2020 11:54:33

Re : [Résolu] agrandissement partition /boot/ & déplacement partition lvm

#4 27-09-2020 12:04:41

Re : [Résolu] agrandissement partition /boot/ & déplacement partition lvm

#5 27-09-2020 12:07:58

Re : [Résolu] agrandissement partition /boot/ & déplacement partition lvm

#6 27-09-2020 15:13:28

Re : [Résolu] agrandissement partition /boot/ & déplacement partition lvm

#7 27-09-2020 15:27:23

Re : [Résolu] agrandissement partition /boot/ & déplacement partition lvm

#8 27-09-2020 15:45:22

Re : [Résolu] agrandissement partition /boot/ & déplacement partition lvm

Pied de page des forums