Last time we discussed this here, we had only sanlock issue:
https://bugzilla.redhat.com/1593853
The bug was fixed upstream about 2 month ago, but the Fedora package was
not available.
The package is not available yet in Fedora, but we have a build here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1182539
You can install sanlock from this build using:
dnf upgrade
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/...
\
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/...
\
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/...
Hopefully the package will pushed soon to updates-testing repo.
With this you can use enable selinux as god intended.
But if you update your host to kernel 4.20.4-100, multipath is broken. All
multipath devices
are not available, and your hosts will probably become non-operational
since they report the
iSCSI/FC storage domains in problem.
The issue was reported here:
https://lkml.org/lkml/2018/11/5/398
And we have this Fedora 29 bug:
https://bugzilla.redhat.com/1669235
Ben explains it is:
The kernel is switching over to use block multiqueue instead of the old
request
queue. Part of doing this is removing support for the old request queue
from device-mapper. Another part is to remove support for the old
request queue from the scsi layer. For some reason, the first part got
into this fedora kernel, but the second part didn't. It seems to me
that since the fedora kernel has removed support for non-blk-mq based
devices,
I should have been compiled with CONFIG_SCSI_MQ_DEFAULT=y
To fix this issue you need to add the scsi_mod.use_blk_mq=Y option to the
kernel command line:
grubby --args=scsi_mod.use_blk_mq=Y --update-kernel
/boot/vmlinuz-4.20.4-100.fc28.x86_64
After reboot, your multipath devices will appear again.
Cheers,
Nir