I was interested in the gptid/rawuuid, not labels.
I was assuming:
If the system boots from nvdX, nvdXpY is mounted as root filesystem on /. So if partition no. Y of disk0 has the UUID uuid0, and partition no. Y of disk1 has the UUID uuid1, I can tell from which disk device the system was booted. Maybe I was assuming too much, or didn't understand the problem. Sorry for the noise.
That assumes that you have two separate disks with separate filesystems on them, and only
/ from one of them was mounted. Then you'll see which device it's being mounted from. Of course, the disk you mount the root filesystem from doesn't always correspond to the disk you booted from (think GELI-encrypted ZFS with unencrypted
/boot. If you have a RAID array across the two disks, or a ZFS pool across the two disks, then
/ refers to data on
both disks simultaneously; even though you only booted off one.
Once the BIOS has read the boot loader off a disk, and the loader has passed control over to the kernel, there's no way to know where the original boot blocks came from. (AFAIK, anyway.) The kernel doesn't care where it was loaded from, so it doesn't track it; it just tracks where the
/ filesystem is mounted from. Which is why you need to make sure you install the boot blocks / loader onto
every disk that you might boot from. Especially when using some kind of RAID (whether hardware, software, or ZFS).
There's nothing worse than have a 2-disk array where disk 0 dies, and there's no boot blocks/loader on disk 1.
Yeah, been there, done that, didn't get a t-shirt.
Required some fancy typing from the loader prompt of an mfsBSD USB stick.
If you're feeling masochistic, with fancy boot loaders like GRUB you can boot off disk 0, load a kernel off disk 1, and mount the root filesystem off disk 3. Good luck figuring that out from just looking at the output of the mount command.
Or boot off a floppy, to load a kernel off an MMC disk, to mount the root filesystem off a ZFS pool. Or load GRUB off the local disk, get a kernel off the network, and do even crazier things with filesystems from local and remote locations. (Yes, these are all things we've done at work at one time or another.)