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.
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 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.
#!/bin/bash
if ifconfig eth0 | grep 192.168.x.x > /dev/null
then
echo "network running"
else
/usr/sbin/service networking start 2>&1 logger
echo "networking started"
fi
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.
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.
cyanide
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 .
.
.