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

Hardware Server
,
1

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

2

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

3

I think it was a problem with a fstab

1 Like
4

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.

5

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?

6

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

7

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)

8

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
9

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.

11

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.

12

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

13

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.

3 Likes
14

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.

15

Can u give me a hint, where to find in the sources on github, what exactly options 52, 54 and 55 do?

16

In case you installed openhabian you should be able to find the sources on your host in /opt/openhabian/functions/ in file menu.bash.
In case you would like to have a look at github then goto GitHub - openhab/openhabian: openHABian - empowering the smart home, for Raspberry Pi and Debian systems

17

thx…then i was about at the right position… somewhere at openhabian/functions it should be… but didn’t see it exactly…

backup.bash looks fine… Especially as that is where @mstormi did do the changes to fix the UUID issue with rsync

but I don’t understand it… The fix just moved the

# shellcheck disable=SC1091

directive from the beginning of the file to the line after the

#!/usr/bin/env bash

directive… no idea how that fixes “cond_redirect in SD mirror PARTUUID extraction” …
but I didn’t do bash scripting for a long time, so it may really does fix the issue