The patch does two things: 1. gets rid of mdstart and sets USE_MDADM to make mdadm run instead. mdstart gets mirrored devices all mixed up because of same superblock. 2. call dmraid before mdadm because dmraid devices can be used by MD volumes.
Created attachment 183233 [details, diff] Fix boot from mirrored fakeraid and soft raid on top of dmraid.
Why would anyone ever put mdraid on top of dmraid? :P Your assignment line is incorrect (the $ isn't needed). Also, setting $USE_MDADM after the code that checks for it has already run doesn't do much good. Please resubmit your patch after actually testing it.
Using mdadm itself sounds like a good idea. Any chance that you can split this into two patches, since it is two requests? The mdadm versus mdstart changes I could see going in right away, for the dmraid/mdraid thing, a *much* better solution would be to use something like baselayout does to specify the order, so the user can do anything they wish, rather than being tied to what is, essentially, a site-local change for your personal configuration. A generic interface would be *much* better, in the long run.
Also, patches should be made against the Git repository, rather than the released tarballs. (This one may apply fine, didn't try it...)
that setting $USE_MDADM was dumb and was added later, after I had removed mdstart and tested it with domdadm. I will attach an updated patch. > Why would anyone ever put mdraid on top of dmraid? :P To create asymmetric software RAIDs which no hardware card or fakeraid allows. Imagine doing raid10 but using only selected partitions off 4 of your older disks which have 147GB (combined from RAID0 of two raptors), 250GB, 320GB and fifth new 1TB capacity. The seq b/w gains are amazing, for only a small cpu usage increase. It does wonders while indexing large video projects or while restoring a suspended VM. > Also, setting $USE_MDADM after the code that checks for it has already run doesn't do much good. Two different functions...:D I know patch looks confusing. As for the order, I think doing dmraid first is the right one because its more at the hardware level. Allowing a specific order of these do* thingies generically may be a little involved and for no apparent user requirement as of now.
Did this patch ever make it into genkernel? I have more patches for genkernel which I will upload tonight. Is someone actively maintaining genkernel?
(In reply to comment #5) > that setting $USE_MDADM was dumb and was added later, after I had removed > mdstart and tested it with domdadm. I will attach an updated patch. Please go ahead attaching updated patches. Perhaps atomically split into single requests.
PS: Adding keyword "Inclusion" to better show this bugs nature in searches...
Please update this patch to the latest genkernel and reopen. I'm also not sure that dropping mdstart is safe, there have been prior reports where mdadm's examine call didn't find stuff properly compared to the kernel start calls.
