I don't understand why this is a won't fix bug.
If users pick a long NIC name by themselves, then it's users'
responsibility to fix it. But apparently this is not the case, it's an
unexpected behavior caused by internal conflicts of different linux
components.
--
You received this bug notificati
** Changed in: systemd (Ubuntu)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1567744
Title:
USB NICs get too long name for ifupdown a
Hi,
we're running into the same problem and wonder whether we could use a
sub-string of the MAC address instead. Does the UDEV library support
something like $env{MAC_ADDR:6}?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to s
Just an update - this problem still exists in Ubuntu 16.04.3 LTS.
In case someone gets to this page due to this problem, there is a
workaround. Downside on this workaround is, that all network interface
names are then changed to eth0, eth1, eth2 etc, so one must change
settings on the /etc/network
Moving to "ubuntu-17.05" (in other words, "just past zesty release"). I
think this still needs to be addressed and I'm sorry it hasn't been
fixed yet. I'll revive the discussion on this subject and look at the
already proposed solutions.
Seems like we don't need vastly new technology to properly h
Good that we have a workaround - "net.ifnames=0 biosdevname=0". Still, I
think we need to reevaluate the importance level of "medium" - this is
toxic.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://
Milestoning, since we should try to not drop the ball on this bug; I
will need to revisit the mailing list thread and how exactly we do the
naming for these devices.
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
** Changed in: systemd (Ubuntu)
I just lost 3 days to this issue before I realized what was happening. I
realize this is an edge case, and understand the issues with fixing
this, but at least some type of better error messages would have helped
prevent that waste of time.
I was trying to setup a host to run docker with macvlan n
This feature worked well in my earlier installation (16.04LTS), but when
I re-installed the system yesterday, adding an alias to my USB network
adapter didn't work any more.
---8<---8<---
$ sudo ifup enx0016:0
RTNETLINK answers: Numerical result out of range
Failed to bring up enx0
Maybe, but that will affect all nics in all nodes.
** Summary changed:
- USB NICs get too long name for ifupdown aliases
+ USB NICs get too long name for ifupdown aliases or bridge names
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is sub
Doesn't adding "net.ifnames=0 biosdevname=0" to your kernel boot line
fix this for you? It will stop udev from creating the longer-than-
desired names.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https:/
I renamed the NIC in the MAAS node page to enx0 to workaround this
issue.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1567744
Title:
USB NICs get too long name for ifup
@andres that's a cool feature, btw :)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1567744
Title:
USB NICs get too long name for ifupdown aliases
Status in systemd pack
I just hit this deploying a MAAS2 xenial node that has a usb nic:
# ifup br-enx0023552c6029
Waiting for br-enx0023552c6029 to get ready (MAXWAIT is 76 seconds).
RTNETLINK answers: Numerical result out of range
Failed to bring up br-enx0023552c6029.
It went far enough to create the bridge, but w
Additionally, Juju creates bridges on top of both physical and VLAN
interfaces to allow for the same level of addressability for containers
as regular machines. The bridges currently use the "br-" prefix and the
underlying device name, which if it happens to be
"enxxaabbccddeef0.1234" already, obvi
This is also an issue for VLAN interfaces. To support VLANs, 10
characters should be the max. (16 - 1 [for \0], -1 [.], -4 [vid])
Throw in VLANs plus aliases, and, well, I guess we ought to use shorter
names, such as (I don't know) "eth0". ;-)
--
You received this bug notification because you ar
Indeed it's not iproute's fault, it's just an unforseen consequence of
using a long string like a MAC to name the device. Perhaps reducing it
by half and using just the second half of the MAC might be good? The
chance of collisions would remain pretty low.
--
You received this bug notification be
This isn't iproute's fault IMHO. There hasn't been much response to the
thread so far, and it's getting tight.
Reassigning to udev as that's where USB NIC names are set.
** Summary changed:
- RTNETLINK answers: Numerical result out of range for alias interface from a
usb NIC
+ USB NICs get too
18 matches
Mail list logo
