Hi Cherry, thank you very much for the explanation. Am 21.12.2020 um 11:49 schrieb Mathew, Cherry G.:
hi - the boot code sequence assumes root device precedence based on a bunch of archaic rules.I'm wondering if having dk in the sequence makes any changes to the assumption, especially since the xen boot path is slightly different from the native one.an easy way to verify this would be to create a new raid set using the underlying disk device nodes (/dev/wdxx ?) and retry booting from that raid set.if it succeeds, then the xen boot code definitely needs further inspection.it's a long shot, and I haven't looked at the codebase in a year, so I'm totally guessing here!
The reason I put GPT partitions on the RAID components is because they are different sized SSDs and I would like to mirror my root filesystem. One is 112GB in size and the other is 1TB. Therefore, there is a 112 GB partition on each. And on the larger of the two is a second GPT partition with a non raidframe file system. At least "architecturally" this setup must have worked before - just about in summer 2018 when I got the tip from Manuel that I have to include the root/bootdev parameter in boot.cfg. But at that time it was under NetBSD 8.0 and Xen 4.11.
I will first recreate the current setup on two other hard disks to make sure that the problem occurs there in the same way.
As a next step, I would try an MBR+disklabel-in-disklabel combination instead of the GPT partitioning, as well as the underlying devices you suggested.
Out of interest, where would the anchor points be if I wanted to compare the executed code from NetBSD 8.0 to 9.1?
Many greetings Matthias