Can't boot into Fedora

Today I tried to boot into Fedora as usual (it worked perfectly fine yesterday). However, it didn’t boot and an error message told me that a component (I can’t remember which) failed (it was a KDE error message). My computer froze so I had to manually reboot. After that, I tried to boot again, but this time it didn’t boot. Instead, Fedora gives me the following error:

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.

After that, there’s another message (in Spanish, my system language) that says that I can’t access console because the root account is locked, and tells me to read sulogin(8) (I read it but found nothing that could be interesting).

After pressing enter, Fedora tries to load again, but still throws the same message. I have tried to launch from the rescue option at boot and happens the same.

On one of the reboots, I pressed ESC and found the following message between the different checks(?):

[FAILED] Failed to start File System Check on /dev/mapper/fedora-home. See ‘systemctl status “systemd-fsck@dev-mapper-fedora\x2dhome.service”’ for details
[DEPEND] Dependency failed for /home
[DEPEND] Dependency failed for Local File System
[DEPEND] Dependency failed for Mark the need to relabel after reboot

After that some checks are OK and then the first message appears. I don’t know if this could be related.

Any suggestions? Thanks in advice.

1 Like

Hello @emmaforner! Welcome to the community! Please do take a few minutes to go over the introductory posts in #start-here when you have the time. They contain lots of useful information.

I would try to boot into one of the previous kernels – just to be sure the issue isn’t with new kernel we’ve got recently. If you get the same behavior regardless of the kernel you choose, then this

can point to troubles with one of your filesystems. As far as I remember, you should be able to do it from emergency mode.

The command should be this:

fsck.ext4 -vf /dev/mapper/fedora-home

Look for any clues in the output. It would also bee good to check fedora-root in the same manner.

If you can’t do it from the emergency shell, then you can do test from Fedora Live usb. You may need to enter one additional command to be able to “see” your root and home partitions:

sudo vgchange --activate a

(note a at the end of the command. It stands for “automatically” or “all”).

Also it’s useful to see if you can access your files from Fedora Live USB, and it’s prudent to try to copy at least most important of them to flash or usb drive if you have suspicion about your filesystem.

Please also check this article for things you can do in Emergency shell:

3 Likes

Thank you! I’m not exactly new to Fedora but I’ll make sure to go over there and the emergency shell article.

Alright, so first of all, I solved the problem (thank you a lot!), but I’ll go over everything in case someone else ever is in this situation:

Tried that, both older versions of the kernel did the same.

As I said, I wasn’t able to use the console on emergency mode, so I got into a live session and used the “vgchange” command like you suggested and after that the fsck on both home and root.

Looks like the problem was on the home partition, but the program was able to fix everything automatically. The root partition didn’t had any problem.

I could perfectly mount and access all my partitions from the live session, so I wasn’t too worried about losing files.

After that, I rebooted and was able to boot into the OS perfectly. I’m writing this from Fedora right now, and I haven’t had any problem yet, however I’ll make sure to report anything if the problem seems to persist.

So like I said, thank you a lot @nightromantic for your help, it was definitely clear and on point! In case anyone is interested, the console log is:

Console log
[liveuser@localhost-live ~]$ su
[root@localhost-live liveuser]# vgchange --activate a
  3 logical volume(s) in volume group "fedora" now active
[root@localhost-live liveuser]# fsck.ext4 -vf /dev/mapper/fedora-home
e2fsck 1.44.6 (5-Mar-2019)
/dev/mapper/fedora-home is mounted.
e2fsck: Cannot continue, aborting.


[root@localhost-live liveuser]# fsck.ext4 -vf /dev/mapper/fedora-home
e2fsck 1.44.6 (5-Mar-2019)
Pass 1: Checking inodes, blocks, and sizes
Inode 1048691 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 1048695 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 1048696 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 1048697 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 1048698 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 1048699 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 1048700 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 4066678 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 4086327 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 4086644 extent tree (at level 1) could be narrower.  Optimize ('a' enables 'yes' to all) <y>? yes to all
Inodes that were part of a corrupted orphan linked list found.  Fix? yes

Inode 22807483 was part of the orphaned inode list.  FIXED.
Inode 22807506 was part of the orphaned inode list.  FIXED.
Deleted inode 22807551 has zero dtime.  Fix? yes

Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(3704644--3704671) -5282112
Fix? yes

Free blocks count wrong for group #113 (8410, counted=8438).
Fix? yes

Free blocks count wrong for group #161 (1329, counted=1330).
Fix? yes

Free blocks count wrong (51524276, counted=51524305).
Fix? yes

Inode bitmap differences:  -22807483 -22807506 -22807551
Fix? yes

Free inodes count wrong for group #2784 (6, counted=9).
Fix? yes

Free inodes count wrong (23755039, counted=23755042).
Fix? yes


/dev/mapper/fedora-home: ***** FILE SYSTEM WAS MODIFIED *****

      624350 inodes used (2.56%, out of 24379392)
        5297 non-contiguous files (0.8%)
         287 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 612345/1235
    45965615 blocks used (47.15%, out of 97489920)
           0 bad blocks
          10 large files

      559362 regular files
       53854 directories
           0 character device files
           0 block device files
           2 fifos
           0 links
       11122 symbolic links (10759 fast symbolic links)
           1 socket
------------
      624341 files
[root@localhost-live liveuser]# fsck.ext4 -vf /dev/mapper/fedora-root
e2fsck 1.44.6 (5-Mar-2019)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

      356083 inodes used (10.87%, out of 3276800)
         545 non-contiguous files (0.2%)
         356 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 328837/197
     5146903 blocks used (39.27%, out of 13107200)
           0 bad blocks
           1 large file

      289169 regular files
       33745 directories
           0 character device files
           0 block device files
           0 fifos
        9950 links
       33001 symbolic links (26882 fast symbolic links)
         159 sockets
------------
      366024 files
1 Like

Congratulations @emmaforner on successfully resolving your issue! Glad to help :slight_smile:
Have a nice day!

1 Like

Sorry, I sort of forgot about it – cause I’ve got absolutely no idea what to try to resolve that issue – though I did read what you’ve said about it. So I offered a few easy to try options, and it’s very good the problem was an easy one to solve.

But – knowing now that filesystem check helped you – actually problem with inaccessible console in emergency shell could be a more interesting of the two you’ve written about. If it’s reproducible – it can be trouble for anyone who needs emergency console.

Would you be willing to try and boot into emergency shell and test if you have access to console now, when problem with /home resolved?

@emmaforner, I’ve tested it myself, and got exactly the same result: if /home can’t be mounted during boot, then emergency shell can’t be used with message about root account being locked.

Maybe this has to be reported as a bug, or maybe it’s completely expected behavior – I don’t know.
I think we need another separate topic about it, maybe someone in the know will answer, is this a bug or not.

I’ll make such a topic later.

Sorry, for unrelated reasons I had to wipe my HDD and reinstall, so I’m not able to try again. I’m glad you could replicate it. If it’s an issue it definitely should be reported.

I’ve been told it’s a known problem (and easy to replicate one). I’ll try do do a small writeup when I have some time.

Edit: I’ve written about it in this topic: