Je suis tombé en recovery mode

Support Debian
, ,
Tags: #<Tag:0x00007f4e604d0c78> #<Tag:0x00007f4e604d0b60> #<Tag:0x00007f4e604d0a98>
#1

Salut, mon Trixie 13.4 ne démarre plus normalement, il me met en mode recovery (console). Parmi les messages trouvés qui pourraient expliquer ça, je trouve « Failed to mount boot-efi.mount - /boot/efi », motif « type de système de fichiers « vfat » inconnu ».

Ça me surprend un peu, car voici la séquence des évènements survenus en amont du problème.

Comme expliqué dans un autre fil, j’ai un peu galéré avec une tentative de désinstallation de grub. La désinstallation s’est mal passée, je me suis retrouvé avec un systemd-boot à la place de grub, installé partiellement car ils saturait ma partition EFI (apt finissait en erreur). Au final, j’ai réussi à remettre grub, virer systemd-boot, libérer de l’espace sur ma partition EFI, et j’ai laissé comme ça. Je précise que plusieurs fois, l’ordinateur a booté convenablement dans cette situation, et que je n’ai rien modifié de fondamental sur cette partition EFI depuis.

Là dessus, l’ordi a connu un autre plantage, qui selon moi n’est pas lié. Alors que tout allait bien, j’ai laissé l’ordi et il est passé en veille, mais là, impossible de le réveiller : écran noir, clavier bloqué (impossible d’éteindre num lock). Je me suis résolu à enfoncer le bouton reset, et c’est en redémarrant que je suis tombé en recovery mode.

Un lsmod réalisé en root ne m’affiche pas le module vfat, ce qui est cohérent avec le message d’erreur de mount.

Et du coup, je voulais savoir ce qui pourrait causer cette absence de vfat. La partition EFI étant forcément en FAT, je ne comprends pas comment j’ai pu me retrouver dans cette situation, ni ce qui a pu être l’élément déclencheur…

Encore une fois j’ai besoin de vous, les gars, j’apprends linux dans la douleur…

#2

Il faut faire attention à la taille de /boot/Efi ne serait-ce que pour ça.
jamais moins de 512Mo. C’est une taille suffisante pour faire face aux différentes situations.

Sur quoi tu te bases?
par ailleurs quelle est la taille de ton swap par rapport à ta mémoire?

Déjà il faudrait vérifier le partitionnement:
Pour voir le partitionnement:
fdisk -l /dev/sdX
Faire un lsblk -f pour voir la partition et son UUID pour vérifier le montage dans /etc/fstab.

C’est pourquoi il faut apprendre mais ne pas chercher à bidouiller quelque truc que ce soit. Surtout avec des éléments touchants au /boot/ à EFI et d’une façon générale avec le bootloader.

Demande ici comment faire, avant de demander ici comment ré&parer ce qui a été mal fait :wink:

#3

Sur le fait que pendant plusieurs jour le PC a booté sans problème, avec de fréquents passages en veille + réveils qui se sont très bien passés.

RAM = 16 Go, swap = 30 Go

# fdisk -l /dev/nvme0n1p1
Disque /dev/nvme0n1p1 : 100 MiB, 104857600 octets, 204800 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 : 0x0a0dff65

Périphérique     Amorçage      Début        Fin   Secteurs Taille Id Type
/dev/nvme0n1p1p1          1869881445 3571221465 1701340021 811,3G 7a inconnu
/dev/nvme0n1p1p2          1634566756 3553817813 1919251058 915,2G 72 inconnu
/dev/nvme0n1p1p3                   0          0          0     0B  0 Vide
/dev/nvme0n1p1p4            28049408   28049849        442   221K  0 Vide
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.

# lsblk -f
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                
├─sda1                                                                             
└─sda2      ntfs         Big   984E58B04E5888C0                      754,7G    73% /media/thibi/Big
sdb                                                                                
sr0                                                                                
nvme0n1                                                                            
├─nvme0n1p1 vfat   FAT32       00E3-B2A2                                           
├─nvme0n1p2                                                                        
├─nvme0n1p3 ntfs               723CFD6C3CFD2BAB                                    
├─nvme0n1p4 ntfs               1C4A57814A57569C                                    
├─nvme0n1p5 ext4   1.0         ca6766ec-c07a-48be-a7d3-24f7e1fa0b5c     78G     9% /
├─nvme0n1p6 ext4   1.0         f4419e2d-8877-49c6-b1b3-69f6304b5038   68,9G    37% /home
└─nvme0n1p7 swap   1           5304fe58-4af9-4cef-ac13-c45c1e4bdced                [SWAP]

# cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p5 during installation
UUID=ca6766ec-c07a-48be-a7d3-24f7e1fa0b5c /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=00E3-B2A2  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/nvme0n1p6 during installation
UUID=f4419e2d-8877-49c6-b1b3-69f6304b5038 /home           ext4    defaults        0       2
# swap was on /dev/nvme0n1p7 during installation
UUID=5304fe58-4af9-4cef-ac13-c45c1e4bdced none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

J’ai demandé de l’aide ici : Virer Grub

#4

Ta r&éponse ne correspond pas à ton commentaire quoté:

Ma question en plus clair: qu’est ce qui te fait penser que l’autre plantage n’est pas lié avec le problème de démarrage en revocery?

ok.
Le nom de ton disque n’est pas bon:
nvme0 c’est le socle nvme de ton système, le premier donc.
n1 c’est le disque sur ce socle
p1 c’est la partition numéro 1

Donc normalement ton device c’est /dev/nvme0n1
Il y a une certaine anomalie à avoir nvme0n1**p1p1&
D’autant que ton disque est en dos, au lieu de gpt pour faire de l’uefi.

C’est pourquoi il aurait fallut faire fdisk -l /dev/nvme0n1
Car ton résultat n’est pas bon (d’autant qu"aucune partition n’est reconnue)

Le lsblk est plus cohérent lui (d’ailleurs ça aurait te mettre la puce à l’oreille une telle différence).

De toute façon et par sécurité il faut que tu refasse ta partition /boot/efi.

N’oublie pas que rfind aussi y utilise de la pl ace il me semble.

Donc il te faut refaire le partitionnement de ton /boot/efi en prenant de la place là où il y en as.
Refait nous un fdisk correct pour avoir une vue correcte du partitionnement de ton disque.

#5

On s’est mal compris, quand je dis « l’ordi a connu un autre plantage, qui selon moi n’est pas lié », je veux dire que ce plantage de sortie de veille n’est pas lié aux mésaventures précédentes sur la désinstall de grub et la saturation de l’EFI. Je suis 100% convaincu qu’il est lié au redémarrage en recovery.

Voilà le bon fdisk, en effet on comprend mieux :grin: :

# fdisk -l /dev/nvme0n1
Disque /dev/nvme0n1 : 465,76 GiB, 500107862016 octets, 976773168 secteurs
Modèle de disque : CT500P2SSD8                             
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 : 018C7F28-98B9-4056-9A50-6CB69AD8D86D

Périphérique       Début       Fin  Secteurs Taille Type
/dev/nvme0n1p1      2048    206847    204800   100M Système EFI
/dev/nvme0n1p2    206848    239615     32768    16M Réservé Microsoft
/dev/nvme0n1p3    239616 463720447 463480832   221G Données de base Microsoft
/dev/nvme0n1p4 975722496 976771071   1048576   512M Environnement de récupération Windows
/dev/nvme0n1p5 463720448 659032063 195311616  93,1G Système de fichiers Linux
/dev/nvme0n1p6 659032064 912939007 253906944 121,1G Système de fichiers Linux
/dev/nvme0n1p7 912939008 975722495  62783488  29,9G Partition d'échange Linux

Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
#6

Ben oui, avec 100M, aucune chance de faire les manips correctement.
Je soupçonne Microsoft de faire exprès pour empêcher toute utilisation.

En fait, je n’utilise JAMAIS l’EFI de Windows. Je créé toujours un nouvel EFI.
Cela n’a pas d’importance car avec os-prober on va pouvoir lancer le gestionnaire de Windows.

Mais par habitude il faut bannir l’utilisation de l’EFI windows car il est volontairement trop petit.

Et faisant ta propre partition elle est alors de la bonne taille.
Prend 512Mo dans l’une de tes partitions (celel de 121Go ferait l’affaire) pour créer ta partition EFI. Tu réinstalle grub en utilisant cette partition spécifiquement et ça devrait aller mieux.

Par ailleurs, tu devrais utiliser LVM c’est nettement plus pratique pour gérer les partitions et l’espace disponible.

#7

Le problème des 100 Mo n’est pas un souci dans l’immédiat, après avoir enlevé systemd-boot je suis revenu à un taux d’occupation de ~35%, j’ai plein de place sur cette partition. Comme je disais, le PC a fonctionné plusieurs jours, redémarré plusieurs fois, avec cette même partition telle qu’elle est encore aujourd’hui. Mon souci semble plutôt être l’absence inexpliquée du module vfat dans le kernel.

#8

Je viens de faire une expérience : j’ai commenté la ligne de la partition EFI dans /etc/fstab, et rebooté. Le système démarre et arrive jusqu’à la mire de login, où je constate que je n’ai plus ni souris, ni clavier. Quelque chose a pourri mon kernel (absence de vfat, clavier, souris), et je ne suis pas loin d’incriminer le driver graphique « nouveau », qui a fait un core dump à la sortie de veille…

Edit : je précise, j’arrive à la mire de login de KDE Plasma, en mode graphique.

#9

Autre expérience, j’ai booté sur une clé USB Debian, j’arrive bien à monter la partition EFI sur /boot/efi en vfat. Ça me permet de donner des chiffres plus précis, la partition est occupée à 39% (60 Mo libres).

#10

Attention, les USB dfournie par Debian ont un efi avec le minimum requis, ce qui en fait un démarrage plus petit.

Mon debian.efi fait 144M
Le shimx64.efi fait 935K
Les fichiers systemd-boot font 130M environ, sachant que tu en as autant que de version de kernel (soit deux à minima).

Sur une clef USB d’installation, tu n’as besoin que d’une seule version de kernel.
Sur un système, les deux dernières version sont préférable (au cas ou la mise à jour du dernier kernel poserait problème.

~# tree -afpughi --du /boot/efi
[drwx------ root     root     438M]  /boot/efi
[drwx------ root     root     287M]  /boot/efi/******
[drwx------ root     root     143M]  /boot/efi/******/6.12.73+deb13-amd64
[-rwx------ root     root     132M]  /boot/efi/******/6.12.73+deb13-amd64/initrd.img-6.12.73+deb13-amd64
[-rwx------ root     root      12M]  /boot/efi/******/6.12.73+deb13-amd64/linux
[drwx------ root     root     143M]  /boot/efi/******/6.12.74+deb13+1-amd64
[-rwx------ root     root     132M]  /boot/efi/******/6.12.74+deb13+1-amd64/initrd.img-6.12.74+deb13+1-amd64
[-rwx------ root     root      12M]  /boot/efi/******/6.12.74+deb13+1-amd64/linux
[-rwx------ root     root     8.0K]  /boot/efi/db
[-rwx------ root     root      10K]  /boot/efi/dbx
[drwx------ root     root     152M]  /boot/efi/EFI
[drwx------ root     root     3.6M]  /boot/efi/EFI/BOOT
[-rwx------ root     root     122K]  /boot/efi/EFI/BOOT/BOOTX64.EFI
[-rwx------ root     root      91K]  /boot/efi/EFI/BOOT/fbx64.efi
[-rwx------ root     root     2.6M]  /boot/efi/EFI/BOOT/grubx64.efi
[-rwx------ root     root     836K]  /boot/efi/EFI/BOOT/mmx64.efi
[drwx------ root     root     4.4M]  /boot/efi/EFI/debian
[-rwx------ root     root      108]  /boot/efi/EFI/debian/BOOTX64.CSV
[-rwx------ root     root      86K]  /boot/efi/EFI/debian/fbx64.efi
[-rwx------ root     root      248]  /boot/efi/EFI/debian/grub.cfg
[-rwx------ root     root     2.6M]  /boot/efi/EFI/debian/grubx64.efi
[-rwx------ root     root     830K]  /boot/efi/EFI/debian/mmx64.efi
[-rwx------ root     root     935K]  /boot/efi/EFI/debian/shimx64.efi
[drwx------ root     root     144M]  /boot/efi/EFI/Linux
[-rwx------ root     root     144M]  /boot/efi/EFI/Linux/debian.efi
[drwx------ root     root     126K]  /boot/efi/EFI/systemd
[-rwx------ root     root     122K]  /boot/efi/EFI/systemd/systemd-bootx64.efi
[-rwx------ root     root     3.9K]  /boot/efi/KEK
[drwx------ root     root      13K]  /boot/efi/loader
[drwx------ root     root     5.0K]  /boot/efi/loader/entries
[-rwx------ root     root      498]  /boot/efi/loader/entries/******-6.12.73+deb13-amd64.conf
[-rwx------ root     root      506]  /boot/efi/loader/entries/******-6.12.74+deb13+1-amd64.conf
[-rwx------ root     root        6]  /boot/efi/loader/entries.srel
[drwx------ root     root     4.0K]  /boot/efi/loader/keys
[-rwx------ root     root       73]  /boot/efi/loader/loader.conf
[-rwx------ root     root       32]  /boot/efi/loader/random-seed
[-rwx------ root     root      886]  /boot/efi/PK

Actuellement ce vieux système tourne avec Grub mais les fichier d’une installation systemd-boot sont présent.
Son installation avait échoué à cause d’un mauvais paramétrage de System Secure Boot.

#11

Dans mes 39 Mo de /boot/efi, j’ai genre 25 Mo de Windows, 5 Mo de Grub inutile et 4 + 4 Mo pour rEFInd et une copie de sauvegarde. Je boote sur rEFInd.

Mais bon, assez parlé du boot, pour moi ce n’est qu’un épiphénomène de mon souci principal. Comment je diagnostique le vrai souci derrière tout ça, qui est (entre autres) à l’origine de la disparition de vfat ?

Est-ce qu’un apt reinstall de mes deux kernels ferait avancer la chose ?
6.12.73+deb13-amd64
6.12.74+deb13+1-amd64

#12

que donne:

lsmod | grep -i vfat

Car vfat dépend aussi de fat, car chez moi:

~# lsmod | grep -i vfat
vfat                   24576  1
fat                   102400  1 vfat

Ensuite que donne:

grep -Rin fat /etc/modprobe.d/

regarde dans les logs :

grep -Rin fat /var/log/syslog* | grep -iv fatal

ou

journalctl -b | grep -Rin fat | grep -iv fatal

En clair: chercher toutes les occurrences de fat dans les logs(car dans certains logs tu n’auras pas vfat mais fat32 par exemple).
Enfin que donne:

locate fat.ko
#13

Absolument rien, vide : ni vfat ni même fat. C’est ce qui m’a fait écrire dans le premier message de cette discussion : « Un lsmod réalisé en root ne m’affiche pas le module vfat, ce qui est cohérent avec le message d’erreur de mount. »

Rien non plus. Le module n’apparait plus du tout.

Ça me renvoie juste des banalités, le contenu de .bashrc_history par exemple comme j’ai fait plein de commandes pour trouver vfat dans les journalctl des boots précédents :

.bash_history:198:grep vfat /etc/*
.bash_history:199:grep vfat /etc/* 2>/dev/null
.bash_history:200:grep vfat /etc/*.d/* 2>/dev/null
.bash_history:213:grep vfat /lib/modules/6.12.73+deb13-amd64/modules.builtin
.bash_history:214:grep fat /lib/modules/6.12.73+deb13-amd64/modules.builtin
.bash_history:215:grep fat /lib/modules/6.12.74+deb13+1-amd64/modules.builtin
.bash_history:217:ls /lib/modules/6.12.74+deb13+1-amd64/kernel/drivers/*fat
.bash_history:219:modprobe vfat
.bash_history:220:modinfo -v vfat
.bash_history:221:modinfo vfat
.bash_history:226:journalctl -b 1 | grep fat
.bash_history:227:journalctl -b 2 | grep fat
.bash_history:228:journalctl -b 3 | grep fat
.bash_history:229:journalctl -b -1 | grep fat
.bash_history:235:journalctl -b -10 | grep vfat 
.bash_history:236:journalctl -b -5 | grep vfat 
.bash_history:237:journalctl -b -8 | grep vfat 
.bash_history:238:journalctl -b -7 | grep vfat 
.bash_history:241:journalctl -b -9 | grep vfat 
.bash_history:243:journalctl -b -9 | grep vfat
.bash_history:244:journalctl -b -7 | grep vfat
.bash_history:245:journalctl -b -8 | grep vfat
.lesshst:3:"vfat
#14

Et le locate?

#15

locate fat.ko ne trouve rien :confused: