Dietpi: Odroid XU4 - v6.15 - Network is not brought up automatically on reboot, and settings are not restored.

[NNpranav]

Network is not brought up automatically on reboot and when brought up manually, settings are not restored.

Required Information:

• DietPi version | 6.15
• Distro version | 8.11
• Kernel version | Linux Sirius 3.10.106+ #1 SMP PREEMPT Fri Nov 24 16:26:38 CET 2017 armv7l GNU/Linux
• SBC device | Odroid XU3/XU4/HC1/HC2 (armv7l)
• Power supply used | 5V 6A.
• SDcard used | Strontium 32GB Class10

Additional Information (if applicable):

• Software title | DietPi
• Was the software title installed freshly or updated/migrated? YES. First reboot after updating to v6.15 and ever since.
• Can this issue be replicated on a fresh installation of DietPi? No Idea

Steps to reproduce:

1. Update Odroid XU4 to DietPi v6.15
2. Reboot

Expected behaviour:

• Networking should pick up saved settings and bring up eth0 automatically on boot-up.

Actual behaviour:

• eth0 is not brought up automatically. Doing ifconfig eth0 up brings up the adapter but network settings are not restored.
• I have to manually enter the following commands ifconfig eth0 192.168.1.xx netmask 255.255.255.0 and route add default gw 192.168.1.1
• Using dietpi-config to set the adapter settings does not work. It keeps using 0.0.0.0 settings for all, even after changing to STATIC and entering the addresses manually and applying the settings.

Extra details:

• /etc/network/interfaces has the correct settings, but they are not applied.
• /etc/resolv.conf points to 127.0.0.1 (Using Pihole)
• I have added a few LAN hosts to /etc/hosts to help resolve local computers.

[MichaIng]

@NNpranav
Thanks for your report.

Hmm due to?: https://github.com/Fourdee/DietPi/blob/6993afc5ddfc737dfbd9af844d9c8081fb8d5de2/rootfs/etc/network/if-up.d/dietpi-disable_offload

• Is the interface brought up as well with exit code 1?
• Could you try to temporary move the file above out of place and reboot?

Btw use the newer ip command to apply interface setting instead of ifconfig. The related net-tools package is outdated and not pre-installed on DietPi anymore.

[NNpranav]

Doesn't seem to be due to dietpi-disable_offload. Not sure how you can check the exit code but I ran the script again and it showed no output.

Moved the file and rebooted, same issue.

Upon running dietpi-config and disabling the eth0 interface, I get messages about stopping and starting services (the usual), and the following:
Cannot find device "0"
Cannot find device "SCHED_OTHER"
Cannot find device "0-7"
Cannot find device "0"

Upon enabling eth0 from dietpi-config again, I get the usual messages, plus:

[ INFO ] DietPi-Config | Dropping connections, please wait...
[ INFO ] DietPi-Config | Restarting network, please wait...
ifup: failed to open lockfile /run/network/.ifstate.lock: No such file or directory

The last line seems to be relevant, but I don't even have a "network" dir inside /run

[Fourdee]

Notes:

Cannot find device "0"
Cannot find device "SCHED_OTHER"
Cannot find device "0-7"
Cannot find device "0"

Process_Tool

Strontium SD

---

Tests:

• Pi-hole

eth0 is not brought up automatically. Doing ifconfig eth0 up brings up the adapter but network settings are not restored.

Using dietpi-config to set the adapter settings does not work. It keeps using 0.0.0.0 settings for all, even after changing to STATIC and entering the addresses manually and applying the settings.

• Master branch install image
• install pi-hole
• Set static when prompted
• finish install, reboot.
• 🈯️ Working fine

---

• Use dietpi-config to change IP address
• Reboot
• 🈯️ Working fine
• 🈯️

root@DietPi:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

root@DietPi:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 DietPi

[Fourdee]

@NNpranav

Unable to replicate in local testing: https://github.com/Fourdee/DietPi/issues/2071#issuecomment-421082225

We'll need to debug your system, please paste/screenshot results:

• cat /etc/hosts
• cat /etc/network/interfaces
• cat /etc/dhcpcd.conf
• dmesg | grep eth

---

Interesting, /etc/network/interfaces takes priority.

/etc/dhcpcd.conf
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
interface eth0
    static ip_address=192.168.0.111/24
    static routers=192.168.0.1
    static domain_name_servers=127.0.0.1

# Ethernet
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.118
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 8.8.8.8

We should detect Pi-hole install and set dns-nameservers 127.... and /etc/dhcpcd.conf

[NNpranav]

Contents of /etc/hosts:
127.0.0.1 localhost
127.0.0.1 Sirius

