Bug 1498207
Summary: | DNF crash during upgrade installation F26 -> F27 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Couret Charles-Antoine <renault> | ||||||||||||||
Component: | libdnf | Assignee: | Jaroslav Mracek <jmracek> | ||||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
Severity: | high | Docs Contact: | |||||||||||||||
Priority: | unspecified | ||||||||||||||||
Version: | 26 | CC: | alick9188, awilliam, barnsls, bkabrda, brad.inch, carwyn, cstratak, decathorpe, dmach, dominik, dowdle, extras-orphan, ezwen-redhatbugzilla, fedora, felix, filbar, gilwooden, gtwilliams, hp, hugotrip, ignatenko, ishcherb, jmracek, jorti, kartochka378, kparal, lizhenbo, mcyprian, mhroncok, michael.d.parker, pahan, pviktori, rkuska, robatino, robinlee.sysu, rpm-software-management, sanjay.ankur, sztsian, th.schoel, tomspur, torsava, wwoods, zbyszek | ||||||||||||||
Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||
OS: | Unspecified | ||||||||||||||||
Whiteboard: | AcceptedPreviousRelease | ||||||||||||||||
Fixed In Version: | libdnf-0.11.0-1.fc26 libdnf-0.11.0-1.fc27 libdnf-0.11.1-1.fc26 | Doc Type: | If docs needed, set a value | ||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2017-10-20 16:36:59 UTC | Type: | Bug | ||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
Embargoed: | |||||||||||||||||
Bug Depends On: | |||||||||||||||||
Bug Blocks: | 1396704 | ||||||||||||||||
Attachments: |
|
That seems like bug in python... I don't see any other libraries in backtrace. Memory corruption... this will be very hard to debug. Can you maybe attach the full log from that boot with failed upgrade? It's possible that the earlier messages will tell us what went wrong. Created attachment 1334194 [details]
Journalctl output before dnf process
*** Bug 1499101 has been marked as a duplicate of this bug. *** "Start the upgrade process. This may take some time." (translation) and then the crash. Nothing interesting in the logs. *** Bug 1499131 has been marked as a duplicate of this bug. *** Created attachment 1335350 [details] journalctl output for comment 7 I also failed to upgrade with similar output. With the journalctl attached. I am currently building Python 3.6.3 for F26: https://koji.fedoraproject.org/koji/taskinfo?taskID=22290082 Please try the build as soon as it is ready to see, if that fixes the issue. Also maaaybe relevant (but it will require some more digging): https://bugs.python.org/issue31532 (In reply to Charalampos Stratakis from comment #8) > I am currently building Python 3.6.3 for F26: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=22290082 > > Please try the build as soon as it is ready to see, if that fixes the issue. > > Also maaaybe relevant (but it will require some more digging): > https://bugs.python.org/issue31532 Unfortunately, this build did not solve my issue. Same here. First attempt was upgrade from 26-testing, second one I revert main system using dnf dist-sync w/o testing repo, it crashed again. Beside, no more attempts as dnf go full reload 5gb updates and I pissed off. Why it cannot keep local cache ? Same was in 24-26 transitions and maybe previous. That insane. I wait for at least RC1 to try again. Created attachment 1335436 [details]
journalctl -b-17 > t1.txt
my log of first attempt to sys-upgrade with dnf crash
Unfortunately I was not able to reproduce the issue on a VM. I've made an experimental scratch build for people to test to see if that fixes the issues: https://koji.fedoraproject.org/koji/taskinfo?taskID=22293517 (Note that the scratch build will be garbage collected soon so if required I will provide a copr repo as well.) Created attachment 1335437 [details]
journalctl -b-7 > t2.txt
Log of last attempt to upgrade, this one from f26 w/o testing, removing steam, nvidia akmod crap, etc. Looks like no crash, but that line
окт 03 21:17:40 fast25 dnf[789]: Ошибка: Не удается синхронизировать кэш для репозитория «updates»
"cannot sync cache for updated repo"
Say it looks like known bug listed in Wiki, i had to "dnf makecache" before "dnf system-upgrade reboot", but I stopped here as it will download 5gb third time and I tired. So, it seems that f26 testing only crashing.
I'm trying the scratch build now. After installing the scratch build dnf can no longer successfully calculate the upgrade. file /usr/lib64/python3.6/collections/__init__.py from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 etc. I can't test with these RPMs it seems. (In reply to Hein-Pieter van Braam from comment #15) > After installing the scratch build dnf can no longer successfully calculate > the upgrade. > > file /usr/lib64/python3.6/collections/__init__.py from install of > python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package > system-python-libs-3.6.3-2.fc26.x86_64 > > etc. I can't test with these RPMs it seems. Please install first https://koji.fedoraproject.org/koji/taskinfo?taskID=22290082 which will land in updates-testing soon and then try to install the scratch build on top. (In reply to Hein-Pieter van Braam from comment #15) > After installing the scratch build dnf can no longer successfully calculate > the upgrade. > > file /usr/lib64/python3.6/collections/__init__.py from install of > python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package > system-python-libs-3.6.3-2.fc26.x86_64 > > etc. I can't test with these RPMs it seems. That might also be a packaging bug in the python3 rpm for the F27 branch (aka not correctly obsoleting system-python-libs which was removed). Yeah, seems to be the case. The RPMs installed cleanly this time, but the upgrade still failed: file /usr/lib64/python3.6/collections/__init__.py from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 I'll try upgrading system-python from F27 maybe? OK, 'pre-upgrading' python to the f27 packages leads to the exact same result. So the bug is at least still present in those packages also. As for the F27 packages failing to obsolete system-python, this conflicting files failure does not happen on a 'stock' F26 box (right after a distro-sync) Same issue here (original bug report). With your 3.6.3-2 build installed, `dnf system-upgrade --releasever=27 download" fails for me too. It fails during transaction check (i.e. after download but before reboot) with hundreds of collissions between python3-libs-3.6.2-13.fc27.x86_64 and system-python-libs-3.6.3-2.fc26.x86_64. This includes many __pycache__ folders under /usr/lib64/python3.6 subfolders. It does not matter whether I upgraded python from 3.6.2-7.fc26 -> 3.6.3-2.fc26 or 3.6.2-7.fc26 -> 3.6.3-1.fc26 -> 3.6.3-2.fc26. Created attachment 1335855 [details]
journalctl -b -1 after failed upgrade
I can see that issue as well. Attaching the logs of the failed upgrade.
*** Bug 1499514 has been marked as a duplicate of this bug. *** (In reply to Hein-Pieter van Braam from comment #19) > As for the F27 packages failing to obsolete system-python, this conflicting > files failure does not happen on a 'stock' F26 box (right after a > distro-sync) This is really confusing. What is the %{version}-%{release} of python3 after a distro-sync? I'm sorry if I was not clear. These are the python3 versions I have now: $ rpm -qa python3 system-python system-python-3.6.2-7.fc26.x86_64 python3-3.6.2-7.fc26.x86_64 With these packages doing the dnf system upgrade computes the dependencies correctly and it appears all deprecations work as expected. With the scratch builds installed system upgrade fails with the conflicting files. Does that clarify what I intended to say? (In reply to Hein-Pieter van Braam from comment #24) > I'm sorry if I was not clear. These are the python3 versions I have now: > > $ rpm -qa python3 system-python > system-python-3.6.2-7.fc26.x86_64 > python3-3.6.2-7.fc26.x86_64 > > With these packages doing the dnf system upgrade computes the dependencies > correctly and it appears all deprecations work as expected. With the scratch > builds installed system upgrade fails with the conflicting files. > > Does that clarify what I intended to say? Yep that helps a lot actually. Will investigate further to see what might be causing that. On another note, you did not get the memory corruption issue? Well yes it makes sense as the NVR is now bigger for F26 if the scratch builds are installed which doesn't make it possible to obsolete it. My understanding from the comments is that https://bugs.python.org/issue31532 seems to fix the issue as people only get transaction error issues after installing the scratch builds (so we are past the invalid pointer issue). Then the update will fail as the NVR of the F27 build is lower from that of the scratch build for F26 which is expected at that point. Will push an update for all the branches. Charalampos, I did also get the memory corruption issue. I filed #1499131 which was a duplicate of this bug. python3-3.6.3-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8e91b32f31 python3-3.5.4-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-48f0da57ca Updates have been submitted for all the active fedora branches. (Also the F27 is here since the fedora update system did not add it to the bugzilla: https://bodhi.fedoraproject.org/updates/FEDORA-2017-a20cf0e9b8 ) Do note that in order to properly test the upgrade path, as soon as the F27 update hit the updates-testing repos, you will need to issue the 'dnf system upgrade' command like this: sudo dnf system-upgrade --enablerepo=updates-testing download --refresh --releasever=27 OK, I'll test it as soon as it hits F27 updates-testing I was able to reproduce the similar problem. In libdnf/nevra-py.c there is a function has_just_name(). If I call it 16x and it returns Py_True, during closing it can create an error. *** Error in `/usr/bin/python3': free(): invalid pointer: 0x00007f7414001bc0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7c8dc)[0x7f7412e418dc] /lib64/libc.so.6(+0x87789)[0x7f7412e4c789] /lib64/libc.so.6(cfree+0x16e)[0x7f7412e520ee] /lib64/libpython3.6m.so.1.0(+0x109a48)[0x7f7413bdba48] /lib64/libpython3.6m.so.1.0(PyInterpreterState_Clear+0x10d)[0x7f7413cab7bd] /lib64/libpython3.6m.so.1.0(Py_FinalizeEx+0x92)[0x7f7413cf4f42] /lib64/libpython3.6m.so.1.0(Py_Main+0x392)[0x7f7413cf6232] /usr/bin/python3(main+0x1f5)[0x560238732cf5] /lib64/libc.so.6(__libc_start_main+0xea)[0x7f7412de550a] /usr/bin/python3(_start+0x2a)[0x560238732e6a] ======= Memory map: ======== Error cannot be reachable with only 15x repeat. If the function returns PyLong_FromLong(1) or Py_False, no problem appears. My python version: python3-3.6.1-8.fc26.x86_64 I can provide dnf and libdnf packages that can simulate the problem. (In reply to Jaroslav Mracek from comment #33) > My python version: python3-3.6.1-8.fc26.x86_64 > > I can provide dnf and libdnf packages that can simulate the problem. Can you still reproduce this with python3-3.6.3-2.fc26? Unfortunately the issue from Comment 33 can be also reproduced with python3-3.6.3-2.fc26. Here is the reproducer. I created a copr repo jmracek/python-problem with libdnf(2 version) and dnf. To reproduce the problem install libdnf-0.10.1-1.git.1566.45ded29.fc2* and dnf-2.7.2-1.git.7957.08323fe.fc2* and run following script. ``` #!/usr/bin/python3 import dnf def get_base(): base = dnf.Base() base.conf.assumeyes = True base.read_all_repos() base.fill_sack(load_system_repo='auto') base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.close() a = 1 while a: print(a) get_base() a -= 1 ``` If you will install libdnf-0.10.1-1.git.1567.2d692dd.fc2*, the problem disappear. Also removal of single base.install("acpi") step restore functionality. Differences between two libdnf versions: libdnf-0.10.1-1.git.1566.45ded29.fc2* Can return Py_True ``` has_just_name(_NevraObject *self, PyObject *unused) { return hy_nevra_has_just_name(self->nevra) ? Py_True : Py_False; } ``` libdnf-0.10.1-1.git.1567.2d692dd.fc2* can return PyLong_FromLong(1) ``` has_just_name(_NevraObject *self, PyObject *unused) { return hy_nevra_has_just_name(self->nevra) ? PyLong_FromLong(1) : Py_False; } ``` Here is the reproducer. I created a copr repo jmracek/python-problem with libdnf(2 version) and dnf. To reproduce the problem install libdnf-0.10.1-1.git.1566.45ded29.fc2* and dnf-2.7.2-1.git.7957.08323fe.fc2* and run following script. ``` #!/usr/bin/python3 import dnf def get_base(): base = dnf.Base() base.conf.assumeyes = True base.read_all_repos() base.fill_sack(load_system_repo='auto') base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.close() a = 1 while a: print(a) get_base() a -= 1 ``` If you will install libdnf-0.10.1-1.git.1567.2d692dd.fc2*, the problem disappear. Also removal of single base.install("acpi") step restores functionality. Differences between two libdnf versions: libdnf-0.10.1-1.git.1566.45ded29.fc2* Can return Py_True ``` has_just_name(_NevraObject *self, PyObject *unused) { return hy_nevra_has_just_name(self->nevra) ? Py_True : Py_False; } ``` libdnf-0.10.1-1.git.1567.2d692dd.fc2* can return PyLong_FromLong(1) ``` has_just_name(_NevraObject *self, PyObject *unused) { return hy_nevra_has_just_name(self->nevra) ? PyLong_FromLong(1) : Py_False; } ``` Here is the reproducer. I created a copr repo jmracek/python-problem with libdnf(2 version) and dnf. To reproduce the problem install libdnf-0.10.1-1.git.1566.45ded29.fc2* and dnf-2.7.2-1.git.7957.08323fe.fc2* and run following script. ``` #!/usr/bin/python3 import dnf def get_base(): base = dnf.Base() base.conf.assumeyes = True base.read_all_repos() base.fill_sack(load_system_repo='auto') base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.install("acpi") base.close() a = 1 while a: print(a) get_base() a -= 1 ``` If you will install libdnf-0.10.1-1.git.1567.2d692dd.fc2*, the problem disappear. Also removal of single base.install("acpi") step restores functionality. Differences between two libdnf versions: libdnf-0.10.1-1.git.1566.45ded29.fc2* Can return Py_True ``` has_just_name(_NevraObject *self, PyObject *unused) { return hy_nevra_has_just_name(self->nevra) ? Py_True : Py_False; } ``` libdnf-0.10.1-1.git.1567.2d692dd.fc2* can return PyLong_FromLong(1) ``` has_just_name(_NevraObject *self, PyObject *unused) { return hy_nevra_has_just_name(self->nevra) ? PyLong_FromLong(1) : Py_False; } ``` Changing it to the appropriate component. Discussed at blocker review meeting [1]: AcceptedPreviousRelease - this bug violates the criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-10-09/ I am really sorry but this is not a problem of libdnf but Python. Or is there any limitation why Py_True cannot be return more that 15x? If it is like that it means that any python binding in any application that returns Py_True must be changed to return something else because Py_True do not allocate memory correctly and is not safe anymore? Changing it to the appropriate component. PS: Py_True is used in libdnf about 17x. It means that we have here about 17x hidden bombs and they are ticking. Here is more simple reproducer for dnf libdnf versions in updates: dnf-2.7.3-1.fc26.noarch libdnf-0.10.1-1.fc26.x86_64 python3-3.6.3-2.fc26.x86_64 ``` #!/usr/bin/python3 import hawkey nevra = hawkey.NEVRA(name='names', epoch=0) nevra.epoch = None nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() nevra.has_just_name() ``` Notes: With Python2 no problem. If function returns False, no problem. Even fails if: `` has_just_name(_NevraObject *self, PyObject *unused) { return Py_True; } ``` Tried upgrade from 26 to 27 and had the same problem as the OP. Noticed that dnf would be downgraded as part of the upgrade. Made second attempt - hit escape to see details during upgrade reboot, saw a bunch of dnf and python errors flash past. Remembered that there was a recent upgrade to dnf on 26 & figured that upgrade is not compatible with the older dnf on 27. Did: dnf --refresh upgrade dnf downgrade dnf (this also downgraded some python stuff - don't recall details) Tried upgrade again and it is working - currently at 3K of 8K operations. Figured this workaround might help other get the upgrade done & might help with diagnosing the cause. (In reply to Steve Barnsley from comment #43) > Tried upgrade from 26 to 27 and had the same problem as the OP. > Noticed that dnf would be downgraded as part of the upgrade. > Made second attempt - hit escape to see details during upgrade reboot, saw a > bunch of dnf and python errors flash past. > Remembered that there was a recent upgrade to dnf on 26 & figured that > upgrade is not compatible with the older dnf on 27. > > Did: > dnf --refresh upgrade > dnf downgrade dnf (this also downgraded some python stuff - don't recall > details) > > Tried upgrade again and it is working - currently at 3K of 8K operations. > > Figured this workaround might help other get the upgrade done & might help > with diagnosing the cause. Update: The upgrade to 27 worked fine after downgrading dnf on 26. However, as soon as the upgrade was completed there were 316 updates available for 27 including updates to dnf and python ..... the above workaround may no longer be needed or may no longer work. I can confirm that with first downgrading dnf the upgrade from F26 to F27 works. I did, however, enable the updates-testing repo in the dnf system-upgrade download step, so I did not have any updates available after the upgrade, as they had already been installed when performing the upgrade. I'll leave my box at F26 so I can test any potential fixes for this. I am really sorry, the problem was really in libdnf. I create a patch that should solve the issue (https://github.com/rpm-software-management/libdnf/pull/337). For anyone following along – By convention, returning an object from a function means the caller receives a reference to that object. So, before returning a pre-existing object (such as Py_True), its reference count must be increased. There are helpers for this: https://docs.python.org/3/c-api/bool.html Changing it back to libdnf again. Thanks for figuring out the root cause Jaroslav. libdnf-0.11.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-925d78e821 libdnf-0.11.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b1cb6f7720 Thanks for the fix! Is there a way to test with dnf system-upgrade? I have tried this: sudo dnf system-upgrade download --refresh --releasever=27 --enablerepo=updates-testing but it shows me that libdnf version 0.10.1-1.fc27 will be installed, and not libdnf-0.11.0-1.fc27 Gwendal: $ sudo dnf install bodhi-client $ bodhi updates download --updateid FEDORA-2017-925d78e821 $ sudo dnf update ./*.rpm Also, you want to install the F26 version on F26, obviously, if you want to test upgrading to F27. Thanks, Kamil (In reply to Kamil Páral from comment #53) > Gwendal: > > $ sudo dnf install bodhi-client > $ bodhi updates download --updateid FEDORA-2017-925d78e821 > $ sudo dnf update ./*.rpm > What should I do after running these commands? Running $ sudo dnf system-upgrade download --refresh --releasever=27 --enablerepo=updates-testing after them would downgrade libdnf-0.11.0-1.fc26.x86_64 to 0.10.1-1.fc27 (In reply to LiZhenbo from comment #54) > Thanks, Kamil > > (In reply to Kamil Páral from comment #53) > > Gwendal: > > > > $ sudo dnf install bodhi-client > > $ bodhi updates download --updateid FEDORA-2017-925d78e821 > > $ sudo dnf update ./*.rpm > > > > What should I do after running these commands? > Running > $ sudo dnf system-upgrade download --refresh --releasever=27 > --enablerepo=updates-testing > after them would downgrade libdnf-0.11.0-1.fc26.x86_64 to 0.10.1-1.fc27 You should wait a bit. The update hasn't yet reached the updates-testing repo. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b1cb6f7720 *** Bug 1500329 has been marked as a duplicate of this bug. *** *** Bug 1498875 has been marked as a duplicate of this bug. *** python3-3.6.3-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8e91b32f31 libdnf-0.11.0-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-925d78e821 python3-3.5.4-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-48f0da57ca python3-3.6.3-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-a20cf0e9b8 libdnf-0.11.0-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b1cb6f7720 Coming from bug 1498875, I can confirm updating libdnf to libdnf-0.11.0-1.fc26 solved this bug for me *** Bug 1500530 has been marked as a duplicate of this bug. *** (In reply to LiZhenbo from comment #54) > > $ sudo dnf install bodhi-client > > $ bodhi updates download --updateid FEDORA-2017-925d78e821 > > $ sudo dnf update ./*.rpm > > > > What should I do after running these commands? > Running > $ sudo dnf system-upgrade download --refresh --releasever=27 > --enablerepo=updates-testing > after them would downgrade libdnf-0.11.0-1.fc26.x86_64 to 0.10.1-1.fc27 Just run the upgrade, yes. The downgrade doesn't matter, because the upgrade will performed with libdnf-0.11.0-1.fc26, and that's all that matters. (In reply to Kamil Páral from comment #65) > Just run the upgrade, yes. The downgrade doesn't matter, because the upgrade > will performed with libdnf-0.11.0-1.fc26, and that's all that matters. Thanks Kamil My procedure $ sudo dnf install bodhi-client $ bodhi updates download --updateid FEDORA-2017-925d78e821 $ sudo dnf update ./*.rpm $ sudo dnf system-upgrade download --refresh --releasever=27 --enablerepo=updates-testing Now I've upgraded to f27 successfully This issue vanished on my computer but another happened: https://paste.fedoraproject.org/paste/ghuuAhAc8Drko~kE-5IHHg/raw (In reply to Couret Charles-Antoine from comment #67) > This issue vanished on my computer but another happened: > https://paste.fedoraproject.org/paste/ghuuAhAc8Drko~kE-5IHHg/raw As a first guess that looks like bug #1492036 to me. *** Bug 1500940 has been marked as a duplicate of this bug. *** libdnf-0.11.0-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. I can confirm that the problem is solved, I just successfully upgraded to F27, thanks! I can also confirm that updating from latest F26 to F27 Beta works now. libdnf-0.11.0-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. dnf-2.7.4-1.fc26 libdnf-0.11.1-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f04c2c90f dnf-2.7.4-1.fc27 libdnf-0.11.1-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-113a221a3d dnf-2.7.4-1.fc26, libdnf-0.11.1-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f04c2c90f dnf-2.7.4-1.fc27, libdnf-0.11.1-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-113a221a3d Two confirmations above that this works, so setting VERIFIED. I am curious: what does the dnf-2.7.4-1.fc26 libdnf-0.11.1-1.fc26 update bring to the party that the libdnf-0.11.0-1.fc26 update, which has already been pushed stable, did not? Do we really need to push the newer update to fully resolve this bug? (In reply to Adam Williamson from comment #78) > Two confirmations above that this works, so setting VERIFIED. > > I am curious: what does the dnf-2.7.4-1.fc26 libdnf-0.11.1-1.fc26 update > bring to the party that the libdnf-0.11.0-1.fc26 update, which has already > been pushed stable, did not? Do we really need to push the newer update to > fully resolve this bug? Absolutely nothing, it is just Jaroslav who copied all bug references from upstream. OK, so I'll edit the update to remove the reference to this bug, and close the bug again. Thanks. dnf-2.7.4-1.fc26, libdnf-0.11.1-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. # dnf upgrade --refresh --enablerepo=updates-testing # dnf distro-sync --allowerasing --enablerepo=updates-testing # dnf system-upgrade download --refresh --releasever=27 --allowerasing --best And it leads to mass errors like on stage of transaction testing: file /usr/lib64/python3.6/xml/parsers/__pycache__/expat.cpython-36.opt-1.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/parsers/__pycache__/expat.cpython-36.opt-2.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/parsers/__pycache__/expat.cpython-36.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/_exceptions.cpython-36.opt-1.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/_exceptions.cpython-36.opt-2.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/_exceptions.cpython-36.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/expatreader.cpython-36.opt-1.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/expatreader.cpython-36.opt-2.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/expatreader.cpython-36.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/handler.cpython-36.opt-1.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/handler.cpython-36.opt-2.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/handler.cpython-36.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/saxutils.cpython-36.opt-1.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/saxutils.cpython-36.opt-2.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/saxutils.cpython-36.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/xmlreader.cpython-36.opt-1.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/xmlreader.cpython-36.opt-2.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 file /usr/lib64/python3.6/xml/sax/__pycache__/xmlreader.cpython-36.pyc from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from package system-python-libs-3.6.3-2.fc26.x86_64 I have updated packages on Fedora 26 box: # rpm -q dnf libdnf dnf-2.7.5-1.fc26.noarch libdnf-0.11.1-1.fc26.x86_64 Should I reopen this bug or report new one? To which component? It looks like python3-libs-3.6.2-13.fc27.x86_64 does not properly obsoletes system-python-libs. (In reply to Pavel Alexeev from comment #82) > # dnf upgrade --refresh --enablerepo=updates-testing > # dnf distro-sync --allowerasing --enablerepo=updates-testing > # dnf system-upgrade download --refresh --releasever=27 --allowerasing --best > > And it leads to mass errors like on stage of transaction testing: > > file > /usr/lib64/python3.6/xml/parsers/__pycache__/expat.cpython-36.opt-1.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/parsers/__pycache__/expat.cpython-36.opt-2.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/parsers/__pycache__/expat.cpython-36.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/_exceptions.cpython-36.opt-1.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/_exceptions.cpython-36.opt-2.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/sax/__pycache__/_exceptions.cpython-36.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/expatreader.cpython-36.opt-1.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/expatreader.cpython-36.opt-2.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/sax/__pycache__/expatreader.cpython-36.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/sax/__pycache__/handler.cpython-36.opt-1.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/sax/__pycache__/handler.cpython-36.opt-2.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/sax/__pycache__/handler.cpython-36.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/saxutils.cpython-36.opt-1.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/saxutils.cpython-36.opt-2.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/sax/__pycache__/saxutils.cpython-36.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/xmlreader.cpython-36.opt-1.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file > /usr/lib64/python3.6/xml/sax/__pycache__/xmlreader.cpython-36.opt-2.pyc from > install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > file /usr/lib64/python3.6/xml/sax/__pycache__/xmlreader.cpython-36.pyc > from install of python3-libs-3.6.2-13.fc27.x86_64 conflicts with file from > package system-python-libs-3.6.3-2.fc26.x86_64 > > > I have updated packages on Fedora 26 box: > # rpm -q dnf libdnf > dnf-2.7.5-1.fc26.noarch > libdnf-0.11.1-1.fc26.x86_64 > > > Should I reopen this bug or report new one? To which component? It looks > like python3-libs-3.6.2-13.fc27.x86_64 does not properly obsoletes > system-python-libs. This happens because you enabled the updates-testing repository during the distro-sync which installs python3-3.6.3-2.fc26, but you did not on the system-upgrade, so it tries to upgrade to python3-3.6.2-13.fc27.x86_64 which is not correct. I have intentionally left the python3-3.6.3-2.fc26 build in updates-testing for this case to not happen (however it will happen if you enable the updates-testing repo and update your system before the distro upgrade). In order to remedy this you should either downgrade python3 first, disable the updates-testing repo during distro-sync or enable it during system-upgrade. Thank you. # dnf system-upgrade download --refresh --releasever=27 --allowerasing --best --enablerepo=updates-testing works. Fixed, no longer needs documenting. |
Created attachment 1333868 [details] Journalctl output I am trying to upgrade my F26 to F27. Downloading part, no problem. I rebooted my system to install. Then, dnf crashed at the beginning of this process and reboot to F26 automatically. Packages release (F26 is up to date currently): dnf.noarch 2.7.2-1.fc26 @updates-testing dnf-conf.noarch 2.7.2-1.fc26 @updates-testing dnf-plugins-core.noarch 2.1.4-1.fc26 @updates-testing dnf-yum.noarch 2.7.2-1.fc26 @updates-testing python3-dnf-plugin-system-upgrade.noarch 2.0.3-1.fc26 @updates-testing F26 is working fine, but no way to get F27 over dnf upgrade for the moment.