Strange problem on startup - cannot open access to console

Question

Rpi 3 Model B, 16gb SD, all configured well and working fine until yesterday sometime, when rebooting, I now have to press "enter" to continue due to:

"Cannot open access to console, the root account is locked."

This is news to me, and pressing enter gets me to the desktop and nothing seems amiss. I can see no errors in the syslog at all. Yesterday I was mounting things but I don't see how something I did affected anything.

What are my next steps? This particular Pi needs to boot into desktop without any keyboard intervention.

Answer 1

Found myself in the same situation just now. Took quite some time to figure out (taking into account that I had neither a USB keyboard nor a Linux computer around this was a long quest).

The reason for this problem appearing seemingly out of the blue is fsck - the automated file system check, which runs on startup. During this check fsck may discover that something is wrong with some of your filesystems and interactive input is needed to confirm fixes. At this point it apparently attempts to launch the root shell via sulogin in order to ask for this input, sulogin then discovers that the root account has no password login privileges (i.e., its line in /etc/shadow has a * in the second field), and suggests to press "Enter" to continue.

If you took out your SD card and edited /etc/shadow on a different machine (I used ExtFS for Windows to do it under Windows) by replacing the * in the password field for root for something valid (e.g. copy the password field of the pi user), you would see a different message on startup:

Give root password for maintenance or press ctrl+D to continue

This still requires interactive input to proceed and thus does not help, but at least adds some clarity to what's happening. One would think that removing the root password completely (setting the corresponding entry to empty string) could help, but it doesn't, unfortunately. The boot still breaks with a prompt for keyboard input.

In any case, the real fix to the problem depends on the reasons fsck is complaining. Most posts in the Internet about this issue say that the problem appeared after a new device was added to /etc/fstab (e.g. a removable drive) which was not available during the next boot. Removing this entry from /etc/fstab obviously helps then.

In my (and probably the question author's) case there were no new entries in fstab - just the original SD card partitions. The problem was instead due to actual corruptions of the file system. Perhaps turning the Pi off by pulling the cord rather than doing a proper sudo shutdown now was to blame, or my SD card was not good enough.

A proper solution to such problem would be to actually fix the filesystem. If I had a keyboard, I'd probably enable the root password, reboot and follow through with the full fsck process. If I had a second Linux machine, I could instead take the SD card there and run a fsck. In my case neither way was an option, so I had to get rid of the message by simply disabling filesystem checks on boot. This can be done by editing /etc/fstab.

Normally, it looks like that:

proc                  /proc           proc    defaults          0       0
PARTUUID=8866c94e-01  /boot           vfat    defaults          0       2
PARTUUID=8866c94e-02  /               ext4    defaults,noatime  0       1

The last number for each entry specifies whether, and how often the corresponding filesystem needs to be checked on boot. 1 means "every boot", 2 - every certain number of mounts. Replacing these with 0 disables boot-time filesystem checks and the Pi boots fine, even though with a potentially broken filesystem.

To conclude the story, let us take a look at /etc/init/mountall.conf, which should be the script responsible for mounting filesystems at boot.

script
    . /etc/default/rcS || true
    [ -f /forcefsck ] && force_fsck="--force-fsck"
    [ "$FSCKFIX" = "yes" ] && fsck_fix="--fsck-fix"

    ... part skipped ....

    exec mountall --daemon $force_fsck $fsck_fix $debug_arg
end script

As far as I can read from it, specifying FSCKFIX=yes in /etc/default/rcS, doing touch /forcefsck and rebooting the system should force a noninteractive fix-all-by-default file system check on the next boot. Unfortunately, it does not seem to work out for me somewhy. The Pi boots fine, but filesystem still reports the same errors (you can't fix a mounted root filesystem, but you can check it in read-only mode by running sudo e2fsck -n /dev/mmcblk0p2).