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

Hi,

Looking for some help.
Yesterday I rebooted my Pi4B. But since then it will not boot. After failing to ssh in to it, I plugged in a monitor to see what was happening. Everything seemed to boot normally until I get a message:

You are in emergency mode. After logging in, type “journalctl -xb” to view system logs, “systemctl reboot” to reboot, “systemctl default” or “exit” to boot into default mode.

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

When I press enter, it tries to do something, but just ends up showing the same message again.

I might suspect SD corruption, except that it seems to boot 99% of the system before this happens. And I can access both the ‘rootfs’ and ‘boot’ partitions of the SD card when I plug it in to my PC.

I am a novice user and this kind of probem is beyond my skillset. Is there anyone here who is willing to Whatsapp me and help me for an hour or two to try to fix this or rebuild as much as possible from what I have copied from the SD card?
I will gladly pay something for your time, or make a contribution to a charity of your choice.

Raspberry Pi4 Model B
PiJuice UPS
DeConz Raspbee II Zigbee hat

Openhabian OS
Latest version of OpenHab 3

Other software
Plex
Pihole

Did you get to the bottom of this one? I’m having exactly the same problem.

I think it was a problem with a fstab

1 Like

Thanks MartOs. I’m struggling with this one as a beginner… today I downloaded the latest openhabian image and installed on a newly formatted SD card. Even using a fresh installation, I get the same failure after the SD sync procedure.

fstab gives me something new to learn about and maybe will fix my problem.

Not sure if it’s a new SD.

I think I was trying to add a new harddrive, but messed up the fstab entry so when it rebooted it broke.
A new SD should make everything new from scratch?

In some cases ( in other context ) it was reported that this message appears in case there is a difference between what is stored in /etc/fstab and the devices that are available.
You may post the content of /etc/fstab and the output of blkid

Thanks MartOs… I created a fresh installation of openhabian on a new SD and have tried mirroring to multiple different cards and on two card readers. The first mirror works, but subsequent overnight syncs render the SD card unbootable. I get the same output you did. Will post the result of further troubleshooting below (and forgive me if I should have created a new thread instead of taking over yours)

Thanks Wolfgang

lsblk (which may be unhelpful but I have seen it asked for in other threads) is below… and is exactly the same after first overnight sync (ie when the mirror will not boot).

openhabian@openhabian:~ $ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1 59.5G  0 disk 
├─sda1        8:1    1  256M  0 part 
├─sda2        8:2    1 14.6G  0 part 
└─sda3        8:3    1 44.7G  0 part /storage
mmcblk0     179:0    0 14.9G  0 disk 
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 14.6G  0 part /
zram0       254:0    0  600M  0 disk [SWAP]
zram1       254:1    0  900M  0 disk /opt/zram/zram1
zram2       254:2    0  600M  0 disk /opt/zram/zram2

blkid after initial setup… ie first mirroring which is successful

/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="DC3E-E470" TYPE="vfat" PARTUUID="0305f292-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="a7adb26a-8b87-4729-99c8-9f5ac069d51e" TYPE="ext4" PARTUUID="0305f292-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="DC3E-E470" TYPE="vfat" PARTUUID="d81a6ae6-01"
/dev/sda2: LABEL="rootfs" UUID="eafffc6d-3e94-4751-891b-571c568bac71" TYPE="ext4" PARTUUID="d81a6ae6-02"
/dev/sda3: UUID="99530310-2ae5-4b4b-bd28-af4d3c79c59f" TYPE="ext4" PARTUUID="d81a6ae6-03"
/dev/zram0: LABEL="zram-config0" UUID="0d94ea02-5751-4516-b22e-126b68441ffc" TYPE="swap"

but after first overnight sync the last line is different…

/dev/zram0: LABEL="zram-config0" UUID="1c48f625-ffa1-4ff6-b42a-288ab77a2d85" TYPE="swap"

Fstab (on the main/original card)

proc            /proc           proc    defaults          0       0
PARTUUID=0305f292-01  /boot           vfat    defaults          0       2
PARTUUID=0305f292-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

Fstab (on the card set up for mirroring - when it will boot) - SD card read on my chromebox

proc            /proc           proc    defaults          0       0
PARTUUID=d81a6ae6-01  /boot           vfat    defaults          0       2
PARTUUID=d81a6ae6-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

But after first overnight sync - when it won’t boot, fstab becomes same as it is on main card (doesn’t seem right to me but I am early in my journey in understanding all of this)

proc            /proc           proc    defaults          0       0
PARTUUID=0305f292-01  /boot           vfat    defaults          0       2
PARTUUID=0305f292-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

PARTUUID returned by blkid and PARTUUID stored in /etc/fstab need to match.
After the original SD card is mirrored

What does

mean ? The SD card has an initial fresh install of openhabian ?

How did you sync the SD card ? Depending on how the mirroring is being done I would expect to see the same PARTUUIDs. Is there still a match between PARTUUIDs and /etc/fstab content ?

I expect to see different UUIDs for zram entries as these ‘partitions’ are generated from scratch after each system start.

What do you mean by “overnight sync” ?
It’s right that the fstab on the mirror card should not change, I think you have found a bug.

I mean the scheduled Rsync that is set up by option 53 | Setup SD mirroring

I’m just going through the process again… doing it more carefully this time and capturing as much information as I can. I think that I’m right in saying fstab changes, but I hope to report back with more confidence over the weekend. (or can I test by running option 55 myself manually?)

Yes you can enforce that sync run via option 55.
I’ve (hopefully) fixed that. Can you please update openHABian (main branch) and run option 55.
Make sure the /etc/fstab files of both cards are correct (i.e. they point to the correct, local UUID) and compare them after the sync run.

2 Likes

You sure have :smiley:

A timed sync ran overnight and the mirror booted. Then I did a further sync run via option 55 and that booted too.

The fstab files contain - and blkid returns - expected UUIDs… ie the mirror has its own UUIDs and these persist through each sync.