Contents of /etc/network/interfaces:
#/etc/network/interfaces
#Please use DietPi-Config to modify network settings.
# Local
auto lo
iface lo inet loopback
# Ethernet
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.88
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4
# Wifi
#allow-hotplug wlan0
iface wlan0 inet dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#dns-nameservers 8.8.8.8 8.8.4.4

/etc/dhcpd.conf does not exist. I am running it as a static IP with Pihole acting as DHCP and DNS server on the network.

Output of dmesg | grep -i eth

[ 0.361949] [c7] vdd_eth: 3300 mV
[ 8.688362] [c7] usbcore: registered new interface driver cdc_ether
[ 8.904214] [c5] r8152 6-1:1.0 eth0: v2.07.0 (2016/06/14)
[ 8.904246] [c5] r8152 6-1:1.0 eth0: This product is covered by one or more of the following patents:

[NNpranav]

Interestingly,
service networking start
or
systemctl start networking

fixes the issue. Settings are loaded automatically and the interface comes up. The 'networking' service is already enabled, but it seems to be failing.

[Fourdee]

@NNpranav

Thanks

Settings are loaded automatically and the interface comes up. The 'networking' service is already enabled, but it seems to be failing.

Debug with:

systemctl status networking -l

Which version of Pi-hole is running on the system? (bottom right of web interface)

And does hostname match hosts?

cat /etc/hostname

[MichaIng]

@Fourdee @NNpranav
Found the issue I guess, that is responsible for this, and might be related to the other WiFi issue as well:

• It seems dietpi-preboot created a dependency cycle that is resolved by systemd by skipping the networking.service, so no interface is brought up. But I could not follow the loop to far, have to check carefully.
• But somehow it seems to be not an issue in every case.

[NNpranav]

Pihole: Pi-hole Version vDev (HEAD, v3.2.1-0-ge602008) Web Interface Version vDev (HEAD, v3.2.1-0-g31dddd8-dirty) FTL Version vDev (v2.13.2 , v2.13.2 )

I switched to this development version because Pihole had broken the web interface after an update. I haven't updated it since.

Output of /etc/hostname is 'Sirius', my hostname. Matches the entry in /etc/hosts

Output of systemctl status networking -l (after starting the networking service):

root@Sirius:~# systemctl status networking -l
● networking.service - LSB: Raise network interfaces.
Loaded: loaded (/etc/init.d/networking)
Drop-In: /run/systemd/generator/networking.service.d
└─50-insserv.conf-$network.conf
/lib/systemd/system/networking.service.d
└─network-pre.conf
Active: active (exited) since Fri 2018-09-14 01:05:31 IST; 5min ago
Process: 3654 ExecStart=/etc/init.d/networking start (code=exited, status=0/SUCCESS)

Sep 14 01:05:31 Sirius networking[3654]: Configuring network interfaces...ifup: interface eth0 already configured
Sep 14 01:05:31 Sirius networking[3654]: done.
Sep 14 01:05:31 Sirius systemd[1]: Started LSB: Raise network interfaces..

[Fourdee]

@NNpranav

Pi-hole uses dnsmasq for this version. This has changed for v4.0.

As this issue cannot be replicated in our testing, please try re-writing the DietPi image and installing Pi-hole v4.0 (stable) through dietpi-software:
https://dietpi.com/downloads/images/DietPi_OdroidXU4-ARMv7-Stretch.7z

[NNpranav]

I have installed Pi-hole v4.0 through their installer (after uninstalling the previous DEV branch) as I cannot see an entry for Pi-hole in dietpi-software.

The issue still persists after upgrading to Pihole 4.0.

[MichaIng]

@Fourdee
Check my post above. I could replicate the same issue on my Jessie VM.
Was able to identify the cycle that systemd finds:

root@VM-Jessie:/lib/systemd/system# systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After networking
Requires=
Requisite=
Wants=network.target system.slice
BindsTo=
PartOf=
Before=sysinit.target shutdown.target network.target dietpi-boot.service
After=mountkernfs.service local-fs.target systemd-random-seed.service network-pre.target systemd-sysctl.service systemd-modules-load.service systemd-journald.socket system.slice resolvconf.service dietpi-preboot.service

• networking wants to run before sysinit.target
• But sysinit.target runs before basic.target, which is required by all our services.
• So it's: networking -> sysinit -> basic -> preboot -> networking
• Interestingly this is no issue on Stretch. There all our services require sysinit.target and networking does not want to run before it.

On Stretch, networking is a systemd service, on Jessie it's init.d, where I can't find any explizit sysinit entry. Not sure, if on Jessie all init.d services want to run before sysinit.target somehow? Would not make sense... and this would mean we have no change to add an ordinary systemd service to run before networking...

