-
Bug
-
Resolution: Done
-
Normal
-
rhel-9.2.0
-
None
-
Low
-
sst_logical_storage
-
ssg_filesystems_storage_and_HA
-
8
-
12
-
2
-
QE ack, Dev ack
-
False
-
-
None
-
None
-
None
-
None
-
If docs needed, set a value
-
-
x86_64
-
None
Description of problem:
In previous RHEL version, a cron entry existed for automatic scrub of software RAID arrays. In current RHEL 9.x two services called mdcheck_start.service and mdcheck_continue.service are provided, and they can be triggered by the respective systemd timers. However they call a non-existing script at path /usr/share/mdadm/mdcheck. The mdcheck script really lives at /usr/share/doc/mdadm/mdcheck.
Indeed, checking which packages provides the mdcheck script shows:
- yum whatprovides */mdcheck
Last metadata expiration check: 2:21:21 ago on Sat 19 Aug 2023 09:40:01 AM CEST.
mdadm-4.2-8.el9.x86_64 : The mdadm program controls Linux md devices (software RAID arrays)
Repo : @System
Matched from:
Filename : /usr/share/doc/mdadm/mdcheck
As things stand now, one has to create a custom cron entry or softlink the /usr/share/doc/mdadm/mdcheck at the path expected by the systemd services (ie: ln -s /usr/share/doc/mdadm/mdcheck /usr/share/mdadm/mdcheck)
Version-Release number of selected component (if applicable):
mdadm-4.2-8.el9.x86_64
How reproducible:
Try starting mdcheck_start.service and see how it fails due to a non-existent ExecStart path.
Steps to Reproduce:
1. systemctl start mdcheck_start.service
2. systemctl status mdcheck_start.service
3. the service is in failed state
Actual results:
mdcheck_start.service and mdcheck_continue.service do not start, nor classical cron entry is provided for software RAID scrub/check
Expected results:
Automatic software RAID scrub/check should be provided out of the box.
Additional info:
None.
- external trackers