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?
