Re: dnf system-upgrade download + reboot does not finish upgrade.
moon's ago I read about / upgraded with one of the following commands: sudo dnf system-upgrade download --releasever=30 --setopt=module_platform_id=platform:f30 --allowerasing OR sudo dnf system-upgrade download --refresh --releasever=30 --setopt='module_platform_id=platform:f30' --allowerasing I don't remember which one and I don't know if it will help here ... ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: dnf system-upgrade download + reboot does not finish upgrade.
On 7/9/19 7:08 AM, Federic Ducon wrote:
Jul 09 01:10:55 localhost.localdomain audit[1]: AVC avc: denied { read } for pid=1
comm="systemd" name="dnf" dev="sda6" ino=1572867
scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:va$
This line shows up twice. Which filesystem is on /dev/sda6? Try
running "find / -xdev -inum 1572867" (replace / with whatever mount
point /dev/sda6 is on) to find out what file dnf is failing to access.
Are the downloaded rpm files still there or were they deleted?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: dnf system-upgrade download + reboot does not finish upgrade.
On 7/9/19 9:24 AM, Greg Woods wrote: At any rate, the first step is to check in /var/log/dnf.log and see if there is a traceback in there, which will usually point to what the problem is. In my case I was trying to go from F28 to F29, and ended up having to remove the "mediatomb" package (which I wasn't using anyway). This is what I found in the DNF log: depsolve errors should be detected at the end of the download process when it does testing. Specifically, I had this same issue with mediatomb and I had to add --allowerasing and then it worked fine. Side note: gerbera is the replacement for mediatomb For some reason the GPG key for Fedora 29 was never imported, so I did it manually, and finally everything worked. Again, something that should be done during the download process. I always get that requested at the end of the downloads before it does the checks. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: dnf system-upgrade download + reboot does not finish upgrade.
On Tue, Jul 9, 2019 at 8:09 AM Federic Ducon wrote:
> I am trying to upgrade from Fedora 29 to Fedora 30
>
> dnf system-upgrade download --refresh --releasever=30 --allowerasing
> dnf system-upgrade reboot
>
> The download stage completes and posts a msg proposing the second line.
>
> The reboot starts up , gets to a certain stage and automatically reboots.
> On rebooting I see the same fed29 kernel is used and it just boots
> normally to the old system.
>
I have had this happen. I've seen two things that can cause it (and there
are probably more but the fix is likely to be similar): a dependency issue,
and a failure for the GPG key for the target Fedora version to get loaded.
Dependency issues can result from a number of things, such as packaging
errors or use of packages from third party repos. The keys for the new
distro are *supposed* to be installed automatically, but sometimes it
doesn't happen.
At any rate, the first step is to check in /var/log/dnf.log and see if
there is a traceback in there, which will usually point to what the problem
is. In my case I was trying to go from F28 to F29, and ended up having to
remove the "mediatomb" package (which I wasn't using anyway). This is what
I found in the DNF log:
2019-06-28T13:30:48Z SUBDEBUG
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in
cli_run
ret = resolving(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 146, in
resolving
base.resolve(cli.demands.allow_erasing)
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 832, in resolve
raise exc
dnf.exceptions.DepsolveError:
Problem: package mediatomb-0.12.2-3.20160522.fc28.x86_64 requires
libixml.so.2()(64bit), but none of the providers can be installed
- libupnp-1.6.25-1.fc28.x86_64 does not belong to a distupgrade repository
- problem with installed package mediatomb-0.12.2-3.20160522.fc28.x86_64
2019-06-28T13:30:48Z CRITICAL Error:
Problem: package mediatomb-0.12.2-3.20160522.fc28.x86_64 requires
libixml.so.2()(64bit), but none of the providers can be installed
- libupnp-1.6.25-1.fc28.x86_64 does not belong to a distupgrade repository
- problem with installed package
mediatomb-0.12.2-3.20160522.fc28.x86_642019-06-28T13:30:48Z SUBDEBUG
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in
cli_run
ret = resolving(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 146, in
resolving
base.resolve(cli.demands.allow_erasing)
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 832, in resolve
raise exc
dnf.exceptions.DepsolveError:
Problem: package mediatomb-0.12.2-3.20160522.fc28.x86_64 requires
libixml.so.2()(64bit), but none of the providers can be installed
- libupnp-1.6.25-1.fc28.x86_64 does not belong to a distupgrade repository
- problem with installed package mediatomb-0.12.2-3.20160522.fc28.x86_64
2019-06-28T13:30:48Z CRITICAL Error:
Problem: package mediatomb-0.12.2-3.20160522.fc28.x86_64 requires
libixml.so.2()(64bit), but none of the providers can be installed
- libupnp-1.6.25-1.fc28.x86_64 does not belong to a distupgrade repository
- problem with installed package mediatomb-0.12.2-3.20160522.fc28.x86_64
I also had a similar problem with the "createrepo" package which I *do*
use, so in that case I just removed the package, did the upgrade, and
reinstalled it afterward.
For the GPG key issue I saw this:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in
cli_run
ret = resolving(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 154, in
resolving
base.do_transaction(display=displays)
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 231, in
do_transaction
self.gpgsigcheck(install_pkgs)
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 284, in
gpgsigcheck
raise dnf.exceptions.Error(_("GPG check FAILED"))
dnf.exceptions.Error: GPG check FAILED
2019-06-28T14:10:25Z CRITICAL Error: GPG check FAILED
For some reason the GPG key for Fedora 29 was never imported, so I did it
manually, and finally everything worked.
--Greg
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
dnf system-upgrade download + reboot does not finish upgrade.
I am trying to upgrade from Fedora 29 to Fedora 30
dnf system-upgrade download --refresh --releasever=30 --allowerasing
dnf system-upgrade reboot
The download stage completes and posts a msg proposing the second line.
The reboot starts up , gets to a certain stage and automatically reboots.
On rebooting I see the same fed29 kernel is used and it just boots normally to
the old system.
I would have expected something indicating that it was processing the update
with the usual message like "this may take some time".
journalctl --list-boots shows me one on 2019-07-08 which seems to be the
first reboot after the initial system-upgrade call. There are many reps after
that as I repeated trying to find the problem.
I expected to get output from this from its boot number , but the following
gives lines with datastamps earlier today.
journalctl -b -15
What do I need to get the boot log ?
TIA.
Here is a snip from one of the boot logs which appears to cover the point where
reaches the Offline Update. If someone can give explicit instructions to get a
better log I will try to submit it somewhere.
Jul 09 01:10:55 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=grub-boot-indeterminate comm="systemd" exe="/usr/lib/syst$
Jul 09 01:10:55 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=grub-boot-indeterminate comm="systemd" exe="/usr/lib/syste$
Jul 09 01:10:55 localhost.localdomain systemd[1]: Reached target Offline System
Update (Pre).
Jul 09 01:10:55 localhost.localdomain audit[1]: AVC avc: denied { read } for
pid=1 comm="systemd" name="dnf" dev="sda6" ino=1572867
scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:va$
Jul 09 01:10:55 localhost.localdomain systemd[1]: Starting Update the operating
system whilst offline...
Jul 09 01:10:55 localhost.localdomain pk-offline-update[648]: another framework
set up the trigger
Jul 09 01:10:55 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=packagekit-offline-update comm="systemd" exe="/usr/lib/sy$
Jul 09 01:10:55 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=packagekit-offline-update comm="systemd" exe="/usr/lib/sys$
Jul 09 01:10:55 localhost.localdomain audit[1]: AVC avc: denied { read } for
pid=1 comm="systemd" name="dnf" dev="sda6" ino=1572867
scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:va$
Jul 09 01:10:55 localhost.localdomain systemd[1]: Started Update the operating
system whilst offline.
Jul 09 01:10:55 localhost.localdomain systemd[1]: Reached target Offline System
Update.
Jul 09 01:10:55 localhost.localdomain systemd[1]: Starting Remove the Offline
System Updates symlink...
Jul 09 01:10:55 localhost.localdomain rm[649]: removed '/system-update'
Jul 09 01:10:55 localhost.localdomain systemd[1]: Started Remove the Offline
System Updates symlink.
Jul 09 01:10:55 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=system-update-cleanup comm="systemd" exe="/usr/lib/system$
Jul 09 01:10:55 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=system-update-cleanup comm="systemd" exe="/usr/lib/systemd$
Jul 09 01:10:55 localhost.localdomain systemd[1]: Startup finished in 1.354s
(kernel) + 8.443s (initrd) + 22.374s (userspace) = 32.172s.
Jul 09 01:10:55 localhost.localdomain systemd[1]: Rebooting: unit succeeded
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
