2017-07-06 18:39 GMT-03:00 R0b0t1 <r03...@gmail.com>: > On Thu, Jul 6, 2017 at 2:44 PM, Francisco Ares <fra...@gmail.com> wrote: > > > > > > 2017-07-06 13:07 GMT-03:00 R0b0t1 <r03...@gmail.com>: > >> > >> On Thu, Jul 6, 2017 at 10:51 AM, Francisco Ares <fra...@gmail.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
