Dietpi: Image update | Odroid XU3/XU4/MC1/HC1/HC2

[MichaIng]

Many thanks for testing our new image ❤️: Download

Linux version: 4.14.176
Debian version: 10/Buster
DietPi version: 6.30.0
Credits: Pre-image by Meveric: https://forum.odroid.com/viewtopic.php?f=96&t=30552

• Consider donating Meveric for his great work on the Odroid images and repository, providing GPU drivers, Kodi and other packages optimised and accelerated for Odroid: https://www.paypal.com/donate/?token=LMCbvftcq_bx4nbNVSB4PX-351eQSd2F7m1x-KoJ_zBE6boqH5cuKvvpwq4Jbs3h3oq0m0&country.x=US&locale.x=US

Please help us to estimate the stability state and give us a short report here if boot and first run setup went fine or if you faced any issue.

[camatthew88]

Does not work. Stuck after crng init done. Also wifi does not work via dietpi-wifi.txt and dietpi.txt

[MichaIng]

@camatthew88
Many thanks for testing. Looks like the entropy daemon does not start as expected. I'll have a look. Meanwhile boot should continue when waiting a while (can be a few minutes) and you can speed it up by attaching a keyboard and typing some random keys, moving an attached mouse etc.

---

Ah nope, crng init done should mean that entropy pool has filled and boot should continue after this is shown. Also checked the image and haveged is installed and enabled.

Found an issue which at least breaks applying the chosen static DNS on first boot, if you chose to apply static IP instead of using DHCP. Was this the case?

Otherwise it would be great if you could paste all of the boot output that you can see/get.

---

I repacked the image, to fix applying static DNS on first boot and as well included our new default boot.ini which exposes a new setting to change RAM frequency: https://github.com/MichaIng/DietPi/blob/dev/boot_xu4.ini#L31

[MichaIng]

Info by @Doctorbeefy: #3552

root@DietPi:~# dmesg -l err,crit,alert,emerg
[    0.156291] CPU4: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.176285] CPU5: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.184626] CPU6: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.192592] CPU7: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    1.873071] exynos-hdmi 14530000.hdmi: Failed to get supply 'vdd': -517
[    1.955956] devfreq 11800000.mali: Couldn't update frequency transition information.
[    3.470432] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[    3.889272] OF: graph: no port node found in /soc/hdmi@14530000
[    8.435748] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[    8.455010] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[    8.739386] sd 0:0:0:0: [sda] No Caching mode page found
[    8.745534] sd 0:0:0:0: [sda] Assuming drive cache: write through

Many thanks for testing. The last two are expected for external USB drives, the first ones are probably something to check or forward to kernel devs, at least to help reducing confusion or fear when seeing red lines in dmesg 😉. The part about spectre v2 at least looks security-relevant...

But as long as you don't face any actual issues, I would not worry!

[MichaIng]

If someone has time and mood for testing, I would like to know if the modern entropy daemon works fine on Odroid XU4:

1. Check current entropy init speed:
   dmesg | grep random
2. Check if hardware random generator device exists:
   ls -l /dev/hwrng
3. Purge haveged entropy daemon
   G_AGP haveged G_AGA
4. Install rng-tools5
   G_AGI rng-tools5
5. Check new entropy init speed on next boot:
   reboot dmesg | grep random

[Doctorbeefy]

Not sure what any of this means but here is this.

Also, after updating to 6.30 the other day I woke up this morning and tried to update my plex server when running sudo apt-get upgrade it told me my storage was full. I looked at my cloud shell screen and I noticed all of my storage values for my SD card and external storage did not have a "storage cap value" it just had how much space was used. (IE. 400mb / )Normally it shows 400mb / 29.8gig a reboot resolved this issue.

root@DietPi:~# dmesg | grep random
[    0.000000] random: get_random_bytes called from start_kernel+0x90/0x424 with crng_init=0
[    0.688124] random: fast init done
[    6.778971] random: systemd: uninitialized urandom read (16 bytes read)
[    6.831290] random: systemd: uninitialized urandom read (16 bytes read)
[    6.860373] random: systemd: uninitialized urandom read (16 bytes read)
[    8.824201] random: crng init done
[    8.826648] random: 7 urandom warning(s) missed due to ratelimiting
root@DietPi:~# ls -l /dev/hwrng
crw------- 1 root root 10, 183 May 21 09:16 /dev/hwrng
root@DietPi:~# G_AGP haveged
[ INFO ] APT purge for: haveged, please wait... 
(Reading database ... 22061 files and directories currently installed.)
Removing haveged (1.9.1-7) ...
(Reading database ... 22052 files and directories currently installed.)
Purging configuration files for haveged (1.9.1-7) ...
Processing triggers for systemd (241-7~deb10u4) ...
[  OK  ] APT purge for: haveged
root@DietPi:~# G_AGA
[ INFO ] APT autopurge, please wait... 
(Reading database ... 22048 files and directories currently installed.)
Removing libhavege1:armhf (1.9.1-7) ...
Processing triggers for libc-bin (2.28-10) ...
[  OK  ] APT autopurge
root@DietPi:~# G_AGI rng-tools5
[ INFO ] APT install for: rng-tools5, please wait... 
Selecting previously unselected package rng-tools5.
(Reading database ... 22042 files and directories currently installed.)
Preparing to unpack .../rng-tools5_5-4_armhf.deb ...
Unpacking rng-tools5 (5-4) ...
Setting up rng-tools5 (5-4) ...
Created symlink /etc/systemd/system/multi-user.target.wants/rngd.service → /lib/systemd/system/rngd.service.
Processing triggers for systemd (241-7~deb10u4) ...
[  OK  ] APT install for: rng-tools5

Reboot

root@DietPi:~# dmesg | grep random
[    0.000000] random: get_random_bytes called from start_kernel+0x90/0x424 with crng_init=0
[    0.688161] random: fast init done
[    6.798712] random: systemd: uninitialized urandom read (16 bytes read)
[    6.850304] random: systemd: uninitialized urandom read (16 bytes read)
[    6.876240] random: systemd: uninitialized urandom read (16 bytes read)
[    9.096501] random: crng init done
[    9.098624] random: 7 urandom warning(s) missed due to ratelimiting

[MichaIng]

@Doctorbeefy

Not sure what any of this means but here is this.

Many thanks for testing. This basically means that the new version of the pure hardware random generator daemon works fine with the XU4. This is less RAM, less CPU and less disk space (both tiny anyway) expensive, and probably a better source for real randomness compared to the software-based HAVEGE algorithm. Randomness is required e.g. to create (temporary) security keys for secure communication or storage, passwords and such, which became more important for recent distro versions. It is bad if you instruct the system to create a random password or key pair and the way the random bits are derived is somehow reproducible, hence not "really" random. The entropy daemons task is to use certain hardware resources (or otherwise a proven algorithm) to produce as-real-as-possible random number and fill a pool with this (i.e. /dev/random) that other software can then use.

Also, after updating to 6.30 the other day I woke up this morning and tried to update my plex server when running sudo apt-get upgrade it told me my storage was full. I looked at my cloud shell screen and I noticed all of my storage values for my SD card and external storage did not have a "storage cap value" it just had how much space was used. (IE. 400mb / )Normally it shows 400mb / 29.8gig a reboot resolved this issue.

Do you mean DietPi-Cloudshell?
And you mean with the new Odroid XU4 beta image? Because there should be no update done since it is already on DietPi v6.30 when flashing it 🤔.

[Doctorbeefy]

@MichaIng

Do you mean DietPi-Cloudshell?

Yes, I was talking about my LCD screen using it.

And you mean with the new Odroid XU4 beta image? Because there should be no update done since it is already on DietPi v6.30 when flashing it 🤔.

