Dnf system-upgrade fails to change anything

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

Have you downloaded them successfully with wget? I’ve tried to look up some mirrors for them, but couldn’t find any. I myself downloaded them successfully several times in the past – but that has more to do with the state of our respectful internet connections and server loads at the time of downloads than anything deterministic.

1 Like

Yes thanks, I did get a dl. I think that problem was that there was not enough disk space for the iso and FFx was giving up silently without showing what was going on. It looked like the server was not sending.

wget started OK and I checked disk space before it actually became a problem and made some room. I have not done the checksum yet and I’m a bit busy to try the live boot just now. Looks OK though.

1 Like

No that did not work out too well. The checksum verified, I dd’d it to a USB key and booted. It said "invalid isolinux.bin " and said it was booting from CD :? It then posted NVidia related msg and started doing DHCP hook-up. I’m guessing that was PXE boot attempts.

/isolinux/isolinux.bin is on the image if I mount it.

I’ll try another ISO but this looks like another day going down the toilet.

OK, more problems. Looks like my system does not want to boot of the key . I burned the image to CD and it boots fine. LXQT seems to run without obvious issues on the limited s/w that comes with the live image. This gives me enough confidence to run the upgrade if only the damned thing would actually complete.

@federic, I’ve tested dd’ing F30-LXQT-x86_64-LIVE-20191009.iso to usb drive and booting from it both is UEFI and BIOS/Legacy mode. It worked for me.

Which doesn’t help you much, I guess. :slight_smile:

Thanks, I was not thinking it was faulty iso image. It is probably some oddity with the BIOS on this laptop ( not using UEFI ). I don’t think h/w coverage is 100%.

I opened a bug on bugzilla about this but most bugs seems to die at hands of EOL robots in my experience.

I may have to do a fresh installation which will really piss me off. Having to redo all the installations and configurations I’ve done since F23 is going to be a pain.

I just recalled that I have an out of tree Geany build as well and the cross-debugger only works with qt4. That may be enough reason to at least keep this partition as a dual boot because that is something I need to retain.

1 Like