J'ai fait la même erreur en ajoutant mon compte à un groupe (j'ai oublié le nom du groupe). -a ). J'avais installé mon système avec le login root verrouillé, et mon compte était le seul sur la machine.
La réponse acceptée ne m'a pas aidé. En démarrant en mode de récupération, tout ce que j'ai obtenu est un message inutile.
Impossible d'ouvrir l'accès à la console, le compte root est verrouillé. Voir page de manuel sulogin(8) pour plus de détails.
Appuyez sur ENTER pour continuer
Après avoir appuyé sur ENTER, le système a démarré normalement : aucune chance d'obtenir un accès root pour résoudre le problème. Je laisse cette réponse au cas où quelqu'un se retrouverait à ma place à ce stade. Utilisez ce qui suit seulement si vous ne pouvez pas accéder au mode de récupération par le menu Grub. .
Une marche à suivre pour obtenir la racine du Shell :
-
Démarrez dans le menu Grub, et mettez en évidence (mais n'appuyez pas sur Enter on !) l'option de démarrage normal (par défaut, pas de récupération !).
-
Appuyez sur e . Grub affichera un éditeur de ligne de commande avec plusieurs lignes, chacune d'entre elles pouvant sembler peu familière, voire intimidante. Ne vous inquiétez pas, les modifications que vous faites ne sont pas enregistrées de façon permanente.
-
Trouvez la ligne qui dit linux ... ro ... . C'est la ligne de commande du noyau. Remplacez le ro jeton avec rw pour rendre le système de fichiers racine en lecture/écriture, et ajouter un autre paramètre de ligne de commande du noyau, init=/bin/sh . Cela indique au noyau d'exécuter sh au lieu de /sbin/init . Au final, la ligne devrait ressembler à linux ... rw init=/bin/sh ... . Nota: Vous pouvez vous en sortir même avec le strict minimum grub> rapide. Je serai heureux de vous expliquer comment faire, étape par étape, si tout le reste échoue pour vous ; il suffit de laisser un commentaire à cette réponse.
-
Après la modification, appuyez sur F10 pour utiliser les commandes de l'éditeur pour démarrer le système (ou lisez les instructions comment démarrer juste en dessous de la fenêtre de l'éditeur, si votre Grub est compilé différemment). Vous obtiendrez l'invite Grub root, puisque le processus init s'exécute en tant que PID 1 avec l'identité root.
-
Effectuez le changement que vous voulez faire, par exemple usermod -a -Gadm,sudo YOURUSERID . Confirmez avec id -a YOURUSERID que tu as récupéré ton statut de membre sudo. Dans le cas où vous obtenez une erreur "command not found", utilisez /sbin/usermod y /bin/id .
-
Vous ne pouvez pas arrêter ou redémarrer le système proprement à ce stade. reboot , halt o poweroff ne fonctionnera pas, et exit à partir du Shell conduira à une panique du noyau, car le processus PID 1 n'est pas censé sortir tout simplement. Donc les deux prochaines commandes que vous devez émettre sont :
sync
exec /sbin/init
sync juste au cas où quelque chose irait mal, pour sauvegarder toutes les modifications sur le disque, et la exec pour remplacer le Shell par le véritable init (qui peut être systemd, upstart ou System V init, mais il est toujours appelé /sbin/init ). Le système continuera très probablement à démarrer normalement (pas de mode de récupération).
-
Connectez-vous et redémarrez le système une fois, par exemple. sudo reboot -- vous devriez avoir récupéré votre privilège sudo. Un redémarrage est recommandé, car (bien que très rarement) init peut se voir passer des paramètres supplémentaires lors d'un démarrage normal, ce que nous n'avons pas fait. Dans le cas où le exec échoue, il suffit de réinitialiser la machine et de la laisser démarrer normalement. Tous les systèmes de fichiers journalistiques modernes comme ext4, xfs et btrfs se rétablissent rapidement (quelques secondes tout au plus pour une vérification du journal, si sync ed avant la réinitialisation), et vous serez prêt.
Un peu d'histoire
Il y avait un discussion sur le rapport de bogue de Debian à propos de ce même problème et, d'après ce que j'ai compris, il a été décidé qu'il s'agissait d'une fonctionnalité et non d'un bogue, ce qui, à mon avis, était plutôt une erreur. Ayant travaillé dans ce domaine pendant 25 ans, je ne peux m'empêcher d'être en total désaccord avec l'argument de Michael Biebl dans son article intitulé message n° 31 dans ce fil :
Considérez ceci : Vous avez un ordinateur portable avec un compte root verrouillé. Par défaut le Grub Grub génère une entrée de démarrage pour le mode de secours. Donc, même si vous verrouillez le bios pour ne pas autoriser le démarrage depuis un CD-Rom ou une USB, et que vous protégez par mot de passe Grub, quelqu'un pourrait facilement obtenir un accès root si vous laissez l'ordinateur portable sans surveillance pendant un moment.
L'objection correcte de l'OMI, même si elle n'est pas assez générale, a été formulée dans le document suivant message #70 par Felipe Sateler :
Pour beaucoup (la plupart ?) d'ordinateurs, l'accès physique signifie la perte de la partie sécurité, car il suffit de démonter la boîte pour récupérer le disque dur. disque dur.
C'est particulièrement vrai pour l'ordinateur portable, mentionné dans l'argumentaire de Michael : si vous le laissez un instant sans surveillance et que quelqu'un en veut à vos données, l'ordinateur portable aura tout simplement disparu pour ne plus jamais être revu. Et pour tout Une machine, pas "beaucoup" ou "la plupart", même celles boulonnées à 8 points dans un rack, dès que l'attaquant obtient un accès physique à la machine, la partie est vraiment terminée.
