Re: Patch to fix boot from RAID-1 partitioned arrays

[Geoff Back <geoff@demonlair.co.uk>]

On 12/05/2021 12:07, Wols Lists wrote:
> On 12/05/21 09:41, Geoff Back wrote:
>> Good morning.
>>
>> I have had problems in all recent kernels with booting directly from MD
>> RAID-1 partitioned arrays (i.e. without using an initrd).
>> All the usual requirements - building md and raid1 into the kernel,
>> correct partition types, etc - are correct.
>>
>> Deep investigation has led me to conclude that the issue is caused by
>> boot-time assembly of the array not reading the partition table, meaning
>> that the partitions are not visible and cannot be mounted as root
>> filesystem.
> 
> The other thing is, what superblock are you using? Sounds to me like
> you're trying to use an unsupported and bit-rotting option.

Yes, I am using 0.9 superblocks, because in-kernel auto detection does
not support the newer 1.x superblock formats.

> 
> Standard procedure today is that you MUST run mdadm to assemble the
> array, which means having a functioning user-space, which I believe
> means initrd or some such to create the array before you can make it root.

Using an initrd would add considerable additional complexity and
resource consumption to a configuration that until recently (some time
since linux 5.5.3) just worked.  Yes, I know that the general approach
for common distros is to use initrd, but for my use case it is not
appropriate.

> 
> You saying that you need to read the partition table even when you have
> a successfully assembled array makes me think something is weird here ...

The problem is not with in-kernel assembly and starting of the array -
that works perfectly well.  However, when the 'md' driver assembles and
runs the partitionable array device (typically /dev/md_d0) it only
causes the array device itself to get registered with the block layer.
The assembled array is not then scanned for partitions until something
accesses the device, at which point the pending GD_NEED_PART_SCAN flag
in the array's block-device structure causes the probe for a partition
table to take place and the partitions to become accessible.

Without my patch, there does not appear to be anything between array
assembly and root mount that will access the array and cause the
partition probe operation.

To be clear, the situation is that the array has been fully assembled
and activated but the partitions it contains remain inaccessible.

> 
> If you can give us a bit more detail, we can then decide whether what
> you're doing is supposed to work or not.
> 
> Basically, as I understand what you're doing, you need a 0.9
> (unsupported) superblock, and also (unsupported) in-kernel raid assembly.

Neither the 0.9 superblock format, nor the in-kernel array detection
process, are marked as deprecated in the kernel Kconfig - indeed
automatic raid detection still defaults to enabled when 'md' is enabled.

My patch is intended as a minimally-invasive fix to a functional
regression - this used to work and the kernel sources/documentation say
it should still work, but in practice (without the patch) it doesn't.

There was a relatively recent change that removed code which
deliberately performed partition probing after assembly in one of the
two code paths, but according to the patch it was only removed on the
basis that it was unclear why the probing was done; I suspect that this
regression may be partly due to that change. My patch effectively
reinstates the same functionality in that code path and adds the same
functionality to the other code path.


> 
> Cheers,
> Wol
> 

Thanks,

Geoff.

-- 
Geoff Back
What if we're all just characters in someone's nightmares?