I made the same mistake adding my account to a group (forgot the
-a). I had my system installed with the root login locked, and my account was the only one on the machine.
The accepted answer did not help me. While booting into recovery mode, all I got was an unhelpful message
Cannot open access to console, the root account is locked. See
sulogin(8) man page for more details
Press ENTER to continue
After pressing ENTER, the system booted normally: no luck getting root access to fix the problem. I'm leaving this answer in case someone ends up in my shoes by this point. Use the following only if you cannot get to the recovery mode through the Grub menu.
A walkthrough to get the root shell:
- Boot into the Grub menu, and highlight (but don't press Enter on!) the normal (default, not a recovery!) boot option.
e. Grub will display a command line editor with multiple lines, every one of which may look unfamiliar if not intimidating. Do not worry, any changes you make are not saved permanently.
- Find the line that reads
linux ... ro .... This is the kernel command line. Replace the
ro token with
rw, to make the root filesystem read/write, and add another kernel command line parameter,
init=/bin/sh. This instructs the kernel to execute
sh instead of
/sbin/init. In the end, the line should look like
linux ... rw init=/bin/sh .... Note: You can get by even with the bare
grub> prompt. I'll be happy to explain how, step by step, if all else fails for you; just leave a comment to this answer.
- After the change, press F10 to use the commands from the editor to boot the system (or read the instructions how to boot right below the editor window, if your Grub is compiled differently). You'll get the root shell prompt, since the init process runs as PID 1 with the root identity.
- Make the change you want to make, for instance
usermod -a -Gadm,sudo YOURUSERID. Confirm with
id -a YOURUSERID that you've got your sudo membership back. In case you get a "command not found" error, use
You cannot shutdown or reboot the system cleanly at this point.
poweroff won't work, and
exit from the shell will lead to a kernel panic, as the PID 1 process is not expected to just exit. So the next two command you must issue are:
sync just in case anything goes wrong, to save all changes to disk, and the
exec to replace the shell with the real
init (which can be systemd, upstart or System V init, but it's always called
/sbin/init). The system will most likely continue to boot normally (no recovery mode).
- Login and reboot the system once, e. g.
sudo reboot--you should have gotten your sudo privilege back. A reboot is recommended, as (although very rarely)
init may be passed additional parameters during a normal boot, and that we did not do. In case the
exec fails, simply reset the machine and let it boot normally. All modern journaling filesystems like ext4, xfs and btrfs recover themselves quickly (a few seconds for a journal check at most, if
synced before the reset), and you'll be all set.
A bit of a background
There was a discussion on the Debian bug report about this very problem, and, as far as understand, this was decided a feature and not a bug, which I judge to have been rather a mistake. Having been in this business for 25 years, I cannot help but entirely disagree with the Michael Biebl's argument in message #31 in that thread:
Consider this: You have a laptop with a locked root account. By default
the grub boot loader generates a boot entry for rescue mode.
So, even if you lock down the bios to not allow booting from CD-Rom or
USB, and you password protect grub, someone could easily get root access
if you leave the laptop unattended for a moment.
The correct, IMO, if not general enough, objection was given in message #70 by Felipe Sateler:
For many (most?) computers, physical access means game lost
security-wise, as you can just disassemble the box and get the hard
This is true especially for the laptop, mentioned in the Michael's argument: if you leave it unattended for a moment, and someone is after your data, the laptop will be simply gone to never be seen again. And for any machine, not "many" or "most," even those bolted at 8 points into a rack, as soon as the attacker gets physical access to the machine, game is really over.