Try the following steps in order.

EDIT (by Harry)

1. Had to do a vgcfgrestore for the rest of commands listed below (starting with vgscan) to take effect.

   vgcfgrestore vg_XYZ

2. Also had to an e2fsck -y /dev/vg_XYZ/lv_root for the mount to succeed.

Details described at this comp.os.linux.setup post here.

Since you've already done a pvscan, proceed to a vgscan:

vgscan --partial --mknodes --verbose

With luck, that should discover the volume group vg_XYZ on /dev/sdb2, and create any necessary device nodes in /dev.

Next, make the volume group available:

vgchange -a y vg_XYZ

Follow that up with an lvscan:

lvscan --verbose

And finally, make the logical volume available:

lvchange -a y vg_XYZ/lv_root

You should now be able to mount lv_root somewhere to access its data, e.g.

mkdir -p /mnt/rescue
mount -t ext4 -o ro /dev/vg_XYZ/lv_root /mnt/rescue

Good luck!

My problems stemmed from confusion and lack of knowledge. I will try to summarise what I've learned here in the hope that some one finds it useful.

BIOS vs UEFI Hardware

When your power on your computer it has to start executing a program somewhere. Typically this is a ROM on the motherboard that contains a program, for a long time this program was called BIOS and it functioned in specific (somewhat) standard ways. It controlled some hardware features among other things but most importantly it passes control over to an OS on some other media in a well defined manner.

The BIOS "standard" program was later replaced by UEFI which has the same purpose (mostly) and it too has a method of passing control over to an OS on some other media.

BIOS boot

When BIOS boots, it reads the first sector from the primary boot device which is assumed to contain a bootloader and starts executing it. This first sector is called the Master Boot Record (MBR). The disk is assumed to be using the DOS partitioning scheme.

On the old DOS partitioning scheme (also sometimes referred to as MBR) a whopping 446 bytes of program space is reserved for the bootloader in the MBR. Who would ever need more than 446 bytes amirite? So larger bootloaders typically make use of a "feature" of the DOS partitioning scheme where there is around 1-2 MBs or so of unused space immediately following the MBR. The bootloader would have a "stage 1" and "stage 2" where stage 1 is stored in the MBR and simply loads stage 2 which is stored in this "unused" area.

UEFI boot

When UEFI boots it assumes that the primary boot device is using GPT, and looks for a partition with a specific type, namely: "EFI System Partition". This partition is assumed to FAT 12,16 or 32. Once found, it scans the partition for bootloaders by looking for files with names that end in .efi.

I found that in the context of installing grub, the texts I read were referring to the UEFI boot procedure as simply UEFI, and BIOS boot procedure as BIOS. Which was confusing as I thought they were talking about the actual software on the motherboard ROM.

At any rate an UEFI motherboard can still perform a BIOS boot procedure, typically called "Legacy Boot" or CSM in the UEFI settings.

GPT and DOS/MBR

While GPT differs greatly from the old MBR/DOS partitioning scheme, it has reserved the region where the bootloader on an MBR partitioned disk would reside. This means that you can install a "legacy" bootloader into this reserved space on GPT and use BIOS boot. However there is a caveat, remember that stage 1/2 thing? Yeah GPT doesn't have that "feature" and the reserved region is still only 446 bytes. So to house the stage 2 of the bootloader a special partition type was introduced: "bios_boot". So the bootloader has to be aware that it is being installed on a GPT disk and find the "bios_boot" partition and put it's stage 2 there and let stage 1 find this partition somehow.

Summary

So there are three ways you can boot:

UEFI boot + GPT

Create a partition to hold the bootloader(s), 100 MB or so should be more than enough, set it's type to "EFI System Partition", format it with FAT 12,16 or 32. Mount it somewhere, typically /boot/efi. Then tell grub to install an EFI loader: grub-install --efi-directory=/boot/efi.

UEFI boot should find the partition by looking at the partition table.

I am told that you can use the ESP for your '/boot' as well but I haven't tried.

BIOS boot + GPT

Create a partition to hold stage 2 of the loader, 1-2 MB typically, and set the type to "bios_boot". You do not need to put a filesystem on this partition or to mount it, grub will "own" it do the what it needs. The position of this partition on the disk should be irrelevant. Then install grub on MBR as usual grub-install /dev/sdx. Grub should detect that it is a GPT disk, find the bios boot partition (and complain if it doesn't!) and install the appropriate stage 1 and stage 2.

BIOS boot + MBR

Simply create a DOS partition scheme on your disk and use grub-install /dev/sdx to write the MBR, the bios boot partition is not needed.

Chain loading secondary drive with MBR from primary drive with GPT

So I found out that grub doesn't allow chain loading a BIOS bootloader from an UEFI bootloader for whatever reason. I personally don't see why it wouldn't be possible but at least grub doesn't seem to support it.

So to fix my issues I set my GPT drive as primary boot device in UEFI settings, then use BIOS boot to load grub from the GPT device as above. Which means that it is able to chain load Win7 from the MBR on the first disk.