Dnf system-upgrade fails to change anything

Does this command say something like the packages have been dowloaded and you can reboot the system?

2 Likes

Yes, all packages are downloaded, it does all the “checking transaction stuff” and invites me to run the reboot command.

Then you issue the sudo dnf system-upgrade reboot command. And what happens? Do you see the progress status, and if you hit Esc, are you able to see the packages upgrade process?

If I said I did not see any errors and did not get the “this may take some time …” message , I’m clearly not looking a blank screen with the F in the middle. I also said I have been using Fedora since fed23 and this is not my first upgrade, so please skip the noob questions, if you have any helpful input that would be most welcome.

Clearly it has not done the package upgrades at all.

@federic, welcome to the Ask Fedora!

You may be bitten by this known Fedora 30 bug. Please check it, and if you’re unsure how to proceed – please ask for clarification here.

I don’t think you are a noob. Absolutely.
You know, it is difficult to diagnose problems without seeing what is happening. In addition my English is not so good, and I always fear to don’t understand what I read. So I need clarifications.

And what do you see? The black screen with the filling F in the middle is the normal F29 boot, isn’t is?
When the upgrade process start you should see this screen.


You don’t reach this stage, right?

This means that he performed the upgrade “successfully” the first time. This could explain why the 3 following times he doesn’t see the “this may take some time …”: because he already is on F30, could it be? :thinking:

@federic could you issue these commands?
cat /etc/os-release
and
cat /etc/redhat-release

3 Likes

Exactly, the symptoms match – although we need additional verification, of course. We had a couple f similar cases here, one looked like known bug exactly, second was something a bit different but with similar symptoms. In both cases reinstalling grub from Live USB session helped – as known bug info suggests to do.


man dnf.plugin.system-upgrade suggests to look at dnf system-upgrade log and/or /var/log/dnf.log. You could? should? also see some logs using journalctl – although I can’t find clear indication for how to distinguish upgrade attempt’s logs – and have nowhere to experiment or check myself.

1 Like

Thanks for reminding me about the grub mess.

This should not affect legacy BIOS installations since Fedora 21.

since I installed at Fed23 this should not matter. However, I did have some grub issues last time and did run grub2-configure. I recall being on a bug report on this and it looked like a complete mess with no credible fixes.

When the upgrade process start you should see this screen.

Exactly, and I have stated several times that I did not see that and it booted directly without the half hour or so for updates ( I know the difference between 1m boot and 30 minutes update ).

Just in case you still don’t believe me:

cat /etc/redhat-release
Fedora release 29 (Twenty Nine)

I suspect it could be grub is failing and this is not being signalled. Since it does not reboot to Fed30 kernel the update silently skips and it boots to 29.

However, I did get a kernel update just a day ago when I did dnf update. This is now in place so grub seems to updating OK
5.2.18-100.fc29.x86_64

Having also seen qt5 fails to work with legacy NVidia cards, I may need to hold off anyway or else I’ll have a totally borked system. I need to check that with a live iso boot.

Can someone clarify when the F30 kernel pkg gets installed ? Should I see F30 kernel directly on rebooting with :
dnf system-upgrade reboot

File “/usr/lib/python3.7/site-packages/dnf/base.py”, line 136, in _add_repo_to_sack
repo.load()
File “/usr/lib/python3.7/site-packages/dnf/repo.py”, line 558, in load
raise dnf.exceptions.RepoError(str(e))
dnf.exceptions.RepoError: Failed to synchronize cache for repo ‘fedora-modular’
2019-10-10T02:31:48Z CRITICAL Error: Failed to synchronize cache for repo ‘fedora-modular’
2019-10-10T03:31:58Z INFO — logging initialized —

That looks like what I was looking for , many thanks. Now to work out what this is all about. I did notice that in the package update info and it looked new. I wondered what it was about.

