[OracleLinux] Pas assez de place sur /boot pour la mise à jour

Bonjour,

Soit un serveur sous Oracle Linux partitionné ainsi :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur devtmpfs 3,9G 0 3,9G 0% /dev tmpfs 3,9G 32K 3,9G 1% /dev/shm tmpfs 3,9G 17M 3,9G 1% /run tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup /dev/mapper/ol-root 9,8G 2,8G 6,6G 30% / /dev/sda1 283M 205M 59M 78% /boot /dev/mapper/ol-tmp 976M 2,6M 907M 1% /tmp /dev/mapper/ol-produits 13G 8,4G 3,3G 72% /produits /dev/mapper/ol-home 976M 5,2M 904M 1% /home /dev/mapper/ol-data 79G 51G 24G 68% /data /dev/mapper/ol-backup 49G 24G 24G 50% /backup tmpfs 795M 0 795M 0% /run/user/1000
Tentative de mise à jour avec dnf update qui est allée jusqu'au bout mais qui a généré cette erreur :

Citation:

cp: error writing '/boot/initramfs-5.4.17-2136.310.7.1.el8uek.x86_64.img': No space left on device
dracut: dracut: creation of /boot/initramfs-5.4.17-2136.310.7.1.el8uek.x86_64.img failed
attention*: %posttrans(kernel-uek-5.4.17-2136.310.7.1.el8uek.x86_64) scriptlet échoué, état de sortie 1

Error in POSTTRANS scriptlet in rpm package kernel-uek

=> Pas assez d'espace disque sur /boot :calim2:

Heureusement que j'avais un snaspshot de la machine virtuelle car le reboot suite à la mise à jour plantait.

Le problème est que /boot ne fait pas partie du volume group. Voilà ce que donne fdisk -l :

Citation:

Disque /dev/sda*: 120 GiB, 128849018880*octets, 251658240*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
Type d'étiquette de disque*: dos
Identifiant de disque*: 0x48d6c7a1

Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2048 616447 614400 300M 83 Linux
/dev/sda2 616448 251658239 251041792 119,7G 8e LVM Linux

Disque /dev/sdb*: 50 GiB, 53687091200*octets, 104857600*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
Type d'étiquette de disque*: dos
Identifiant de disque*: 0xaf90f3f6

Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdb1 2048 104857599 104855552 50G 8e LVM Linux

Disque /dev/mapper/ol-root*: 10 GiB, 10737418240*octets, 20971520*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/ol-swap*: 8 GiB, 8589934592*octets, 16777216*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/ol-data*: 80 GiB, 85899345920*octets, 167772160*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/ol-tmp*: 1 GiB, 1073741824*octets, 2097152*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/ol-backup*: 49,7 GiB, 53368324096*octets, 104235008*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/ol-home*: 1 GiB, 1073741824*octets, 2097152*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/ol-produits*: 12,5 GiB, 13421772800*octets, 26214400*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

Un vgdisplay me montre qu'il reste 7,5 GiB non affectés sur la LVM :

Citation:

--- Volume group ---
VG Name ol
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 12
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 7
Open LV 7
Max PV 0
Cur PV 2
Act PV 2
VG Size <169,70 GiB
PE Size 4,00 MiB
Total PE 43443
Alloc PE / Size 41524 / 162,20 GiB
Free PE / Size 1919 / <7,50 GiB
VG UUID fooOCT-QQsj-wwAr-H4PC-bJvK-AvjD-PtttDW

J'aimerais augmenter la partition /boot à 500 M ou 1 G mais comment faire ?

Est-il possible de diminuer la LVM pour ensuite affecter cet espace disque inutilisé à la parttion /boot, donc à /dev/sda1 ?

Bonjour :coucou:

Pour stocker toujours plus de noyaux que tu n'utiliseras jamais ?

Code:

/dev/sda2 174M 110M 52M 69% /boot

Merci pour la réponse.

