On Thu, Jan 31, 2019 at 12:57 AM Nir Soffer <nsoffer@redhat.com> wrote:
On Wed, Jan 30, 2019 at 10:39 PM Nir Soffer <nsoffer@redhat.com> wrote:
Last time we discussed this here, we had only sanlock issue:

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:

You can install sanlock from this build using:


Hopefully the package will pushed soon to updates-testing repo.

sanlock 3.0.6-4 is available now in updates-testing repo.

Use this to update:

   sudo dnf update --enablerepo=updates-testing sanlock python2-sanlock sanlock-devel

And provide feedback here:

Fedora 28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ea4ecdc166
Fedora 29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a27b970ddf
 

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:

And we have this Fedora 29 bug:

The Fedora 28 bug (thanks Ben)


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