Partition de boot pleine
Résolu/Fermé
SylverWolf
Messages postés
13
Date d'inscription
samedi 24 août 2019
Statut
Membre
Dernière intervention
13 juin 2022
-
29 mars 2022 à 17:01
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 - 6 mai 2022 à 13:16
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 - 6 mai 2022 à 13:16
A voir également:
- Partition de boot pleine
- Dual boot - Guide
- Easeus partition master - Télécharger - Stockage
- Boot camp - Télécharger - Systèmes d'exploitation
- Hiren boot cd - Télécharger - Divers Utilitaires
- Boite mail pleine - Guide
3 réponses
mamiemando
Messages postés
33077
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 avril 2024
7 748
Modifié le 4 avril 2022 à 15:21
Modifié le 4 avril 2022 à 15:21
Bonjour
En réponse au message #2 :
Non, je ne pense pas avoir besoin des 4 noyaux présents sur mon système, et pour le moment, je n'ai pas prévu de la redimensionner (je préfère savoir si tout ce qui est dedans est bien nécessaire pour moi avant de juste "perdre" plus de place alors qu'un simple coup de nettoyage aurais fait l'affaire ^^).
Dans l'absolu seul un noyau est nécessaire (celui sur lequel tu démarres, en supposant qu'il soit fonctionnel). En cas de mise à jour, on en a éventuellement deux (l'ancien et le nouveau) et on supprime l'ancien une fois qu'on pense que le nouveau fait l'affaire. Cela permet de s'éviter de se retrouver sans noyau.
Je pense qu'ils sont la raison pour laquelle la partition est pleine. Il est possible qu'ils datent du moment où j'essayais d'utiliser Garuda linux, et je ne les ai pas supprimé lorsque j'ai décidé de ne plus utiliser cette distribution. Si c'est bien le cas, (c'est le plus probable a mon avis), comment est-ce que je pourrais faire pour savoir quels sont les noms des paquets que je dois supprimer, sans non plus me retrouver sans noyau ?
Oui, un noyau peut-être gros, mais d'après les commandes que tu m'as retournées, en fait ils sont plutôt petits (par exemple sous Debian, les noyaux font plutôt ~65Mo de nos jours. C'est la partition
Concernant les paquets : le gestionnaire de paquets de ta distribution ne connaît que les paquets qui le concerne. Cela signifie que ton gestionnaire de paquets Arch Linux n'a pas l'information de ce que ton gestionnaires de paquets Garruda a pu installer. Du coup la seule manière de nettoyer
D'après cette page, le gestionnaire de paquets utilisé sous Arch Linux est
Que donne :
Je ne pense pas avoir besoin d'une partition /boot dédiée, mais étant donné que j'ai un dual boot Linux et Windows 10, j'ai suivi les conseils que j'ai trouvé en ligne, et simplement utilisé la partition /boot existante.
Retour à ton problème
Je vois 4 approches possibles. Avant de se lancer (surtout pour la 3e et la 4e) il serait bon que tu me reportes les résultats de :
... et en root, au choix, le résultat de l'un de ces deux commandes :
Je te laisse lire tranquillement ce qui suit pour avoir un aperçu et en fonction des résultats de ces commandes et de tes préférences, on avisera.
Approche 1 : supprimer les noyaux inutiles
Avec cette approche, on reste avec la partition actuelle.
On commence par identifier le noyau sur lequel tu démarres et contrôle par rapport aux résultats de pacman le ou les noyau correspondant à ton Archi Linux (les autres peuvent être supprimés). Un autre indice est regarder le numéro de version du noyau sur lequel tu as démarré avec
Dans les faits, le chemin exact du noyau sur lequel tu as choisi de démarrer via GRUB est indiqué dans
Exemple : chaque entrée du menu GRUB est déclarée dans un bloc
Dans mon exemple, les fichiers
En utilisant cette méthodologie tu devrais être en mesure d'identifier les fichiers devenus inutiles. S'ils ont été installés via
Si tu supprimes des noyaux, veille à régénérer GRUB en lançant en root :
Approche 2 : redimensionner
Tu peux utiliser depuis un Live USB ou un Live CD
Approche 3 : déplacer
Au préalable il faut comprendre que normalement
Attention : Ce qui suit ne doit être envisagé que si
En root :
... puis on supprime de
Approche 4 : réinstaller :-)
Lors de la réinstallation, on veille cette fois à mettre
Bonne chance
En réponse au message #2 :
Non, je ne pense pas avoir besoin des 4 noyaux présents sur mon système, et pour le moment, je n'ai pas prévu de la redimensionner (je préfère savoir si tout ce qui est dedans est bien nécessaire pour moi avant de juste "perdre" plus de place alors qu'un simple coup de nettoyage aurais fait l'affaire ^^).
Dans l'absolu seul un noyau est nécessaire (celui sur lequel tu démarres, en supposant qu'il soit fonctionnel). En cas de mise à jour, on en a éventuellement deux (l'ancien et le nouveau) et on supprime l'ancien une fois qu'on pense que le nouveau fait l'affaire. Cela permet de s'éviter de se retrouver sans noyau.
Je pense qu'ils sont la raison pour laquelle la partition est pleine. Il est possible qu'ils datent du moment où j'essayais d'utiliser Garuda linux, et je ne les ai pas supprimé lorsque j'ai décidé de ne plus utiliser cette distribution. Si c'est bien le cas, (c'est le plus probable a mon avis), comment est-ce que je pourrais faire pour savoir quels sont les noms des paquets que je dois supprimer, sans non plus me retrouver sans noyau ?
Oui, un noyau peut-être gros, mais d'après les commandes que tu m'as retournées, en fait ils sont plutôt petits (par exemple sous Debian, les noyaux font plutôt ~65Mo de nos jours. C'est la partition
/bootqui est beaucoup trop petite.
Concernant les paquets : le gestionnaire de paquets de ta distribution ne connaît que les paquets qui le concerne. Cela signifie que ton gestionnaire de paquets Arch Linux n'a pas l'information de ce que ton gestionnaires de paquets Garruda a pu installer. Du coup la seule manière de nettoyer
/boot, c'est à la main en supprimant avec
rmles noyaux qui ne sont plus utilisés. Note qu'il y a dissociation entre les noyaux et le système d'exploitation. Dans l'absolu, tu pourrais lancer Arch Linux avec un noyau Garuda par exemple.
D'après cette page, le gestionnaire de paquets utilisé sous Arch Linux est
pacman, c'est donc lui qui te permettra de voir les éventuels paquets liés aux noyaux actuellement installés. D'après cette page, ça pourrait être les paquets dont le nom commence par
linux.
Que donne :
pacman -Qqe | grep linux
Je ne pense pas avoir besoin d'une partition /boot dédiée, mais étant donné que j'ai un dual boot Linux et Windows 10, j'ai suivi les conseils que j'ai trouvé en ligne, et simplement utilisé la partition /boot existante.
/bootn'a pas besoin d'être sur une partition dédiée. Cela se fait sur certains serveur mais selon moi, l'intérêt pratique reste limité. D'ailleurs dans l'absolu, on pourrait installer Linux sur une seule séparation (donc par exemple réunir
/et
/homesur la même partition) mais pour le coup je ne le recommande pas à moins d'avoir un disque dur minuscule, car avoir une partition
/homedédiée permet de réinstaller Linux sans perdre ses documents et profils utilisateurs.
Retour à ton problème
Je vois 4 approches possibles. Avant de se lancer (surtout pour la 3e et la 4e) il serait bon que tu me reportes les résultats de :
mount
cat /etc/fstab
... et en root, au choix, le résultat de l'un de ces deux commandes :
parted -l
fdisk -l
Je te laisse lire tranquillement ce qui suit pour avoir un aperçu et en fonction des résultats de ces commandes et de tes préférences, on avisera.
Approche 1 : supprimer les noyaux inutiles
Avec cette approche, on reste avec la partition actuelle.
- Avantage : on ne prend pas de risque en se "ratant" au moment de repartitionner.
- Inconvénient : ta partition
/boot
est minuscule donc tu seras régulièrement confronté au problème auquel tu fais face.
On commence par identifier le noyau sur lequel tu démarres et contrôle par rapport aux résultats de pacman le ou les noyau correspondant à ton Archi Linux (les autres peuvent être supprimés). Un autre indice est regarder le numéro de version du noyau sur lequel tu as démarré avec
uname -a.
Dans les faits, le chemin exact du noyau sur lequel tu as choisi de démarrer via GRUB est indiqué dans
/boot/grub/grub.cfg.
Exemple : chaque entrée du menu GRUB est déclarée dans un bloc
menuentry. Moi par exemple, j'ai démarré en choisissant
'Debian GNU/Linux'.
...
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-3381e88b-8cf2-4bde-9fc6-382ff5855b62' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt6'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt6 --hint-efi=hd0,gpt6 --hint-baremetal=ahci0,gpt6 3381e88b-8cf2-4bde-9fc6-382ff5855b62
else
search --no-floppy --fs-uuid --set=root 3381e88b-8cf2-4bde-9fc6-382ff5855b62
fi
echo 'Loading Linux 5.16.0-5-amd64 ...'
linux /boot/vmlinuz-5.16.0-5-amd64 root=UUID=3381e88b-8cf2-4bde-9fc6-382ff5855b62 ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-5.16.0-5-amd64
}
...
Dans mon exemple, les fichiers
/boot/vmlinuz-5.16.0-5-amd64et
/boot/initrd.img-5.16.0-5-amd64correspondent au noyau sur lequel j'ai démarré. Les éventuels autres fichiers
/boot/vmlinux*et
/boot/initrd*correspondent à d'autres noyaux, qui n'ont pas été utilisé pour ce démarrage.
En utilisant cette méthodologie tu devrais être en mesure d'identifier les fichiers devenus inutiles. S'ils ont été installés via
pacman, désinstalle le paquet correspondant avec
pacman. Sinon, il s'agit probablement de reliquats de Garuda et tu peux les supprimer avec la commande
rm(en root).
Si tu supprimes des noyaux, veille à régénérer GRUB en lançant en root :
update-grub
Approche 2 : redimensionner
/boot
- Avantage : on aura enfin de la place sur
/boot
. - Inconvénient : il ne faut pas se rater au moment de repartitionner. Je recommande de sauver au préalable sur une clé USB les documents auxquels on tient au cas où.
Tu peux utiliser depuis un Live USB ou un Live CD
gparted(peu importe la distribution live, tu peux prendre une Ubuntu par exemple). Il faudra sans doute réduire une partition (e.g.
/donc
/dev/sda6dans ton cas).
Approche 3 : déplacer
/bootsur
/.
- Avantage : on aura enfin de la place sur
/boot
. A priori pas besoin de distribution Live pour "réparer". - Inconvénient :
- Il ne faut pas se rater car sinon on risque de casser GRUB (c'est réparable avec
boot-repair
). -
/boot
et/boot/EFI
doivent être sur des partitions différentes (j'ai l'impression que ça n'est pas ton cas)
- Il ne faut pas se rater car sinon on risque de casser GRUB (c'est réparable avec
Au préalable il faut comprendre que normalement
/boot/EFIn'est pas stocké physiquement sur la même partition que
/boot(il faut vérifier avec
mountet
sudo parted -l). Si c'est bien le cas il sera donc inutile de recopier le contenu de ce dossier. En outre, j'aimerais voir le système de fichiers utilisé pour
/dev/sda1. Je suspecte très fortement que c'est de la FAT32 (vfat) et que tu as installé par erreur
/bootdans la partition EFI, chose qu'il ne faut pas faire !
Attention : Ce qui suit ne doit être envisagé que si
/bootet
/boot/EFIne sont pas sur la même partition physique.
En root :
umount /boot/EFI
cp -r /boot /boot.bak
umount /boot
cp /boot.bak/* /boot
mkdir /boot/EFI
mount /boot/EFI
update-grub
... puis on supprime de
/etc/fstabla ligne qui concerne
/boot(ou on met un # en début de ligne). On redémarre, on teste, et si tout va bien. A priori on peut se débarrasser de l'ex-partition
/boot(
/dev/sda1dans ton cas), windows s'en fiche car il n'utilise que ses propres partitions et la partition EFI.
Approche 4 : réinstaller :-)
- Avantage : on aura enfin de la place sur
/boot
. - Inconvénient : vu que malheureusement dans ton cas,
/
et/home
semblent sur la même partitions, il faut récupérer ses documents dans/home
avant de réinstaller.
Lors de la réinstallation, on veille cette fois à mettre
/bootet
/sur la même partition. Par contre on mettra / et /home sur des partitions dédiées (compter ~25Go pour
/et autant que tu veux pour
/home, les deux formatées en ext4). Cela permettra en cas de réinstallation future de n'écraser que la partition
/et de conservant la partition
/homeexistante (en veillant bien à ne PAS la formater).
Bonne chance
mamiemando
Messages postés
33077
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 avril 2024
7 748
Modifié le 4 avril 2022 à 15:57
Modifié le 4 avril 2022 à 15:57
Bonjour,
Par rapport au résultat de
Visiblement :
... semble avoir été installés via
Pour :
... c'est moins clair. Il faudrait regarder si ça provient du même paquet.
Mais quoi qu'il en soit, nous allons voir que ça n'a pas vraiment d'importance car tu vas appliquer la méthode 3 ou 4 qui permettra de tout faire rentrer dans l'ordre.
Par rapport à la commande
On voit la ligne :
Cette information est confirmée par les résultats de
Dit autrement, au moment d'installer Arch Linux, il aurait fallu mettre
Par rapport à la commande
Cette commande montre que tu as probablement démarré sur
<gras>Par rapport à la résolution de ton problème (approche 4)
Pour moi, je pense que dans tout les cas, la réinstallation est le meilleur choix, entre autre pour me permettre une certaine flexibilité dans le futur.
Comme tu veux, c'est plus simple. Sache toutefois que maintenant que j'ai compris ce qui s'est passé, ça se répare sans réinstaller, en adaptant l'approche 3 (voir section suivante).
Si tu pars sur l'approche 4 :
Par rapport à la résolution de ton problème (approche 3)
Voici comment adapter ce que j'ai expliqué avant.
1) Passe en root :
2) Copie les
Vérifie qu'ils ont bien été copiés dans
3) Démonte la partition
4) Corrige
Corrige la ligne :
... en :
Sauve et quitte (ctrl x, o, entrée).
5) Vérifie que
Vérifie qu'ils apparaissent bien dans
5) Crée le dossier
6) Monte
7) Supprime les anciennes copie noyaux de /boot/efi qui n'ont plus lieu d'être :
8) Régénère GRUB, puis redémarre :
Bonne chance
Par rapport au résultat de
pacman -Qqe | grep linux:
Visiblement :
├── initramfs-linux-lts-fallback.img
├── initramfs-linux-lts.img
... semble avoir été installés via
pacman(à l'installation d'Arch Linux ou par tes soins) via le paquet
linux-lts.
Pour :
├── initramfs-linux-fallback.img
├── initramfs-linux.img
... c'est moins clair. Il faudrait regarder si ça provient du même paquet.
pacman -Ql linux-lts | grep img
Mais quoi qu'il en soit, nous allons voir que ça n'a pas vraiment d'importance car tu vas appliquer la méthode 3 ou 4 qui permettra de tout faire rentrer dans l'ordre.
Par rapport à la commande
mount
On voit la ligne :
/dev/sda1 on /boot type vfat. Le fait que ce soit de la vfat (= FAT32) confirme ce que je pensais, c'est une partition EFI, normalement utilisé pour mettre en place un secure boot. Cette partition est sensé accueillir des signatures (pour les différents noyaux et modules installé sur ton ordinateurs), et pas des noyaux. Cela explique pourquoi elle est sous dimensionnée pour accueillir
/boot.
Cette information est confirmée par les résultats de
fdisk -let
parted -l(qui permettent de voir la table des partitions de ton disque dur).
Dit autrement, au moment d'installer Arch Linux, il aurait fallu mettre
/bootsur une autre partition (ou mieux, la laisser avec
/).
Par rapport à la commande
uname -a:< /gras>
Cette commande montre que tu as probablement démarré sur
initramfs-linux-lts.img(peut-être sur
initramfs-linux-lts-fallback.img) mais en tout cas pas sur l'un des deux autres noyaux. Pour être certain, il faudrait nous dire ce que tu as choisi dans GRUB et nous reporter les
menuentryde
/boot/grub/grub.cfg.
<gras>Par rapport à la résolution de ton problème (approche 4)
Pour moi, je pense que dans tout les cas, la réinstallation est le meilleur choix, entre autre pour me permettre une certaine flexibilité dans le futur.
Comme tu veux, c'est plus simple. Sache toutefois que maintenant que j'ai compris ce qui s'est passé, ça se répare sans réinstaller, en adaptant l'approche 3 (voir section suivante).
Si tu pars sur l'approche 4 :
- Commence par sauver les documents auxquels tu tiens sur clé USB. Ils a priori tous dans
/home
. - Réinstalle en veillant à ce que
/dev/sda1
soit monté dans dans/boot/efi
et non/boot
. - Une fois la réinstallation terminée, pense également une fois ta réinstallation faite à virer les fichiers
img
actuels, qui seront restés dans/boot/efi
(la réinstallation aura mis des.img
à leur place, à la racine de/boot
).
Par rapport à la résolution de ton problème (approche 3)
Voici comment adapter ce que j'ai expliqué avant.
1) Passe en root :
su -
2) Copie les
imgailleurs, mettons dans
/root:
cp /boot/*img /root
Vérifie qu'ils ont bien été copiés dans
/rootavant de continuer :
ls /root
3) Démonte la partition
/dev/sda1(actuel
/boot, futur
/boot/efi)
umount /dev/sda1
4) Corrige
/etc/fstabpour monter
/dev/sda1dans
/boot/efiet non
/bootavec l'éditeur de ton choix, e.g.
nano:
nano /etc/fstab
Corrige la ligne :
UUID=EE52-20FC /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
... en :
UUID=EE52-20FC /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
Sauve et quitte (ctrl x, o, entrée).
5) Vérifie que
/bootest désormais vide et transvase les
.imgdedans :
mv /root/*img /boot
Vérifie qu'ils apparaissent bien dans
/boot:
ls /boot
5) Crée le dossier
/boot/efi:
mkdir -p /boot/efi
6) Monte
/boot/efiet vérifie que dedans apparaît bien le dossier
EFI(donc
/boot/efi/EFI) :
mount /boot/efi ls /boot/efi
7) Supprime les anciennes copie noyaux de /boot/efi qui n'ont plus lieu d'être :
rm /boot/efi/*img
8) Régénère GRUB, puis redémarre :
update-grub reboot
Bonne chance
SylverWolf
Messages postés
13
Date d'inscription
samedi 24 août 2019
Statut
Membre
Dernière intervention
13 juin 2022
2 mai 2022 à 18:17
2 mai 2022 à 18:17
Bonsoir !
Cela à fonctionné !
Merci beaucoup du temps pris pour m'expliquer en détail !
Sans vous je ne sais pas comment j'aurais fait (d'autant plus que le fichier de boot de Windows a décidé à ce moment de se supprimer lui même après une mise à jour annulée par Windows...ce problème a été vite réglé après avoir fait la modification que vous m'avez recommandé (-_^) ) !
Bonne continuation !
Sylver
Cela à fonctionné !
Merci beaucoup du temps pris pour m'expliquer en détail !
Sans vous je ne sais pas comment j'aurais fait (d'autant plus que le fichier de boot de Windows a décidé à ce moment de se supprimer lui même après une mise à jour annulée par Windows...ce problème a été vite réglé après avoir fait la modification que vous m'avez recommandé (-_^) ) !
Bonne continuation !
Sylver
mamiemando
Messages postés
33077
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 avril 2024
7 748
>
SylverWolf
Messages postés
13
Date d'inscription
samedi 24 août 2019
Statut
Membre
Dernière intervention
13 juin 2022
6 mai 2022 à 13:16
6 mai 2022 à 13:16
Toutes mes félicitations et bonne continuation :-)
mamiemando
Messages postés
33077
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 avril 2024
7 748
Modifié le 30 mars 2022 à 12:54
Modifié le 30 mars 2022 à 12:54
Bonjour,
Bonne chance
- Quelle est la taille de
/boot
? (df -h
) ? As-tu envisagé de la redimensionner ? - Quelle est celle de tes noyaux (
ls -sh /boot
) ? - As-tu besoin de tous (actuellement tu en as 4) ?
- Est-ce que le noyau que tu utilises a été compilé par tes soins ? Si oui, as-tu essayé d'enlever des fonctionnalités dont tu n'as pas besoin ? Sinon j'imagine que tu les as installé via ton gestionnaire de paquets et peut être que tu devrais supprimer ceux que tu n'utilisent pas ?
- As-tu une utilité à avoir une partition
/boot
dédiée ?
Bonne chance
SylverWolf
Messages postés
13
Date d'inscription
samedi 24 août 2019
Statut
Membre
Dernière intervention
13 juin 2022
Modifié le 31 mars 2022 à 16:31
Modifié le 31 mars 2022 à 16:31
Bonjour,
Merci de cette réponse !
Non, je ne pense pas avoir besoin des 4 noyaux présents sur mon système, et pour le moment, je n'ai pas prévu de la redimensionner (je préfère savoir si tout ce qui est dedans est bien nécessaire pour moi avant de juste "perdre" plus de place alors qu'un simple coup de nettoyage aurais fait l'affaire ^^).
Je pense qu'ils sont la raison pour laquelle la partition est pleine. Il est possible qu'ils datent du moment où j'essayais d'utiliser Garuda linux, et je ne les ai pas supprimé lorsque j'ai décidé de ne plus utiliser cette distribution. Si c'est bien le cas, (c'est le plus probable a mon avis), comment est-ce que je pourrais faire pour savoir quels sont les noms des paquets que je dois supprimer, sans non plus me retrouver sans noyau ?
Je ne pense pas avoir besoin d'une partition
Je n'ai pas compilé le noyau que j'utilise actuellement (linux-lts il me semble), est-ce que je devrais ?
Taille de la partition
Taille des noyaux (via la commande
Merci de cette réponse !
Non, je ne pense pas avoir besoin des 4 noyaux présents sur mon système, et pour le moment, je n'ai pas prévu de la redimensionner (je préfère savoir si tout ce qui est dedans est bien nécessaire pour moi avant de juste "perdre" plus de place alors qu'un simple coup de nettoyage aurais fait l'affaire ^^).
Je pense qu'ils sont la raison pour laquelle la partition est pleine. Il est possible qu'ils datent du moment où j'essayais d'utiliser Garuda linux, et je ne les ai pas supprimé lorsque j'ai décidé de ne plus utiliser cette distribution. Si c'est bien le cas, (c'est le plus probable a mon avis), comment est-ce que je pourrais faire pour savoir quels sont les noms des paquets que je dois supprimer, sans non plus me retrouver sans noyau ?
Je ne pense pas avoir besoin d'une partition
/bootdédiée, mais étant donné que j'ai un dual boot Linux et Windows 10, j'ai suivi les conseils que j'ai trouvé en ligne, et simplement utilisé la partition
/bootexistante.
Je n'ai pas compilé le noyau que j'utilise actuellement (linux-lts il me semble), est-ce que je devrais ?
Taille de la partition
/ boot(via la commande
df -h) :
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
dev 5,8G 0 5,8G 0% /dev
run 5,8G 1,8M 5,8G 1% /run
/dev/sda6 141G 26G 114G 19% /
tmpfs 5,8G 0 5,8G 0% /dev/shm
tmpfs 5,8G 7,5M 5,8G 1% /tmp
/dev/sda1 96M 96M 0 100% /boot
tmpfs 1,2G 104K 1,2G 1% /run/user/1000
Taille des noyaux (via la commande
ls -sh /boot) :
total 61M
1,0K EFI 8,5M initramfs-linux-lts.img
1,0K 'System Volume Information' 1,5M initramfs-linux.img
1,0K grub 10M vmlinuz-linux
0 initramfs-linux-fallback.img 9,8M vmlinuz-linux-lts
31M initramfs-linux-lts-fallback.img
Modifié le 4 avril 2022 à 15:56
Tout d'abord, merci beaucoup pour cette réponse !
Désolé des temps de réponse, je suis très occupé en ce moment.
L'avantage est que j'ai décidé de régler les problèmes potentiels liés mon installation de linux des le début, donc si besoin, je peux tout réinstaller sans rien perdre.
Voici les différents résultats de commandes :
__________
Après avoir regardé le fichier , j'ai non seulement comme prévu trouvé la partie du code initialisant le noyau linux que je semble utiliser, mais également que le code du "dossier" dans la configuration de mon GRUB actuel sont des liens d'exécutions identiques à celui dont je me sers pour lancer le système d'exploitation, mais avec les autres noyaux trouvés avec les autres commandes.
Pour moi, je pense que dans tout les cas, la réinstallation est le meilleur choix, entre autre pour me permettre une certaine flexibilité dans le futur.
Par contre, j'aurai juste besoin d'une autre petite précision, ne maîtrisant pas encore correctement ces systèmes. Comment faire pour réaliser la solution 4, et y-a-t'il autre chose à faire au préalable ?
Encore merci !
Bonne journée,
Sylver