• Ref: https://unix.stackexchange.com/questions/229048/how-to-start-a-systemd-service-before-networking-starts
  
  
  
  • https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771118 ?
  
  
  • ... due to failed service before? https://bbs.archlinux.org/viewtopic.php?id=145075
  
  

root@VM-Jessie:~# cat /lib/systemd/system/graphical.target
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
Wants=display-manager.service
AllowIsolate=yes
root@VM-Jessie:~# systemctl status display-manager.service
● display-manager.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
root@VM-Jessie:~# systemctl show -p Requires,Wants,Requisite,WantedBy,BindsTo,PartOf,Before,After graphical.target
Requires=multi-user.target
Requisite=
Wants=display-manager.service systemd-update-utmp-runlevel.service dropbear.service dirmngr.service
BindsTo=
PartOf=
WantedBy=
Before=systemd-readahead-done.timer systemd-readahead-done.service systemd-update-utmp-runlevel.service
After=dirmngr.service dropbear.service multi-user.target

• Okay the above is not the issue. Removing Wants=display-manager.service from graphical.target resolves the error on starting display-manager.service, but it does not solve the dependency cycle, so seems to be expected, if no desktop is installed.
  No idea why our services depend on sysinit and basic targets, but sounds reasonable as very early boot stage targets. The more strange question is, why networking wants to run before sysinit/basic on Jessie, and how we can change that.

[Fourdee]

@NNpranav

Pi-hole is near the bottom of optimized software list:

You can also use the search feature to search for hole:

As you have installed via non-dietpi-software, you'll also need to tweak the Pi-hole service:

• Copy and paste all into term

# - Fix service to disable syslog pre-req preventing start
G_CONFIG_INJECT '# Required-Stop:' '# Required-Stop: $network $remote_fs' /etc/init.d/pihole-FTL
G_CONFIG_INJECT '# Required-Start:' '# Required-Start: $network $remote_fs' /etc/init.d/pihole-FTL

Unless Pi-hole has updated/resolved the above, the service wont run, unless rsyslog is installed

---

Check my post above. I could replicate the same issue on my Jessie VM.

@MichaIng
Yep, looks a Jessie specific issue, i've been unable to replicate it on any of our Stretch images. However, I believe @NNpranav you are running our stretch image?

cat /etc/os-release

---

I suspect the following may be due to a filesystem corruption:

Cannot find device "0"
Cannot find device "SCHED_OTHER"
Cannot find device "0-7"
Cannot find device "0"

@NNpranav

Any power cuts/hard power off when system was on?
May be worth checking for mmc issues with:

dmesg | grep mmc

[Fourdee]

This is also running extremely late in boot process:

[ 8.688362] [c7] usbcore: registered new interface driver cdc_ether

Should be eariler:

[    0.471207] usbcore: registered new interface driver cdc_ether

Might be the reason why its not being brought up automatically, as the hardware has not yet been detected by kernel.

---

@NNpranav

Doing ifconfig eth0 up brings up the adapter but network settings are not restored.

Same issue with?:

ifdown eth0
ifup eth0

[Fourdee]

@MichaIng

New ticket for the Jessie sysinit/systemD issue skipping networking:
https://github.com/Fourdee/DietPi/issues/2075

[NNpranav]

@Fourdee
I do not have Pihole in the list, screenshot attached. No results on searching either. That, itself is not an issue for me.

I did have a dirty shut-down, that issue has been fixed.

/etc/os-release:
root@Sirius:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Will confirm the ifdown eth0 and ifup eth0 results later today.

[MichaIng]

@Fourdee

Distro version | 8.11

Jessie 😉.

Oh my goodness, we forgot an important thing about Pi-hole FTLDNS: Jessie is supported again, as no dnsmasq (required version broke Jessie support) is needed any more 🙈. But I will test, just to be sure.

• 🈯️ Install, service start and WebUI works like a charm on my Jessie VM 👍
• 🈯️ Commit sent: https://github.com/Fourdee/DietPi/commit/6d34e4e27234672d3115d1041d3d2bbff49ba134
• 🈯️ Changelog: https://github.com/Fourdee/DietPi/commit/de30fd9780873f20adfa6ae6822272dcc47be306

@NNpranav
You can manually enable/test it:
nano /DietPi/dietpi/dietpi-software
Remove the following lines a after index_current=93 (Pi-hole):

        #Disable Jessie: https://github.com/Fourdee/DietPi/issues/1524
        if (( $G_DISTRO == 3 )); then

            aSOFTWARE_AVAIL_G_HW_MODEL[$index_current,$G_HW_MODEL]=0

        fi

[NNpranav]

@MichaIng
Sure, will do. I guess we can close this since the root cause has been identified and an applicable issue has been created. Thanks!