guidol Posted November 30, 2017 Posted November 30, 2017 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
Hian Posted December 18, 2017 Posted December 18, 2017 I have the same problem after updating from 5.25 to 5.35. IP was given the first time. After SSH login, modified the password and reboot, failed to get ip. Any solution instead of workaround?
Igor Posted December 18, 2017 Posted December 18, 2017 If you have internet access please provide the output of: armbianmonitor -u Also good to know: uname -a
Hian Posted December 18, 2017 Posted December 18, 2017 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.
keckec Posted December 20, 2017 Posted December 20, 2017 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.
gahabana Posted December 26, 2017 Posted December 26, 2017 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.
TonyMac32 Posted December 27, 2017 Posted December 27, 2017 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.
moricef Posted February 7, 2018 Posted February 7, 2018 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."
zador.blood.stained Posted February 7, 2018 Posted February 7, 2018 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.
Recommended Posts