Bug 1477321 - dnf update broken on fresh install
dnf update broken on fresh install
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2017-08-01 15:14 EDT by Jonathan Nicol
Modified: 2017-08-04 19:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-04 19:18:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Nicol 2017-08-01 15:14:56 EDT
'dnf update' fails on fresh install.

# dnf update
Delta RPMs reduced 356.9 MB of updates to 161.5 MB (54.1% saved)
warning: /var/cache/dnf/updates-2854b3113b7a3c6c/packages/python3-bind-9.11.1-2.P2.fc26.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 64dab85d: NOKEY
Importing GPG key 0x64DAB85D:
 Userid     : "Fedora 26 Primary (26) <fedora-26-primary@fedoraproject.org>"
 Fingerprint: E641 850B 77DF 4353 78D1 D7E2 812A 6B4B 64DA B85D
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-26-x86_64
Is this ok [y/N]: y
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (No such file or directory)
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.

Key import failed (code 2)Failing package is: python3-bind-32:9.11.1-2.P2.fc26.noarch
 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-26-x86_64

# rpm -qa | grep dnf

# rpm -q fedora-release
Comment 1 Jonathan Nicol 2017-08-01 16:57:55 EDT
Here's the "root cause":

/dev/mapper/vg0-root--1 on /sysroot type ext4 (rw,relatime,seclabel,data=ordered)
/dev/mapper/vg0-root--1 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/mapper/vg0-root--1 on /usr type ext4 (ro,relatime,seclabel,data=ordered)
/dev/mapper/vg0-root--1 on /var type ext4 (rw,relatime,seclabel,data=ordered)

/usr is mounted RO. /var/lib/rpm is a symlink to /usr/share/rpm.

So Fedora is broken by default, apparently.
Comment 2 Daniel Mach 2017-08-02 07:13:38 EDT
This doesn't seem to be supported (and supportable) configuration.
/var/lib/rpm has to be writable
while /usr/share/rpm can be read-only

If you disagree with closing this NOTABUG, please
reopen the bug and provide more details about your system.
Comment 3 Jonathan Nicol 2017-08-02 13:47:36 EDT
I guess this is two separate bugs?

#1, why is /var/lib/rpm a symlink to /usr/share? That belongs to the rpm package. You shouldn't be writing lock files to /usr/share!

#2 What is causing /, /usr, and /var to be mounted separately? This is a default fresh install, so it seems something is horribly wrong with the installer. If /usr is RO, how will I ever update packages? What component is mounting these separately? I've never seen this before.

/dev/mapper/vg0-root--1 /                       ext4    defaults        1 1
UUID=00de9402-ec53-402e-8cd3-cb07c656523b /boot                   ext4    defaults        1 2
UUID=19cca096-0d8a-4341-b93f-960336b313c9 swap                    swap    defaults        0 0
UUID=d1aea570-afb9-4449-be8c-c634f6545563 swap                    swap    defaults        0 0

# cat /etc/mtab | grep vg0
/dev/mapper/vg0-root--1 /sysroot ext4 rw,seclabel,relatime,data=ordered 0 0
/dev/mapper/vg0-root--1 / ext4 rw,seclabel,relatime,data=ordered 0 0
/dev/mapper/vg0-root--1 /usr ext4 ro,seclabel,relatime,data=ordered 0 0
/dev/mapper/vg0-root--1 /var ext4 rw,seclabel,relatime,data=ordered 0 0

What more information do you want about my system?
Comment 4 Jonathan Nicol 2017-08-04 19:18:38 EDT
I did a fresh install with fresh media and everything is normal. I wish I knew what happened here, but I haven't got a clue.

Note You need to log in before you can comment on or make changes to this bug.