ODroid XU4 - v6.15 - Network settings not saved on reboot.

Just updated my odroid xu4 to dietpi 6.15

Network settings are lost on reboot. Here is how I have them (replace xx with IP):
IP: 192.168.1.xx/24
DNS: (Pihole)

Extra hosts added to /etc/hosts

Behavior noticed after the update to 6.15

Upon every reboot, eth0 isn’t brought up automatically.

I have to do the following:

ifconfig eth0 up
ifconfig eth0 192.168.1.xx netmask
route add default gw

Setting them in dietpi-config does nothing. The /etc/network/interfaces file has the correct settings. But they are not applied on startup. This is a big problem because the odroid is running headless, so I need to attach a monitor and a keyboard to turn on networking again.

I am experiencing the exact same issue. At least now I have a temp fix. Thank you.

Could you put that string in /etc/rc.local?

ifconfig eth0 up
ifconfig eth0 192.168.1.xx netmask
route add default gw

Odd that it doesn’t come up…

Further discussion is carried on here: https://github.com/Fourdee/DietPi/issues/2071

If anyone has anything to add or another data point, please feel free to join in.

The easier thing is to simply do

service networking start


systemctl start networking

No need to even enter the ifconfig or route command. The networking service fails to start on boot and this causes the actual issue.

It does not work on my Odroid C2

If you are on Jessie, could you please try:

sed -i '/[[:blank:]]Workaround_WiFi$/a\\t\tsystemctl start networking' /DietPi/dietpi/boot

6.16 did NOT fix this issue.

Indeed, I also thought that this fix needs to be done first, as it breaks all Jessie systems :thinking:.

However did you try the above?

Not yet. I just do the following:

ifconfig eth0 up
ifconfig eth0 netmask
route add default gw

edit the following DNS

nano /etc/resolv.conf

You can either follow MichaIng’s instruction or do

sudo service networking start

instead of the ifconfig and route commands. It will bring up the interface and restore your network settings. I guess 6.17 will have the fix for this.

Jep exactly, the networking service is the one that fails on boot due to the dependency bug and manually starting it includes all the interface and resolver steps/settings.

My command suggestion above adds the manual networking service start to DietPi boot script, so you do not need any manual step anymore afterwards.

I tried that but it didn’t work for me.

dosent work on Odroid C2 only this work
sudo service networking start
then dietpi-config, networking, ethernet, save and restart…

why? any idea?

It is a Debian Jessie issue. Wait for fix in Dietpi 6.17 most probably.

I wish they would get Debian Stretch up and running for the XU4. That would have fixed the pi-hole issue as well apparently. They went straight for the pi-hole issue rather then move to stretch so it is probably a bigger thing then I would understand.

I do wish they could fix this asap as I used to try to reboot my device every 3 days or so and cannot until they fix this unless I get a keyboard and type in the commands manually. Perks of a headless server.

Save this as a .sh file in your root’s home folder, chmod +x it. Replace the IP to whatever your local IP should be set to.


if ifconfig eth0 | grep 192.168.x.x > /dev/null
        echo "network running"
        /usr/sbin/service networking start 2>&1 logger
        echo "networking started"

Add it in root’s crontab like so:

*/1 * * * * /root/networkcheck.sh

The script will run every minute and if it sees the network down, it will start it. Usually takes about a minute after I start my system for the network to come up and start working. Incredibly “hackish” but it works for now and the fix is just having to remove the crontab entry.

We have a Debian Stretch image for XU4: https://dietpi.com/downloads/images/DietPi_OdroidXU4-ARMv7-Stretch.7z

Also there is no Pi-hole issue with Jessie any more since Pi-hole v4.0, so this should work in every case.

sed -i '/[[:blank:]]Workaround_WiFi$/a\\t\tsystemctl start networking' /DietPi/dietpi/boot

This does not work in your case?

cat /DietPi/dietpi/boot | grep 'systemctl start networking'

Does this show an output?

Interesting. Two questions…

  1. Will this be rolled out into the dietpi-update system? I’m currently on 6.15, Jessie as per /etc/os-release, planning on upgrading to 6.16 over the weekend. But if there is no roadmap for the updater to migrate the system to Stretch automatically, I would rather move my setup to Stretch.
  2. Will this networking bug be present in Stretch?

The fix is already implemented for coming v6.17 release, not yet in v6.16.

We will not officially support a Jessie → Stretch migration. The possible failures are simply too much to test/sort out for all devices and system setups. Impossible to guarantee it works fine and you will not face any issues afterwards.
Since not only DietPi, but also the offered base images from manufacturers contain config and system files outside of APT packages, the apt full-upgrade after manually adjusting the APT sources will leave your system partly in between Jessie and Stretch. Or lets say, those outside of APT placed files and binaries will expect the system to be Jessie. Unpredictable if this will directly or later cause issues and if those are critical or ignorable.

  • Of course nothing can prevent you from simply trying. Do a dietpi-backup first of course, or perhaps a full SDcard/drive backup.
  • Reduce installed software/packages to a minimum first, clean your system as much as you manually can first as well.
  • The less packages, files and services/processes running, the higher the change for a sustainable successful distro upgrade.

But finally you will go better with a fresh image. You can do dietpi-backup to an external drive/card and in case recover manually adjusted config files and/or placed binaries/software from the backup then. Keep the backup for some time, until you are sure really everything works as before.

There are no known networking bugs on Stretch, besides using magic characters as WiFi password, which we currently try to fix/handle/support: https://github.com/Fourdee/DietPi/issues/2087

Ah, one other external bug, but this seems to occur only in veeeery rare cases, since it survived for years inside official Debian package: https://github.com/Fourdee/DietPi/issues/2074

  • Finally our report got this fixed, for now on unstable repo. I hope it will be backported at least to Stretch soon.

Another topic, since I see you guys often use old net-tools commands (ifconfig, route, …):


This program is obsolete! For replacement check ip addr and ip link. For statistics use ip -s link.

Use ip a s eth0 instead.

Also /usr/sbin/service networking start should only work on Jessie, as they use deprecated (on Debian) init.d service there.
To have this working on Stretch as well (also works on Jessie), use systemctl start networking to handle it in systemd service way.

I would also suggest this running only once at/after boot, as of my command above. If this does not work, then the issue would need further investigation.
Running a cron job every minute is no sustainable solution, since it spams the syslog and takes quite some resources. If the network really breaks repeatedly randomly, there is a more serious issue with either the network or the servers network/system config, that should be fixed instead :wink:.