Bug 877831

Some how you have an old hotplug.pp file on your system.

rm -f /etc/selinux/targeted/modules/active/modules/hotplug.pp
semodule -B

Should fix the problem.

(In reply to comment #1)
> Some how you have an old hotplug.pp file on your system.

Interesting ;)

# find /etc/selinux/targeted/modules/active -name '*.pp'  | xargs rpm -qf | grep not
file /etc/selinux/targeted/modules/active/modules/kudzu.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/hotplug.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/howl.pp is not owned by any package


FWIW: What I did, was to give the yum-upgrade procedures from the link above a try on a copy of an image of an F17 installation for mere testing purposes.

IIRC, this image originally started with F13...F15 and had gone through several updates since then.


> rm -f /etc/selinux/targeted/modules/active/modules/hotplug.pp
> semodule -B
> 
> Should fix the problem.
Thanks, will check.

Remove the others also.  They are no longer supposed to be in policy.

Had the same issue here, on an upgraded F18 system:

$ setsebool -P httpd_can_network_connect_db on
libsepol.print_missing_requirements: hotplug's global requirements were not met: bool init_systemd
libsemanage.semanage_link_sandbox: Link packages failed
Could not change policy booleans

$ find /etc/selinux/targeted/modules/active -name '*.pp'  | xargs rpm -qf | grep not
file /etc/selinux/targeted/modules/active/modules/kudzu.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/hotplug.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/local_httpd.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/howl.pp is not owned by any package


After removing these orphans (local_httpd.pp might've been generated by myself) setsebool succeeded.

Will future versions of SELinux policy upgrades take care of cleanups like this? Or generate a more helpful error message? :-)

I see the deletion lines for these in the latest selinux-policy package.

I'm not sure why this was closed as NOT a bug.  I just ran a fedup to upgrade from Fedora 17 to Fedora 18.  And indeed, at 63% progress I see the same error message during the upgrade.  After that the upgrade froze for a very long time.  Long enough that I was considering rebooting and seeing if there was something I could manually repair.   But by the time I navigated to bugzilla and started typing the comment it finally resumed.   

There are probably many users that end-up with broken upgrades because they are not patient enough to see the upgrade eventually continue after this error message.

The upgrade is still in progress, so I cannot provide any diagnosis on this yet.

Bill

Well we have these removed from F19 selinux-policy.spec file.    


%define postInstall() \
. %{_sysconfdir}/selinux/config; \
if [ -e /etc/selinux/%2/.rebuild ]; then \
   rm /etc/selinux/%2/.rebuild; \
   (cd /etc/selinux/%2/modules/active/modules; rm -f amavis.pp clamav.pp gnomeclock.pp matahari.pp xfs.pp kudzu.pp kerneloops.pp execmem.pp openoffice.pp ada.pp tzdata.pp hal.pp hotplug.pp howl.pp java.pp mono.pp moilscanner.pp gamin.pp audio_entropy.pp audioentropy.pp iscsid.pp polkit_auth.pp polkit.pp rtkit_daemon.pp ModemManager.pp telepathysofiasip.pp ethereal.pp passanger.pp qpidd.pp pyzor.pp razor.pp pki-selinux.pp phpfpm.pp consoletype.pp ctdbd.pp fcoemon.pp isnsd.pp l2tp.pp ) \
...

Maybe we can get this into F18, but it will still break on most continuous upgraded systems, since this package will not be available.  The problem is these orphans have been around for a while.  We have not shipped kudzu policy for many releases for example.

What about user-defined policy packages? In my case there was also:

  file /etc/selinux/targeted/modules/active/modules/local_httpd.pp is not
  owned by any package

...which is true, since it's custom policy, made by myself. setsebool could break again in the future with "libsepol.print_missing_requirements...", couldn't it? So, a better error message could really help here, I think.

Well the problem we are seeing is caused by old pp files containing an boolean name that we have changed.  Not likely that your local_http.pp would contain it.  It is valid for you to have local customizations, but we should make sure that any pp files that we used to ship, have been removed from the system.

 Updating   : selinux-policy-targeted-3.11.1-50.fc18.noarch                                                                                                                    1142/3585 
libsepol.print_missing_requirements: hotplug's global requirements were not met: bool init_systemd
libsemanage.semanage_link_sandbox: Link packages failed
/usr/sbin/semodule:  Failed!
...

Basically this message is reporting that init_systemd boolean does not exist in the new policy.  When we were first converting from sysvinit to systemd, we had this boolean, we decided to remove it, but had old references to in policy that should no longer be used.

I get the same error with pads

sudo semodule -i pads.pp
libsepol.print_missing_requirements: pads's global requirements were not met: type/attribute pads_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!

Could you try to re-install the policy?

# yum reinstall selinux-policy-targeted

pads should be a part of the policy.

You are replacing the pads.pp file from the policy with your own.  If you want to customize pads policy please use another name like mypads.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Observed during "fedup" F21->F22upgrade (phase between reboots), with
officially blessed Fedora 22.

From: selinux-policy-targeted-3.13.1-105.13.fc21.noarch
To:   selinux-policy-targeted-3.13.1-126.fc22.noarch

This time, the affected module was from 3rd-party package
("depends on kill in class service").  I am not sure what API
guarantees are provided on these classes, but what would be
great when this failure is observed is to check if any RPM
package can be associaced with module in question and provide
a more informative message in positive case, e.g.:

  Package `frobnical' probably relies on deprecated SELinux policy
  classes, please notify the maintainer.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.