6

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.

  • 2
    Edit in the line about root from /etc/passwd (it is probably the top one). Don't worry, this is not confidential information. – goldilocks Oct 12 '17 at 13:45
  • 2
    Did you fix this already? I've got the same issue. @goldilocks you know what is happening? – Refilon Dec 3 '17 at 22:42
  • I have searched hours and still don't know the answer to this? @goldilocks mentioned editing in the line about root from /etc/passwd but to what? need help! – Mikeys4u Mar 23 '18 at 0:28
  • @Mikeys4u By "edit in" I meant copy paste the line into the question above. The cause of the problem is likely in that line if you know how to read it (see man 5 passwd). Anyway, if you have a question use the Ask Question page, linked top right. – goldilocks Mar 23 '18 at 13:37
  • BTW, K.T.'s new answer below is a good one. More in relation to that: unix.stackexchange.com/a/168422/25985 – goldilocks Mar 23 '18 at 13:40
7

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).

  • I seem to have the same problem as you. Running sudo e2fsck -n /dev/mmcblk0p2 does return disk errors where I can't fix them. Could you elaborate on how to run this filecheck in order to fix the disk (maybe from another computer or so)? – GuyKhmel Jul 24 '18 at 6:56
  • If you have a spare Linux machine with an SD card reader, you should be able to fsck the SD card easily (as it is not a root filesystem then). In fact, if you have an USB SD card reader and a second card to boot your Pi from, you should be able to put the USB reader with the card that requires checking into the (running) Pi and then run the check from the Pi. – KT. Jul 24 '18 at 21:40
  • What command should I run? The same sudo e2fsck -n /dev/mmcblk0p2 only on my (other) device? – GuyKhmel Jul 25 '18 at 9:00
  • /dev/mmcblk0p2 is the filename of the boot-time SD card on the Pi. If you insert the SD card via a USB reader into another computer (or into the Pi itself) its filename will be different. You can use lsblk to figure it out. Then just run sudo e2fsck <filename of the inserted card>. The -n flag means "check, but don't fix". – KT. Jul 26 '18 at 9:58
0

It showed this issue after i disconnect the boot disk drive and plugged into Mac, then mac created .DS_Store file in this disk, after deleted all those .DS_Store files, reconnect to raspi, it works without any issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy