Archdevs, I don't know if there were any recent changes to how the fsck check is done, but this is the first time I've had a fsck check cause a machine to dump to the maintenance shell due to a missing md1 (root fs) UUID. There is no issue with the array or disk. If there have been recent changes to either the systemd startup order or it's management of the fsck check, it may be worth a look to ensure that all mdadm arrays are assembled and ready before the fsck check fires. Just a guess, but it looked to me like the fsck check was attempting to run on the array UUID before the array was ready. The timing of any change would be from today back through whatever number of days the default fsck check schedule is. So this may have absolutely nothing to do with the 4.20.10 update and more to do with some change that could have happened to the fsck check scheduling or mdadm array assembly scheduling (or some combination of the two) I put it out here as I'm not really sure what to check in this regard, there are no drive or array errors in the journal. -- David C. Rankin, J.D.,P.E.