Stuck in Emergency Mode – Fedora 40 WS

Ask Fedora
, , ,
1

Greetings.

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

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

Press enter to continue.

This is what started to appear when booting when I edited the /etc/fstab file (which from what I researched on the subject is the main cause of this problem and others like it) when I followed a tutorial to automatically mount a disk (/dev/sda1), which I only use to store files. (Note: HDD 500gb in ext4). I had added a line similar to
UUID=???????????? /mnt/disksda1 ext4 defaults,uid=1000,gid=1000 0 2 .

When restarting, abnormally, the grub2 countdown started, with the selection of the different kernels (it only appeared when, for example, the first boot after a power outage with the PC turned on). When waiting for 3 seconds the system does not start, sometimes it shows the Fedora boot animation , sometimes it doesn’t, and the aforementioned message appears. I can not do anything.

Before researching, I had the (not so) good idea of starting a live system from a usb drive and deleting the line I had written in the /etc /fstab file; I barely remembered that I couldn’t do anything, since the main drive is formatted in btrfs, the system files don’t appear like a normal ext4 installation.

I researched the problem a little and tried some processes, like, briefly: Open grub, enter the editor (letter e), look for where it says subvol = root and replace '= root ’ with ‘=@’; Ctrl+X ; use chroot /sysroot ; edit fstab file.

Honestly, I don’t know if this is the best approach, and that’s why I’m asking for help. Thanks in advance.

2

From Ask Fedora to Proposed Common Issues

3

Added boot, f40, grub, workstation

4

This line has an error unless you tested it before rebooting.

It should be something like this (from my own fstab file)
UUID=dfeb394f-2d5c-4ff4-a974-105d8551d0a4 <mount point> ext4 defaults,user,nofail,uid=1000,gid=1000 1 2

What I would suggest is to

  1. Verify the device can be mounted using sudo as
    sudo sh -c mount -t ext4 -o user,nofail,uid=1000,gid=1000 UUID=xxxx /mnt/disksda1` and verify that it mounts properly.
  2. then unmount it with sudo umount /mnt/disksda1
  3. following that then test the entry in fstab with sudo mount -a and verity that the device mounts properly.
  4. If, and only if, the device mounts properly in step 3 then reboot and it should mount correctly.

The nofail option is intended to prevent a hang during boot if the device fails to mount, and the user option is intended to allow the user to use the mount command and perform the mount without using sudo.

Note that the mount point (/mnt/disksda1) must exist before a device can be mounted there.

Personally I always create a directory that I intend to use as a mount point and set the ownership of that directory as I desire. I then attach the device (mount it) and use the chown command recursively to set it properly. Then my user has full access to that device and the file system
The commands involved would be something like
sudo mkdir /mnt/mntpnt
sudo chown USER:USER /mnt/mntpnt
sudo mount /dev/sda1 /mnt/mntpnt
sudo chown -R USER:USER /mnt/mntpnt

Following this the entry in /etc/fstab could be simplified to
UUID-xxx /mnt/mntpnt ext4 defaults,user,nofail 0 2
and the user would always have full access and ownership of the entire device.
I would leave in the nofail and user since I assume the device may be attached by usb and those options prevent a boot hang if the device is not attached as well as allowing the user to use the mount command for mounting the device…

1 Like
5

Thanks for the answer.

A user from another forum helped me mount my system’s main partition on a system in live mode, specifying the subvolume of the btrfs partition, managing to access /etc/fstab and delete the line I had previously entered. The system starts by opening GDM normally. However, when I try to log in, the screen goes momentarily black, as usual, but instead of starting gnome, it goes back to gdm. Do you know what could have happened?

Thank you again for your tips and I will take them into consideration when I have the system fully functional.

6

I noted one other thing that may have been related.

An ext4 file system is a linux file system and has linux native ownership and access permissions. Trying to force ownership with the uid and gid options in fstab quite probably caused the error in mounting.
When mounting a non-linux file system such as ntfs or fat32 the uid & gid options are quite appropriate to force ownership. When mounting a linux file system that already has the ownership and permissions specified those options are not an appropriate approach to management of file systems.

7

From Proposed Common Issues to Ask Fedora