F38 Stuck on Blinking Cursor, Black Screen

Hello all, I’ve been troubleshooting this for hours, and I’ve gotten nowhere.

It all started when I was trying to change permissions for /home/public so plex could see media files I have stored. My PC got slow, and frozen, so I restarted it. When I booted it back up, it didn’t get past a black screen with a blinking cursor. I’m not even able to boot into the rescue image. I AM able to boot into text mode where I am prompted with a login, but when I enter my credentials, I am told they are wrong. I cannot get any further than this.

Though I can boot into a live environment, I don’t know how to reinstall without wiping the home folder. I need to keep the home folder, since I have 1.6TB of data there.

I am not using a GPU, I have an old intel processor.

I have googled my issue, and have read many many other discussions, but none of them are useful.

I would suggest that you first edit the fstab under the installed root partition and do not mount the home partition. At the same time make sure you are able to log in with text mode as root, which also means you would need to do a chroot and give the root user a password so it allows root login (if not already done).

To do a successful chroot you would need to mount the installed /, then bind mount /sys, /proc, /dev, and /run from the live environment into same locations under the mount point for /.

Once able to log in directly as root then you could work on fixing the problems on /home without needing to use the live image to boot.

I have another obligation in just a few minutes so cannot work with this for a time, but will check back when I return.

The only issue is, both / and /home are on the same partition- their UUID’s are the same when I look at them in fstab.

Did I mess up?

Thank you for your response.

Please do not use vulgar language. It is against the rules here.

You should have separate lines for mounting / and /home. Simply comment out the line for /home with a # at the beginning of that line.

Sorry about that, won’t happen again.

I’ve commented out the /home line in fstab. Only thing is, since I’m not too experienced with mounting drives under these circumstances. Could you explain to me what you meant by this?

To do a successful chroot you would need to mount the installed /, then bind mount /sys, /proc, /dev, and /run from the live environment into same locations under the mount point for /.

I’m not sure what commands I’d need to run.

You can edit your earlier post and fix the problem so it may be seen by others.

if you were able to edit the /etc/fstab how did you do that? Was it for the live media or was it on the installed root file system? Your post above said you were able to boot into text mode but could not log in. If you were able to edit /etc/fstab on the installed system then you now should be able to boot to text mode and log in as root which would allow fixing the problem.

I need to understand just how experienced you are and what the system access is before a plan to proceed may be formed.

Okay, news, I’ve managed to reset my root password & log in via text mode. I’ll answer the questions you had anyway

  1. I’ve edited fstab for the installed system via the live environment. I navigated to the file via nautilus.
  2. I don’t believe I could log in through text mode because I could access the filesystem of the installed system via live env. I didn’t need to enter a password to access the installed filesystem. It only asked me to “authenticate.” Unless I’m misunderstanding, I believe there was a disconnect.
  3. I asked a friend of mine who’s very experienced with Linux for help, and he instructed me on how to bypass selinux to reset my password for root. I’ve just been able to log in as root.

I’m a novice in Linux. I’m familiar with normal user things; Installing packages, updating, CLI, using Google etc.
As far as system access goes, what would you like to know? I do have physical access to the machine if that’s what you’re asking for.

(Deleted my last post and made this one since the last one wasn’t made in reply to your post)

Ok, then we now need to know if you are able to properly mount the original /home partition.

When booted normally and logged in as root then edit /etc/fstab and remove the # sign I asked you to put at the beginning of the line to mount /home. Then run mount -a and tell me the result.

If it mounts then good, if not then I need info as to why it did not so the failure can be fixed.

Removed #, did mount -a, didn’t get an output so I ran the df command, and /dev/sda3 mounted on /home showed up!

Ok, does a normal reboot work now?

It does not, no. It’s stuck at “booting a command list” with the same blinking cursor below it.

I normally only see that after using the grub menu and selecting to edit something within the grub command list before continuing to boot. What are the steps followed just prior to seeing this message.?

That was user error, sorry about that. I didn’t realize that pressing E would change the way it boots from grub. I tried booting to Fedora again without pressing E, and It’s on the same screen. Same blinking cursor.