I updated from 6.29 to 6.30 via Dietpi-Update and this is when the issue happened. I will check on it again tomorrow to see if it does it again and let you know. It was weird seeing it acted like every storage attached (SD card/ External HD's) were all full when they weren't.

[MichaIng]

@Doctorbeefy
Ah probably you used the previous beta image then, as I repacked it on Mai 18. However this should not influence functionality since it is based on the same firmware/kernel.

I will check on it again tomorrow to see if it does it again and let you know.

I just checked the cloudshell script and it's output is based on df. If it really happens again, would be great if you could check df directly to see if it is a low-level issue, probably as well the dmesg -l err,crit,alert,emerg again to see if there are any errors with later timestamp then lets say [ 500.000000] so that it is not something from the boot process but happened during normal operation.

[Doctorbeefy]

``` ─────────────────────────────────────────────────────
DietPi v6.30.0 (beta) : 15:01 - Tue 26/05/20
─────────────────────────────────────────────────────

• Device model : Odroid XU3/XU4/MC1/HC1/HC2 (armv7l)
• CPU temp : /boot/dietpi/func/dietpi-globals: line 1519: cannot create temp file for here-document: No space left on device
  0'C : 32'F (Who put me in the freezer!)
• LAN IP : 10.0.0.244 (eth0)
• MOTD : Check your kernel error logs from time to time: dmesg -l err,crit,alert,emerg
  ─────────────────────────────────────────────────────

DietPi Team : MichaIng (lead), Daniel Knight (founder), Joulinar (support)
Image : DietPi Core Team (pre-image: Meveric)
Web : https://dietpi.com | https://twitter.com/dietpi_
Patreon Legends : Bryce
Donate : https://dietpi.com/#donate
DietPi Hosting : Powered by https://myvirtualserver.com

dietpi-launcher : All the DietPi programs in one place.
dietpi-config : Feature rich configuration tool for your device.
dietpi-software : Select optimized software for installation.
htop : Resource monitor.
cpu : Shows CPU information and stats.

root@DietPi:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 951628 0 951628 0% /dev
tmpfs 204244 21892 182352 11% /run
/dev/mmcblk1p2 29894439 3415100 26475243 12% /
tmpfs 1021216 8 1021208 1% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 1021216 0 1021216 0% /sys/fs/cgroup
tmpfs 1048576 1048576 0 100% /tmp
tmpfs 51200 8 51192 1% /var/log
/dev/mmcblk1p1 255744 45716 210028 18% /boot
/dev/sda1 1921720520 735905360 1185798776 39% /mnt/storage
root@DietPi:~# sudo apt-get upgrade
Reading package lists... Error!
E: Write error - write (28: No space left on device)
E: Write error - write (28: No space left on device)
E: The package lists or status file could not be parsed or opened.
root@DietPi:~# dmesg -l err,crit,alert,emerg
[ 0.156303] CPU4: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[ 0.176284] CPU5: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[ 0.184612] CPU6: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[ 0.192608] CPU7: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[ 1.874393] exynos-hdmi 14530000.hdmi: Failed to get supply 'vdd': -517
[ 1.957251] devfreq 11800000.mali: Couldn't update frequency transition information.
[ 3.470420] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[ 3.889464] OF: graph: no port node found in /soc/hdmi@14530000
[ 8.614423] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[ 8.633804] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[ 8.898491] sd 0:0:0:0: [sda] No Caching mode page found
[ 8.902944] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 219.762490] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[ 219.784279] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
root@DietPi:~# ```

[Doctorbeefy]

@MichaIng
I noticed the temp is way low as well. Here are screenshots from the cloud shell LCD as well (Don't Mind the dust)

Also, I want to note I can still access my media content via plex even though it says mount not active.

Also this started happening with DietPi version: 6.30.0. It didn't seem to happen with DietPi version: 6.29

[Joulinar]

Hi,

did you remove some files and tried to clean /tmp ??

[Doctorbeefy]

@Joulinar No I haven't done anything, this only happens randomly after running for a day or so.

[Joulinar]

maybe something is filling up /tmp and did not get remove. can you check what is located in /tmp?

[Doctorbeefy]

@Joulinar A ton of crap is in /tmp such as

0000706a-e090-4d85-955f-4d5f8859d1f9 55d7f3df-4ed3-4e8c-b37f-bf3046ce0f83 aafe1b29-8bcd-4b41-b3b6-fd87cec43f75 000a5373-993d-41b5-846d-49141381cf77 55debdcc-e838-44e7-aa68-2d63981d8d03 ab03697f-aab6-4da1-8ce9-238002e3d996 00111bd6-79d2-46ed-a0b4-1d6b19d8b541 55e4c56e-d634-4cf9-8594-60ac63cefc8d ab04c667-a76c-45be-ad09-452fbe1b0302 0016fc18-737e-4d3e-859a-82fac5b99952 55e955d0-be16-48f4-ab62-17c966ee7f98 ab096d88-624f-4ff5-937f-321b43074368 001c174f-589d-4fd8-adbc-29d2a7631a70 55edc049-018f-45f3-9ff9-9d02a1028e7d ab115248-0720-43e2-9f9f-5a209e6c700a 001d84f1-5646-4bfa-9605-be17b1fc266b 55f875e1-db48-4661-ae36-24bf98c1c73c ab188456-3b1d-4a4b-aad1-1aefdd22a9d3 00255bc0-3135-4b9a-9b66-2f66e906e7cb 55f8c893-2a4a-4001-92c8-0c722560e888 ab32e2c8-31bf-46e0-b66c-c613141dae29

[Doctorbeefy]

@Joulinar I would like to note as well a reboot will fix this issue, I have been waiting though to do this until troubleshooting is done.

plexinstaller.log
pms-cb8366f4-eddb-493c-a307-e23221705b92

^ These are the only two things that stand out in that list and the second one is a folder that contains

'Convert to Dolby Digital (High Quality - 640 kbps)' 'Convert to Dolby Digital Plus (Max Quality - 1024 kbps)' 'Convert to Dolby Digital (Low Quality - 384 kbps)' 'Convert to WAV (to 2ch or less)' 'Convert to Dolby Digital Plus (High Quality - 384 kbps)' 'Convert to WAV (to 8ch or less)'

Edit:

-rw-r--r-- 1 plex dietpi 1073332224 May 22 02:02 1c04cfda-8782-4941-8ab9-1bf6c746e407 -rw-r--r-- 1 plex dietpi 397312 May 22 02:03 c7d61117-f9e4-4710-a86a-92b18b228c44 -rw-r--r-- 1 plex dietpi 4096 May 22 02:03 b5b5111b-ead0-4987-a479-a8b20a603f6a -rw-r--r-- 1 root root 532 May 21 09:25 plexinstaller.log -rw-r--r-- 1 plex dietpi 78 May 22 02:04 c36f10f1-ccd0-4e94-94f1-c65a99df5d6c drwxr-xr-x 2 root root 60 May 26 17:45 DietPi-Cloudshell drwxr-xr-x 3 plex dietpi 60 May 22 02:01 pms-cb8366f4-eddb-493c-a307-e23221705b92

Top files by size in /tmp

1c04cfda-8782-4941-8ab9-1bf6c746e407 looks like it is being made by plex but I have no idea what the hell it is.

[Joulinar]

for sure a reboot will fix it, because /tmp is not a persistent directory. It's a tmpfs, located in memory and will be freshly created during boot.

hmm plex is creating these files. Seems to be used for transcoding. I found an interesting discussion on plex forum about /tmp usage. It seems some others having similar issues

https://forums.plex.tv/t/pms-stopped-honoring-temporary-directory-setting-now-uses-tmp/594501/20

A possible solutions is offered as well, to create an additional override.conf and to specify an alternative path for the temp file location to avoid filling up /tmp

[Doctorbeefy]

@Joulinar great catch looks like they messed up something. Should I delete all my extra crap here?

[Joulinar]

I would go to try to implement the workaround using the additional override.conf and reboot your system afterwards. You can point with the plex tmp dir to some other location. maybe on your external device.

[Doctorbeefy]

@Joulinar it looks like the easiest fix is to disable the new intro skip they implemented. It looks like that is storing data in tmp for every intro.

[Joulinar]

ok, honestly I'm not that familiar with plex functionality and usage. at least you could disable the into function and check how /tmp will behave.

[MichaIng]

I've just overseen the 100% /tmp usage. Good find, seems Plex currently has an issue of not cleaning up temporary files. Regardless if /tmp is a tmpfs or not, this must not happen of course. Using an alternative location could make it even worse, filling up the SDcard which might make the whole system break + adds SDcard wear.

I'll have a look into the other error, but I guess it is minor or expected when not having certain feature packages installed:

s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel

---

The linked Plex forum thread deals all around the used tmp directory, but since we never faced such issues before I doubt that Plex wrote such amount of data in such short time anywhere before. If it would, if would render PMS incompatible with RPi and most SBCs with SDcard and limited RAM. Lets see what the others think about this: https://forums.plex.tv/t/pms-stopped-honoring-temporary-directory-setting-now-uses-tmp/594501/48?u=michaing

[Joulinar]

@MichaIng
You are right, moving Plex temp to SD card could make thinks worse if it's filling up completely. As of now we don't know how much space would be needed. Anyway we hijacked this topic now as it was initially intent for the new image but turned into the Plex discussion. Should me move to a new one?

[MichaIng]

Lets go on with this issue here: https://github.com/MichaIng/DietPi/issues/3568

[Sudrien]

Got a new HC1 for the cluster -

Oddly, the (three?) IPv6 dns9.quad9.net pings were failing for me, but forcing 9.9.9.9 did not. I presume it's due to my network VPN setup. Otherwise setup went smoothly.

Any particular reason dietpi.com isn't being used for those?

[MichaIng]

EDIT moved to new issue: #3573

@Sudrien
Many thanks for testing.

Not sure, somehow pinging any domain that resolves with IPv6 currently fails from my network as well with timeout, while running curl to connect to the webserver on the same IPv6 works pretty fine. I tested the same from our server and observed a significant time delay when pinging to IPv6 before the first answer arrives, around 3 seconds.

Just to verify, if you run

ping dns9.quad9.net

it resolves to an IPv6 IP?
And does it receive any package at all when waiting long, else which error?

ping -4 dns9.quad9.net

instead works fine?

Generally when IPv6 works slow I would simply disable it, but ping/ICMPv6 seems to behave somehow different then HTTP(S).

Another try while playing around from dietpi.com server:

2020-05-29 09:40:59 root@dietpi:~# ping -v6 google.com
ping: socket: Permission denied, attempting raw socket...
PING google.com(ams15s30-in-x0e.1e100.net (2a00:1450:400e:807::200e)) 56 data bytes
From dietpi.com (XXX) icmp_seq=9 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=10 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=11 Destination unreachable: Address unreachable
64 bytes from ams15s30-in-x0e.1e100.net (2a00:1450:400e:807::200e): icmp_seq=22 ttl=54 time=2062 ms
64 bytes from ams15s30-in-x0e.1e100.net (2a00:1450:400e:807::200e): icmp_seq=23 ttl=54 time=1038 ms
64 bytes from ams15s30-in-x0e.1e100.net (2a00:1450:400e:807::200e): icmp_seq=24 ttl=54 time=14.3 ms

Another interesting attempt:

2020-05-29 09:45:14 root@dietpi:~# curl -vIL google.com
* Rebuilt URL to: google.com/
*   Trying 2a00:1450:400e:807::200e...
* TCP_NODELAY set
*   Trying 172.217.17.142...
* TCP_NODELAY set
* Connected to google.com (172.217.17.142) port 80 (#0)
> HEAD / HTTP/1.1
> Host: google.com
> User-Agent: curl/7.52.1
> Accept: */*
...

Host resolves to IPv6 but curl quickly switches to IPv6. Forcing IPv6 (-6) breaks the connection:

2020-05-29 09:43:24 root@dietpi:~# curl -IL -6 google.com
curl: (7) Failed to connect to google.com port 80: No route to host

It's a pain, the DNS lookup to get the IPv6 address has no issue and works immediately but connections are somewhat broken or unstable or slow. I'll do further tests...

---

Obvious solution is to disable IPv6, but it's somehow contra-productive to do that in nearly every case then (either for fix or for connection performance) and by this break all efforts to establish the future 🤔.

---

2020-05-29 11:32:17 root@dietpi:~# wget --spider google.com
Spider mode enabled. Check if remote file exists.
--2020-05-29 11:37:27--  http://google.com/
Resolving google.com (google.com)... 2a00:1450:400e:807::200e, 172.217.17.142
Connecting to google.com (google.com)|2a00:1450:400e:807::200e|:80... failed: No route to host.
Connecting to google.com (google.com)|172.217.17.142|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.com/ [following]
Spider mode enabled. Check if remote file exists.
--2020-05-29 11:37:45--  http://www.google.com/
Resolving www.google.com (www.google.com)... 2a00:1450:4001:81d::2004, 172.217.22.100
Connecting to www.google.com (www.google.com)|2a00:1450:4001:81d::2004|:80... failed: No route to host.
Connecting to www.google.com (www.google.com)|172.217.22.100|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.

The google.com IPv6 address is btw correct as can be seen by public reverse IP lookups for a google.com server in Germany, which makes sense as our VPS is located there. Also ping -6 succeeds after a few failing attempts. I guess this initial failures make curl and wget switch to IPv4.

---

Traceroutes

2020-05-29 13:17:30 root@dietpi:~# traceroute6 google.com
traceroute to google.com (2a00:1450:400e:807::200e), 30 hops max, 80 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * dietpi.com (XXX)  3051.680 ms !H
2020-05-29 13:18:01 root@dietpi:~# traceroute6 dns9.quad9.net
traceroute to dns9.quad9.net (2620:fe::9), 30 hops max, 80 byte packets
 1  2a06:1c40:3::1 (2a06:1c40:3::1)  13.032 ms  12.880 ms  12.785 ms
 2  2a06:7f80::1 (2a06:7f80::1)  12.880 ms  12.735 ms  12.720 ms
 3  dns9.quad9.net (2620:fe::9)  12.557 ms !X  12.576 ms !X  12.528 ms !X
2020-05-29 13:18:12 root@dietpi:~# ping -6 dns9.quad9.net
PING dns9.quad9.net(dns9.quad9.net (2620:fe::9)) 56 data bytes
64 bytes from dns9.quad9.net (2620:fe::9): icmp_seq=1 ttl=61 time=4.98 ms
64 bytes from dns9.quad9.net (2620:fe::9): icmp_seq=2 ttl=61 time=4.72 ms

• dns9.quad9.net works fine here but big old Google is not reachable. The question is why ping -6 finally succeeds after sending ~10 unanswered packets.

---

Another topic:

2020-05-29 13:23:46 root@dietpi:~# ping -v dns9.quad9.net
ping: socket: Permission denied, attempting raw socket...
ping: socket: Permission denied, attempting raw socket...
PING dns9.quad9.net(2620:fe::fe:9 (2620:fe::fe:9)) 56 data bytes
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=1 ttl=61 time=4.71 ms
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=2 ttl=61 time=4.83 ms
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=3 ttl=61 time=4.71 ms

By default ICMP sockets are disabled: sysctl net.ipv4.ping_group_range returns 1 0
This is for IPv4:

2020-05-29 13:24:19 root@dietpi:~# ping -v4 dns9.quad9.net
ping: socket: Permission denied, attempting raw socket...
PING dns9.quad9.net (9.9.9.9) 56(84) bytes of data.
64 bytes from dns9.quad9.net (9.9.9.9): icmp_seq=1 ttl=54 time=4.86 ms
64 bytes from dns9.quad9.net (9.9.9.9): icmp_seq=2 ttl=54 time=4.85 ms
64 bytes from dns9.quad9.net (9.9.9.9): icmp_seq=3 ttl=54 time=5.51 ms
64 bytes from dns9.quad9.net (9.9.9.9): icmp_seq=4 ttl=54 time=4.91 ms

Now I set a "group range" from group 0 to group 0, means only the root group is allowed to use ping sockets then:

2020-05-29 13:25:20 root@dietpi:~# sysctl -w net.ipv4.ping_group_range='0 0'
net.ipv4.ping_group_range = 0 0
2020-05-29 13:26:45 root@dietpi:~# ping -v4 dns9.quad9.net
PING dns9.quad9.net (149.112.112.9) 56(84) bytes of data.
64 bytes from dns9.quad9.net (149.112.112.9): icmp_seq=1 ttl=54 time=5.74 ms
64 bytes from dns9.quad9.net (149.112.112.9): icmp_seq=2 ttl=54 time=5.09 ms
64 bytes from dns9.quad9.net (149.112.112.9): icmp_seq=3 ttl=54 time=5.54 ms

🈯 ICMP(v4) sockets are allowed for root group, hence no error message anymore.
Now looking for a related option for ICMPv6, although not sure if this is related since disabled ICMP sockets are default everywhere.

---

No separate setting for IPv6 available or required, but has nothing to do with unreliable connection:

2020-05-29 13:40:19 root@dietpi:~# ping -v dns9.quad9.net
PING dns9.quad9.net(2620:fe::fe:9 (2620:fe::fe:9)) 56 data bytes
From dietpi.com (XXX) icmp_seq=20 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=21 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=22 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=23 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=24 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=25 Destination unreachable: Address unreachable
From dietpi.com (XXX) icmp_seq=26 Destination unreachable: Address unreachable
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=27 ttl=61 time=1023 ms
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=28 ttl=61 time=9.82 ms
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=29 ttl=61 time=5.49 ms
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=30 ttl=61 time=17.2 ms
64 bytes from 2620:fe::fe:9 (2620:fe::fe:9): icmp_seq=31 ttl=61 time=12.9 ms
^C
--- dns9.quad9.net ping statistics ---
31 packets transmitted, 5 received, +7 errors, 83% packet loss, time 30578ms
rtt min/avg/max/mdev = 5.492/213.746/1023.189/404.739 ms, pipe 2