Bug 1733575 - polkit fails to run under a yum installed diskless installation
Summary: polkit fails to run under a yum installed diskless installation
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: polkit
Version: 7.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Polkit Maintainers
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-26 15:07 UTC by Schlake
Modified: 2019-07-26 15:07 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Schlake 2019-07-26 15:07:45 UTC
Description of problem:  Installing a diskless machine via the redhat suggested method (yum install -y @BASE --installroot=/path --releasever=/) preduces a diskless machine where polkit just doesn't work.  It seems unfixable.


Version-Release number of selected component (if applicable):

kernel-3.10.0-957.el7.x86_64
polkit-0.112-18.el7.x86_64

How reproducible:

Prepare a diskless image via the yum install with --installroot, boot it.  Rebooting via the reboot command will show errors about polkit.  Deeper down, the inability of udisks to function is what led me to polkit.

Steps to Reproduce:
1. yum install -y @BASE --installroot=/path --releasever=/
2. (all the other stuff to diskless boot like tftp, and dhcpd edits)
3. diskless boot from /path
4. type 'reboot'

Actual results:
I don't have it in my scrollback, but it was an error asking if polkit was running.

Expected results:
No error about polkit running.


Additional info:

We are still using udisks via the oldudisks package because the new udisks implementation removed functionality we needed.  I tried the polkit with the rpm --setperms and --setugids suggested in https://access.redhat.com/discussions/3959351 but that didn't help.  Also, a RedHat 6.9 diskless image has a working udisks on a diskless machine.  I think that deep down this is a systemd issue.


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