On 11/17/21 1:39 PM, Michael Ströder wrote:
HI!
Is it possible to configure the full path name of the ebtables executable used somewhere in libvirt's config?
That's done in meson.build when you're building from source. Look for "optional_programs".
Background: I'd like to avoid automatic alternatives implementation to mess up libvirt installation.
See also: https://bugzilla.opensuse.org/show_bug.cgi?id=1192799
I don't think the problem is what is being suggested in that bug. Your claim about /etc/alternatives in comment 3 doesn't make any sense - I have ebtables-2.0.11 installed on my Fedora machine, and it is using /etc/alternatives, and I don't get that error message. Try running this command: /sbin/ebtables -t nat -N xyzzy and see if it gives you the same error. If it does, then follow the symlink from /sbin/ebtables to (probably) /etc/alternatives/ebtables and to the final destination from there - you should either end up with /usr/sbin/ebtables-legacy or /usr/sbin/ebtables-nft. If you don't, then your "alternatives" stuff is messed up, and you need to fix that. I just checked the current source code for ebtables and the word "subcommand" doesn't appear anywhere in it. This sounds more like SUSE has some sort of special off-brand alternative that doesn't understand all valid ebtables commands (because the command being complained about in the error message in the bug *is* a valid ebtables commandline); maybe something that put's a shell script wrapper around calling ebtables or something?. If so, you need to switch away from that alternative, or somebody needs to fix the alternative. Anyway, I think you'd be better off fixing the problem at the source rather than trying to make some special local build of libvirt to work around the problem.