Citation:

Envoyé par Flodelarab

Pour stocker toujours plus de noyaux que tu n'utiliseras jamais ?

Non, bien sûr !

Citation:

Code:

/dev/sda1 174M 110M 52M 69% /boot

Ça c'est l'occupation avant mise à jour.

Après la mise à jour plantée, c'était ça :

Citation:

/dev/sda1 283M 260M 3,9M 99% /boot

Mais c'est vrai que dans /boot, j'ai ça :

Citation:

-rwxr-xr-x. 1 root root 10376768 8 avril 10:23 vmlinuz-0-rescue-13f3cf3861ab49d5b43567ae7afb7c5e
-rwxr-xr-x. 1 root root 10225200 10 mars 22:50 vmlinuz-4.18.0-348.20.1.el8_5.x86_64
-rwxr-xr-x. 1 root root 10376768 29 mars 04:11 vmlinuz-5.4.17-2136.305.5.4.el8uek.x86_64

Et uname -a donne ça :

Citation:

Linux oracle19test.ensfea.fr 5.4.17-2136.305.5.4.el8uek.x86_64 #2 SMP Mon Mar 28 19:05:22 PDT 2022 x86_64 x86_64 x86_64 GNU/Linux

Je peux donc supprimer simplement vmlinuz-4.18.0-348.20.1.el8_5.x86_64 et vmlinuz-0-rescue-13f3cf3861ab49d5b43567ae7afb7c5e ou bien y a til une commande pour supprimer en même temps d'éventuelles dépendances ?

Et c'est quoi ce vmlinuz-0-rescue-13f3cf3861ab49d5b43567ae7afb7c5e ?

Du coup j'ai aussi ça dans / boot :

Citation:

-rw-------. 1 root root 100450286 8 avril 10:25 initramfs-0-rescue-13f3cf3861ab49d5b43567ae7afb7c5e.img
-rw-------. 1 root root 32186126 8 avril 10:22 initramfs-4.18.0-348.20.1.el8_5.x86_64.img
-rw-------. 1 root root 34237303 8 avril 10:23 initramfs-5.4.17-2136.305.5.4.el8uek.x86_64.img

=> Encore un "rescue"

Et ça :

Citation:

-rw-r--r--. 1 root root 193938 10 mars 22:49 config-4.18.0-348.20.1.el8_5.x86_64
-rw-r--r--. 1 root root 218115 29 mars 04:11 config-5.4.17-2136.305.5.4.el8uek.x86_64

Par contre...
Code:

1 2 3 4 5 6 7 8 9 10 rpm -q kernel kernel-4.18.0-348.20.1.el8_5.x86_64 dnf list kernel Dernière vérification de l’expiration des métadonnées effectuée il y a 1:17:50 le lun. 05 sept. 2022 11:45:32 CEST. Paquets installés kernel.x86_64 4.18.0-348.20.1.el8_5 @anaconda Paquets disponibles kernel.src 4.18.0-372.19.1.0.1.el8_6 ol8_baseos_latest kernel.x86_64 4.18.0-372.19.1.0.1.el8_6 ol8_baseos_latest
Pas de version 5.4.17 ! 8O

Vu que c'est une VM, je créerais un nouveau disque virtuel sur lequel je booterais et qui monterais le / depuis le disque d'origine.

Si tu veux n'avoir qu'un disque, tu déplaces ensuite tes volumes logiques LVM sur le nouveau disque.

Mais il te faut de la place sur ton datastore.

Bon j'ai réussi à faire un

Code:

dnf update

