Bonjour,
Impossible d’ouvrir une session, au démarrage apparaît le message ci-dessous juste, avant la page de login ; idem en démarrant sur Recovery Mode ; dans le bios tous les mots de passe (Admin, system…) sont sur « not set ».
Aucun problème signalé lors de la dernière fermeture. machine sous Debian 12, mises à jour faites régulièrement.
Merci pour vos suggestions
@photini1, visiblement le système ne semble pas reconnaître la partition ou le disque où serait présent les utilitaires Linux, les commandes…
Un audit de l’état des disques et de leurs partitions semble nécessaire avec par exemple l’aide d’un LiveCD (ou une clef USB).
As-tu créé un mot de passe root à l’installation ? Car sans mot de passe définit, le compte est automatiquement vérrouillé dans ce genre de cas.
Non @Zargos, car en mode emergency, il n’y aurait pas besoin d’entrer de mot de passe.
@photini1 voici si nécessaire comment s’assurer que l’on démarre correctement en mode emergency.https://fr.unixlinux.online/fn/1001003432.html Si non, cf mon précédent post.
Partition manager ( avec un Debian live), n’indique pas d’anomalies sur les partitions :" SMART status : good)" ; retour de fdisk en PJ.
Une précision : pas de mot de passe root lors de l’installation de Deb12
fdisk.txt (2,4 Ko)
complément d’infos :
- en PJ les différentes partitions : sdb3 est d’origine monté sur /home, il est ici monté sur /media/user ?? est-ce du au fonctionnement en live ?
- la procédure proposée de démarrage en mode de secours n’est pas très claire, semble ne considérer que le cas d’utilisation d’un mot de passe root, ce qui n’est pas mon cas, je n’ai donc pas tenté de l’appliquer
partitions.txt (497 Octets)
Le mot de passe root est pour le moment un problème secondaire que tu pourras activer ultérieurement.
Il est normal de ne pas avoir au mode de dépannage système sans accès root.
La priorité est de clarifier l’origine de l’UUID du blockdev qui bloque dans ton premier message.
D’où vient cet UUID ? Du fstab ? Si oui, pourquoi cette modification après juste une ‹ simple mise à jour ›.
Vérifies en live le contenu du fstab.
Tu pointes à juste titre le fstab car je l’ai modifié il y a peu en rajoutant une ligne pour assurer le montage auto d’un DD externe de sauvegarde ( qui pour une raison inconnue refusait d’être monté au démarrage ) en utilisant son UUID repéré pourtant avec soin, mais qui donne ça :
: $ cat /etc/fstab
overlay / overlay rw 0 0
tmpfs /tmp tmpfs nosuid; nodev 0 0
On passe donc ‹ d’une simple mise à jour ›, qui était peu probable pour expliquer le boot, à un tripatouillage de fstab. Plus qu’à rétablir un fstab correct, avec la bonne partition système.
cat /etc/fstab
Es-tu sûr de consulter le fstab de la partition système en analyse, et non pas celui de la session live ?? J’ai un gros doute…
Dans le 1er message j’ai indiqué l’OS et ajouté que les MàJ étaient faites régulièrement juste pour situer l’état de la machine, sans corrélation avec le problème ; ceci dit pour l’édition du fstab c’est en évidemment live, comment faire autrement , ne pouvant ouvrir une session ?
En live, tu as bien accès au disque en question.
Si non, il faut expliquer pourquoi.
Soit à partir d’un file manager, tu accèdes à cette partition système et trouves .../etc/fstab
, à partir du point de montage de cette partition, ou dans un terminal, tu crées un point de montage, monte la partition système dessus.
grossière erreur en début de ligne 15 il manque UUID=… !!
Effectivement… Un peu étonnant d’oublier une modification fstab avant reboot, avec pourtant un message explicite de mauvais blockdev.
systemd détecte et convertit les modifications de fstab en services de montage, et bloque en cas de problème.
Pour le mot de passe root, si tu l’estimes utile, tu peux essayer ça:
sudo passwd root
sudo passwd -u root