Bug 1303936 - systemd update fails
Summary: systemd update fails
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 23
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-02 13:00 UTC by Kai A. Hiller
Modified: 2016-02-08 12:40 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-08 12:40:29 UTC
Type: Bug

Attachments (Terms of Use)
Output when running 'dnf update systemd' (1.48 KB, text/plain)
2016-02-02 13:00 UTC, Kai A. Hiller 		no flags Details
journalctl -b (846.10 KB, text/plain)
2016-02-02 16:34 UTC, Kai A. Hiller 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Description Kai A. Hiller 2016-02-02 13:00:58 UTC 
Created attachment 1120410 [details]
Output when running 'dnf update systemd'

Description of problem:
When trying to update systemd, unpacking of the rpm fails.

Version-Release number of selected component (if applicable):
systemd-222-13.fc23.x86_64

How reproducible:
dnf update systemd

Actual results:
systemd fails to update

Expected results:
Update without errors

Additional info:
systemd-222-14.fc23.x86_64 in updates-testing doesn't update as well.
Kernel: 4.3.3-300.fc23.x86_64
Comment 1 Zbigniew Jędrzejewski-Szmek 2016-02-02 13:15:03 UTC 
Can you attach the logs (journalctl -b)? This looks like a file system error to me, reassigning to dnf to get a confirmation. At least the line about reducing download by -30% looks suspicious.
Comment 2 Kai A. Hiller 2016-02-02 16:34:35 UTC 
Created attachment 1120512 [details]
journalctl -b
Comment 3 Zbigniew Jędrzejewski-Szmek 2016-02-02 19:36:19 UTC 
Hm, nothing interesting in the log.
Comment 4 Kai A. Hiller 2016-02-04 10:38:28 UTC 
I now got the systemd update to work after simply removing /usr/lib/systemd/system/final.target (after I backed it up).

Somehow final.target was not a file but a folder with a bunch of xml-files in it. I guess that's what caused dnf the read problems. What is the supposed behaviour of dnf in such a case?
Comment 5 Michal Luscon 2016-02-08 12:40:29 UTC 
Negative percentage is not connected to this rpm error and it has been already reported in #1238808.

Regarding the error, dnf behaves as expected.
Note You need to log in before you can comment on or make changes to this bug.