Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WireGuard and Lighttpd not working after update to v6.26.3 #3175

Closed
Joulinar opened this issue Oct 18, 2019 · 23 comments
Closed

WireGuard and Lighttpd not working after update to v6.26.3 #3175

Joulinar opened this issue Oct 18, 2019 · 23 comments
Labels
Bug 🐞 Solution available 🥂 Definite solution has been done
Milestone
v6.27

Comments

@Joulinar
Copy link
Collaborator

Required Information

  • DietPi version | 6.26.3
  • Distro version | stretch
  • Kernel version | Linux DietPi_DEV 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
  • SBC device | RPi 3 Model B (armv7l)
  • Power supply used | na
  • SDcard used | SanDisk Ultra

Additional Information (if applicable)

  • Software title | Wireguard and PiHole
  • Was the software title installed freshly or updated/migrated? | updated from v6.25.3
  • Can this issue be replicated on a fresh installation of DietPi? | not tested

Steps to reproduce

  1. run dietpi-update from v6.25.3 to v6.26.3

Expected behaviour

  • Wireguard and PiHole should work after updating to v6.26.3

Actual behaviour

  • Wiregurd not starting
  • Lighttpd Daemon not starting

Extra details

I have quite some issues after updating to v6.26.3
I have seen that Wireguard was uninstalled during the update. But it was not reinstalled.

-------- Uninstall Beginning --------
Module:  wireguard
Version: 0.0.20190702
Kernel:  4.19.57+ (armv7l)
-------------------------------------
...
...
DKMS: uninstall completed.
------------------------------
Deleting module version: 0.0.20190702
completely from the DKMS tree.
------------------------------
Done.

Howerver I see in journalctl that the system is still trying to start wg0 during boot.

