Hi,

Thanks for the report, guess that's what I get by assuming instead of 
testing.

> I’ve tried the patches, but `guix system reconfigure` fails(?) with
>
> 	building /gnu/store/cy6d2a4b8bcqcjiaz8bm367j7vbdrslc-upgrade-shepherd-services.scm.drv...
> 	guix system: error: exception caught while executing 'start' on service 'device-mapping-disk3-data':
> 	error: <>: unbound variable

Can you test with the attached patch, it seems like `cut` macros is 
undefined while shepherd service is expanded(?). I fixed it by replacing 
it with a plain lambda. I managed to mount a flash disk with LVM using 
this patch, so I think it should be working now.

> I’m also curious why sources is a list of VG’s as opposed to a list of device
> nodes (i.e. /dev/sdX), like the other mappings. Does `pvscan --cache` not work
> here?

I always thought that it wasn't possible to mount LVM by PV's, but 
looking at man, `pvscan --cache -aay` seems to do the thing. Still, I 
think that using VG's instead of PV's is better, since you must `pvscan` 
all PV's in a VG in order to activate it, so you'll still need to think 
in terms of VG's. This also can be a source of errors, for example 
adding a device to a VG will result in entire VG not being activated 
until the configuration is changed and the system is reconfigured. Also 
I think that LVM doesn't put that much importance on individual PV's as 
it does on VG's as a place where LV's live.

All of this goes out of the window if you use LVM on only one PV, so it 
may be possible to have a heuristic that will check if source is a 
device node as opposed to a VG name and perform appropriate actions, but 
I'm not sure if the resulting complexity is worth it.

Mikhail