maven-resolver-util noarch 1:1.1.1-2.module_f28+3939+dc18cd75 fedora-modular 147 k
maven-shared-utils noarch 3.2.1-0.1.module_f28+3939+dc18cd75 fedora-modular 164 k
maven-wagon-file noarch 3.1.0-1.module_f28+3939+dc18cd75 fedora-modular 25 k
maven-wagon-http noarch 3.1.0-1.module_f28+3939+dc18cd75 fedora-modular 26 k
maven-wagon-http-shared noarch 3.1.0-1.module_f28+3939+dc18cd75 fedora-modular 48 k
maven-wagon-provider-api noarch 3.1.0-1.module_f28+3939+dc18cd75 fedora-modular 62 k
plexus-cipher noarch 1.7-14.module_f28+3939+dc18cd75 fedora-modular 28 k
plexus-classworlds noarch 2.5.2-9.module_f28+3939+dc18cd75 fedora-modular 64 k
plexus-interpolation noarch 1.22-9.module_f28+3939+dc18cd75 fedora-modular 78 k
regexp noarch 1:1.5-26.module_f28+3872+5b76729e fedora-modular 52 k
slf4j noarch 1.7.25-4.module_f28+3939+dc18cd75 fedora-modular 76 k
xml-commons-apis noarch 1.4.01-25.module_f28+3872+5b76729e fedora-modular 233 k
xz-java noarch 1.8-2.module_f28+3872+5b76729e fedora-modular 105 k
system-config-printer x86_64 1.5.11-18.fc30 updates 309 k

Can’t help with this. I don’t upgrade, I just reinstall new release – so I don’t know inner workings of upgrade process.


I think it still is prudent to reinstall grub manually – just to be safe – because of

This happens because the GRUB core and modules in legacy BIOS are never updated unless the grub2-install command is executed.

If GRUB has not been updated since Fedora 20 or earlier, it is recommended to execute the grub2-install command before doing a system upgrade.

Here’s a link with more details about reinstalling grub properly – if you’re using Legacy/BIOS boot.

It shouldn’t harm you in any way, and it can help, if


Regarding the error message – check this:

with one possible work-around:

If I disable the updates-modular repo everything goes normal.

And the longer thread it links to.

There were quite a number of problems with cache sync for fedora-modular earlier in the year, and this helped as a temporary measure (later it was resolver in libdnf update, if I remember correctly).

It was not that I don’t believe you. :pensive:
It was that if it was that you were facing the bug suggested by @nightromantic, I was expecting that you were on F30 and grub was still loading F29 kernel.
But this is not the case. The upgrade process did not took place (as you said, ok).

2 Likes

@federic, and by the way I second @alciregi. We can’t always magically see into the heart of the problem, there’s no telepaths/oracles here. The situation that’s quite clear to you – as the one facing it – sometimes can’t be as clear to us from your description. That’s quite normal.

Please don’t be harsh with people trying to help you, it can discourage people from taking their time to help.

It’s not a criticism, it’s more an appeal to you on my part.

Thanks, I quite understand your point but at some stage of having what you have clearly stated several times repeatedly put in to question can be a little irritating or even insulting. I did not intend to be “harsh” but felt the need to be a bit clearer with our friend that I meant what I had reported and he should accept it.

My general experience on such forums is that those who insist in this manner or demand lots of results and information are those who are not knowledgeable enough to help anyway. I would not wish to infer that that was the case here.

Many thanks for dnf.log tip. That was what I wanted from the outset. I’m not sure that this is as resolved as the bug report from May suggests. It was supposedly fixed in 10.1.2 and I’m now on 10.1.5

This can be, of course. There can be also some F29-specific regression, or some other external factors – such as bad/unresponsive mirrors – producing similar results.

Did you try one of the two workarounds suggested?


I’ve also personally heard from one of package maintainers, that it’s not very good to stay on previous release after new one is out for some time. He said that some of maintainers get lazy (a bit) and don’t update packages for previous releases. I don’t know if it’s true or not.

I have not yet since I need to find the time to make a live image and test whether qt5 is broken on my hardware. ( It may have been a spot of luck that this did not install already ).

I avoid new releases since there are always bugs and problems. I like to let the dust settle before upgrading. Since 29 is getting a bit old now I did want to update but I need to check qt5 issues.

I suggest to use a respin for it, not original Live ISO. It’s official and contains updated packages (unlike original ISO).

https://dl.fedoraproject.org/pub/alt/live-respins/

2 Likes

thanks, I had not heard of respins. I’m downloading that now.

You’re welcome!


those links are not working for me , they all fail. I got about 20% of one file earlier and it stalled, now nothing.

EDIT: seems like Firefox was not even trying any more. I used wget and it seems to be coming down fine.

sudo dnf system-upgrade log

https://paste.fedoraproject.org/

2 Likes