"Cannot open access to console. The root account is locked see sulogin(8) man page for more details."

[heavy_mental]

Hi,

I keep getting this error most of the time during boot. It pauses the booting waiting for me to press enter, so it's kinda annoying. Yet after I press it everything loads fine. Any ideas?

[B.Goode]

Well it's not 'normal' or expected, or something that everyone sees...

So what is the history or background to this?

What version of Raspbian are you running on your RPi? What modifications to its configuration have you made?

Have you considered installing a fresh version of the current Raspbian Stretch Operating System onto a spare microSD card to see if the problem is reproducible?

[heavy_mental]

This is almost untouched new stretch. Had this error before and I think it may be related to www.waveshare.com/wiki/3.5inch_RPi_LCD_(A) . Only other thing I installed is https://pi-hole.net/ but that one worked normally before.

[dulluhan]

Had the same problem after setting up the screen. But it was not immediate, seemed to happen a few reboots later, could be other things I've been doing on it. But, I do also notice the problem after setting up the screen

[epoch1970]

I've seen someone in the French forum having the same issue, he had added a touchscreen, too.
Unfortunately he reinstalled Stretch and did not try to search further. Reinstall seems to have solved the issue for him.

I would suspect something is wrong with the "console=" statement(s) you people have in /etc/cmdline.txt.

[mmarcon]

Same is happening to me (Rasperry Pi Zero W). The first time the problem went away with a reboot, but now it's unfortunately stuck. I also installed the drivers for the waveshare touch screen.

Problem is, I have no keyboard to connect to the pi, I was lucky enough to make everything work completely in headless mode. I guess I'll have to get a microUSB adapter and connect a keyboard.

[WheelingWizard]

I noted the same issue on two different Raspberry Pi 2 devices. I loaded a fresh copy of 2018-03-13-raspbian-stretch. Initial operation was correct. After updating and reboot; system halts on startup with "cannot open access to console" & "root account is locked". With a USB keyboard, select Enter key and startup proceeds. I reloaded an earlier version of Stretch (2017-11-29-raspbian-stretch) on one of the Raspberry Pi 2 devices. The startup error did not occur. However, after I ran sudo apt-get upgrade - the same problem manifested.

[mikeys4u]

Just got this error message and the last thing I done was to change my password, from the usual raspberry to something else.
Rebooted and this came up....
It must be login related....
How do I reset this?

[janet]

I managed to stop this by renaming sulogin (dogy ik but it fixed it).

sudo mv /sbin/sulogin /sbin/sulogin.bak



Good luck

[MrBrown666]

I just ran into the same issue after setting up my Octoprint with a touchscreen. I ended up restarting from scratch, but this time pulled an image while everything was still working. Seems like I can replicate this error whenever I do a hard shutdown (aka unplug it). Yes, I know this isn't how you're supposed to turn it of , but hey this might still happen when the power goes out.

After some research I stumbled upon this: https://bugs.debian.org/cgi-bin/bugrepo ... bug=789950
which led me to this commit: https://git.kernel.org/pub/scm/utils/ut ... 72461aa254

This commit is a few years old and Idon't know if I understood all of this, but I think somewhere on the first site they described how something like a corrupted fs (like after a hard shutdown) might trigger this.
And on the second site we can see part of the sulogin code that describes this the exact error message we are having. The description suggests that sulogin was changed to require "--force" to start a root shell when a locked root account is detected.

Of course now that i wanted to test my approach, I cannot get the error to show up again...

But here is what I would try:

sudo nano /etc/inittab
find the line
"~~:S:wait:/sbin/sulogin"
and change it to
"~~:S:wait:/sbin/sulogin --force"

Pls let me know if this fixes it.

[MrBrown666]

EDIT: sry, double post... guess i'm a noob

[DougieLawson]

/etc/inittab does NOT exist on systemd systems like Raspbian Stretch. The last Raspbian version with an inittab was Wheezy.

[MrBrown666]

Well, this was helpfull...

But it DOES exist:

inittab.JPG (43.53 KiB) Viewed 23258 times

This is on a 3B+, so i had hardly any other choice than the newest version of Raspbian.

But OK, you're right. I see my error: I'm still kinda new to this and I was confused by inittab still being there ( BTW /etc/init/ does also exist, shouldn't this be gone too?)

So this brings us to /lib/systemd/system/ right?
I see two files mentioning sulogin in there, "emergency.service" and "rescue.service". This seems to correlate with my observation of this error happening when the fs might be corrupted.

I totally get why they added this safety feature, instead of just starting a root shell without password. But on a headless system, waiting for the user to press enter might not be the best idea.

[DougieLawson]

You are NOT running Stretch. /etc/inittab does NOT exist on DebIan Stretch or Raspbian Stretch. So everything you've read about systemd is probably null and void.

Start by looking at /etc/os-release and/or /etc/lsb-release (which ever of those two exists).

[MrBrown666]

here it is

stretch.JPG (41.94 KiB) Viewed 23230 times

can we now finally get back to the original issue instead of having a slapfight on whether these files exist my system or not?

[DougieLawson]

It's not Devuan is it?

Try creating a fresh new SDCard with plain Raspbian 2018-03-13 and see how that works.

[eilex]

First of all sorry fot my bad english

I've just got the same error after dist-upgrade and this is how I solved it:

- "cat /etc/fstab" and search for your root partition PARTUUID.

Code: Select all

proc            /proc           proc    defaults          0       0
PARTUUID=3e904640-01  /boot           vfat    defaults          0       2
PARTUUID=3e904640-02  /               ext4    defaults,noatime,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
/var/log/ispconfig/httpd/xenopi.dynu.net /var/www/clients/client1/web2/log    none    bind,nobootwait    0 0

(PARTUUID=3e904640-02 in my case)

- "sudo nano /boot/cmdline.txt" check if there is the right root partition or fix it.


(This is what I had before fixing it)

Code: Select all

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo

(This is the working one)

Code: Select all

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=PARTUUID=3e904640-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo

This fix only works in case your cmdline root partition is miss configured. If you have "/boot.bak/" dir you are problably having this isue because the old "/boot/" it's left as backup and the dist-upgrade may did'nt setup the root= argument correctly.

I leave here my "/boot.bak/cmdline.txt" just for info, don't use this old one for stretch it does some strange behaviours

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=3e904640-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Hope this helps you

[islandmarmot]

UPDATE: I was wrong this did not fix the issue.

I changed fsck.repair to "NO" and the Pi boots ok.

It appears to me that the boot partition is being checked at startup and as a result systemd times out on reading /boot/cmdline.txt. Hence no console and hence emergency mode.

This is but a theory and I don't really have time to test it.

------------------------------------------------------------------------------------------------------------------------------------------------


Hi - I was having similar problems - had to press a key to continue. I did notice that systemd was complaining about a timeout with a reference to serial. (I cant remember the exact message).

I changed

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=3e904640-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

to

Code: Select all

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=PARTUUID=3e904640-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

and it booted fine..... I only changed the console to ttyAMA0 .. and yes I checked my PARTUUID's

NOTE: This Pi zero had taken a number of hard resets on a fresh install of stretch lite.

Hope this helps and thanks for posting eilex...

[juanmasaiz]

Changing

root=PARTUUID=XXXXXX

and

fsck.repair=no

resolves the problem for me.
Thanks!

[egawtry]

I am getting this on my initial boot. It never reaches a point where I can login and do anything.

I am using the latest image from the downloads on a 32GB SD card. Anyone have any ideas?

[stefan9717]

Hello,

I had the same fault when migrating from a pi2b with boot from sd-card but root fs on an ssd to a pi3b+.
what helped was to alter /etc/fstab, then everythink worked fine for me.

[JaredW]

I had the exact same error. Some of the hints above about fstab made me realize that I had added a USB mount point to my fstab and it was taking forever looking for it. Once I plugged back in the missing USB device, it worked just fine. I'd imagine that if I edited my fstab and took out the usb mount line, it would boot just fine without the usb device but I never bothered to test that.

Hope that helps someone!

[daudipa]

I had the same problem after detaching the external HD, reformatting one of its partition and re-connecting it to the Raspi. It appears (to me) that the situation occurs when partitions loaded with parameters provided in /etc/fstab cannot be found. The same error message occurs when the HD is detached.
My solution was to take the SD card out of the Raspi and edit the /etc/fstab file on another Linux computer. One must comment out all lines related to the HD. Then put the SD back into the Raspi, start it up (it now boots flawlessly), and run "sudo blkid" to find out the new UUIDs on the HD and verify this against what is written in fstab, modifying the lines if required.
Thus, there is no need to re-install Raspbian and starting from scratch.
One question remains: I had the last two columns in fstab set to "0 0". Does the last zero matter? Maybe somebody knows or can take the time to experiment.

[precubcr]

Hello all
Happened the same for me.
I have created a nas, and looks like if rasp does not load all partitions inside fstab file, it never loads.
I removed my nas line from fstab file and all went good.
Tried several times to make sure and allways the same result.
I hope ihelp someone.

Please do a copy of fstab before editing it in any way. Just to make sure...

[rpdom]

One question remains: I had the last two columns in fstab set to "0 0". Does the last zero matter? Maybe somebody knows or can take the time to experiment.

The last zero doesn't matter. In fact you can leave both of those last two numbers off of the the entry in fstab without it affecting anythng.