Okt 18 20:01:12 DietPi_DEV wg-quick[614]: [#] ip link add wg0 type wireguard
Okt 18 20:01:12 DietPi_DEV wg-quick[614]: RTNETLINK answers: Operation not supported
Okt 18 20:01:12 DietPi_DEV wg-quick[614]: Unable to access interface: Protocol not supported
Okt 18 20:01:12 DietPi_DEV wg-quick[614]: [#] ip link delete dev wg0
Okt 18 20:01:12 DietPi_DEV wg-quick[614]: Cannot find device "wg0"
Okt 18 20:01:12 DietPi_DEV systemd[1]: wg-quick@wg0.service: Main process exited, code=exited, status=1/FAILURE
Okt 18 20:01:12 DietPi_DEV systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
Okt 18 20:01:12 DietPi_DEV systemd[1]: wg-quick@wg0.service: Unit entered failed state.
Okt 18 20:01:12 DietPi_DEV systemd[1]: wg-quick@wg0.service: Failed with result 'exit-code'.

Checking DietPi Software indicates, that Wireguard is still installed.

Question: Do I need to reinstall Wireguard using DietPi Software or is there another way??

+++++++++++++++++++++
May secound issue is with Lighttpd Daemon. It's not coming up after the update.

 DietPi-Update
─────────────────────────────────────────────────────
 Mode: Completed

[ INFO ] DietPi-Update | Current version : v6.25.3
[ INFO ] DietPi-Update | Latest version  : v6.26.3
[  OK  ] DietPi-Survey | Connection test: ssh.dietpi.com
[  OK  ] DietPi-Survey | Successfully sent survey data
[  OK  ] DietPi-Update | Syncing new DietPi scripts to disk
[ SUB1 ] DietPi-Services > restart
[  OK  ] DietPi-Services | restart : php7.3-fpm
[FAILED] DietPi-Services | restart : lighttpd
[  OK  ] DietPi-Services | restart : cron

Checking journalctl after reboot is giving the following information

Okt 18 20:01:12 DietPi_DEV systemd[1]: Starting Lighttpd Daemon...
Okt 18 20:01:13 DietPi_DEV lighttpd[710]: Duplicate config variable in conditional 0 global: server.error-handler-404
Okt 18 20:01:13 DietPi_DEV lighttpd[710]: 2019-10-18 20:01:12: (configfile.c.1154) source: /etc/lighttpd/conf-enabled/99-dietpi-pihole.conf line: 33 pos: 1 p
arser failed somehow near here: (EOL)
Okt 18 20:01:13 DietPi_DEV lighttpd[710]: 2019-10-18 20:01:12: (configfile.c.1154) source: find /etc/lighttpd/conf-enabled -name '*.conf' -a ! -name 'letsenc
rypt.conf' -printf 'include "%p"\n' 2>/dev/null line: 2 pos: 8 parser failed somehow near here: (EOL)
Okt 18 20:01:13 DietPi_DEV lighttpd[710]: 2019-10-18 20:01:12: (configfile.c.1154) source: /etc/lighttpd/lighttpd.conf line: 65 pos: 1 parser failed somehow
near here: (EOL)
Okt 18 20:01:13 DietPi_DEV systemd[1]: lighttpd.service: Control process exited, code=exited status=255
Okt 18 20:01:13 DietPi_DEV systemd[1]: Failed to start Lighttpd Daemon.
Okt 18 20:01:13 DietPi_DEV systemd[1]: lighttpd.service: Unit entered failed state.
Okt 18 20:01:13 DietPi_DEV systemd[1]: lighttpd.service: Failed with result 'exit-code'.
Okt 18 20:01:13 DietPi_DEV systemd[1]: lighttpd.service: Service hold-off time over, scheduling restart.
Okt 18 20:01:13 DietPi_DEV systemd[1]: Stopped Lighttpd Daemon.

Any idea?
@MichaIng
Copy link
Owner

@Joulinar
Many thanks for your report.

WireGuard

The old module is expected to be removed, since your kernel has been upgraded. But the new module should be build afterwards.
Can you please run: dash /etc/kernel/postinst.d/dietpi-wireguard

Lighttpd

Please paste: grep -r 'server.error-handler-404' /etc/lighttpd/

@Joulinar
Copy link
Collaborator Author

@MichaIng see below as requested

WireGuard

root@DietPi_DEV:~# dash /etc/kernel/postinst.d/dietpi-wireguard
Loading new wireguard-0.0.20190702 DKMS files...
It is likely that 4.19.66-v7+ belongs to a chroot's host
Building for 4.19.66+ and 4.19.66-v7+
Building initial module for 4.19.66+
Done.

wireguard:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.19.66+/kernel/net/

depmod....

DKMS: install completed.
Building initial module for 4.19.66-v7+
Done.

wireguard:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.19.66-v7+/kernel/net/

depmod....

DKMS: install completed.
root@DietPi_DEV:~#

looks like wg0 is coming up after reboot now.

Okt 19 23:31:30 DietPi_DEV systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Okt 19 23:31:30 DietPi_DEV systemd[1]: Started Permit User Sessions.
Okt 19 23:31:30 DietPi_DEV systemd[1]: Started /etc/rc.local Compatibility.
Okt 19 23:31:30 DietPi_DEV wg-quick[619]: [#] ip link add wg0 type wireguard
Okt 19 23:31:30 DietPi_DEV kernel: wireguard: loading out-of-tree module taints kernel.
Okt 19 23:31:30 DietPi_DEV kernel: wireguard: WireGuard 0.0.20190702 loaded. See www.wireguard.com for information.
Okt 19 23:31:30 DietPi_DEV kernel: wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
Okt 19 23:31:30 DietPi_DEV wg-quick[619]: [#] wg setconf wg0 /dev/fd/63
Okt 19 23:31:30 DietPi_DEV wg-quick[619]: [#] ip -4 address add 10.10.0.1/24 dev wg0

However wg is still giving nothing back. It was needed to execute systemctl restart wg-quick@wg0 to get an output. Anyway, after reboot wg is not working again.

Lighttpd

root@DietPi_DEV:~# grep -r 'server.error-handler-404' /etc/lighttpd/
/etc/lighttpd/conf-available/99-dietpi-pihole.conf:server.error-handler-404 = "/html/pihole/index.php"
/etc/lighttpd/lighttpd.conf:server.error-handler-404    = "/pihole/index.php"
root@DietPi_DEV:~#

@MichaIng
Copy link
Owner

MichaIng commented Oct 20, 2019 •
edited
Loading

@Joulinar
For WireGuard to start on boot, please run: systemctl enable --now wg-quick@wg0
To fix Lighttpd, run: sed -i '/^[[:blank:]]*server.error-handler-404/d' /etc/lighttpd/lighttpd.conf

  • Note that this removes any custom 404 handler page. Pi-hole itself uses the 404 handler to show the blocking page on blocked requests.
  • If you want to disable the blocking page instead, run the above command with /etc/lighttpd/conf-available/99-dietpi-pihole.conf as target.
  • Finally (re)start Lighttpd: systemctl restart lighttpd
  • I see we should run the above command, or better not remove but comment custom 404 handler on Lighttpd config file before adding the one for Pi-hole blocking page.

@Joulinar
Copy link
Collaborator Author

Joulinar commented Oct 20, 2019 •
edited
Loading

@MichaIng

WireGuard
Still not coming up after reboot

Lighttpd
ok perfect, Lighttpd is working again now.

@Joulinar
Copy link
Collaborator Author

Joulinar commented Oct 21, 2019 •
edited
Loading

@MichaIng sorry I missen to copy Wireguard error messages

Okt 21 11:23:09 DietPi_DEV wg-quick[615]: [#] ip link add wg0 type wireguard
Okt 21 11:23:09 DietPi_DEV kernel: wireguard: loading out-of-tree module taints kernel.
Okt 21 11:23:09 DietPi_DEV kernel: wireguard: WireGuard 0.0.20190702 loaded. See www.wireguard.com for information.
Okt 21 11:23:09 DietPi_DEV kernel: wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
Okt 21 11:23:09 DietPi_DEV wg-quick[615]: [#] wg setconf wg0 /dev/fd/63
Okt 21 11:23:09 DietPi_DEV wg-quick[615]: [#] ip -4 address add 10.10.0.1/24 dev wg0
Okt 21 11:23:09 DietPi_DEV wg-quick[615]: [#] ip link set mtu 1420 up dev wg0
Okt 21 11:23:09 DietPi_DEV systemd[1]: Started Lighttpd Daemon.
Okt 21 11:23:10 DietPi_DEV systemd[1]: Starting Network Time Synchronization...
Okt 21 11:23:10 DietPi_DEV wg-quick[615]: [#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(sed -n 3p /DietPi/dietpi/.network) -j MASQUERADE
Okt 21 11:23:10 DietPi_DEV wg-quick[615]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(sed -n 3p /DietPi/dietpi/.network).forwarding=1
Okt 21 11:23:10 DietPi_DEV wg-quick[615]: net.ipv6.conf.wg0.forwarding = 1
Okt 21 11:23:10 DietPi_DEV wg-quick[615]: sysctl: cannot stat /proc/sys/net/ipv6/conf/NONE/forwarding: No such file or directory
Okt 21 11:23:10 DietPi_DEV wg-quick[615]: [#] ip link delete dev wg0
Okt 21 11:23:10 DietPi_DEV systemd[1]: Started Network Time Synchronization.
Okt 21 11:23:10 DietPi_DEV systemd[1]: Reached target System Time Synchronized.
Okt 21 11:23:10 DietPi_DEV systemd[1]: wg-quick@wg0.service: Main process exited, code=exited, status=255/n/a
Okt 21 11:23:10 DietPi_DEV systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
Okt 21 11:23:10 DietPi_DEV systemd[1]: wg-quick@wg0.service: Unit entered failed state.
Okt 21 11:23:10 DietPi_DEV systemd[1]: wg-quick@wg0.service: Failed with result 'exit-code'.
Okt 21 11:23:10 DietPi_DEV kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Okt 21 11:23:10 DietPi_DEV kernel: smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

As well it seems to be an older version of Wireguard WireGuard 0.0.20190702. Best to my knowledge, there should be a newer one available.

@MichaIng
Copy link
Owner

MichaIng commented Oct 21, 2019 •
edited
Loading

@Joulinar

Best to my knowledge, there should be a newer one available.

Indeed there should be. So since you are on RPi, verify the following:
cat /etc/apt/sources.list.d/dietpi-wireguard.list should contain the Raspbian Bullseye source now.
cat /etc/apt/preferences.d/dietpi-wireguard should set the priority for this repo to -1, only the WireGuard packages to 100.
I think in a previous version of the patch file, we set this to 99, which IMO does not allow auto-upgrades then, but explicit installs only.

You can test with 99 by running: apt update && apt upgrade
If no updates are offered and applied, use priority 100 and repeat, and we'll know for sure.

However, besides running the current WireGuard version makes definitely since (since it is still in heavy development), the actual issue is this:

Okt 21 11:23:10 DietPi_DEV wg-quick[615]: sysctl: cannot stat /proc/sys/net/ipv6/conf/NONE/forwarding: No such file or directory
...
Okt 21 11:23:10 DietPi_DEV kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes read
Okt 21 11:23:10 DietPi_DEV kernel: smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

WireGuard tries to start before the main network interface becomes ready.
If you see further logs around, does DietPi-Boot starting...+started. before or after those entries? Due to contained Lighttpd entry, it looks like it is already during DietPi-PostBoot execution, but probably you enabled it for systemd start control.
Your login banner (and the small one before login) shows correct local IP and interface, right?

In case you can either delay the service (e.g. After=dietpi-boot.service) start or explicitly add /DietPi/dietpi/func/obtain_network_details as ExecStartPre script, based on the actual boot order currently.

@Joulinar
Copy link
Collaborator Author

@MichaIng

So the packages is set to 99 on my RPi

root@DietPi_DEV:~# cat /etc/apt/sources.list.d/dietpi-wireguard.list
deb http://raspbian.raspberrypi.org/raspbian/ bullseye main
root@DietPi_DEV:~# cat /etc/apt/preferences.d/dietpi-wireguard
Package: *
Pin: release n=bullseye
Pin-Priority: -1

Package: wireguard wireguard-dkms wireguard-tools
Pin: release n=bullseye
Pin-Priority: 99
root@DietPi_DEV:~#

And yes it's needed to set it to 100 to have it updated by running apt update && apt upgrade

@MichaIng
Copy link
Owner

@Joulinar
Okay, that is good to know.

@Joulinar
Copy link
Collaborator Author

@MichaIng
I'm still testing regarding the interface. Will let you know the outcome later the day.

@Joulinar
Copy link
Collaborator Author

@MichaIng ok I tried to compare the boot logs between 6.25 and 6.26. For this I reset my DEV system by restoring an 6.25 image (backup from PROD system).

Attached the 2 log files. I copied the section between DietPi-Boot starting...+started. Basically they looks like same.

boot_6.26.3.txt
boot_6.25.3.txt

Next to that, I noticed that WireGuard is updated during 6.26 update process and package Priority is set to 100 now. Installed version is WireGuard 0.0.20190913 .

Did you already changed something?

@MichaIng
Copy link
Owner

MichaIng commented Oct 21, 2019 •
edited
Loading

@Joulinar
Indeed DietPi-Boot does not necessarily finish before WireGuard starts. Seem to be nuances about the boot process that lead to eth0 being fully loaded and stored as such by boot script or not, e.g. the newly added initial_turbo that speeds up RPi boot process significantly.

What I will add to dietpi-software to cover this is:

mkdir -p /etc/systemd/system/wg-quick@wg0.service.d
echo -e '[Unit]\nAfter=dietpi-boot.service' > /etc/systemd/system/wg-quick@wg0.service.d/dietpi.conf
  • This assures as well that workarounds for known network start issues are applied, time sync finished etc before WireGuard starts.

Did you already changed something?

Jep I fixed the patch_file to apply the correct priority now. This simply makes sense, also to have all RPis WireGuard packages migrated to the Raspbian repo, which probably contain some device specific tweaks.

Fixed with: f9149af
Changelog: 5085975

MichaIng added a commit that referenced this issue Oct 21, 2019
@MichaIng
v6.27
f9149af 
+ DietPi-Software | WireGuard: Assure WireGuard server starts after DietPi-Boot: #3175
@MichaIng MichaIng added Solution available 🥂 Definite solution has been done Bug 🐞 and removed Investigating 🤔 labels Oct 21, 2019
@MichaIng MichaIng added this to the v6.27 milestone Oct 21, 2019
@Joulinar
Copy link
Collaborator Author

Joulinar commented Oct 22, 2019 •
edited
Loading

@MichaIng
I tried to implement your fix by creating the wg-quick@wg0.service.d entry. And yes, now WireGuard is started after DietPi-Boot finished. However it still fails.

I set the Turbo Option back to 0 and WireGuard starts working after reboot. Seems system is still booting to fast, having the Turbo Option enabled.

Attached the 2 logs, with ARM Initial Turbo=20 and ARM Initial Turbo=0

boot_6.26.3_turbo0.txt
boot_6.26.3_turbo20.txt

@MichaIng
Copy link
Owner

@Joulinar
Hmm I am thinking if that has something to do with alllow-hotplug vs auto entries in /etc/network/interfaces. However DietPi-Boot checks for established default route/gateway, so no real chance that the interface is still down 🤔. Speed should not play a role if the conditions are checked correctly.

What made me think is this part of the log with initial_turbo:

Okt 22 11:22:17 DietPi_DEV sh[483]: eth0=eth0
Okt 22 11:22:17 DietPi_DEV systemd[1]: Started Lighttpd Daemon.
Okt 22 11:22:17 DietPi_DEV systemd[1]: Starting Network Time Synchronization...
Okt 22 11:22:18 DietPi_DEV systemd[1]: Started Network Time Synchronization.
Okt 22 11:22:18 DietPi_DEV systemd[1]: Reached target System Time Synchronized.
Okt 22 11:22:18 DietPi_DEV kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Okt 22 11:22:18 DietPi_DEV kernel: smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
  • eth0=eth0 is part of the ifup@.service which is responsible to initiate interfaces defined with allow-hotplug in /etc/network/interfaces (default on DietPi) instead of auto (known to fail in some cases of e.g. external network devices) which are initiated by networking.service.
  • The problem is that ifup@ is service type "simple" while networking is of type "oneshot". Type oneshot inherits that all services and targets, which are defined to run afterwards (e.g. network-online.target) must wait before the ExecStart command has fully finished. Type "simple" allows follow-up services to start already when the ExecStart command just began but did not necessarily finish.
  • As a result, the network-online.target can be reached (which by default must happen before WireGuard service starts), while the eth0 interface is still in initialisation process.

However probably this is intended, e.g. otherwise online target would be never reached if some defined adapter is simply not attached (but another one). But if I understood correctly, the ifup@ services are created via udev rules, so are simply not present for non-attached adapters. But not sure how this is handled exactly from first insight.

So regardless of the above, DietPi-Boot does not wait for network-online.target, but checks for an active route. I could not create any state where a route has been established without the network device being fully initialised, however I know from Rock(Pro)64 where a current kernel/firmware issue leading to Ethernet interface states being reported as "UNKNOWN" instead of "UP", but the route is established regardless + all network target reached. Only our script (e.g. banner) does not show the network device as active then. Probably we should change that.

If you want to check, change that part: https://github.com/MichaIng/DietPi/blob/master/dietpi/boot#L39-L42
Into:

			if ip r | grep ' via '; then

				ip a
				G_DIETPI-NOTIFY 0 "$(date) | Valid network connection found"
				break

Testing a fallback: https://github.com/MichaIng/DietPi/pull/3192/files

Finally I think this script we use is generally no good idea but instead network states should be always re-obtained. ip r s 0.0.0.0/0 e.g. is an easy way to get the current www interface, which makes sense for WireGuard instead of scraping a file that can contain outdated info.

@Joulinar
Copy link
Collaborator Author

@MichaIng

OK i changed the lines within /DietPi/dietpi/boot script as indicated. But it still keep on failing as soon as I'm activating ARM Initial Turbo=20

root@DietPi_DEV:~# systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
   Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/wg-quick@wg0.service.d
           └─dietpi.conf
   Active: failed (Result: exit-code) since Tue 2019-10-22 23:01:49 CEST; 30s ago
     Docs: man:wg-quick(8)
           man:wg(8)
           https://www.wireguard.com/
           https://www.wireguard.com/quickstart/
           https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
           https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8
  Process: 717 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=255)
 Main PID: 717 (code=exited, status=255)

Okt 22 23:01:49 DietPi_DEV wg-quick[717]: [#] ip link set mtu 1420 up dev wg0
Okt 22 23:01:49 DietPi_DEV wg-quick[717]: [#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(sed -n 3p /DietPi/dietpi/.network)
-j MASQUERADE
Okt 22 23:01:49 DietPi_DEV wg-quick[717]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(sed -n 3p /DietPi/dietpi/.network).forwarding=1
Okt 22 23:01:49 DietPi_DEV wg-quick[717]: net.ipv6.conf.wg0.forwarding = 1
Okt 22 23:01:49 DietPi_DEV wg-quick[717]: sysctl: cannot stat /proc/sys/net/ipv6/conf/NONE/forwarding: No such file or directory
Okt 22 23:01:49 DietPi_DEV wg-quick[717]: [#] ip link delete dev wg0
Okt 22 23:01:49 DietPi_DEV systemd[1]: wg-quick@wg0.service: Main process exited, code=exited, status=255/n/a
Okt 22 23:01:49 DietPi_DEV systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
Okt 22 23:01:49 DietPi_DEV systemd[1]: wg-quick@wg0.service: Unit entered failed state.
Okt 22 23:01:49 DietPi_DEV systemd[1]: wg-quick@wg0.service: Failed with result 'exit-code'.
Warning: wg-quick@wg0.service changed on disk. Run 'systemctl daemon-reload' to reload units.
root@DietPi_DEV:~#

attached a picture from the screen showing the output during boot.

20191022_230805

@MichaIng
Copy link
Owner

@Joulinar
The boot script lines were for debugging. And jep, indeed a default gateway (route) has been applied to eth0, as well as an IP, and network-online.target has been reached, all when interface reports still "linkdown"/"state DOWN", hence is not recognised as active IP by our script.

To fix it, add the fallback lines to our obtain_network_details script that I linked above. You can revert boot script again then. Result:

  • If no network adapter shows state "UP" yet, the first with assigned IP will used instead.
  • If there is even none with assigned IP yet (should be impossible if route/gateway has been assigned already), then the first found interface name (eth0) will be used instead.

@Joulinar
Copy link
Collaborator Author

@MichaIng well done. I adjusted dietpi/func/obtain_network_details and your fix is working quite well. WireGuard is now starting, having ARM Initial Turbo=20 activated.

@MichaIng
Copy link
Owner

@Joulinar
Thanks for feedback. Then we are sure to have the issue identified. I am not yet 100% sure how to implement finally, depends on how much time I find to do some more planned rework on the networking part. Perhaps adding the PR as it is now is best, so even if I don't find the time anymore, we have a working solution 🤔.

@MichaIng MichaIng mentioned this issue Oct 24, 2019
Merged
@Joulinar
Copy link
Collaborator Author

@MichaIng
I was continuing testing a little bit and it seems the interface issue, leading WireGuard to fail, is related to Stretch only. I did 2 fresh installations on Stretch and Buster. And I need to say, on Buster it was working right from the beginning.

So probably it's time to setup a fresh install on Buster and migrate all my data from Stretch :)

@MichaIng
Copy link
Owner

@Joulinar
The issue AFAIK can always appear while it does only rarely. It is a bid by chance, depending on the whole systemd unit assembly, the time the hardware needs to init and some other factors. I merged the workaround btw, which should solve the issue with WireGuard at least. It is still not 100% beauty, as of how those hotplug devices are handled by systemd/udev/ifupdown, but this is something we need to report to the package maintainers. There is an old bug report about this, which states that the current situation is temporary until a real fix has been done in another place, however after some years now thing happened about that so far. Time to bring this back to attention 😉

@Joulinar
Copy link
Collaborator Author

@MichaIng
thx for explanation and inside. Always nice to hit something that just appears rarely. If you have something more to test around this, let me know.

@MichaIng
Copy link
Owner

MichaIng commented Oct 28, 2019 •
edited
Loading

Just to reference here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791920

  • Type=oneshot implies that that the service needs to have fully finished before any other unit can start/be reached, that sorts itself to run afterwards.
  • Type=simple (which is default, if not defined) implies that the service needs to have started only before any other unit can start/be reached, that sorts itself to run afterwards. Hence this service type is actually not usable if any follow-up service requires it to have anything specific done/finished, like network-online.target expecting ifup@eth0.service to have fully finished the eth0 network interface setup.
  • However Type=oneshot obviously leaded to boot hang in some cases, since ifup@eth0.service obviously can hang in some cases, hence finishes late/never, hence delays any follow-up services. So of course in such strict service dependencies, a hang must be handled gracefully, which obviously is or at least was not the case.
  • Now I have headache thinking this through 🤣 ...

@MichaIng MichaIng mentioned this issue Nov 13, 2019
Merged
@MichaIng MichaIng mentioned this issue Dec 8, 2019
Closed
@MichaIng MichaIng mentioned this issue Dec 30, 2019
Merged
@MichaIng MichaIng closed this as completed Jan 1, 2020
@sesamzoo
Copy link

sesamzoo commented Jan 7, 2020 •
edited
Loading

@MichaIng, thx for the fix.
Could this also be the solution for the issue reported in this DietPi troubleshooting topic (Wireguard failing at startup in case of static IP address)?

@MichaIng
Copy link
Owner

MichaIng commented Jan 8, 2020

@sesamzoo
Exactly, the issue is the same and the fix should solve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug 🐞 Solution available 🥂 Definite solution has been done
Projects
None yet
Milestone
v6.27
Development

No branches or pull requests
3 participants
@sesamzoo @MichaIng @Joulinar