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.