caribou-snake
commented
6 years ago issue just disappeared after repeated reboot / restart attempts no changes ?
Closed caribou-snake closed 6 years ago
caribou-snake
commented
6 years ago issue just disappeared after repeated reboot / restart attempts no changes ?
MichaIng
commented
6 years ago @d4f2 Thanks for your report. Means the issue is resolved for you, now?
As nearly all services were found dead, it looks like a deeper system issue. A look into systemctl could reveal errors, e.g. where systemd starts.
Otherwise check logs of related services from within /var/log/.
I just tested Nextcloud + PiHole working fine (including web ui) on Stretch VM. I see RealMedia and OpenVPN running besides at your system. Also tested this on VM, which works generally fine:
DietPi-Services
─────────────────────────────────────────────────────
Mode: status
[ OK ] DietPi-Services | cron active (running) since Mon 2018-02-26 19:08:36 CET; 34s ago
[ OK ] DietPi-Services | lighttpd active (running) since Mon 2018-02-26 19:08:36 CET; 34s ago
[ OK ] DietPi-Services | php7.0-fpm active (running) since Mon 2018-02-26 19:08:37 CET; 33s ago
[ OK ] DietPi-Services | mysql active (running) since Mon 2018-02-26 19:08:38 CET; 32s ago
[ OK ] DietPi-Services | minidlna active (running) since Mon 2018-02-26 19:08:38 CET; 32s ago
[ OK ] DietPi-Services | pihole-FTL active (running) since Mon 2018-02-26 19:08:38 CET; 32s ago
[ OK ] DietPi-Services | redis-server active (running) since Mon 2018-02-26 19:08:38 CET; 32s ago
[ OK ] DietPi-Services | dnsmasq active (running) since Mon 2018-02-26 19:08:36 CET; 34s ago
[ OK ] DietPi-Services | openvpn active (exited) since Mon 2018-02-26 19:08:35 CET; 35s agoBut RPi is a different APT repository.
If error still occurs on your system, besides error logs (above), you could try to purge and reinstall the software 1 by 1 and see on which the issue occurs. Somebody with testing ready RPi can try to replicate, sadly mine is production server 😅.
caribou-snake
commented
6 years ago Hello, unfortunatelly it is not resolved
checked systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
dhcpcd.service loaded failed failed dhcpcd on all interfaces
dhcpcd.service - dhcpcd on all interfaces Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/dhcpcd.service.d └─wait.conf Active: failed (Result: exit-code) since Mon 2018-02-26 15:02:17 CET; 17h ago
Feb 26 15:02:17 DietPi64G systemd[1]: Starting dhcpcd on all interfaces... Feb 26 15:02:17 DietPi64G dhcpcd[293]: Not running dhcpcd because /etc/network/interfaces Feb 26 15:02:17 DietPi64G dhcpcd[293]: defines some interfaces that will use a Feb 26 15:02:17 DietPi64G dhcpcd[293]: DHCP client or static address Feb 26 15:02:17 DietPi64G systemd[1]: dhcpcd.service: Control process exited, code=exited status=6 Feb 26 15:02:17 DietPi64G systemd[1]: Failed to start dhcpcd on all interfaces. Feb 26 15:02:17 DietPi64G systemd[1]: dhcpcd.service: Unit entered failed state. Feb 26 15:02:17 DietPi64G systemd[1]: dhcpcd.service: Failed with result 'exit-code'. #
I started all over again from scratch with a clean install "DietPi_v6.2_RPi-ARMv6-Stretch.img" and it is the pivpn installation causing this from previous installations I noticed the setup part AFTER the key generation, where the publicIP or DNS is set is missing during the installation process! is dnsmasq installation missing?
:::
::: Stopping OpenVPN service... done.
:::
::: Installing scripts to /opt/pivpn... done.
::: Using protocol: udp
::: Building CA...
::: CA Complete.
Note: using Easy-RSA configuration from: ./vars
Note: using Easy-RSA configuration from: ./vars
DH parameters of size 2048 created at /etc/openvpn/easy-rsa/pki/dh.pem
Note: using Easy-RSA configuration from: ./vars
An updated CRL has been created.
CRL file: /etc/openvpn/easy-rsa/pki/crl.pem
net.ipv4.ip_for
#Here I get stuck due to my limited know how thank you very much for your help
MichaIng
commented
6 years ago @d4f2 Thanks for your retry, I will investigate our installation script and recheck on VM, until someone with RPi find time to reproduce.
MichaIng
commented
6 years ago @pedrom34 I don't think it is related, but let's see if I can help. Several services crashing over night can have several reasons, often filled memory when e.g. daily cron tasks add to memory usage. I had that once with some rsync backup and mysql dump and sadly that time without swap file on my RPi2. But also sdcard corruption is possible.
The crashed MariaDB then often leads to file system, database and or log corruption, preventing it from regular startup. I also found especially the database quite sensitive here.
About the specific Can't init tc log I mostly find the quick solution to remove /var/lib/mysql/tc.log. In case it doesn't work, better move it:
mv /var/lib/mysql/tc.log /var/lib/mysql/tc.log.bak
If MariaDB starts up again, it cannot be wrong to do a database corruption check. I personally do this after every MariaDB crash or unexpected exit:
mysqlcheck --all-databases in case
mysqlcheck --auto-repair --all-databases
If you don't have a swapfile, please add one with at least 1G via dietpi-config>Advanced. In case you have much software/services active, a higher value could be necessary. Check usage via htop, especially on high load (access to your servers services).
Finally you can force a file system check on reboot:
touch /forcefsck or to do on every reboot
add fsck.mode=force to your cmdline: nano /boot/cmdline.txt
caribou-snake
commented
6 years ago Sadly I can reproduce my pivpn installation problem over and over again tried several approaches but it comes down to:
dhcpcd.service loaded failed failed dhcpcd on all interfaces - see above
(might want to change the subject of the issue to point at the pivpn installation causing it?)
:::
::: You are root.
::: Verifying free disk space...
:::
::: Checking apt-get for upgraded packages.... done!
:::
::: Your system is up to date! Continuing with PiVPN installation...
:::
::: Setting IP to 192.168.200.100. You may need to restart after the install is complete.
:::
::: Using User: pivpn
:::
::: Checking for existing base files...
::: Checking /etc/.pivpn is a repo...::: Cloning https://github.com/pivpn/pivpn.git into /etc/.pivpn... done!
:::
::: Stopping OpenVPN service... done.
:::
::: Installing scripts to /opt/pivpn... done.
::: Using protocol: udp
::: Building CA...
Generating a 2048 bit RSA private key
........................+++
..+++
writing new private key to '/etc/openvpn/easy-rsa/pki/private/ca.key.BXam5r5pmt'
-----
::: CA Complete.
Note: using Easy-RSA configuration from: ./vars
rand: Use -help for summary.
Generating a 2048 bit RSA private key
.....................+++
.......................+++
writing new private key to '/etc/openvpn/easy-rsa/pki/private/server_'
-----
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.cnf
Can't open /etc/openvpn/easy-rsa/pki/index.txt.attr for reading, No such file or directory
1995662752:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:74:fopen('/etc/openvpn/easy-rsa/pki/index.txt.attr','r')
1995662752:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:81:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
Certificate is to be certified until Feb 26 12:02:07 2028 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
Note: using Easy-RSA configuration from: ./vars
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
............................
DH parameters of size 2048 created at /etc/openvpn/easy-rsa/pki/dh.pem
Note: using Easy-RSA configuration from: ./vars
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.cnf
An updated CRL has been created.
CRL file: /etc/openvpn/easy-rsa/pki/crl.pem
net.ipv4.ip_forward = 1
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
ip6tables-save v1.6.0: Cannot initialize: Address family not supported by protocol
run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with return code 1
::: Install Complete...
::: Restarting services...
Synchronizing state of openvpn.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable openvpn
::: done.
:::
::: Installation Complete!
::: Now run 'pivpn add' to create an ovpn profile for each of your devices.
::: Run 'pivpn help' to see what else you can do!
::: It is strongly recommended you reboot after installation.
:::
::: The install log is located at: /etc/pivpn/install.log
[ SUB1 ] DietPi-Services > stop
[ OK ] DietPi-Services | stop : cron
DietPi-Software
─────────────────────────────────────────────────────
Mode: Optimize and configure software
[ INFO ] DietPi-Software | Applying DietPi optimizations and configurations for RPi 3 Model B (armv7l), please wait...
[ SUB1 ] DietPi-Services > dietpi_controlled
[ OK ] DietPi-Services | dietpi_controlled : cron
DietPi-Software
─────────────────────────────────────────────────────
Mode: Installation completed
[ OK ] DietPi-Software | The system will now reboot.
This completes the DietPi-Software installation.
pedrom34
commented
6 years ago @MichaIng I deleted my comments as it's unrelated. Thanks for the help, but I managed to fix everything by uninstalling and re-installing MariDB and Sckrg.
Thanks!
Fourdee
commented
6 years ago @MichaIng @d4f2 In regards to PiHole + OpenVPN. This is a possible known issue (AFAIK) as PiHole + OpenVPN require additional manual configuration at this time. REF: https://github.com/Fourdee/DietPi/issues/1245.
^^ actually unsure, needs reviewing/testing.
MichaIng
commented
6 years ago @Fourdee @d4f2 Okay seems to be 2 mixed things here now:
I tried again the following, as before I installed (just) OpenVPN:
pivpn command works.dhcpcd.service failing, but this makes sense as we disabled DHCP to use PiVPN. On my preconfigured/but not really loaded WLAN interface it still shows up and seems that dhcpcd notices this, showing error, but this should not hurt in any way.systemctl disable dhcpcd on PiVPN installation, as it is anyway unused then/doesn't work, avoiding the systemd messages about it? Maybe we should already disable it when switching to STATIC on all enabled+connected adapters and re-enable when switching to DHCP?€: Interesting, I just enabled DHCP for eth0 successfully but forgot to enable dhcpcd. It does not seem to be necessary? dhclient is up on htop, IP correct, network up, dhcpcd disabled 🤔.
@d4f2
systemctl disable dhcpcd to avoid them, but note that currently you need to systemctl enable dhcpcd again, if you want to switch back to DHCP network.dietpi-services status showing all services up as expected.caribou-snake
commented
6 years ago thank you vey much for all your efforts! to point this out - this has got nothing to do with PiHole !
this a PiVpn installation problem only
the installation breaks off after key generation and does not continue to configure the server thus adding a client pivpn -a fails
cat: Default.txt: No such file or directory
looking at: https://github.com/pivpn/pivpn/blob/master/auto_install/install.sh
confOpenVPN - appears to finish fine - the server.conf is created
but the netfilter-persistent save (PLAT=Raspbian) in confNetwork brakes off with:
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
ip6tables-save v1.6.0: Cannot initialize: Address family not supported by protocol
run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with return code 1https://github.com/pivpn/pivpn/blob/25aaf24c893175894d0a54d159a10fbb74b6b463/auto_install/install.sh#L987
subsequent functions confOVPN / setClientDNS ..etc.. are missing
hope this details my problem
caribou-snake
commented
6 years ago after these hours trying to get to the bottom of this I finally found... https://github.com/pivpn/pivpn/issues/464 enabled IPV6 and installed again... PiVPN installation problem solved !
though still get the:
root@DietPi:~# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● dhcpcd.service loaded failed failed dhcpcd on all interfaces
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
root@DietPi:~# systemctl status dhcpcd.service
● dhcpcd.service - dhcpcd on all interfaces
Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/dhcpcd.service.d
└─wait.conf
Active: failed (Result: exit-code) since Fri 2018-03-02 09:29:31 GMT; 1min 14s ago
Process: 298 ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w (code=exited, status=6)
Mar 02 09:29:31 DietPi systemd[1]: Starting dhcpcd on all interfaces...
Mar 02 09:29:31 DietPi dhcpcd[298]: Not running dhcpcd because /etc/network/interfaces
Mar 02 09:29:31 DietPi dhcpcd[298]: defines some interfaces that will use a
Mar 02 09:29:31 DietPi dhcpcd[298]: DHCP client or static address
Mar 02 09:29:31 DietPi systemd[1]: dhcpcd.service: Control process exited, code=exited status=6
Mar 02 09:29:31 DietPi systemd[1]: Failed to start dhcpcd on all interfaces.
Mar 02 09:29:31 DietPi systemd[1]: dhcpcd.service: Unit entered failed state.
Mar 02 09:29:31 DietPi systemd[1]: dhcpcd.service: Failed with result 'exit-code'.
Warning: dhcpcd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
root@DietPi:~#which I will negelect as advised
I need a break now .. will continue later with my remaining setup nextcloud etc... will follow up in case the restart of services issue was not related to this and re-occurs nevertheless all this point me in the required direction and did help me thank you
MichaIng
commented
6 years ago @d4f2
Ah sorry, I did not recognize: ip6tables-save v1.6.0: Cannot initialize: Address family not supported by protocol, jep so IPv6 needs to be enabled!
May I ask how you enabled IPv6? By default we do not disable it, but you can toggle within dietpi-config. But as you run RPi, I recognized some default alias blocking within /etc/modprobe.d/ipv6 which is installed by default on Raspbian images (where DietPi for RPi is based on). This had no visible effect on my RPi, IPv6 module is still active and used, but was this file the issue for you?
About your dhcpcd error, as said, as PiVPN+OpenVPN needs DHCP to be disabled, just do:
systemctl stop dhcpcd
systemctl disable dhcpcdand you are free or error messages.
caribou-snake
commented
6 years ago @MichaIng confirm I disabled IPv6 in dietpi-confg when setting the static IP I want back and started again from scratch (too much messing with confgurations when during my attempts) IPv6 is indeed enabled by default
thank you very much just for completness: in the old jessie version none of these issues and dhcpd active togehter with PiVPN+OpenVPN installed
MichaIng
commented
6 years ago @d4f2 Okay thanks for testing. Maybe the older versions of openvpn handled absence of IPv6 different, without throwing errors. Actually I am wondering if it is possible to use it just with IPv4 as well by pre-configuring/choosing different option within PiVPN install dialogs. Otherwise we could simple force enabling of IPv6 during our installation script and inform user about that. I will have a look into this.
k-plan
commented
6 years ago @MichaIng
Okay seems to be 2 mixed things here now:
Wir vermischen hier noch mehr Dinge würde ich meinen. :smiley:
"Verschiedene" DHCP-Server
OpenVPN / PVPN: Können in zwei verschiedenen Modi betrieben werden.
mit TAP Interface (eine Layer 2 (MAC Adressen basierte) gebridgete Verbindung zwischen Client und VPN-Server angebundenen Netzwerk)
Ethernet-Adapter LAN-Verbindung :Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : TUN-Windows Adapter V9 #2 DHCP aktiviert. . . . . . . . . . : Ja IPv4-Adresse . . . . . . . . . . : 10.8.0.6(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.252 Lease erhalten. . . . . . . . . . : Freitag, 2. März 2018 17:59:09 Lease läuft ab. . . . . . . . . . : Samstag, 2. März 2019 17:59:09 Standardgateway . . . . . . . . . : 10.8.0.5 DHCP-Server . . . . . . . . . . . : 10.8.0.5 DNS-Server . . . . . . . . . . . : 192.168.0.100 Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::b09c:610:98f9:e1d9%44(Bevorzugt)
Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 21 10.8.0.4 255.255.255.252 Auf Verbindung 10.8.0.6 276 0.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 21 128.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 21 192.168.0.0 255.255.255.0 10.8.0.5 10.8.0.6 21
Der nächste verbundene VPN Client bekäme 10.8.0.10/30 aus den darauf folgenden Subnetz 10.8.0.8/30.
TUN Interface Adresse des VPN Server wäre in diesem Fall dann die 10.8.0.9/30, auf der dann, wenn du so willst, der "nächste DHCP Server" läuft.
Und so fort.
Der Transport der IP Pakete der Clients erfolgt mittels Routing und wird beim Weitertransport zum LAN hin maskiert (NAT - genauer PNAT). Dies geschieht mittels IPtables rules.
Der VPN Server benötigt nur eine physikalische Schnittstelle, z.B. eth0 oder wlan0.
DHCP Server `isc-dhcp-server`:
Dieser sollte nur laufen, wenn Software einen eigenen DHCP Server benötigt. Hier fällt mir spontan für DietPi der Hotspot und TORSpot ein. Dieser DHCP Server sollte an die entsprechende Schnittstelle, hier WLAN Interface gebunden sein und nur dort lauschen und Adressen vergeben. Denn im LAN kann es durchaus einen weiteren DHCP Server geben. Zwei DHCP Server im selben Netzsegment gibt Unfug.
Der Transport der IP Pakete der Clients erfolgt mittels Routing und wird beim Weitertransport zum LAN hin maskiert (NAT - genauer PNAT). Dies geschieht mittels IPtables rules.
Der HotSpot Server benötigt zwei physikalische Schnittstelle, z.B. eth0 und wlan0.
Pi-Hole DHCP Server `dnsmasq` :
Neben DNS Server kann `dnsmasq` auch gleichzeitig ein DHCP Server sein. Das ist aber standardmäßig deaktiviert. Schaltet man diesen ein und hat einen weiteren DNS Server im Netzsegment, gibt es Unfug.
Aktiviert man DHCP in `dnsmasq`, ist das Problem, dass dieser an die Schnittstellen gekoppelt ist, auf denen auch DNS Server `dnsmasq` läuft/lauscht.
Also immer schön aufpassen, was man da genau macht, wenn am besten noch z.B. HotSpot und OpenVPN gleichzeitig laufen und man einen weiteren DHCP und DNS Server im LAN z.B. Router laufen hat. Da ist schnell der totale Unfug passiert, wenn jeder was anderes verteilt und die Routen nicht stimmen.
Aber auch alles gleichzeitig laufen lassen ist kein Problem, wenn man weiß, was man da tut und es richtig konfiguriert. Selbst getestet, hatte ich schon laufen.
------------------
**IPv6 abschalten:**
Wie schon gesagt, den IPv6 Stack zu deaktivieren, davon halte ich gar nichts. Das gibt nur Probleme. Aber da habe ich nun schon einige Male gegen Wände gesprochen. :smiley:
Du hattest mich damals nach einem konkreten Beispiel gefragt, jetzt hast du eins: PiVPN
Wenn man keine extrene (Internet) IPv6 Konektivät haben will, also ungewollte IPv6 Verbindungen in die weite Welt verhindern möchte, sollte man den IPv6 Stack aktiviert lassen, aber nur eine Link-Local-Unicast-Adressen `fe80::/64` auf aktiven Schnittstelle ermöglichen. Diese vergibt sich das Gerät dann selber auf allen aktiven Schnittstelle. Diese Adressen dienen nur zur lokalen Kommunikation, werden nicht geroutet. Der IPv6 Stack sollte damit laufen. Somit wäre dann immer ein `ip6tables` Eintrag möglich, was eine `Cannot initialize: Address family not supported by protocol` vermeidet.
Mit seiner `fe80::/64` Adresse kommt das Geräte nirgends außerhalb seiner Layer 2 Broadcast Domäne hin. Die Router begrenzen diese und routet die `fe80::/64` Link-Local-Unicast-Adressen nicht weiter. Darf er gar nicht, gemäß IPv6 Standard.
Es sein den, die Entwickler des Routers haben einen nicht Standard konformen eigenen IPv6 Stack geschrieben und implementiert. Die Wahrscheinlichkeit geht aber eher gegen Null. :wink: @MichaIng
Maybe the older versions of openvpn handled absence of IPv6 different
PiVPN installer handle this different in the paste. Can't say this exactly, because I dislike and use OpenVPN.
Starting officially in the 2.3.0 release, OpenVPN supports IPv6 inside the tunnel, and can optionally be configured with IPv6 as a transport protocol for the tunneled data.
https://community.openvpn.net/openvpn/wiki/IPv6
root@DietPi:~# cat /DietPi/dietpi/.version
122root@DietPi:~# cat /etc/debian_version
8.9
root@DietPi:~# openvpn --version
OpenVPN 2.3.4 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 26 2017@k-plan @Fourdee
Haha, I just found some more things, that got mixed up:
dhcpcd5 is installed and active, at least on Debian images, by default, where we use ics-dhcp-client by default? On my Buster Raspbian RPi there at least is no dhcpcd5 installed, seemed to be autoremoved there.dhcpcd5 more passiv, without active background process and ics-dhcp-client with dhclient as active background process, that enables some monitoring features, as far as I understood.dhcpcd5 is not autoremoved, since no other package depends on it and it is not essential nor "required". But somehow on my Stretch VM and seems as well d4f2's Stretch RPi it is installed and even with enabled service, besides and doubling dhclient (isc-dhcp-client).dhcpcd seems to be more lightweight and passive (htop shows process as well, but with 0.0% memory use). Is there some reason, why we have isc-dhcp-client as default (and somehow doubled) with DietPi? In this case we should purge dhcpcd5 on all systems to avoid interference and error messages as above.About all this DHCP server stuff:
About IPv6+PiVPN:
k-plan
commented
6 years ago @MichaIng
if we by default disable DHCP server functionality for dnsmasq and openvpn by default and inform users, if we find multiple DHCP capable software titles?
Vielleicht habe ich mich nicht deutlich genug ausgedrückt.
bei dnsmasq von Pi-Hole ist die DHCP Server Funktion per default deaktiviert, bei jeder Installation. Da muss erst der Nutzer etwas aktivieren und konfigurieren bevor dieser läuft. Wenn man einen Blick in root@RPi-Zero:~# cat /etc/dnsmasq.conf | grep dhcp wirft, kann man sehen, dass die Funktionen auskommentiert sind.
openvpn Server ist kein klassischer DHCP Server. Der Dienstopenvpn Server nutzt nur das DHCP Protokoll um IP Adressen den openvpn Clients zuzuweisen. Und das auch nur auf den TUN Interface.
https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-software#L9772-L9801
Eigentlich kommt sich das nie in die Quere, auch nicht im LAN mit DHCP vom Router.
Selbst wenn man dann noch den HotSpot aktiviert, funktioniert das. isc-dhcp-server läuft dann nur auf dem WLAN Interface.
https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-software#L9880-L9882
Es sei denn, man fummelt daran herum und weiß nicht was man da tut. https://github.com/Fourdee/DietPi/issues/992
k-plan
commented
6 years ago @MichaIng
Haha, I just found some more things, that got mixed up:
yes, nice finding. 👍 Noticed this now here as well. We should decide to use only one on all devices.
RPi v6:
root@RPi-Zero:~# dpkg -l | grep dhc
ii dhcpcd5 1:6.11.5-1+rpt4 armhf DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
ii isc-dhcp-client 4.3.5-3 armhf DHCP client for automatically obtaining an IP addressOrange-Pi-One v6 (test-build):
root@DietPi-OrangePi-One:~# dpkg -l | grep dhc
ii isc-dhcp-client 4.3.5-3 armhf DHCP client for automatically obtaining an IP addressOdroid-C1 v6:
root@Odroid-C1-v6:~# dpkg -l | grep dhc
ii isc-dhcp-client 4.3.1-6+deb8u2 armhf DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.1-6+deb8u2 armhf common files used by all of the isc-dhcp packages---- ONLY for reference ----
OLD ARMbian based build
root@NanoPi-Neo:~# dpkg -l | grep dhc
ii dhcpcd5 6.0.5-2 armhf DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
ii isc-dhcp-client 4.3.1-6+deb8u2 armhf DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.1-6+deb8u2 armhf common files used by all of the isc-dhcp packagesOLD Odroid based build
root@Odroid-C2:~# dpkg -l | grep dhc
ii isc-dhcp-client 4.3.1-6+deb8u2 arm64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.1-6+deb8u2 arm64 common files used by all of the isc-dhcp packages@MichaIng
Check for enabled IPv6, otherwise inform users, that IPv6 need to be enabled and block installation.
Wie schon gesagt, ich sehe nur zwei Optionen:
entweder implementiert man alle IPv6 Konfigurationsmöglichkeiten in dietpi-config vollständig.
oder man lässt IPv6 laufen, da Dual Stack Support heute Standard des Betriebssystems und entfernt die Möglichkeit diesen zu deaktivieren. IPv6 konfiguriert sich eigentlich im Hintergrund von alleine richtig. Das war auch ein Ziel bei der Einführung dieses Standards.
Die erste Lösung wird aufwendig, da will im Moment keiner ran. Außerdem können die vielfältigen Einstellmöglichkeiten unbedarfte Nutzer leicht überfordern und zu weiteren Fehlern führen. Über kurz oder lang wird aber kein Weg daran vorbei führen.
Die zweite Option vermeidet Fehlkonfigurationen und Software Inkompatibilitäten. Man hat aber nicht mehr vollständig im Griff, was genau läuft und wohin Verbindungen aufgebaut werden, wenn man ein Dual Stack LAN mit Dual Stack ISP Internetzugang oder IPv6 Tunnel Provider hat.
So, nun ist aber Schluss. 😄 Vielleicht ziehen wir die Themen besser hier heraus, da es verwirren könnte und nur noch teilweise mit dem Ausgangsproblem zu tun hat.
MichaIng
commented
6 years ago Okay I will close this, as TOs issue is solved by enabling IPv6. I open new issues about the two other topics.
Required Information:
Additional Information (if applicable):
Expected behaviour:
services to start after reboot
Actual behaviour:
services are not running after reboot
dietpi-services status
[ OK ] Root access verified.
DietPi-Services ───────────────────────────────────────────────────── Mode: status
[ INFO ] DietPi-Services | cron inactive (dead) [ INFO ] DietPi-Services | lighttpd inactive (dead) [ INFO ] DietPi-Services | php7.0-fpm inactive (dead) [ INFO ] DietPi-Services | mysql inactive (dead) [ INFO ] DietPi-Services | minidlna inactive (dead) [ INFO ] DietPi-Services | pihole-FTL inactive (dead) [ INFO ] DietPi-Services | redis-server inactive (dead) [ OK ] DietPi-Services | dnsmasq active (running) since Mon 2018-02-26 14:28:58 CET; 18s ago [ OK ] DietPi-Services | openvpn active (exited) since Mon 2018-02-26 14:28:58 CET; 19s ago
attempt to restart results in this error asking me to open a ticket
Steps to reproduce:
installed nextcloud and updated to v13 installed pi-hole
Additional logs:
[FAILED] DietPi-Services | Unable to continue, the program will now terminate.