qemu-kvm should be replaced by a better "grub install" strategy

[ManuelAmadorAditazz]

alternatively use qemu-kvm stdio to console instead, so we can script the root device password

[seriv]

I confirm need to replace qemu-kvm: zpool created on physical device, like USB flash drive, when used in qemu-kvm, gets virtual names of the device and stores it somewhere in zfs cache in initramfs. Then on attempt to boot in physical machine from this USB flash, zpool is in faulted state, and the only way I've discovered to get out of this state is to import zpool renaming it to some different name, destroy cached faulted zpool, then export renamed zpool and reboot and edit manually in grub menu the lines to use this new zpool name.

[Rudd-O]

That's weird because the very point of using qemu is that I export the pool first so it'll boot cleanly in qemu, and then get the device name that it would get in the real...

ahh.... I see. So in qemu it gets a weird device name that does not correspond at all with what the actual device is, and then it fails to import?

I am stumped as to how to fix this bug! What do you suggest?

[maci0]

maybe using /dev/disk/by-label/ ?

[Rudd-O]

Try it with file-backed vs. Device-backed "devices" and you will be able to notice whether the devices work fine in both cases. Consider that the program supports encryption too.

[Rudd-O]

Alright, the initial RAM disk that we create does no longer include a zpool.cache file with labels or anything — it is generated as no-hostonly — so the pool should import fine on first boot in bare metal, by relying on scan import rather than cache import.

My testing rig tests both hostonly and no-hostonly initial RAM disks. They work okay.

We also — finally! — use qemu-kvm stdio to script things like password prompts properly.