Dirk,
Is there a specific download site for the fix for this problem? I wrote a bug report yesterday to the RedHat bugzilla "Bug 1596827 – dnf non-functional after upgrade".
Bug 1596827 – dnf non-functional after upgrade
Best regards,
George...
On Sat, 30 Jun 2018 16:57:47 +0000 (UTC) George R Goffe grgoffe@yahoo.com wrote:
Is there a specific download site for the fix for this problem? I wrote a bug report yesterday to the RedHat bugzilla "Bug 1596827 – dnf non-functional after upgrade".
Bug 1596827 – dnf non-functional after upgrade
You can find all fedora dnf packages available here:
https://koji.fedoraproject.org/koji/packageinfo?packageID=14310
On Sat, 2018-06-30 at 12:39 -0700, stan wrote:
On Sat, 30 Jun 2018 16:57:47 +0000 (UTC) George R Goffe grgoffe@yahoo.com wrote:
Is there a specific download site for the fix for this problem? I wrote a bug report yesterday to the RedHat bugzilla "Bug 1596827 – dnf non-functional after upgrade".
Bug 1596827 – dnf non-functional after upgrade
You can find all fedora dnf packages available here:
https://koji.fedoraproject.org/koji/packageinfo?packageID=14310
Sadly it seems the 3.0.2 and 2.7.5 packages cannot be installed due to various different broken dependencies, so simple upgrade or downgrade of dnf from the current state of the Fedora install is not possible.
I know this is Fedora and there is a caveat emptor, but I wonder if this episode indicates that there should be work done to make sure that a broken dnf can never be installed? dnf is too important to a Fedora install to allow having a broken one be put in place. Ditto rpm, obviously.
On Sun, 01 Jul 2018 09:19:15 +0100 Russel Winder russel@winder.org.uk wrote:
Sadly it seems the 3.0.2 and 2.7.5 packages cannot be installed due to various different broken dependencies, so simple upgrade or downgrade of dnf from the current state of the Fedora install is not possible.
I know this is Fedora and there is a caveat emptor, but I wonder if this episode indicates that there should be work done to make sure that a broken dnf can never be installed? dnf is too important to a Fedora install to allow having a broken one be put in place. Ditto rpm, obviously.
I agree with you on the importance of dnf to the functionality of Fedora. From what I've read, though, they are aware of this and dnf is very well tested for compatibility. But, rawhide. In a stable version, people aren't trying to get the next version of libraries and critical system components in before the freeze. The time between releases is short, and there almost always seems to be a frenzy in rawhide about something. Not to mention orphaned packages causing update blocks.
Because of events like this, when I run rawhide, I always do it on a machine with an earlier Fedora that works available. Then, if (when?) something goes wrong, I can use the functioning Fedora as a fallback, and a base to help correct the compromised rawhide. 'chroot dnf update' worked for me the last time dnf was compromised in rawhide. I also have used rpm to download and update, or remove, or downgrade packages. It's tedious, but works.
On Sun, 1 Jul 2018 10:21:40 -0700 stan stanl-fedorauser@vfemail.net wrote:
'chroot dnf update' worked for me the last time dnf was compromised in rawhide.
This can't be true. I remember using it, but that can't have been why, because if dnf is borked in rawhide, it won't work.
Has anyone discovered a way forward for updating Fedora Rawhide given dnf just seg faults currently?
On Thu, Jul 5, 2018 at 10:40 AM, Russel Winder russel@winder.org.uk wrote:
Has anyone discovered a way forward for updating Fedora Rawhide given dnf just seg faults currently?
Can you use rpm to just update it lmanually?
-- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/m...
On Thu, 2018-07-05 at 10:48 +0100, Peter Robinson wrote:
On Thu, Jul 5, 2018 at 10:40 AM, Russel Winder russel@winder.org.uk wrote:
Has anyone discovered a way forward for updating Fedora Rawhide given dnf just seg faults currently?
Can you use rpm to just update it lmanually?
So far no. The RPM files downloaded from Koji require the Python 3.7 ABI but currently Python is 3.6. This apples to dnf 3.0.2 and 2.7.5 RPMs downloaded.
On Sun, 2018-07-01 at 09:19 +0100, Russel Winder wrote:
I wonder if this episode indicates that there should be work done to make sure that a broken dnf can never be installed?
How do you propose we do that?
On Wed, Jul 4, 2018 at 4:14 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2018-07-01 at 09:19 +0100, Russel Winder wrote:
I wonder if this episode indicates that there should be work done to make sure that a broken dnf can never be installed?
How do you propose we do that?
Personally I would have hoped that dnf would have an appropriate test harness as part of the upstream process that tests all the common use cases with each pull request like most modern software development processes so that breakage like this would be discovered long before it gets to a koji build.
On Tue, 2018-07-03 at 20:14 -0700, Adam Williamson wrote:
On Sun, 2018-07-01 at 09:19 +0100, Russel Winder wrote:
I wonder if this episode indicates that there should be work done to make sure that a broken dnf can never be installed?
How do you propose we do that?
Using a two stage system: 1. take a one step back version of Fedora Rawhide and add the new dnf; then run a few tests such as "dnf check-update --refresh" and "dnf upgrade". 2. take a current version of Fedora Rawhide and add the new dnf; then run the same set of tests. This should ensure dnf dependencies are correct and that "dnf upgrade" never causes a seg fault.
I would have thought the dnf people would have been doing this sort of system testing given just how important dnf is to Fedora Rawhide. To have people (it's not just me) in a situation of not being able to amend their system with dnf should I feel cause deep embarrassment to the dnf people despite the caveat emptor nature of Fedora Rawhide.
On Thu, 2018-07-05 at 10:38 +0100, Russel Winder wrote:
On Tue, 2018-07-03 at 20:14 -0700, Adam Williamson wrote:
On Sun, 2018-07-01 at 09:19 +0100, Russel Winder wrote:
I wonder if this episode indicates that there should be work done to make sure that a broken dnf can never be installed?
How do you propose we do that?
Using a two stage system: 1. take a one step back version of Fedora Rawhide and add the new dnf; then run a few tests such as "dnf check-update --refresh" and "dnf upgrade". 2. take a current version of Fedora Rawhide and add the new dnf; then run the same set of tests. This should ensure dnf dependencies are correct and that "dnf upgrade" never causes a seg fault.
I would have thought the dnf people would have been doing this sort of system testing given just how important dnf is to Fedora Rawhide. To have people (it's not just me) in a situation of not being able to amend their system with dnf should I feel cause deep embarrassment to the dnf people despite the caveat emptor nature of Fedora Rawhide.
But the new dnf doesn't break everywhere; I updated to it and didn't hit any of the reported issues. I'm sure the DNF developers *do* test it on their local machines, but this is not some sort of cast-iron guarantee that it will never fail anywhere else.
On Thu, 2018-07-05 at 12:49 -0700, Adam Williamson wrote: […]
But the new dnf doesn't break everywhere; I updated to it and didn't hit any of the reported issues. I'm sure the DNF developers *do* test it on their local machines, but this is not some sort of cast-iron guarantee that it will never fail anywhere else.
Can I suggest that the DNF people ought to be interested in the fact that two people prepared to say something on this list have a real problem that they have no idea how to fix without doing a reinstall from scratch.
It sounds like there is a set up for which there is no problem and that is good. It implies there is hope!
If given direction I can create a list of all packages installed, George I suspect can do likewise. This then might be able to allow people to ascertain what went wrong, why the tests didn't find it, and (the most important thing) how to get out of this situation.
I did an "strace dnf check-update" and got:
… pwrite64(24, "\305\33\10\3\2\3\7s\2\305\34\10\3\2\3\7s\2\305\35\10\3\2\3\7s\2\305\36\10\3\2"..., 1024, 1595392) = 1024 pwrite64(24, "s\2\305\215\10\3\2\3\7s\2\305\216\10\3\2\3\7s\2\305\217\10\3\2\3\7s\2\305\220\10"..., 1024, 1596416) = 1024 pwrite64(24, "\3\7s\2\305\377\10\3\2\3\7s\2\306\0\10\3\2\3\7s\2\306\1\10\3\2\3\7s\2\306"..., 609, 1597440) = 609 munmap(0x7f95ff0c8000, 1598055) = 0 close(24) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x40} --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped)
but that isn't entirely helpful on its own I guess.
By pure fluke I ran "dnf check-update --refresh" not as root and got:
RuntimeError: C++ std::exception: Failed to open backup database: /var/lib/dnf/history/history-2015-04-01.sqlite
Surprising in that I have run this command not as root before and it didn't fail, but the file was owned root:root on 0600 so the failure is not a surprise. The file being in /var I took the view that it is ephemeral and so deleted it.
Now as root I get proper behaviour, and indeed as not root I get proper behaviour.
I am now upgrading all my Fedora Rawhide machines.
:-)
On Fri, 2018-07-06 at 12:33 +0100, Russel Winder wrote:
By pure fluke I ran "dnf check-update --refresh" not as root and got:
RuntimeError: C++ std::exception: Failed to open backup database: /var/lib/dnf/history/history-2015-04-01.sqlite
Surprising in that I have run this command not as root before and it didn't fail, but the file was owned root:root on 0600 so the failure is not a surprise. The file being in /var I took the view that it is ephemeral and so deleted it.
Now as root I get proper behaviour, and indeed as not root I get proper behaviour.
That's interesting, but rather odd, as it suggests that run as root dnf just *happens* to have a *different* issue involving the same file (since obviously, when run as root, it wouldn't have had any problem accessing it). I don't suppose you kept a backup of the file? That would be very helpful for investigating the problem...
On Fri, 2018-07-06 at 07:43 -0700, Adam Williamson wrote:
[…]
That's interesting, but rather odd, as it suggests that run as root dnf just *happens* to have a *different* issue involving the same file (since obviously, when run as root, it wouldn't have had any problem accessing it). I don't suppose you kept a backup of the file? That would be very helpful for investigating the problem...
Sorry, I am obsessive about backups of /home and /etc, but I do not backup /var. I just ran rm on the file on all of my machines. In hindsight I should have moved it away not rm.
accessing it). I don't suppose you kept a backup of the file? That would be very helpful for investigating the problem...
See https://bugzilla.redhat.com/show_bug.cgi?id=1598590#c4 .
On Thu, 2018-07-12 at 20:42 +0000, Andre Robatino wrote:
accessing it). I don't suppose you kept a backup of the file? That would be very helpful for investigating the problem...
See https://bugzilla.redhat.com/show_bug.cgi?id=1598590#c4 .
It would seem that this is a possible reason for the behaviour I saw. I am now even more sorry I used rm instead of mv. Apologies.
PS Is it correct that dnf works fine without the history database, and seems not to recreate it?
On 07/13/2018 07:23 AM, Russel Winder wrote:
PS Is it correct that dnf works fine without the history database, and seems not to recreate it?
You will have lost your past history of dnf transactions. The next time you install, update, or remove something, it should create it again.
On Fri, 2018-07-13 at 09:06 -0700, Samuel Sieb wrote:
On 07/13/2018 07:23 AM, Russel Winder wrote:
PS Is it correct that dnf works fine without the history database, and seems not to recreate it?
You will have lost your past history of dnf transactions. The next time you install, update, or remove something, it should create it again.
Apologies for the delay in responding.
It seems the files I deleted in /var/lib/dnf/history/ have not been recreated. There is a /var/lib/dnf/history.sqlite that is being updated. It seems the file I deleted is just ancient history that had the wrong schema.
On Fri, 2018-07-06 at 11:57 +0100, Russel Winder wrote:
On Thu, 2018-07-05 at 12:49 -0700, Adam Williamson wrote: […]
But the new dnf doesn't break everywhere; I updated to it and didn't hit any of the reported issues. I'm sure the DNF developers *do* test it on their local machines, but this is not some sort of cast-iron guarantee that it will never fail anywhere else.
Can I suggest that the DNF people ought to be interested in the fact that two people prepared to say something on this list have a real problem that they have no idea how to fix without doing a reinstall from scratch.
Sure they are. So far as I'm aware, no-one claimed that the bugs *aren't* a problem, did they?
It sounds like there is a set up for which there is no problem and that is good. It implies there is hope!
If given direction I can create a list of all packages installed, George I suspect can do likewise. This then might be able to allow people to ascertain what went wrong, why the tests didn't find it, and (the most important thing) how to get out of this situation.
It wouldn't hurt (it's easy to do: rpm -qa | sort -u > packagelist.txt), but it may not necessarily help either. The problem may not be down to some specific combination of packages, but some other factor to do with exactly how your repositories are set up or something like that.
I did an "strace dnf check-update" and got:
… pwrite64(24, "\305\33\10\3\2\3\7s\2\305\34\10\3\2\3\7s\2\305\35\10\3\2\3\7s\2\305\36\10\3\2"..., 1024, 1595392) = 1024 pwrite64(24, "s\2\305\215\10\3\2\3\7s\2\305\216\10\3\2\3\7s\2\305\217\10\3\2\3\7s\2\305\220\10"..., 1024, 1596416) = 1024 pwrite64(24, "\3\7s\2\305\377\10\3\2\3\7s\2\306\0\10\3\2\3\7s\2\306\1\10\3\2\3\7s\2\306"..., 609, 1597440) = 609 munmap(0x7f95ff0c8000, 1598055) = 0 close(24) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x40} --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped)
but that isn't entirely helpful on its own I guess.
No, generally speaking, when you get a core dump, the backtrace of the core dump (as generated by abrt, if you're lucky) is the most useful thing you can provide. strace is only helpful in some specific situations.
-
Adam Williamson -
Andre Robatino -
George R Goffe -
Peter Robinson -
Russel Winder -
Samuel Sieb -
stan