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.
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.
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?
@federic could you issue these commands? cat /etc/os-release
and cat /etc/redhat-release
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.
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 ).
File “/usr/lib/python3.7/site-packages/dnf/base.py”, line 136, in _add_repo_to_sack
File “/usr/lib/python3.7/site-packages/dnf/repo.py”, line 558, in load
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
It was not that I don’t believe you.
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).
@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.