Not sure if this is a NetBSD bug or a cockpit error on my part so some expert guidance would be helpful.
I’ve got a system with two hard drives that I’ve installed NetBSD onto, using both NetBSD-8.0 and NetBSD-8.0_STABLE. (Current doesn’t boot on this HP MT 6200 - that’s a different issue but has been reported by myself and others already.) In setting up the disks I’ve used GPT partitions and a Legacy BIOS boot (UEFI booting also doesn’t work on this HP MT 6200). To do this I’ve crafted an install script that basically sets up the target disk the same way regardless of which disk I’m using, and this is where I started running into problems. (Seems that sysinst isn’t quite up to the task of dealing with multiple GPT wedges during an install, but that’s a different problem and the reason I do my installs with a script. Also my script provides a way to ping-pong between the two disks, copying my local files from the current boot disk to the target disk when I do a new install.) When setting up GPT partitions on the target disk I’ve specified a root, swap, var, usr and home wedges. The names are the same regardless of which disk I’m targeting. Since the wedge processing of disks dynamically assigns all the disk wedges to DKn devices on boot I decided to use the NAME= option in my fstab to mount the wedges. That way I don’t have to decode what DKn devices the disk wedges have been assigned to by the system during boot. That works up to a point, that point being until it discovers that the same wedge name exists on multiple disk volumes. At this point the system gets really confused at boot and tries to use (or mount) the first wedge that matches by name, so booting from the second disk now becomes impossible. So a bit further digging and I discover that one can replace the actual wedge name with the unique UUID (actually the wedge GUID value). That works on a system that has already been booted, but fails during boot. Apparently the utilities used during boot haven’t been modified to use either wedge by name or wedge by UUID. Is this a bug or oversight in wedge processing by the components used for booting? My work-around at this point is to uniquely name the wedges on both disk volumes, but I was under the impression that wouldn’t be necessary if I used the UUIDs instead of the wedge names. Is this not true? Thanks, -bob
