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.

3 Likes

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:

4 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
4 Likes

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:

https://discussion.fedoraproject.org/t/howto-cannot-open-access-to-console-the-root-account-is-locked-in-emergency-mode-dracut-emergency-shell/2010

My laptop with Fedora 26 (in dual boot with Ubuntu 16.04) suddenly froze and after doing a hard shutdown with power button, I started getting this error during boot and getting into emergency console with File System Check errors (as attached)

.

fsck.ext4 -vf /dev/mapper/fedora_<>-root did not help through the emergency shell.

Then I used LiveUSB (Fedora 25) and could mount the filesystems and backup some data after I did ‘vgchange --activate -a’, as suggested.

However, the boot problem did not get resolved.
Hence, I did ‘fsck.ext4 -cDfty -C 0 /dev/mapper/fedora_<>-root’ from LiveUSB terminal.

This version of fsck did claim to have fixed some problems, however I still can’t boot into Fedora KDE. Moreover, after this so-called repair by ‘fsck.ext4 -cDfty -C 0 …’ the affected LVM does not even show or mount in LiveUSB anymore. Further ‘vgchange --activate -a’ does not mount the LVM anymore. dmesg logs following error:
0x9 (media error)
[91788.984681] ata1.00: status: { DRDY ERR }
[91788.984683] ata1.00: error: { UNC }
[91788.984684] ata1.00: failed command: READ FPDMA QUEUED
[91788.984688] ata1.00: cmd 60/08:10:e8:46:92/00:00:13:00:00/40 tag 2
ncq dma 4096 in
res 41/40:70:90:45:92/00:00:13:00:00/40 Emask

I shall be immensely helped if anyone can help me restore my system as I have very critical configuration data in that laptop.

Thanks in advance.

The original problem was a filesystem error on the /home partition “/dev/mapper/fedora-home” that forces the system into emergency mode.
What you just posted was about fedora-root

With the live system booted you should be able to install the smartmontools package then use smartctl to test the drive.

What does “smartctl -a /dev/sdX” tell you about the drive in question? It is possible that failure of the hardware is the issue and you may need to run the “smartctl -t long -C /dev/sdX” to do a long test and confirm the status.

However, if the drive does not show up in either /dev/mapper/fedoraXXX or /dev/fedoraXXX when you boot from the liveUSB device then something is seriously wrong with the hardware and the smartmontools will do you no good.

@mountainlion, I think, it’s better to open a new thread for your problem. Although it has some similarity with the one @emmaforner posted above, the reasons in your case are different, and mashing two problems together will confuse both people who want to help you and other people looking for help with something similar.


Aside from that to add to @computersavvy’s answer,

As far as I know such messages mean a hardware issue with you disk drive. There’s some chance it’s a connection/cable issue – though seems unlikely from your description. One possible way to check it would be plugging the harddrive into another computer/notebook (using another data cable) and checking dmesg for similar messages there.

Depending on the construction of you notebook, taking out harddrive can be relatively easy or quite complicated thing to do.

If you see the same dmesg messages on other computer as well (and likely no your partitions in such a case) – then the fault is with the hardware of your drive itself. As far as I know there’s no easy fix for that.

In such a case you can try partial data recovery with tools like ddrescue and photorec for the data you haven’t been able to back up earlier. The best way to do it would be using another machine. If you have none available – this could be done using Live CD / USB and external drive.

If the other computer can access the drive without such dmesg messages – then just replugging the connectors on you notebook can help, or the change of data cable (later can be troublesome for notebook too).

1 Like

Thank you @nightromantic and @computersavvy for your valuable advice on this issue. I am yet to finish trying the smartctl device test on the fedora LVM. Will update the thread if I could get anything other than hardware failure for the benefit of the community.In the mean time a ray hope showed for me when I saw the Fedora LVM loading in Ubuntu LiveUSB as /dev/sda* and the Anaconda of Fedora 25 LiveUSB recognizes the /dev/mapper/fedora_-root as ‘Unknown’ filesystem. Hence, it might as well be a LVM corruption issue rather than a h/w issue at /dev/sda.

Also, with little bit more investigation I would be creating a new thread. I appended to this existing one as it seemed there were still open questions as to how and why this boot error occurs.

2 Likes

That is good information.
Please run the smartctl tests and enable the long test as previously noted while the drive is accessible in ubuntu. That should confirm if this is a filesystem or hardware error as well.
You can run fsck.ext4 (assuming you are using ext4 filesystems) on the lvm volumes while the drive is accessible as well. Doing that may well fix any filesystem corruption errors.

2 Likes