On 7/10/26 5:39 PM, Lukasz Michalski wrote:
On 10/07/2026 05.20, David C Rankin wrote:
I downloaded a fresh 7/01 Arch install iso, dd'ed it to a USB and
booted from it choosing the x86_64 install/maintenance entry. The init
image loaded fine, but then the loading of Arch froze, in the same
manner, appearing like a hardware freeze.
This suggest a hardware problem that was causing kernel-side freeze
during boot. I have been using RAID1/RAID10 mdadm arrays on a couple of
servers for over 15 years or so, where root and /boot (legacy and uefi)
partitions are under mdadm and I've never had such problem. Experienced
a lot of reboots in degraded mode, when arrays were in syncing or
checking state - no problems. The worst case I had was a disk failure
that caused whole SATA controller to be unresponsive. Then it was enough
to disconnect failed disk and boot from the other mirror. So I do not
think that it is mdadm related - a coincidence maybe - and may strike
you back in the future.
Regards,
Łukasz
Thank you Lukasz,
I too have been using RAID1 arrays in this exact config since at
least 2007 or 2008 and I've never seen this problem. I've had disk
failures before and degraded arrays, that's always handled properly
where the array is marked as degraded and the good disk is used.
Here, the array isn't 'degraded', both disks are fine, it is
resync'ing which I'm sure was the root cause of this problem (I watched
it finish repeating "cat /proc/mdstat").
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)
To the credit of the kernel and mdadm, the arrays were properly
assembled and the inconsistent state detected, the metadata was properly
read to determine the disk with the most recent write, and resync
started to the other disk. That was done by both the installed system
and the install ISO. (that's really good design)
Now if there is just some way to get a message to that effect, that
would solve the box appearing frozen issue. (I'd even take a "WAIT
Dummy, / is resyncing...")
I'll try and dig into the process to see if that is possible. I was
hoping somebody smarter on that than I am may know offhand. But given
this was the first time I've ever run into this in near 20 years of
using the setup, it may be rare enough there isn't a way to get any type
of resync status to report.
If I don't see it again for another 20 years -- it will be somebody
else's problem.
Thanks again for the feedback.
--
David C. Rankin, J.D.,P.E.
