No login screen after internet disconnect during upgrade to f43 (Solved: upgrade went awry but fixed with 'sudo dnf distro-sync' and proper params)

Ask Fedora
1

Issue was solved with the use of ‘sudo dnf distro-sync’. See response from Vladislav below with link to the solution that worked for me.

Issue
I have never posted to a forum before, and I’m kind of a Linux newbie. I’m not even sure of what all the correct terms are, but I’ll do my best to describe my issue.

Last week (Wednesday) I was attempting to upgrade from Fedora 42 to 43 on my Dell XPS laptop (after backing up data, making sure Fedora 42 was up-to-date, and downloading Fedora 43). I used the graphical software updater tool to perform the update as well as the download and upgrade.

After launching the upgrade and while the progress bar was crawling across the screen, thinking that I didn’t need internet connection anymore (since I had downloaded the upgrade) and wanting to move to a different room, I unplugged the wired internet connection from my computer. After a little bit, the progress bar stopped moving after getting to about 70%, and after a while my computer rebooted. I don’t remember what was displayed on the screen after the progress bar stopped updating and before the reboot (wasn’t paying real close attention because I didn’t expect any issues). After the reboot, all I saw on the screen was a black screen with what looked to be a cursor at the top of the screen. It just hung there, forever.

I am able to get a shell login by hitting Ctl-Alt-F3.

My first thought: Did I break the upgrade by unplugging from the internet? I haven’t been able to find an answer. If so, is there a way to rollback to my last good install? If there was (the immediate previous version), I think I might have clobbered it when I tried a refresh, because the second Fedora listed in my boot list (6.18.4-100) doesn’t boot into a graphical interface either. The only other version listed in the boot menu is a rescue version 34. Does the system save any older versions besides the immediately previous one?

I researched the issue fairly extensively but no solution has worked for me:

  1. My computer does have an Nvidia graphics card, but adding “nomodeset” to the boot parameters did not allow the boot process to complete.
  2. I did had wine installed that I wasn’t using (because it did not provide what I needed), so I uninstalled wine.
  3. I checked the authselect setting, and it returned useful data (not failed).
  4. Using “sudo dnf” commands, I tried refresh, download, and install, and it tells me some f43 packages are already installed and also says “Problem: the operation would result in removing the following protected packages NetworkManager, gnome-shell, grub2-tools-minimal, selinux-policy-targeted, setup, systemd, systemd-udev.

I collected a bunch of data from my computer using the shell login, text files containing the:

  1. journalctl entries from the failed upgrade
  2. journalctl entries from one (of many) failed boot
  3. journalctl entries listing all the boots around the time of the failed install
  4. Output from “authselect current”
  5. Output from “cat /etc/fedora/release”. (Reports 43)
  6. Output from “df -h” (shows /boot directory is 974M and 50% used)
  7. Output from “lsblk-f”
  8. Output from “dnf list —installed” (shows a weird mix of fc42 and fc43 files)
  9. Output from “dnf list —installed kernel” (shows 3 entries, including two fc42 updates and one fc43 )
  10. Similar file to above with lines containing kernel-tools (can’t remember what command I used to generate this)
  11. List of failed services (systemd-update-utmp-runlevel.service, loaded but failed ACTIVE and failed SUB)
  12. Output of ”systemctl status systemd-update-utmp-runlevel.service”
  13. Output of “hostnamectl”
  14. Output of the repo file contents
  15. Output of “uname -r” (reports 6.18.5-100.fc42.x86_64)

I also have a file I called systemctl_default_target.txt that I can’t remember how I generated it that looks like it shows some info about systemd settings.

I also some literal screen shots (taken using my iPad) showing some of the red lines during the boot process (including some kind of dump) as well as a couple of commands I couldn’t figure out how to redirect the output (I only know > and tee).

Can someone please help me fix my issue or at least point me in a direction to help diagnose/fix my issue? I’m really hoping to avoid the pain of a fresh install.

I’m in a tough spot, though, because I can’t figure out how to upload any of the data I collected (if it or other data is needed). My laptop is my only “modern” computer. I have a very old desktop that is Windows 7 and CentOS dual boot that I stopped using (and updating) in mid-2021 when I bought my laptop. I’ve been using my iPad and the CentOS computer for researching this issue, but the CentOS doesn’t have a browser compatible with this forum. The iPad can’t do anything with any of the data, but I am using the iPad to enter this question to the forum.

