I understand that it may not *look* grave, but it's pretty bad behavior in user-land.
> I disagree, if user creates (with the controller bios utility) a fakeraid > array, > dmraid assumes correctly the partition device nodes as part of a dmraid array. > If user adds them in a software (mdadm) raid, this is only a misconfiguration. Factories now commonly ship computers with windows installed on fakeraid arrays. Nor can BIOS be relied upon for sane or robust vendor-supplied configuration tools. The current interaction of mdadm and dmraid makes it difficult to dual-boot with each OS in it's "natural" state, e.g. Windows using FakeRaid and Linux using mdadm. Dual-booting is increasingly desired (and in my case required by boss). It's trivial to shrink the windows partitions on a factory-fresh machine. Windows boots fine after it FSCKs. It's trivial to configure md arrays in the freed space and complete the install into that space. What's not trivial is understanding why this configuration doesn't boot, yielding messages about no root device, then using a livecd and chroot to fiddle with initramfs, and finally discovering this bug with instructions to cycle the installation state of mdadm (after removing dmraid). Afterwards, windows fakeraid and linux mdadm co-habitate peacefully, each oblivious to the other. Given peaceful cohabitation of fakeraid and mdadm in different OS's, misconfiguration is not an accurate statement. Alternately, could a "nodmraid" parameter get passed to the bootloader? That's where i googled first... christian gunning university of new mexico biology -- Far better an approximate answer to the right question, which is often vague, than the exact answer to the wrong question, which can always be made precise -- j.w. tukey -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
