Investigate `Failed SG_IO ioctl in DriveMHVTL::getDeviceInfo Errno=5: Input/output error` errors
Solution
See comment: #743 (comment 8664864)
Workaround until this problem gets solved:
Use image ALMA9 - x86_64 [2024-05-01]
and run
sed -i 's/baseurl=http:\/\/linuxsoft\.cern\.ch\/cern\/alma\/\$cernalmalinux\//baseurl=https:\/\/vault\.almalinux\.org\/9\.3\//' /etc/yum.repos.d/almalinux-*
sed -i 's/baseurl=https:\/\/linuxsoft\.cern\.ch\/cern\/alma\/\$cernalmalinux\//baseurl=https:\/\/vault\.almalinux\.org\/9\.3\//' /etc/yum.repos.d/almalinux-*
After this, setup the machine as usual.
Problem
There seems to be a bug related to the kernel (I have not been able to precisely pinpoint the issue) for RHEL9.4 releases which makes mt-st
fail on an ioctl
call; cta-tape-label
also calls directly ioctl
and the problem is the same, EIO
(Input/Output Error). It was working fine in Alma9.3 kernels.
According to the AlmaLinux Release page (and RHEL) the latest stable release contains the 5.14.0-427.13.1.el9_4
kernel, while in OpenStack the kernels for the latest images are:
2023 - 1 - 1 _ 5.14.0-162.6.1.el9_1.x86_64
[...]
2023 - 9 - 1 _ 5.14.0-284.25.1.el9_2.x86_64
[...]
2023 - 12 - 1 _ 5.14.0-362.8.1.el9_3.x86_64
[...]
2024 - 4 - 1 _ 5.14.0-362.18.1.el9_3.x86_64
2024 - 5 - 1 _ 5.14.0-362.24.2.el9_3.x86_64
2024 - 6 - 17 _ 5.14.0-427.18.1.el9_4.x86_64
2024 - 6 - 18 _ 5.14.0-427.18.1.el9_4.x86_64
2024 - 6 - 25 (TEST) 2 images for this day
2024 - 7 - 1 _ 5.14.0-427.20.1.el9_4.x86_64
There is no 427.13
kernel available for us, so we cannot directly check if that kernel version is ok or not, I suppose not. Also, all the kernel rpms related to 9.3 have been archived (and some people are asking why in the Alma9 community and CERN Linux repos seems to be just mirroring the Alma repos, so the situation is the same for us.
We are not the only ones facing this problem, in the mhvtl repo someone has the same problem: https://github.com/markh794/mhvtl/issues/127 and on our community, once month ago, George open an issue with the same problem for Rocky9 with kernel 5.14.0-427.16.1.el9_4.x86_64
and real drives; they moved to kernel 6.1.91 and the problem is fixed, but that should not be the way to go...
We have a workaround for now until the fix gets back ported to Alma9. We will contact the LinuxSoft team.