Emergency mode, root account locked

Hi,
I’m a bit in a panic. This happened: because a connected SSD drive sometimes disconnected during the day, I used disks to have it mounting at a mounting point at /mnt/. That was a few days ago, no problems with that.
Today I noticed I couldn’t copy files to that drive anymore. I changed the fstab file with a suggestion from chatgpt. I tried using chown, but that gave errors.
After reboot I get now:
You are in emergency mode. After logging in, type “journalctl -xb” to view system logs, “systemctl reboot” to reboot, or “exit” to continue bootup.
Cannot open access to console, the root account is locked.
Press Enter to continue.

Then

Reloading system manager configuration.
Starting default.target
And again You are in…

I read about using “esc” to go to rescue mode, but I don’t know where or when…

Help very much appreciated…

For future reference: you have to push ‘esc’ while booting. In that screen, I could choose a previous version of my system.
A question:
I saw as previous versions, one from 30/3/2025 (it’s 2/4/2025 today) and 25/3/2025. Based on what are these versions kept? Also: I saw those two versions mentioned twice, with really no difference. Is there a difference and why those 2 seemingly identical versions?

Still having the permission problem with the SSD. I will remove it from fstab for starters.

Also, NEVER blindly trust chatgpt to help with system maintenance. The reason why should be obvious at this point.

chatgpt can be a help while learning but you MUST verify what it is suggesting to you. Is it hallucinating? Are the suggested steps pertinent to the OS / version you are using? Is it missing some key step?

Please be careful.

There is no substitute for knowledge - except maybe a bad experience. :wink:

I wasn’t completely blindly following chatgpt, it seemed reasonable with what I know of Linux (which is, I have to admit, not very much, I’m still learning).

Although my solution worked, when I reboot, it starts with the snapshot (is that the correct term in this situation? Boot version? Kernel?) that crashes. How can I remove that version?
It’s OK to point me to a manual page!

Also, besides the question about the double versions: why only versions on those to dates (30/3/2025 and 25/3/2025)? Isn’t it better to have more versions?

Is this helpful:

rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 6h ago
Deployments:
  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:70484782631d5622e09abf8e378e645c21dd56aa26dba74a98770f4c050d40e7
                  Version: gts-40.20250330 (2025-03-30T06:07:44Z)
                     Diff: 75 upgraded

● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:3708cfc07ae12ae479c206e2e6911e116d45dd9a3a699f2ba8ed755e538ccf1a
                  Version: gts-40.20250323 (2025-03-23T06:07:18Z)

rpm -q kernel
kernel-6.13.5-100.fc40.x86_64

The suggestion that I found to remove the faulty version is:

sudo dnf remove kernel-<crashing version>
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

or can I just do:
rpm-ostree rollback

You may know, but those are backups from when your system was updated. They aren’t your usual hourly/daily backups like you would make with Pika or Vorta. The system software doesn’t change between updates, so there is no need to “backup” more often.

As for the cadence of releases/updates:
The release cycle for gts is slower than others.
I’m using stable, and the update cycle is usually once per week.
I believe latest has the fastest cycle, and can be daily.

These are related to the Fedora release cycle.

latest > stable > gts

More nuance can be found here

ps: There is an LTS release in the works, which is based on CentOS.

2 Likes