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