On Wed, Jan 02, 2019 at 01:55:56PM +0300, pierre-philipp braun wrote: > Hello Patrick,
Hello Pierre - thanks for taking a look! > your problem is either badly explained or too complicated, or both. I am reaching the conclusion that it must be "bad disks". > You say you do not see raid0 when using netboot, and then it seems the same > happens when booting from the disk. Correct. > I suppose there's something wrong about partitioning, either with MBR or > labels. Not sure there is something specific in that regard, compared > to non-booting arrays. But the relying and unused EFI partition makes > the whole thing a bit far fetched. Unless you really want EFI, just a > big NetBSD partition as with `fdisk -0ua /dev/rwd0d`. If there were something wrong the MBR or the labels, I wouldn't be able to boot the kernel from raid0a. > just in case, even though dmesg does not show it, you could check that > /dev/rraid0 /dev/raid0 are truly absent. They are truly absent in the sense of ioctls fail. After the raidctl -c (and no further initialisation), raid0 is fine, i.e., the behaviour is exactly as if I hadn't set the raid to autoconfigure. [The need for netboot to illustrate is that no root filesystem is found on normal boot] > Also I donno about `2 0` as > array setting. I do `1 2 0` for RAID-1 as explained in the manual. The initial '1' was redundant and has been removed in the newer syntax. Since then I booted that box with Seatools. Both disks passed the long test. dmesg doesn't contain "can't read blk ..." errors. I notice sometimes delays in writes and an associated unwelcome "thunk" from the disks, so I will shelve this as unprovable disk hardware issue (unsatisfactory). Cheers, Patrick