This is really another subject, but I wouldn’t need it if I didn’t have the above issue…. To try and get a computer with a usable graphical interface, so I could upload these files to my question here on the forum (if needed), I tried creating a live Fedora 42 USB stick using my laptop and livecd-iso-to-disk, but it fails with the message “ATTENTION: A bootable kernel and initial RAM disk could not be found. Exiting….” I looked into how to solve THAT, but I couldn’t figure that out either.

Thank you so much to anyone that can help me troubleshoot and/or fix my issue!

2

try

sudo dnf update --allowerasing

from the new tty

3

Do you have EPEL repo installed? You should be able to get Firefox

4

Thanks for your reply! Firefox is installed on my CentOS 7 desktop, but it’s super old (mid-2021), and I read that CentOS 7 is end of life. I assumed there was no way to get a current compatible browser on that computer, although I did not try an update of the browser. I guess I’m not sure how to answer your question about EPEL. Can you please let me know how to check that? Thanks!

5

Thanks for the suggestion! Item #4 in my list of research/fix steps described in the original issue was that I tried a ‘sudo dnf’ refresh, download, upgrade. I used only --releasever=43 and --allowerasing, but it failed with a problem regarding protected packages and exited. (This was updated to clarify - my original reply was VERY unclear.)

6

Ah yes, CentOS 7 is very EOL. You might be able to install Firefox from a .rpm

7

You could try to download an ISO, and flash it to a USB drive, from the command line:

curl https://download.fedoraproject.org/pub/fedora/linux/releases/43/Workstation/x86_64/iso/Fedora-Workstation-Live-43-1.6.x86_64.iso -o ~/f43.iso

dd if=~/f43.iso of=/dev/sdz status="progress" conv="fsync"

where you replace /dev/sdz in the second command with your actual USB device. (Check and double-check using lsblk that you have the right one.)

8

Repos seem to all be out of date after upgrading to 43 - #4 by vgaetera

1 Like
9

I recently had a similar problem when updating from 42 to 43, but did not involve the internet and was updating using dnf. The dnf offline reboot stage got to the final reboot and failed to bring up the graphical login screen. The main thing noted (I have the rhgb quiet options removed from the kernel command line by default) was that the failure on boot was an inability to set context on all of the /dev/tty devices – an apparent selinux issue.

To recover I followed several steps after booting to the live media where I opened a terminal then used su to obtain root access which was needed for all the following.

  1. mounted the root file system on /mnt
  2. bind mounted /proc /sys /run, /dev, and /sys/firmware/efi/efivars onto /mnt
  3. chrooted into /mnt where I then ran ‘mount -a’ to mount all the remaining file system as they would be with a normal boot.
  4. I then used dnf distro-sync --releasever=43 which upgraded several packages that had apparently been missed by the update failure.
  5. Used dnf reinstall kernel* to ensure the kernel was properly upgraded
  6. Used akmods --rebuild --force --kernels 6.18.6-200.fc43.x86_64 to rebuld the nvidia drivers
  7. Some of the errors shown when failing to boot had shown selinux errors so I tried sudo dnf reinstall \*selinux\* and several packages failed to complete the scripts because of running in chroot.
  8. Added the file to force autorelabeling on the next boot touch /.autorelabel
  9. set the kernel command line to disable selinux when booting. grubby --update-kernel=ALL --args='selinux=0'
  10. exited the chroot and rebooted, which then was successful

The relabeling at boot was not performed since selinux was totally disabled.

Then after logging back in I performed the update of all selinux packages properly. sudo dnf reinstall \*selinux\* which completed properly.
I finally re-enabled selinux with sudo grubby --update-kernel=ALL --remove-args=selinux then rebooted again.

This time the autorelabel was performed and the system was back to normal

Note that there were several trial and error reboots involved in the recovery steps listed so it was not an entirely straight-forward progress.

While all the above steps are probably not required for your recovery my hope is that it gives enough guidance and ideas for you to be able to recover without a full reinstall.

10

Thank you so much Vladislav!! This worked, and I am now typing this on my working(!) laptop, which I’ve been without for a week…

3 Likes
11

Thank you for your reply Jeff! Vladislav’s recommendation worked for me. I will update my original post to note the fix.