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