en supprimant à la main ce qui se rapportait au noyau de base 4.18... mais il me l'a réinstallé. J'ai quand même pu rebooter et j'ai maintenant ceci dans /boot :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
ll /boot
total 243411
-rw-r--r--  1 root root    195995  5 août  23:04 config-4.18.0-372.19.1.0.1.el8_6.x86_64
-rw-r--r--. 1 root root    218115 29 mars  04:11 config-5.4.17-2136.305.5.4.el8uek.x86_64
-rw-r--r--  1 root root    218631 18 août  00:20 config-5.4.17-2136.310.7.1.el8uek.x86_64
drwxr-xr-x. 3 root root      1024  8 avril 10:10 efi
drwx------. 4 root root      1024  6 août  01:03 grub2
-rw-------. 1 root root 100450286  8 avril 10:25 initramfs-0-rescue-13f3cf3861ab49d5b43567ae7afb7c5e.img
-rw-------  1 root root  29879811 14 sept. 11:40 initramfs-4.18.0-372.19.1.0.1.el8_6.x86_64.img
-rw-------. 1 root root  31409663 14 sept. 11:40 initramfs-5.4.17-2136.305.5.4.el8uek.x86_64.img
-rw-------  1 root root  31490986 14 sept. 11:39 initramfs-5.4.17-2136.310.7.1.el8uek.x86_64.img
drwxr-xr-x. 3 root root      1024  8 avril 10:13 loader
drwx------. 2 root root     12288  8 avril 10:09 lost+found
lrwxrwxrwx  1 root root        56 14 sept. 11:36 symvers-4.18.0-372.19.1.0.1.el8_6.x86_64.gz -> /lib/modules/4.18.0-372.19.1.0.1.el8_6.x86_64/symvers.gz
lrwxrwxrwx. 1 root root        57  8 avril 10:19 symvers-5.4.17-2136.305.5.4.el8uek.x86_64.gz -> /lib/modules/5.4.17-2136.305.5.4.el8uek.x86_64/symvers.gz
lrwxrwxrwx  1 root root        57 14 sept. 11:38 symvers-5.4.17-2136.310.7.1.el8uek.x86_64.gz -> /lib/modules/5.4.17-2136.310.7.1.el8uek.x86_64/symvers.gz
-rw-------  1 root root   4360507  5 août  23:03 System.map-4.18.0-372.19.1.0.1.el8_6.x86_64
-rw-------. 1 root root   4449399 29 mars  04:11 System.map-5.4.17-2136.305.5.4.el8uek.x86_64
-rw-------  1 root root   4458981 18 août  00:20 System.map-5.4.17-2136.310.7.1.el8uek.x86_64
-rwxr-xr-x. 1 root root  10376768  8 avril 10:23 vmlinuz-0-rescue-13f3cf3861ab49d5b43567ae7afb7c5e
-rwxr-xr-x  1 root root  10469928  5 août  23:04 vmlinuz-4.18.0-372.19.1.0.1.el8_6.x86_64
-rwxr-xr-x. 1 root root  10376768 29 mars  04:11 vmlinuz-5.4.17-2136.305.5.4.el8uek.x86_64
-rwxr-xr-x  1 root root  10859064 18 août  00:20 vmlinuz-5.4.17-2136.310.7.1.el8uek.x86_64

Et du coup je n'ai presque plus de place sur la partition /boot :

Code:

1
2
3
df -h /boot
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1          281M    243M   19M  93% /boot

Il faut maintenant désinstaller les vieux noyaux inutiles.

un :

dnf remove <nom du noyau> devrait fonctionner.

Citation:

Envoyé par chrtophe

Il faut maintenant désinstaller les vieux noyaux inutiles.

Sincérement, ils se téléchargent et s'effacent tous seuls. CinéPhil cherche à contrôler un truc qui se débrouille. C'est automatique. Évidemment l'avertissement est encombrant, mais on peut l'ignorer.

Citation:

ils se téléchargent et s'effacent tous seuls

Si il a effacé les fichiers à la main, et qu'ils se sont "téléchargés" tout seul (enfin retéléchargés), c’est qu'ils font partie de la base des paquets installés. Si il désinstalle les paquets concernés via dnf ça devrait rentrer dans l'ordre.