2:39 p.m.
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
4:57 p.m.
On Wed, Jan 30, 2019 at 10:39 PM Nir Soffer <nsoffer(a)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/...
\
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
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
1:33 a.m.
Il giorno mer 30 gen 2019 alle ore 21:39 Nir Soffer <nsoffer(a)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_...
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/...
\
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
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://red.ht/sig>
4:44 p.m.
On Thu, Jan 31, 2019 at 12:57 AM Nir Soffer <nsoffer(a)redhat.com> wrote:
On Wed, Jan 30, 2019 at 10:39 PM Nir Soffer
<nsoffer(a)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/...
> \
>
>
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.
>
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
>
1905
days inactive
1907
days old
3 comments
2 participants
participants (2)
-
Nir Soffer -
Sandro Bonazzola