I've used the storage configuration specified to run a Xenial install, and then re-use the same disks to perform a trusty install on those images.
At least under VMs, I cannot reproduce this issue.
Our next best course of action is to install Xenial to the system as normal. Then attempt the trusty install, which should fail as indicated, and then install Xenial again (but use the second disk (/dev/sdb?) as the boot device instead of sda (or even the NVME device).
Note, during the final install, you'll need to ensure that you don't wipe sda; altogether, it would be best if you overrode the curtin storage config to not enumerate the the original install disk (curtin will ignore it) and then we can mount it up and inspect it.
I've used the storage configuration specified to run a Xenial install, and then re-use the same disks to perform a trusty install on those images.
At least under VMs, I cannot reproduce this issue.
Our next best course of action is to install Xenial to the system as normal. Then attempt the trusty install, which should fail as indicated, and then install Xenial again (but use the second disk (/dev/sdb?) as the boot device instead of sda (or even the NVME device).
Note, during the final install, you'll need to ensure that you don't wipe sda; altogether, it would be best if you overrode the curtin storage config to not enumerate the the original install disk (curtin will ignore it) and then we can mount it up and inspect it.