I've got a couple of Linux desktops lsb_release -rd Description: openSUSE Leap 15.0 Release: 15.0 uname -rm 5.0.0-lp150.5.g6bc6477-default x86_64 that boot to 2-disk RAID-1 array, e.g., mdadm --version mdadm - v4.0 - 2017-01-09 mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Wed Feb 22 16:26:58 2017 Raid Level : raid1 Array Size : 1047552 (1023.00 MiB 1072.69 MB) Used Dev Size : 1047552 (1023.00 MiB 1072.69 MB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Tue Mar 12 08:52:56 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : resync Name : desk07:0 UUID : 1d3... Events : 60 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 17 1 active sync /dev/sdb1 been working that way for years. After recently upgrading them to Linux v5.0.x, after each build/point kernel-update + initrd refresh -- which appear to work with no reported error -- on reboot, the RAID-1 array breaks, and needs to be re-sync'd. The only logged info I've found (so far) is a 'not clean -- starting reconstruction' notice in dmesg. This does NOT happen if there's just a initrd rebuild, or simple reboot -- but ONLY in the case of the kernel updates. And, it does NOT happen on a number of other boxes. I'm not seeing/noticing errors in logs -- other than the broken RAID on boot. I've run SMART checks on all invovled drives. No errors/issues anywhere. The drives have NOT had bitmaps enabled. A chat on IRC #linux-raid has convinced me to put those inplace ... (will do, right after re-sync's finished). That should dramatically speed-up the increasingly-frequent resyncs on boot-break. I'm still left, however, with what is *causing* these breaks-on-boot in the first place? How's one go about troubleshooting this? Are there any know/new issues?
