pas assez de mémoire pour mise à jour du système

Domolibre · Le 17/09/2021, à 14:56

Bonjour,
je reprends mon ubuntu après une longue pause...
En voulant faire une mise à jour, le système me donne cette réponse :

"La mise à niveau nécessite un total de 134 M d'espace libre sur le disque « /boot ». Veuillez libérer au moins 53,9 M sur « /boot ». Vous pouvez supprimer les anciens noyaux en utilisant « sudo apt autoremove », et vous pouvez également définir COMPRESS=xz dans /etc/initramfs-tools/initramfs.conf pour réduire la taille de votre initramfs."

J'ai toujours eu ce genre de problème car pas suffisamment de place a été réservé sur la mémoire boot (enfin si ma mémoire est bonne car j'ai un peu oublié tout les termes exactes. pardonnez-moi.

D'habitude je m'en sort en faisant le " sudo apt autoremove" manuellement et régulièrement...

mais là ça semble plus compliqué pour moi, car j'obtiens cette réponse :

bernardin@bernardin-P7812:~$ sudo apt autoremove
[sudo] Mot de passe de bernardin : 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 282 non mis à jour.
bernardin@bernardin-P7812:~$

Quelqu'un peut-il m'aider svp ?

geole · Le 17/09/2021, à 15:07

Bonjour
Peux-tu donner le contenu du répertoire de boot

ls -lS /boot

Ainsi que les implantations des partitions afin de voir si on peut agrandir.
Il faut remplacer X par la bonne lettre. Certainement a

sudo parted /dev/sdX unit    MiB print free

question: As-tu un support d'installation. Si oui avec quelle version (16.04? 18.04? 20.04?)

Dernière modification par geole (Le 17/09/2021, à 15:11)

erresse · Le 17/09/2021, à 15:48

Bonjour,
De toute manière, la commande "sudo apt autoremove" n'a aucune chance de libérer de l'espace dans le répertoire "/boot", vu qu'elle agit sur les paquets de dépendances résiduels, donc plutôt dans "/usr"...
Par ailleurs, lorsque c'est une partition séparée, "/boot" est toujours taillé trop juste pour y mettre plus de 2 ou 3 noyaux, va savoir pourquoi alors qu'on dispose de dieu sait combien d'espace pour ne pas être gêné aux entournures !

xubu1957 · Le 17/09/2021, à 16:23

Bonjour,

Épisode précédent > Mise à jour depuis le passage à Linux 18 LTS [Résolu]

geole · Le 17/09/2021, à 16:54

Ma proposition serait de booter avec un support d'installation.
De réduire la partition LVM d'au moins 2 Go
Voici les commandes détaillées
1) Obtenir la taille minima que peut avoir actuellement le système de fichier

resize2fs -PM /dev/mapper/ubuntu--vg-root

2) Trouver la valeur en giga-octets avec cette formule
Taille en GO = nbre affiché * 4096 / 1024 /1024
Espérons que cette valeur va être inférieure à 675G. En théorie la partition fait 680G. Comme il est inutile de rétrécir au maxima, on fixera cette valeur car je ne sais pas de diminuer de 2 Go
3) Faisons le contrôle de la qualité de la partition

sudo e2fsck -f /dev/mapper/ubuntu--vg-root

4) Lançons le rétrécissement à la nouvelle taille

resize2fs  /dev/mapper/ubuntu--vg-root 675g

5) Rétrécissons le LVM

lvresize --resizefs --size -2G    /dev/mapper/ubuntu--vg-root

ou

lvresize --resizefs --size 678G    /dev/mapper/ubuntu--vg-root

6) Remettons le système de fichier à la taille du LVM

resize2fs /dev/mapper/ubuntu--vg-root

7) Recherchons l'emplacement du dernier extent utilisé

sudo pvs -v --segments /dev/sda2??

8) Eventuellement, retasser la partition. Attention, les valeurs sont à adapter

sudo pvmove --alloc anywhere /dev/sdda2???:40000-99999 /dev/sdda???:0-39999

9) Lancer gparted
Dire que la partition /dev/sda2??? fait maintenant 678G au lieu de 680G
(Normalement, gparted refuse de mettre trop petit)

Puis de booter pour vérifier que tout c'est bien passé.
Puis transférer la partition de boot dans cet espace récupéré avec gparted puis d'agrandir la partition de boot au maxima afin que le problème disparaisse
Puis lancer un boot-repair pour mettre à jour le MBR.

Ajout. Mais avant de commencer, donne ce retour afin de savoir ce qu'il y a exactement maintenant sur le disque.

sudo fdisk  -l /dev/sda

sudo parted /dev/sdX unit    MiB print free

NOTA. Il serait bon de fabriquer une clé USB bootable avec la version 20.04 au cas où la mise à niveau se passerait mal et de vérifier qu'elle boote bien avant de commencer la mise à niveau

Dernière modification par geole (Le 21/09/2021, à 13:41)

Domolibre · Le 04/10/2021, à 16:58

Bonjour, je vous prie de m'excuser cette longue absence , j'ai déménagé à Stockholm...

voici ce que ça donne :

bernardin@bernardin-P7812:~$ ls -lS /boot
total 141530
-rw-r--r-- 1 root root 55144314 mai   17 15:50 initrd.img-5.4.0-73-generic
-rw-r--r-- 1 root root 55136208 mai   14 21:48 initrd.img-5.4.0-72-generic
-rw------- 1 root root 11764480 avril 14 18:37 vmlinuz-5.4.0-73-generic
-rw------- 1 root root 11760384 avril 12 18:56 vmlinuz-5.4.0-72-generic
-rw------- 1 root root  4750832 avril 14 18:35 System.map-5.4.0-73-generic
-rw------- 1 root root  4750202 avril 12 17:12 System.map-5.4.0-72-generic
-rw-r--r-- 1 root root   237851 avril 12 17:12 config-5.4.0-72-generic
-rw-r--r-- 1 root root   237851 avril 14 18:35 config-5.4.0-73-generic
-rw-r--r-- 1 root root   184884 août  18  2020 memtest86+_multiboot.bin
-rw-r--r-- 1 root root   184380 août  18  2020 memtest86+.elf
-rw-r--r-- 1 root root   182704 août  18  2020 memtest86+.bin
drwx------ 2 root root    12288 févr. 16  2017 lost+found
drwxr-xr-x 5 root root     1024 mai   14 21:53 grub
lrwxrwxrwx 1 root root       27 mai   14 21:46 initrd.img -> initrd.img-5.4.0-72-generic
lrwxrwxrwx 1 root root       27 mai   13 22:41 initrd.img.old -> initrd.img-5.4.0-73-generic
lrwxrwxrwx 1 root root       24 mai   13 22:38 vmlinuz -> vmlinuz-5.4.0-72-generic
lrwxrwxrwx 1 root root       24 mai   13 22:38 vmlinuz.old -> vmlinuz-5.4.0-73-generic
bernardin@bernardin-P7812:~$

Domolibre · Le 04/10/2021, à 17:01

  bernardin@bernardin-P7812:~$ sudo parted /dev/sda unit    MiB print free
[sudo] Mot de passe de bernardin : 
Modèle : ATA WDC WD7500BPVX-0 (scsi)
Disque /dev/sda : 715405MiB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : msdos
Drapeaux de disque : 

Numéro  Début      Fin        Taille     Type      Système de fichiers  Drapeaux
        0,03MiB    1,00MiB    0,97MiB              Espace libre
 1      1,00MiB    244MiB     243MiB     primary   ext2                 démarrage
        244MiB     245MiB     1,00MiB              Espace libre
 2      245MiB     715404MiB  715159MiB  extended
 5      245MiB     715404MiB  715159MiB  logical                        lvm
        715404MiB  715405MiB  0,87MiB              Espace libre

bernardin@bernardin-P7812:~$

Domolibre · Le 04/10/2021, à 17:03

pour repondre à la question :

"question: As-tu un support d'installation. Si oui avec quelle version (16.04? 18.04? 20.04?)"

je ne sais plus ce que cela veut dire...

j'avais une clé rebootable mais je l'ai laissée en france. Et je suis maintenant à Stockholm

geole · Le 04/10/2021, à 18:06

Bonjour
D'abord bonne installation....

Pour reprendre le problème, le plus simple serait d'acheter une nouvelle clé USB, de télécharger la version 20.04 LTS ( https://www.ubuntu-fr.org/download/ )
De télécharger un logiciel de fabrication de clé de boot ( https://doc.ubuntu-fr.org/live_usb )
Je conseille ventoy ( https://doc.ubuntu-fr.org/ventoy )
afin de faire une clé BOOTABLE

Cela te permettra de rétrécir logiquement la partition LVM de 2 Go. Puis physiquement la partition SDA5
La documentation LVM a été mise à jour. ( https://doc.ubuntu-fr.org/lvm )Cela ne me semble pas insurmontable et ensuite la partition SDA2

Après tu aura le choix entre
a) Dupliquer la partition SDA1 dans l'espace libre en fin de disque et de l'agrandir de plusieurs Mo
Puis lancer une boot-repair. Cette solution perd la taille de la partition SDA1 actuelle (243MiB )
b) Déplacer vers la droite la partition SDA5 puis SDA2 et agrandir SDA1 de l'espace récupéré. Le déplacement vers la droite est une opération risquée qui exige que l'ordinateur ne soit pas arrêté de façon violente pendant l'opération (électricité...) je pense que déplacer 715159MiB va prendre entre 5 et 10 heures...
Tu as quand même intérêt à sauver tes données personnelles avant de commencer l'opération si tu n'y as pas encore pensé.

De façon alternative, tu pourrais bricoler en éliminant méchamment la version 5.4.0-72
( echo RAZ > /boot/initrd.img-5.4.0-72-generic
echo RAZ > /boot/System.map-5.4.0-72-generic
echo RAZ > /boot/config-5.4.0-72-generic)

Mais cela ne fera que reculer encore le problème qui surviendra à chaque changement de noyau.

Dernière modification par geole (Le 04/10/2021, à 18:14)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 17/09/2021, à 14:56

pas assez de mémoire pour mise à jour du système

#2 Le 17/09/2021, à 15:07

Re : pas assez de mémoire pour mise à jour du système

#3 Le 17/09/2021, à 15:48

Re : pas assez de mémoire pour mise à jour du système

#4 Le 17/09/2021, à 16:23

Re : pas assez de mémoire pour mise à jour du système

#5 Le 17/09/2021, à 16:54

Re : pas assez de mémoire pour mise à jour du système

#6 Le 04/10/2021, à 16:58

Re : pas assez de mémoire pour mise à jour du système

#7 Le 04/10/2021, à 17:01

Re : pas assez de mémoire pour mise à jour du système

#8 Le 04/10/2021, à 17:03

Re : pas assez de mémoire pour mise à jour du système

#9 Le 04/10/2021, à 18:06

Re : pas assez de mémoire pour mise à jour du système

Pied de page des forums