1

I have multiple PCs with Fedora 35 and RAID-1 MDADM arrays.

Among them, only one is facing a weird problem:

If I leave it shutdown for more than 2~3 days, it will definitely perform an automatic check at the next reboot.

Here is the output result of journalctl -b | grep -E "(md1|/dev/md)":

Mar 14 23:06:49 zx-E5430 kernel: md/raid1:md127: active with 2 out of 2 mirrors
Mar 14 23:06:49 zx-E5430 kernel: md127: detected capacity change from 0 to 209582080
Mar 14 23:06:51 zx-E5430 systemd-fsck[586]: /dev/md127: clean, 236394/6553600 files, 3281182/26197760 blocks
Mar 14 23:06:51 zx-E5430 kernel: EXT4-fs (md127): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Mar 14 15:06:57 zx-E5430 kernel: EXT4-fs (md127): re-mounted. Opts: (null). Quota mode: none.
Mar 14 15:07:03 zx-E5430 systemd[1]: Started Timer to wait for more drives before activating degraded array md126..
Mar 14 15:07:04 zx-E5430 kernel: md/raid1:md126: active with 2 out of 2 mirrors
Mar 14 15:07:04 zx-E5430 kernel: md126: detected capacity change from 0 to 1743542272
Mar 14 15:07:04 zx-E5430 systemd[1]: [email protected]: Deactivated successfully.
Mar 14 15:07:04 zx-E5430 systemd[1]: Stopped Timer to wait for more drives before activating degraded array md126..
Mar 14 15:07:06 zx-E5430 systemd-fsck[847]: /dev/md126: clean, 24857/54493184 files, 4511205/217942784 blocks
Mar 14 15:07:06 zx-E5430 kernel: EXT4-fs (md126): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Mar 14 15:07:09 zx-E5430 mdadm[914]: RebuildStarted event detected on md device /dev/md/fedora_localhost-live00
Mar 14 15:07:09 zx-E5430 kernel: md: data-check of RAID array md126
Mar 14 15:07:09 zx-E5430 mdadm[914]: RebuildFinished event detected on md device /dev/md/fedora_localhost-live00
Mar 14 15:07:15 zx-E5430 kernel: md: delaying data-check of md127 until md126 has finished (they share one or more physical units)
Mar 14 15:07:15 zx-E5430 mdadm[914]: RebuildStarted event detected on md device /dev/md/fedora_localhost-live00
Mar 14 15:52:15 zx-E5430 mdadm[914]: Rebuild20 event detected on md device /dev/md/fedora_localhost-live00
Mar 14 16:40:17 zx-E5430 mdadm[914]: Rebuild40 event detected on md device /dev/md/fedora_localhost-live00

Note that the time gap within the logs was caused by dual systems (Windows 7 usually uses local time instead of UTC time) and thus should have nothing to do with this problem.

And here is the output result of mdadm -D /dev/md126:

/dev/md126:
           Version : 1.2
     Creation Time : Mon Aug  9 18:45:19 2021
        Raid Level : raid1
        Array Size : 871771136 (831.39 GiB 892.69 GB)
     Used Dev Size : 871771136 (831.39 GiB 892.69 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Mar 14 17:21:03 2022
             State : active, checking 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

      Check Status : 57% complete

              Name : fedora_localhost-live00
              UUID : 55508b5a:e2b47b55:aae847c6:0704ee20
            Events : 16456

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       2       8       18        1      active sync   /dev/sdb2

I've checked /etc/cron.d and found no entry related to MDADM. The SMART status of both 2 disks is all right as well.

At present, I can only cancel the checks manually by following commands:

sudo -i
echo idle > /sys/devices/virtual/block/md126/md/sync_action
echo idle > /sys/devices/virtual/block/md127/md/sync_action

Could someone please tell me that what is the reason that MDADM behaves like that?

3
  • "Windows usually use local time instead of UTC time" unless you're using the highly obsolete Windows XP it hasn't done this for a long time Commented Apr 10, 2022 at 18:42
  • @roaima AFAIK Windows 7 uses local time (actually the raw BIOS time) by default. Commented Apr 24, 2022 at 2:00
  • This is 2022. Windows 7 support ended at the beginning of January 2020. If you're going to use an obsolete OS you should document it in your question Commented Apr 24, 2022 at 8:05

1 Answer 1

2

I had the same problem and I solved it by disabling the raid-check.timer timer. I used the cockpit web interface to do it, the following command will work too:

systemctl disable raid-check.timer
1
  • 1
    You are right. It is caused by /usr/lib/systemd/system/raid-check.timer. Commented Apr 24, 2022 at 9:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .