Fedora workstation rescue

My notebook computer has two internal hard drives. One boots to Windows 7, and the other boots to Fedora. I originally installed Fedora 23 three years ago, and I subsequently upgraded to Fedora 27. My computer works fine running Windows 7, and it used to work fine running Fedora 23 and Fedora 27.

Recently, both versions of Fedora failed to boot. When the boot window with the ‘f’ in the middle appears and the ‘f’ becomes completely visible, instead of presenting the login window, the boot process enters emergency mode. I do not know how to restore the boot procedure in emergency mode. If I repower my computer, I know how to boot to the grub prompt, but I do not know how to restore the boot procedure in this mode.

Online documentation (17.2 Booting into rescue mode) says that to do a rescue, I should boot to the same version, but I can’t find a source of Fedora 27 online. I can only find a source of Fedora 30. So I created a live image of Fedora 30 and booted to it. However, my Bluetooth mouse doesn’t work with Fedora 30, and when I open my computer to use the touch pad, Fedora 30 doesn’t work at all. As a result, Fedora 30 is inoperable on my computer. Note that I normally use my computer closed, employing an external monitor.

Here are my questions:

  1. Can I fix the boot procedure in emergency mode?
  2. Can I fix the boot procedure in grub mode?
  3. Is there a source of Fedora 27 so that I can make a live image of it?
  4. Is there a way to get Fedora 30 to run on my computer?

Welcome to Ask Fedora! Check out #start-here to learn your way around the community.

Fedora 27 hasn’t been supported for a very long time. Based on the fact that you upgraded to 27 from 23 (which also hasn’t been supported for a long time), I think an LTS distro (e.g. CentOS or RHEL Developer Edition) would better suit your workflow.

Some other things to note:

  • Did you do anything at all to the Fedora installs before they stopped working? Given that they both seemingly died at once, if you didn’t do anything to potentially trigger that, I’d be very concerned about the health of the hard drive they’re on.
  • What hardware do you have? Knowing the laptop model, GPU inside, and bluetooth mouse in particular would be incredibly helpful. It’s also interesting to me that both issues you mentioned seem are input-related… Also, does input on the USB work if you boot the laptop without the external monitor (i.e. start with it unplugged, instead of unplugging after boot)?
  • When you’re in emergency mode, you can run systemctl --failed to see a list of failed units, and journalctl -b -u THE-FAILED-UNIT -xe to see logs on why it may have failed.


Thank you for your reply! Here is more info in response to your suggestions.

I obtained Fedora 27 from the following link, created a live image, and booted to it.


My bluetooth mouse initially did not work, but when I opened my computer to use the touchpad, the computer continued working, and I was able to boot to the Fedora 27 live image.

This establishes that Fedora 30 has not been configured to work with my computer. My computer is a 2008 Dell XPS M1730, with an Nvidia GeForce 8700M GT video card. Can Fedora 30 be configured to work with this computer? I’m puzzled why they didn’t design Fedora 30 work with all of the computers that the earlier versions of Fedora worked with. Note that Fedora 30 has the same problem with or without the external monitor connected.

My hard drives are SSDs, only a few years old. The Fedora SSD was new 3 years ago, purchased for installing Fedora. I can access the Fedora SSD when booted to Windows; I can see the directory structure and files on the drive; and I can copy any given file to my Windows drive and open it. I located the file grub.cfg and opened it on my Windows drive. It is readable, and, as far as I can tell, it is fine.

I subsequently rebooted to the Fedora 27 live image, and at the option window I hit escape to get the grub prompt. I then typed “linux rescue”. No info was displayed, and I eventually rebooted to the Fedora drive. The boot now worked, and I was back in Fedora 27. I tried a few things, and they all worked fine. I was pleased! But I rebooted to verify that I could reboot, and on the reboot, Fedora went into emergency mode. I then booted to the live image and did the rescue again. But when I rebooted to the Fedora drive, the boot went into emergency mode. It has been this way ever since. Thus, linux rescue worked the first time but not subsequently.

Per your suggestion, in emergency mode, I typed “systemctl --failed” and got the following line:

<97> systemd-fsck-root.service loaded failed failed File system check on /dev/disk/by-uuid/…

Per your suggestion, I then typed “journalctl -b -u systemd-fsck-root.service -xe” and got the following lines:

systemd[1]: Starting file system check on /dev/disk/by-uuid/…
systemd-fsck[456]: [the label shown to the left appeared on the LHS of each of the remaining lines]
Root contains a file system with errors, check forced
Root inode 395679 has an invalid extent node (blk 1606927, lblk 0)
Root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY (i.e., without -a or -p option)
fsck failed with error code 4
Running request emergency.target/start/replace
systemd-fsck-root.service: Main process exited, code=exited, status=1/FAILURE
Failed to start file system check on /dev/disk/by-uuid/…
systemd-fsck-root.service: Unit entered failed state
systemd-fsck-root.service: Failed with result ‘exit code’

Do you understand the boot problem and how to fix it?
Do you understand why rescue worked the first time but not subsequently?

Ah, the filesystem check just failed. This can occasionally happen from e.g. a forced shutdown or such. A sudo fsck /dev/MY-PARTITION should walk you through fixing the issues. (Do that this can cause data integrity issues, but this error seems relatively minor and shouldn’t cause issues from being fixed.)

As for Fedora 30 not working, did you ever install the proprietary drivers? In general, what devices work or don’t work are heavily dependent on your kernel. For NVIDIA, the in-kernel driver, nouveau, is a best-effort, reverse-engineered driver that’s known to often break. You can try booting the installer with the “nomodeset” option to see if you get far enough to install the proprietary driver; if not, well, that’s what we’re here for :wink:.

That being said, I would highly advise against continuing to run Fedora 27. It would not be exaggeration to say that hundreds of security issues have been patched after F27 hit EOL, and continuing to use it can be rather dangerous and undesired (unless e.g. you’re running old OSs in an isolated VM for fun). In general, it’s always best to try to resolve the problem (and ask for help if needed), rather than staying on very old, insecure software to work around it.

1 Like

Regarding fsck, I booted to the Fedora live image, and in the terminal I typed “sudo fsck /root” since systemd-fsck said there were errors in the root file system. Here is the result:

fsck from util-linux 2.30.2
e2fsck 1.43.5 (04-Aug-2017)
fsck.ext2: Is a directory while trying to open /root

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
e2fsck -b 32768

Regarding Fedora 30, you say, “You can try booting the installer with the “nomodeset” option to see if you get far enough to install the proprietary driver.” How do I set this option in booting to the live image?

Regarding hundreds of security issues with Fedora 27, can you provide a link that explains what this is all about. Otherwise, can you cite a few?

Regarding entering boot options, I see that if I type tab at the boot menu, I can enter boot options. Thank you! I’ll try this, but first I must recreate a Fedora 30 live image.

In the terminal I ran “ls -l /dev/[sd]*”. I have sda, along with some sdaX, where X = a digit. Ditto for sdb. So I assume that I should run “sudo fsck /dev/sdY”, where sdY is the Fedora disk.

What terminal commands will reveal the identity of the sdY and the sdaX devices? I can distinguish the Fedora disk from the Windows disk by disconnecting the Windows disk, but I’m wondering if there are terminal commands to reveal this info.

This is not right.
It should be like this:

sudo umount /dev/mapper/fedora-root
sudo fsck.ext4 -f /dev/mapper/fedora-root
1 Like

I don’t have any links handy. Here’s one explaining Fedora release life cycle, but it’s more developer-centric and doesn’t really answer your question.

My understanding is this: as you can see for yourself, Fedora has rather rapid update cycle. Almost every day there are updates for some packages. Some of them are new upstream releases, some are bugfixes, some may contain security fixes.

Each Fedora release is supported for (approximately) 13 months. After that release is considered to reach its End of Life. This means that no updates for this release are done any more – even if there are known bugs and vulnerabilities in its packages. Updates for newer releases are done instead.

Fedora 27 has reached EOL at 2018-11-30. This means that at this moment it misses almost a full year of patches and new software. In general it’s not advisable to run older unpatched software as it may contain known bugs and vulnerabilities.


Fedora 27 rescue completion

I booted to the Fedora 27 live image, and in the terminal I executed lsblk. This lists the disk drives (sda, sdb, …) and for each disk drive, its partitions (sda1, sda2, …, sdb1, sdb2, …). The size of each partition is included, and I identified the drive labeled Root by looking for a partition with this size, which was sda3. I then executed fsck without unmounting: sudo fsck /dev/sda3. This reported the inode error on the partition, and it proceeded by reporting a series of errors, each with an option to fix it. I fixed them all and was then able to boot to the Fedora 27 hard drive.

1 Like

Well, you actually checked the consistence of the partition without mounting because the Live image does not mount anything by itself as far as I know. Therefore, you were able to perform that operation, since it would not be possible doing it on a mounted system.

If you think a filesystem check (fsck) would come handy during a boot, edit your /etc/fstab file and pay attention to the two numbers at the end of the line:

  • if there is a 0 (zero) then the partition will not be checked.
  • if there is a 1 (in case of a root partition) or 2 (in case of others), the partition will be fscked.

Doing this, you can avoid some problems, such as mounting a filesystem readonly and other fancy stuff, but you will pay with some prolonged boot time. The decision is yours.


@lruzicka, to clarify a bit, fsck is usually enabled by default for root filesystem, but sometimes this automatic check can’t complete for some reason and requires manual intervention.

There’s a good chance that’s exactly what happened with @phibit’s system.

@nightromantic, yeah you are right.

However, my intention was not to describe the solution to the problem, as the problem has been already solved, but I wanted to correct the statement that the fsck operation can be done without actually unmounting the affected partition. AFAIK it cannot and attempting that would fail, so some less experienced users might get confused.

I only added the fstab thing to make the matter even more complete.

Anyway, thanks for clarifying.

1 Like