Problems upgrading via terminal from F35 to F37

,

Hello everyone!

I used to have Fedora 34 and then i upgraded once to Fedora 35. After that, for reasons not relevant , didn’t upgrade to newer versions. That was until a couple of days ago, where i wanted to upgrade from 35 to 37.

There wasn’t any visual installation available in store for Fedora as other people seem to have it(big notification). The only thing i had was as if i was upgrading normally any other app out there. There was F35 and F37. So i downloaded F35(which is weird since i have F35 but i thought that this is a subversion i skipped in past). Rebooted, nothing happend. Downloaded F37. Rebooted, still on F35.

At this point i decided to look for a help online and i came across a certain tutorial saying that two versions upgrade will most likely work. So i ran this command, with 37 version instead of 36 version as shown in video(it was upgrade from 35 to 36
sudo dnf system-upgrade download --releasever=37

Anyways, after it was all done downloading and installing i got greeted by lots of errors in boot of fedora.

Here’s a picture of when i later tried to access rescue mode for grub:

Perhap you can’t see clearly everything, but i think the main problem is visible. A lot of things failed and i don’t why.

Well, in order to fix it i found like two solutions online which turned out to not work. After a long process of figuring out what i’m doing and chrooting and mounting and all of that stuff via live USB(which i’ve never done before) i think i have problem with .services which are either missing oe who knows.

In the mean time i chrooted into the system and updated it, config grub too, therefore loosing Windows 10 temporarily (i can get it back i know but that’s for later). It downloaded something about kernel but didn’t fix anything.

Anyhow, the only solution i can think of now is to reinstall linux, but the problem is i have a / and /boot/efi partition and i need to do it with f34(later plan to go to f37 of course) and it’s a windows 10 dual boot and i’m really confused by all of this.

If You think all of this is confusing or i didn’t explain something right, please don’t refrain from asking me to explain because this is definetly the biggest problem i’ve ever encounteres with Linux in generally so it’s a lot to process at my level of expertise.

Thank you!

You don’t mention if your F35 was fully updated before you attempted the upgrade to F37. Before upgrading to a newer version of Fedora it is important to update your current version to get

Quoting How to update Fedora by GUI and command-line ways

Note: Do not miss this procedure. System updates are essential to get signing keys for higher-versioned releases, and they frequently resolve upgrade-related issues.

Please avoid posting images of text screens. Images often cut off important details, quoting text from images requires extra OCR steps, and searches won’t find image text, so your post may not be seen by others searching for similar problems (including those who know how to recover from your situation!).

2 Likes

Downloading the ISO image does not in any way perform an upgrade. It merely downloads the installation image that can be used to boot and perform an install.

The link noted above gives a way to upgrade as does this official one from the fedora docs. Note the fedora doc shows how to do so using the gui as well as command line, but I definitely recommend using the command line method as the one I prefer.

Essentially from the command line it involves 3 steps.

  1. sudo dnf upgrade --refresh This step is critical to ensure that every thing needed to support the upgrade (including the keys for the newer release) are installed.
  2. sudo dnf system-upgrade download --releasever=XX where the XX is replaced by the version number the users wishes to upgrade to. You may need to install the dnf-plugin-system-upgradepackage before doing this.
  3. The final step to actually upgrade is running the command sudo dnf system-upgrade reboot. This command actually reboots and installs all the upgraded packages that were downloaded in step 2.
3 Likes

Hello. To be honest i don’t think it was fully upgraded now looking back at it. I ran a command to update, rebooted too with that specific command(when i find it later i’ll edit which one excatly) but there were some seemingly unimportant updates in the store for example for couple of games.

My question is: can i upgrade something and fix it now that i can’t boot directly but only via live image and chroot?

It appears that i have Fedora 37, it’s showing in grub but here’s an interesting thing. In grub menu i used to have multiple Fedora version as well as recovery mode fedora(if that’s what’s called). Now trying to boot in any of these doesn’t work.

Thanks for the tip about images. I’ll edit the post detaily soon when i gather all relevant information. I think this picture shows some problems that aren’t relevant to the problem that i already fixed(i didn’t unmount a partition and therefore had a problem with whole different error until i finally unmounted it)

Hello. I did this excat procedure and got an error that i’m speaking of.

Can i repeat it again somehow from live(chrooted) to fix it or is it useless once the problem is there?

That would depend upon what the error is.
first do the chroot (booted into a live F37 image), then try cat /etc/system-release to see what the system thinks it actually is. Once we know that then the steps to move forward in the repair are easier to determine.

If it shows as Fedora 37 it is simpler, but if it still shows fedora 34 or 35 the steps will be much different.

Just to be clear, the errors you got previously are insignificant. The errors you receive right now are the ones that matter.

It is critical that you tell us exactly what you are seeing. Copy & paste into the post is the best method since we can see your commands and the results. When you paraphrase or generalize the response we are left guessing about the actual messages you see. Without the actual command in the post it may be difficult to guess what you were trying to do.

I just chrooted and the system release is 37.

I never mounted /boot partition, should i do it next time?

Errors i’m currently getting are black screen with white underscore in the top left corner and nothing else, but when the first problem occured it was this:

Failed to start thermald.service
Failed to start dbus-broker.service
Failed to start systemd-modules-load.service

Once you have done the chroot to the root partition then you should run mount -a in that environment to ensure all file systems are properly mounted before you do anything else.

Since /boot and /boot/efi are part of the system where your kernels are stored and MUST be mounted before you can do anything with grub, the kernel, or anything else related to recovering for boot then yes, mount everything.

Since you commented about the fact that the system release is 37, I am assuming that the cat /etc/system-release showed Fedora release 37 (Thirty Seven)
It is requested that you always, if possible, do a post of the command and results as preformatted text using the </> button. That would look like this

$ cat /etc/system-release
Fedora release 37 (Thirty Seven)

Once everything is mounted in that chroot environment then please run the following.
sudo dnf upgrade --refresh followed by sudo dnf distro-sync

After those commands complete then check to see exactly which kernels are installed with dnf list installed kernel

1 Like

I ran

sudo mount -a

And got nothing as a result.

I used this tutorial for chrooting(under classic method section), with the addition of

sudo mount /dev/sdaX /mnt/boot

sdX being my /boot/efi partition. I also changed their vdaX for my sdaX. The other thing i had to change was remove a symlink for stub-resolve.conf but i never put it back, is that a problem?

I also had to use this command as the one shown in tutorial didn’t work because of echo and sudo having a disagreement.

echo 'nameserver 1.1.1.1' | sudo tee /mnt/run/systemd/resolve/stub-resolv.conf

When i ran sudo dnf upgrade --refresh there were a couple of packages but they do not seem to be relevant to our problem(if they are i can list the too).

sudo dnf dystro-sync finished immediately.

dnf list installed kernel gave me three kernels:

kernel.x86_64 6.0.12-100.fc35 @updates
kernel.x86_64 6.1.8-200.fc37 @updates
kernel.x86_64 6.1.9-200.fc37 @updates

Hello.

Am not sure how relevant this information is but i ran this command

ls -a /etc/modules-load.d

In rescue mode. Rescue mode is in F34(as shown in grub menu). Anyhow, it showed it was empty. Same thing running it chrooted.

You would not see a result unless it errored; The command completes silently.
Did you run the mount command after doing that to see what was actually mounted.

That was wrong.
That command would have mounted what should have been at /mnt/boot/efi on /mnt/boot. Did you also mount the partition used for /boot on /mnt/boot?

If that is what was actually done then things may be even more messed up than they were initially.

Though it has been posted repeatedly I will go over the entire process to do a cleanup from a failed upgrade.

  1. boot from the live image and open a terminal
  2. run the command lsblk -f which should show all the partitions on the usb drive as well as on the main system drive. It should also show the UUIDs and file system type for each partition.
  3. gain root permissions with su
  4. Select the partition you have as the / partitions and mount it at /mnt.
    for an ext4 partition mount /sdaX /mnt will recognize the file system and mount it.
    for a btrfs partition/subvolume with the standard fedora options use mount -t btrfs -o subvol=root,compress=zstd:1 UUID=XXXXX /mnt where the XXXXX is replaced with the UUID given in the earlier lsblk command.
  5. mount the extra but necessary file systems. (all are virtual file systems)
    for dir in proc sys run dev ; do mount --bind /$dir /mnt/$dir ; done
    Note that by mounting the /run filesystem in this manner you do not need to modify the /mnt/run/systemd/resolve/stub-resolv.conf file as you stated above and as shown in the linked instructions. Name resolution should be exactly the same as if you had booted directly.
    Removing the symlink /etc/resolv.conf is problematic. It must be in place for name services to function normally. /etc/resolve.conf --> /run/systemd/resolve/stub-resolv.confIf you removed that link then please restore it after doing the chroot in step 6.
  6. now chroot to /mnt chroot /mnt
  7. mount all the normal file systems in the chroot environment. mount -a
  8. Verify that everything is properly mounted with mount to display all mounted file systems in this chroot environment. The result should look very similar to the result from your normally running system. You should see /, /home, /boot, /boot/efi, /proc, /sys, /run, /dev, and anything else you normally have mounted.
  9. Now you can do all the needed recovery steps as if you had booted directly to the system.

Commands such as dnf upgrade --refresh, dnf distro-sync and anything else you would normally do when booted directly to the system should work normally.

After you get to this step and it seems everything has worked but you still cannot boot directly, please tell us exactly what you see on the screen when trying to boot. Those messages will be critical to analyzing remaining problems.

2 Likes

My whole /dev/sdaX partition is a /boot/efi. Does that mean i should mount it to /mnt/boot/efi?

When i run that command

for dir in proc sys run dev ; do mount --bind $dir /mnt/$dir ; done

I get errors:

mount: /mnt/proc: special device proc does not exist

And same for sys run dev

This tells me you may not properly have the root filesystem mounted on /mnt. The root file system will have mount points for those devices and that mount command must be done before you chroot to the /mnt environment.

My steps must be done in sequence, and you must verify that the proper file system is mounted at /mnt before you continue. This can be done by first mounting the file system at /mnt then running ls / and ls /mnt The results should look very similar.

I also made one small typo in that command I posted above which I have edited so it now reads.
for dir in proc sys run dev ; do mount --bind /$dir /mnt/$dir ; done
The change should solve this error

I ran this for loop like this

for dir in proc sys run dev ; do mount

Then pressed enter and when the > sign showed i typed the rest

--bind /$dir /mnt/$dir ; done

I got a wall of a lot of things but the problem is there was this text at the end of couple of texts(seems it looped it a couple of times)

bash: --bind: command not found...

It wasn’t supposed to be typed like that, was it?

Edit:

I just wrote it in one line and did ls /mnt and everything seems to be there

Comparing ls / and ls /mnt the onyl difference is that /mnt has additional afs directory and snap which is in red, marked in some kind of dark color.

Is that okay? Should i proceed to the next step?

I just did everything mentioned above, and to my understanding everything worked well. What’s interesting is that in the upgrades i got this package

intel-media-driver

Hopefully that fixes something. However, i still have these three kernels i mentioned above.

I won’t be leaving chroot soon tho, because i’m not sure how to umount all of this. When i find out, I’ll see if boot works or not.

How do i unmount all of this? Could I run a loop of some sort to make it easier?

Did you do the mount command from step 8 to verify all needed file systems are mounted as I indicated there?

If not then do so and if it is all mounted properly then you can proceed with step 9.
If not all is mounted then go back to step 7. If the 4 virtual file systems (/proc, /run, /sys, & /dev) are not properly mounted you will need to exit the chroot and run mount in the live terminal to see what is actually mounted in /mnt before continuing.

The command errored when you put it on two lines because it broke the single line command that way. I showed it as one line and it must be done as one line (although it could be broken into different lines at the ;, but only there.)

As I indicated, you can proceed with the 2 dnf commands I gave and see if they complete properly. Let us know the results

Not needed. When you exit the chroot and/or reboot the system will unmount things for you.

To be honest, I don’t know what i should get when i go mount.

Currently, / seems to be mounted as well as
/proc /sys /run /dev /boot/efi
(I don’t see how /boot is supposed to be mounted if i have my /boot/efi in /dev/sdaX partition, so i don’t see /boot anywhere)

And live media is also mounted. From all of this it looks like it’s mounted well, right?

Well, I just rebooted and everything is the same as before.

Grub loads in. I press enter on OS i want. Fedora start loading. Then it just stops at black screen with white underscore in top left corner and stays that way.