Jump to content
  • 0

No IP-assignment with C2 and 3.14.79-odroidc2

guidol

Asked by guidol,

 Share

Question

guidol

guidol

Posted
Posted

Today I installed Armbian_5.35_Odroidc2_Debian_jessie_default_3.14.79 on my Odroid C2

Installation went fine and I got a DHCP-IP

 

But now neither armbian-config will configure me a IP to eth0 (only device lo) nor /etc/network/interfaces would be "read" when I manually edit it to eth0

So I cleared the file.

nmtui does let me configure a connection and I could activate this connection. At this time I got a/the right IP.

 

But after a reboot this IP wouldnt reconnected.

Every boot I do get an additional connection eth0 generated.

 

Before boot 

root@odroidc2:~# nmcli con show
NAME   UUID                                  TYPE            DEVICE
guido  2b96719d-bbee-4fef-9848-8663cda99dcc  802-3-ethernet  eth0
eth0   3888b480-d230-4bf7-a3b3-076f4b61b35b  802-3-ethernet  --

After next boot 

root@odroidc2:~# nmcli con show
NAME   UUID                                  TYPE            DEVICE
eth0   569592fe-7704-4054-bb6a-74567526cd72  802-3-ethernet  --
guido  2b96719d-bbee-4fef-9848-8663cda99dcc  802-3-ethernet  eth0
eth0   3888b480-d230-4bf7-a3b3-076f4b61b35b  802-3-ethernet  --


So I named "my" connection guido and did try the following in the /etc/rc.local 

nmcli con down eth0
nmcli con up guido

but on startup the boot-log (not in dmesg) shows me: 

[FAILED] Failed to start /etc/rc.local Compatibility.

[EDIT] as workaround it does work with these 2 nmcli config-lines if I put a "sleep 1" before them in the /etc/rc.local
but this shouldnt be the final solution :)

 

But manually these command does work: 

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection2)

 

root@odroidc2:~# armbianmonitor -u
System diagnosis information will now be uploaded to http://sprunge.us/ADIU

 

 

Link to comment
Share on other sites

8 answers to this question

Recommended Posts

Help us fund some #badass gear for our continuous integration build framework

  • 0
Hian

Hian

Posted
Posted

Hi Igor,

Here is what I have the first time I logged in. After changing root password and creating a user account, and reboot, failed to get ip. I don't have this issue when I retried version 5.25 from the fresh.

 

Linux odroidc2 3.14.79-odroidc2 #4 SMP PREEMPT Wed Nov 22 16:09:18 CET 2017 aarch64 GNU/Linux

 

System diagnosis information will now be uploaded to <html>
 <head>
  <title>500 Internal Server Error</title>
 </head>
 <body>
  <h1>500 Internal Server Error</h1>
  The server has either erred or is incapable of performing the requested operation.<br /><br />

 </body>
</html>Please post the URL in the forum where you've been asked for.

Link to comment
Share on other sites
  • 0
keckec

keckec

Posted
Posted

I'm having the same problem on a new install of Armbian_5.35_Odroidc2_Debian_jessie_default_3.14.79 on an Odroid C2. Networking is fine on first boot, but after setting root password, creating new user, and reboot, eth0 doesn't connect.

 

Output from   # armbianmonitor -U   is here:  http://sprunge.us/EOZQ

Output from  # uname -a   is this:   Linux odroidc2 3.14.79-odroidc2 #4 SMP PREEMPT Wed Nov 22 16:09:18 CET 2017 aarch64 GNU/Linux

 

After quite a bit of fiddling using nmcli, renaming devices and connections, and several reboots, this seems to have resolved itself and it now connects and gets an IP via dhcp.

Link to comment
Share on other sites
  • 0
gahabana

gahabana

Posted
Posted

I've foudn solution to be commenting of the line where MAC address is assigned on OdroidC2 in /etc/network/interfafces

It should not cause a problem but my guess is something is causing incompatibility recently and if user defined MAC address is asigned to the adapter (so that it would get always same DHCP IP address) ... things are going awry. Not sure if it is caused by some changes in Kernel over last 1-2 months or something else ... but that is the solution ... my OdroidC2 seems to show always same MAC address upon boot so i don't need it.

Link to comment
Share on other sites
  • 0
TonyMac32

TonyMac32

Posted
Posted

https://github.com/hardkernel/u-boot/commit/460fc4d3f4e97e8044cfba68ee8536d1b461d72c

 

That should have made the MAC address correct/consistent on boot, assuming Hardkernel is setting it from factory.  The only reason I'm not having any luck with this method on Le Potato and the K2 is that those devices are blank from factory.

Link to comment
Share on other sites
  • 0
moricef

moricef

Posted
Posted

This kind of problem would not it be due to the fact that now it is that the network is configured by systemd?  the Predictable Network Interface Names does not just prevent this kind of problem of confusion of the kernel at boot?

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ :

"The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.

To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back."

Link to comment
Share on other sites
  • 0
zador.blood.stained

zador.blood.stained

Posted
Posted
3 minutes ago, moricef said:

This kind of problem would not it be due to the fact that now it is that the network is configured by systemd?

Network is not configured by systemd by default, unless you create files in /etc/systemd/network and enable several additional services.

 

6 minutes ago, moricef said:

the Predictable Network Interface Names does not just prevent this kind of problem of confusion of the kernel at boot?

Predictable names rely on devices having HW MAC addresses, and most SBC devices have no hardware MAC addresses and usually have different methods for generating a persistent MAC based on CPU serial number or storing a randomly generated MAC somewhere. Sometimes this does not work as intended.

 

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to question listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept