Created attachment 658707 [details] Log containing the error Description of problem: When attempting 'dnf update', dnf crashes. Log attached. Version-Release number of selected component (if applicable): dnf-0.2.17-1.git6a055e6.fc19.noarch How reproducible: Not sure.. It seems that dnf doesn't like the following: # rpm -qa | grep -i iptables iptables-1.4.16.2-4.fc19.x86_64 iptables-1.4.16.2-5.fc19.x86_64 iptables-services-1.4.16.2-4.fc19.x86_64 Steps to Reproduce: 1. run dnf update 2. 3. Actual results: dnf crashes. Expected results: dnf handles the update correctly. Additional info:
Jan, how did you manage to install both iptables-1.4.16.2-4.fc19.x86_64 and iptables-1.4.16.2-5.fc19.x86_64? I tried to arrive at the same state: [root@localhost ~]# rpm -qa |grep iptables iptables-services-1.4.16.2-4.fc18.x86_64 iptables-1.4.16.2-4.fc18.x86_64 [root@localhost ~]# rpm -iv iptables-1.4.16.2-5.fc19.x86_64.rpm ... many file conflicts between the old and the new iptables ... If I remember correctly we also tried to do the iptables-services update manually and RPM refused to do that. That could point to a problem in the package database caused by forcing a previous install over deps/conflict checks. It is certain that DNF should never crash, but I am not sure it can help much in these scenarios.
(In reply to comment #1) > Jan, > > how did you manage to install both iptables-1.4.16.2-4.fc19.x86_64 and > iptables-1.4.16.2-5.fc19.x86_64? I tried to arrive at the same state: I have no idea. It happens sometimes. Check the SeeAlso bug (884648). > It is certain that DNF should never crash, but I am not sure it can help > much in these scenarios. Well, it seems that the failure was on the rpm's side. I think that all that dnf could do would probably be to just die with an error and suggest rpm --rebuilddb or something if there is an error like this.
Fixed by adc00b0, in the way discussed in comment 2.