oVirt on Fedora 28 status update
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/pyt... \ https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san... \ https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san... 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
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: 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/pyt... \
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san... \
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san...
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
The Fedora 28 bug (thanks Ben) https://bugzilla.redhat.com/1670966
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
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: 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/pyt... \
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san... \
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san...
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: https://lkml.org/lkml/2018/11/5/398
And we have this Fedora 29 bug: https://bugzilla.redhat.com/1669235
The Fedora 28 bug (thanks Ben) https://bugzilla.redhat.com/1670966
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
Il giorno mer 30 gen 2019 alle ore 21:39 Nir Soffer <nsoffer@redhat.com> ha scritto:
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
Reviewing it on https://bodhi.fedoraproject.org/updates/FEDORA-2019-ea4ecdc166 I see takotron found 6 issues with automated testing: there's a comment in spec file containing a macro: # %patch0 -p1 -b .0001-foo.patch which may cause unexpected behavior and should either be escaped (%%patch) or dropped. Also: rpmlint FAILED for sanlock-3.6.0-4.fc28 (x86_64, noarch, src): 6 errors, 9 warnings ##### SRPMs ##### sanlock.src: E: description-line-too-long C The sanlock daemon manages leases for applications on hosts using shared storage. sanlock.src:40: W: macro-in-comment %patch0 sanlock.src:81: W: mixed-use-of-spaces-and-tabs (spaces: line 7, tab: line 81) 1 packages and 0 specfiles checked; 1 errors, 2 warnings. ##### RPMs ##### python2-sanlock.x86_64: W: no-documentation sanlk-reset.x86_64: W: spelling-error %description -l en_US lockspace -> lock space, lock-space, locks pace sanlk-reset.x86_64: E: dir-or-file-in-var-run /var/run/sanlk-resetd sanlk-reset.x86_64: E: non-standard-dir-perm /var/run/sanlk-resetd 775 sanlock.x86_64: E: description-line-too-long C The sanlock daemon manages leases for applications on hosts using shared storage. sanlock.x86_64: W: manual-page-warning /usr/share/man/man8/sanlock.8.gz 535: warning: macro `/"' not defined sanlock.x86_64: E: dir-or-file-in-var-run /var/run/sanlock sanlock.x86_64: E: non-standard-dir-perm /var/run/sanlock 775 sanlock.x86_64: W: empty-%postun sanlock-devel.x86_64: W: no-dependency-on sanlock/sanlock-libs/libsanlock sanlock-devel.x86_64: W: no-documentation sanlock-lib.x86_64: W: no-documentation 5 packages and 0 specfiles checked; 5 errors, 7 warnings. RPMs tested: python2-sanlock-3.6.0-4.fc28.x86_64.rpm sanlk-reset-3.6.0-4.fc28.x86_64.rpm sanlock-3.6.0-4.fc28.src.rpm sanlock-3.6.0-4.fc28.x86_64.rpm sanlock-devel-3.6.0-4.fc28.x86_64.rpm sanlock-lib-3.6.0-4.fc28.x86_64.rpm If you want to whitelist some warnings/errors, see https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint#whitelist These RPMs use `python-` prefix without Python version in *Requires: sanlock-3.6.0-4.fc28 BuildRequires: * python (python2 is available) * python-devel (python2-devel is available) This is strongly discouraged and should be avoided. Please check the required packages, and use names with either `python2-` or `python3-` prefix. Read the following document to find more information and a possible cause:https://fedoraproject.org/wiki/Packaging:Python#Dependencies Or ask at #fedora-python IRC channel for help. If you think the result is false or intentional, file a bug against:https://github.com/fedora-python/task-python-versions/issues ----------- You've used /usr/bin/python during build on the following arches: sanlock-3.6.0-4.fc28: armv7hl, x86_64 Use /usr/bin/python3 or /usr/bin/python2 explicitly. /usr/bin/python will be removed or switched to Python 3 in the future. Grep the build.log for the following to find out where: DEPRECATION WARNING: python2 invoked with /usr/bin/python Read the following document to find more information and a possible cause:https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build Or ask at #fedora-python IRC channel for help. If you think the result is false or intentional, file a bug against:https://github.com/fedora-python/task-python-versions/issues -----------
You can install sanlock from this build using:
dnf upgrade https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/pyt... \
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san... \
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/san...
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
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig>
participants (2)
-
Nir Soffer -
Sandro Bonazzola