On Sat, 2015-12-26 at 12:44 -0200, Daniel Miranda wrote:
> I've written some udev rules to attempt to exclude docker and
> libvirt
> interfaces, but I'm not having great success. The bridges, even if
> marked with the NM_UNMANAGED=1 udev attribute are still showing up
> as
> managed. Only one
I've written some udev rules to attempt to exclude docker and libvirt
interfaces, but I'm not having great success. The bridges, even if
marked with the NM_UNMANAGED=1 udev attribute are still showing up as
managed. Only one of the libvirt interfaces (not the bridge) is ignored
as expected.
OK, I checked /usr/lib/udev/rules.d/85-nm-unmanaged.rules.
I extended it for my purposes (why there aren't rules by default for
libvirt and docker bridges btw?)
I am including updated rules file.
With all this in place. (NM config file is still the same)
$ udevadm test /sys/class/net/tap0
[ --
Ops, forgot to attach the file :/
On Wed, Nov 18, 2015 at 10:06 AM Jetchko Jekov
wrote:
> OK, I checked /usr/lib/udev/rules.d/85-nm-unmanaged.rules.
> I extended it for my purposes (why there aren't rules by default for
> libvirt and docker bridges btw?)
> I am
On Wed, 2015-11-18 at 09:06 +, Jetchko Jekov wrote:
> OK, I checked /usr/lib/udev/rules.d/85-nm-unmanaged.rules.
> I extended it for my purposes (w)hy there aren't rules by default for
> libvirt and docker bridges btw?
NM makes a distinction between software/virtual interfaces (like
On Mon, 2015-11-16 at 21:58 +, Jetchko Jekov wrote:
> OK, I spent some time with filtering of NM log. I removed the debug
> lines related to WiFi connections management (they contain way too
> much sensitive data IMO, and are irrelevant to my problem anyway).
> Still the resulting file is
Hi,
Here it is.
Jeka
On Tue, Nov 17, 2015 at 2:25 PM Thomas Haller wrote:
> On Mon, 2015-11-16 at 21:58 +, Jetchko Jekov wrote:
> > OK, I spent some time with filtering of NM log. I removed the debug
> > lines related to WiFi connections management (they contain way too
On Tue, 2015-11-17 at 13:30 +, Jetchko Jekov wrote:
> Hi,
> Here it is.
NM will always detect all kernel interfaces and expose them through its
APIs, but it will *not* necessarily actively manage them. That is what
an "unmanaged" device means. But NM will still reflect the state of
that
I am not comfortable sending full NM log (even partially filtered) on
public mailing list. is there a way to do it privately?
Br,
Jeka
On Mon, Nov 16, 2015 at 4:29 PM Thomas Haller wrote:
> On Mon, 2015-11-16 at 15:05 +, Jetchko Jekov wrote:
> > Hello,
> >
> > I am
On Mon, 2015-11-16 at 15:05 +, Jetchko Jekov wrote:
> Hello,
>
> I am pretty sure that this question was raised several times already
> on this list as I found some references when searching. But somehow
> none of proposed settings work for me.
>
> In general, I want to tell NM to ignore all
Hello,
I am pretty sure that this question was raised several times already on
this list as I found some references when searching. But somehow none of
proposed settings work for me.
In general, I want to tell NM to ignore all virtual interfaces which are
not explicitly created with it. For
OK, I spent some time with filtering of NM log. I removed the debug lines
related to WiFi connections management (they contain way too much sensitive
data IMO, and are irrelevant to my problem anyway). Still the resulting
file is around 280k (1,5k lines), so the question is: Is it OK to attach
12 matches
Mail list logo