On 11/07/2026 05.29, David C Rankin wrote:
The boot process was trying to mount the / filesystem. What makes me
think this might be mdadm related, is that mdadm is smart enough to
handle the degraded-array case with no problem. But here, that wasn't
the case, mdadm knew both disks were good, it just saw the
inconsistent state and knew a resync was needed and started the
process. The unknown is whether mdadm has any way of communicating
that state to the boot process so a warning or message can be issued.
What was also pretty amazing was mdadm knew when enough of the drive
had been resynced that the array could be mounted allowing the boot to
continue while the resync finished. After / got mounted the "degraded
array" message scrolled by prompting me to check /proc/mdstat as soon
as I got a console.
So having more time to think through the issue, the actual time we
are talking about is the time between when mdadm_udev is called in the
HOOKS array to assemble the arrays, where mdadm started the resync,
and the time when enough of the resync has completed to allow / to be
mounted. Technically, I have no clue how all that is sequenced. And I
*guess* this is that period between where / gets mounted read-only,
which may be when the need to resync is discovered, and then later
when / gets mounted read-write. (that's what I'll have to research and
whether anything can be communicated back in that time period)
You can mount and use filesystem if underlaying mdadm device is checking
or resyncing. There is no such thing like "enough of the resync" to
allow mount.
Regards,
Lukasz
