Please review, but don't merge as I'm still doing some testing. Thanks!

Please do no merge this, it's likely not the right location to fix this, and will possibly break multiarch.

Please do no merge this, it's likely not the right location to fix this, and will possibly break multiarch.

k. is that because those modules don't exist for non x86_64 ?

As pbrobinson said, this is not the right place to fix. The module should be added automatically by dracut in no "host-only" mode.
/me reads anything related to atomic and kmod...

As pbrobinson said, this is not the right place to fix. The module should be added automatically by dracut in no "host-only" mode.
/me reads anything related to atomic and kmod...

@kwizart, yes. I'll cancel this pull request. but would like to follow an issue somewhere where progress is being made on having this done in dracut itself?? Do you know where I can do that?

where can we follow up on this?

@kwizart ??

Please verify to have the dracut-config-generic package installed in your install set.
Then it's just a matter to have the dracut initramfs generated normally.

Usually "regular" livemedia images have the dracut-config-generic package installed, then removed in %post after the initramfs is generated. So end-users will default to a generic host agnostic image on first boot. But will have a lighter host-specific initramfs on later kernel updates.

If vmware/hyperv kernel modules aren't present on generic initramfs, then it's a matter to patch dracut upstream.
You can start looking at:
https://github.com/dracutdevs/dracut/tree/master/modules.d/90kernel-modules

That been said, you should be already have the --no-hostonly option from your json file
So it could also be an issue with theses kernel modules to have the appropriate alias or use the function so that dracut can autodetect them as disk drivers...
Probably Fixing dracut is the way forward

As pbrobinson said, this is not the right place to fix. The module should be added automatically by dracut in no "host-only" mode.

you are right, at least on f29 i verified that both "vmw_pvscsi", "hv_storvsc" are present when providing --no-hostonly. We're good here.