Re: [gentoo-user] mixing predictable with old style network interface naming

[Francisco Ares]

2017-07-06 18:39 GMT-03:00 R0b0t1 <r030t1@×××××.com>:

> On Thu, Jul 6, 2017 at 2:44 PM, Francisco Ares <frares@×××××.com> wrote:
> >
> >
> > 2017-07-06 13:07 GMT-03:00 R0b0t1 <r030t1@×××××.com>:
> >>
> >> On Thu, Jul 6, 2017 at 10:51 AM, Francisco Ares <frares@×××××.com>
> wrote:
> >> > Hi, All.
> >> >
> >> > This is a bit odd, because of a non conventional hardware platform:
> >> > Odroid
> >> > (Hardkernel).
> >> >
> >> > But I guess overall rules apply to all.
> >> >
> >> > I need a second network interface, the original and single one present
> >> > on
> >> > the board is to be connected to a GigE camera, so I use a USB/ethernet
> >> > adapter to have SSH remote access.
> >> >
> >> > I have set up the boot manager so that network interfaces would be
> named
> >> > according to the predictable names rules. If not, the USB/eth adapter
> >> > gets
> >> > "eth0" if the device is present at boot, otherwise, it is "eth1".
> >> >
> >> > But if I disconnect the USB/ethernet adapter to leave the system
> alone,
> >> > and
> >> > after a while I need to take a look on what's going on and plug back
> the
> >> > USB/ethernet adapter, it comes up as "eth0" again.
> >> >
> >> > Anyone could give me a hint on where to look at it?  Why the new
> >> > interface
> >> > is named in a way during boot and another during normal use?
> >> >
> >> > Thank you!
> >>
> >> Your question doesn't seem to involve any mixing of the naming schemes
> >> at all, and it looks like the kernel you are using simply uses the old
> >> style names. Can you compile your own kernel which supports the new
> >> naming convention, remove net.ifnames=0 from the kernel command line
> >> if it is present, or check for udev rules that perform naming that
> >> overrides the default? You may wish to refer to
> >>
> >> https://wiki.gentoo.org/wiki/Handbook:X86/Networking/
> Advanced#Network_interface_naming
> >> though it is not very information dense.
> >>
> >> Unfortunately my experience with hardkernel devices is that the
> >> developers put most of their effort behind the Android release and
> >> will make an Ubuntu release, if it exists, barely work. I would
> >> strongly recommend not buying their devices. They barely support them
> >> and without their help the devices are unsupportable.
> >>
> >> R0b0t1.
> >>
> >
> >
> > Thanks for the tip.  I've checked in /etc/udev files and directories, and
> > there is no rule for naming interfaces.
> >
> > Instead of removing "net.ifnames=0" from the kernel command line, I have
> > altered it to "net.ifnames=1". Gonna try removing it at once.
> >
>
> I would expect that to work as you did, are you using their kernel? If
> you are I believe there is an option to force the old-style naming by
> effectively removing the code which does the new-style naming. That's
> why I asked.
>
> > But, imho, Odroid is a good hardware, and I have learned a lot about
> Linux -
> > not Android - in their Odroid magazine. And their Ubuntu image works very
> > good. And, as always, there are a lot of guys in the community.
> >
>
> It is some of the best available hardware, but the support its
> manufacturer provides isn't amazing. It's the bare minimum to get it
> to work. Admittedly they did have a bit more customer involvement than
> I've seen elsewhere at first (e.g. signing user-provided code with
> Samsung keys to enable ARM TrustZone for QEMU) but they are still
> focused on making money, and sell whatever it is they can as quickly
> as possible and then move on to the next thing and avoid supporting
> past products.
>
> R0b0t1.
>
>
I have cloned their git kernel repository, and built a new kernel (not yet
the initrd) as from here:

https://wiki.gentoo.org/wiki/Xu4#Installing_Gentoo_on_an_Odroid-XU4
(already updated a few details here, too)

The "boot.ini" configuration for the boot loader did present a
"net.ifnames=0".  Now I have removed it, but still could not reboot, I'm in
the middle of a "emerge -e world", as many files got corrupted because of a
power failure during a move operation from a media to another. Now building
also binary packages to keep them safe in another device.  And using a UPS
;-)

On that article about net interfaces naming, I found a workaround using
udev rules just for this period of implementation.

Thanks for your point of view about hardkernel, I'll keep an eye on them.

Thank you, again,
Francisco