Can you get a text console with <Ctrl-Alt 3) from the blinking cursor screen? Now that you found Grub edit mode you can edit the kernel command line to remove the rhgb quiet. This will allow you to see messages when the system is booting. On older systems they may go by slowly enough so you can read them.

This sounds like a hardware failure, and may have nothing to do with permissions. You can boot from the Live USB and use Gnome Disks to check S.M.A.R.T health of the system disk. If you have important data you could use the Live boot to copy it to a USB drive.

  1. I cannot get to a console using Ctrl-alt-F3. It clearly affects the cursor, but other than that, there is no change on the screen.

  2. I removed rhgb quiet, and there are lots of “failed” statuses. They move too quickly for me to read them, but here are the few that I can read:

  • dbus-broker.service
  • power-profiles-daemon.service

It appears that these two try to start back up, but constantly fail. There is an additional service that fails, the plexmediaserver.service. Which is what I was messing around with before all of this.

Most notably, everything stops after

Starting virtqemud.service
Starting plymouth-quit-wait.service
Starting plymouth-quit.service

These are the only 3 services that don’t have any lines that say that they failed, started, or are trying to restart.

  1. I’m running this system off of a 4TB HDD that I bought new a month or so ago. I’ve heard that there are issues with my particular machine, and drives over 2TB. I have an old Dell Optiplex 980. Getting my server set back up through a USB would be an incredible feat, so I don’t believe it’s possible.

So USB-2. Until the video card failed a year ago (BIOS beep code, no video) my daily driver was a Dell Vostro early Core i7 with USB-2 that worked well with Fedora and could boot from USB keys.

You mention booting a live environment. USB is more convenient, but optical media or eSATA should also support booting a live system so you can try to get S.M.A.R.T drive health. There are other disk test utilities that should tell you if there is an issue with your large drive.

Booted live env from USB stick, ran an extensive drive health check, all said it was fine.

Since the disk is healthy, we can proceed with troubleshooting (but still important to have a backup of important files before proceeding).

We need get more details of the failures using journalctl. Quoting from Linux command-line mode (uses Ubuntu as an example, but should work with Fedora):

when the GUI fails or has problems and cannot complete startup, we can use the command-line mode to troubleshoot

You may want to explore options to journalctl using a terminal in the live environment before booting to command-line mode. Useful options include:

       -b [[ID][±offset]|all], --boot[=[ID][±offset]|all]
           Show messages from a specific boot. This will add a match for "_BOOT_ID=".

           The argument may be empty, in which case logs for the current boot will be shown.

           If the boot ID is omitted, a positive offset will look up the boots starting from the beginning of the journal, and an
           equal-or-less-than zero offset will look up boots starting from the end of the journal. Thus, 1 means the first boot
           found in the journal in chronological order, 2 the second and so on; while -0 is the last boot, -1 the boot before last,
           and so on. An empty offset is equivalent to specifying -0, except when the current boot is not the last boot (e.g.
           because --directory was specified to look at logs from a different machine).

           If the 32-character ID is specified, it may optionally be followed by offset which identifies the boot relative to the
           one given by boot ID. Negative values mean earlier boots and positive values mean later boots. If offset is not
           specified, a value of zero is assumed, and the logs for the boot given by ID are shown.

       -p, --priority=           Filter output by message priorities or priority ranges. Takes either a single numeric or textual log level (i.e. between
           0/"emerg" and 7/"debug"), or a range of numeric/text log levels in the form FROM..TO. The log levels are the usual syslog
           log levels as documented in syslog(3), i.e.  "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4),
           "notice" (5), "info" (6), "debug" (7). If a single log level is specified, all messages with this log level or a lower
           (hence more important) log level are shown. If a range is specified, all messages within the range are shown, including
           both the start and the end value of the range. This will add "PRIORITY=" matches for the specified priorities.

        -g, --grep=
          Filter output to entries where the MESSAGE= field matches the specified regular expression. PERL-compatible regular
           expressions are used, see pcre2pattern(3) for a detailed description of the syntax.

          If the pattern is all lowercase, matching is case insensitive. Otherwise, matching is 
case sensitive. This can be  overridden with the --case-sensitive option, see below.