[SOLVED] PVE host and PVE guest on ZFS, rpool fails to import

[CaptainLegot]

Hi, I have a Proxmox host installed on ZFS, with the default pool name 'rpool'.
Recently I installed an NVME drive, passed that through to a VM, and installed Proxmox on that VM directly to that passed through drive, also with the default pool name 'rpool'

So the issue might be obvious, but what is happening is when I reboot the host initramfs tries to import 'rpool' and finds more than one matching pool and drops me into the BusyBox shell, where I can successfully import using the pool ID of the correct pool.

Boot Error


Output of zpool import


Output of zpool import 9570938744399426821


on exit the system successfully boots onto the correct pool.

Once the system boots into PVE the PCI drive is passed through to the VM, and it is not available to the host system. Everything works as expected on both the PVE host and Guest once the host 'rpool' is manually imported.

The problem is obviously that the two zpools carry the same name 'rpool', but I don't believe there is a straightforward way to change that on the host or the guest, since Proxmox depends on that name for several functions.

I see that initramfs is using the command:

/sbin/zpool import -N 'rpool'

How would I configure it to use the command:

/sbin/zpool import -N 9570938744399426821

Is this even an appropriate solution?

Thanks

 

[CaptainLegot]

Appears to be fixed with Kernel 6.2.16-18-pve, marking as resolved.

 

[crash]

I have run into this issue too on PVE8 with kernel 6.8.12-2-pve. Was there a solution?

 

[infinisean]

I have run into this issue too on PVE8 with kernel 6.8.12-2-pve. Was there a solution?

Has anyone found a solution to this yet? I am running into the same thing...

I am getting ready to boot into a live ubuntu environment and nuke the drives containing the conflicting rpool (in my case I don't need to keep the other one), but it seems like this is a very heavy-handed approach (which obviously would not work for everyone) and there has to be a better way.

I would also suggest the devs consider adding a check during installation for an existing pool and throw an error and force the user to pick a unique name for the new pool, as that would be a simple way to avoid this frustration going forward.

Using a static value for something like a pool name and then using that as the mounting mechanism is... let's say... an odd design decision, at best.

 

[crash]

I never found a solution. As you can see no one replied here or in a separate thread that I started.

I think it’s doable but you would need to hack together some edits to the boot loader. Much easier to use a different pool name on the other disk, which I what I ended up doing.

It’s clearly a bug, but not a high-priority one, it appears.

 

[Nemesiz]

Rename pool name on host or VM. Adjust boot settings.

 

[crash]

Rename pool name on host or VM. Adjust boot settings.

Can you link some reference on what adjustments are needed to be made in the boot settings and how to accomplish them?

In my search, the bare few mentions of this I found were very muddy on what needs to be adjusted.