DietPi 🚀 - Open Beta v6.34 | Please help testing and hardening the upcoming release

I'll start up a Tor relay (Bridge), with open ports this time.

ravenclaw900 on 9 Dec 2020

maybe we should do a test plan. a spreadsheet where we can track. quite a lot to test.

Joulinar on 9 Dec 2020

Okay, 2 things. After updating to the beta branch, boot starts about 160 seconds in and is pretty slow. And, if you install Tor Relay, then DietPi-Cloudshell, it will automatically see that the file exists and try to use the non-existent nyx (easy fix there, just need to add another G_AG_CHECK_INSTALL_PREREQ).

ravenclaw900 on 9 Dec 2020

Okay, 2 things. After updating to the beta branch, boot starts about 160 seconds in and is pretty slow.

I was thinking that this might become an issue. It's the automated APT update check that runs now along with the DietPi update check at the end of boot. But it's a background process which should not delay the login prompt, does it?

Generally I think it's fine to update the package lists on boot, but it needs to be silent and not disturbing.

And, if you install Tor Relay, then DietPi-Cloudshell, it will automatically see that the file exists and try to use the non-existent nyx

But one needs to enable the scene manually first, isn't it? I'm currently looking for where and which scenes are enabled by default, when no settings file exists yet (EDIT: Ah it's indeed all, but the ones which are not disabled due to missing file: Pi-hole, Tor Relay). However, the file check is actually wrong. Not Tor needs to be installed, by nyx:

/root/.nyx/config

Or we check for both files, since nyx without Tor has no point as well.

Okay we could:

Check for nyx config, or even executable, to assure it's there.
Check for Tor config additionally, which depends on whether nyx shows some meaningful info when Tor is not present, or some ugly one.
Even hide the Tor Relay option from the menu, when it is not installed, same with Pi-hole. Reasonable on the one hand, as it cannot work, but hides that features from users as well. Not bad to show what is supported in general without the related software title being installed already.

MichaIng on 9 Dec 2020

It does show 'meaningful' info, Unable to connect to tor. Are you sure it's running?. The best thing would probably be to check for both Tor and nyx config files.

ravenclaw900 on 9 Dec 2020

Okay let's do it like that, but let's check for executables instead of the config files:

command -v tor > /dev/null && command -v nyx > /dev/null || aEnabledScenes[9]=0

Done: https://github.com/MichaIng/DietPi/commit/1f10f8e590e5a754012ad1c7f87ef54e2a70b7ae

MichaIng on 9 Dec 2020

The boot usually works now, it hasn't taken that long since last night. However, I do have automatic APT package updates on, but it is just reporting them instead.

ravenclaw900 on 9 Dec 2020

The boot usually works now, it hasn't taken that long since last night.

160 seconds actually sound like a service startup hanged and timed out (90 seconds default timeout), probably due to time sync failure (60 seconds default timeout). We faced a few more reports and I ran myself into it where the default [0-3].debian.pool.ntp.org time sync servers had issues, but that sees to be sorted now, at least here the sync succeeds moreless immediately now.

I do have automatic APT package updates on, but it is just reporting them instead.

Yes I just tested again here and it works as expected: Update checks run in background while login prompt is there right after service startups. The DietPi update check itself finishes usually quickly, so usually, if a DietPi update is available, you'll see it in the banner. APT updates take longer, so when logging in directly, likely they are not yet shown, but instead on a subsequent login or SSH login.

Also on first boot of a fresh image, that check is skipped in favour of the automated first run update.

MichaIng on 9 Dec 2020

Yes, the packages are showing on the banner correctly, but I want them to update automatically like I have it set.

ravenclaw900 on 9 Dec 2020

but I want them to update automatically like I have it set.

Ah, on boot this is disabled by intention. We documented it a way that packages are auto-upgraded on a daily basis via cron job, so it can be well controlled when this happens and other cron jobs ordered accordingly, e.g. a backup before the APT upgrades are started. On boot, this could make the system unusable for a certain time, e.g. during time consuming and/or heavy package upgrades like kernel or larger software that includes builds, like WireGuard and the kernel module rebuild. When booting the system, one usually wants to do something with it within the next minutes and not deal with heavy load and potential repeated service restarts during their APT config/postinst steps.

Ah btw, I forgot to add a dietpi-services start to the end of automated APT upgrades. DietPi-controlled services are "disabled" so that they are not started by systemd during boot but by our own boot scripts at a later stage in controlled order. But that implies that some APT upgrades stops their related service, but do not start it up again. E.g. when upgrading MariaDB this is definitely the case. So to assure all services are back up, we need to run dietpi-services start. This does not touch already/still running services, only stopped ones.

MichaIng on 9 Dec 2020

Makes sense. I really just wasn't sure if the banner was supposed to show when automatically updating packages.

ravenclaw900 on 9 Dec 2020

You've been super helpful to me, I would like to return the favor.... I have a Rock64 coming in the next 2 days that I could use for testing in case you don't have any Rock64 testers yet

arpegius5555 on 9 Dec 2020

booting on my RPi3B+ is quite ok

root@DietPi3:~# systemd-analyze blame
          6.696s dietpi-boot.service
          1.041s dev-mmcblk0p2.device
           507ms systemd-fsck@dev-disk-by\x2dpartuuid-907af7d0\x2d01.service
           365ms keyboard-setup.service
           272ms networking.service
           241ms systemd-udev-trigger.service

Main part is waiting on valid network connection due to DHCP 🙄

Joulinar on 10 Dec 2020

Guys for your information. Currently it's not possible to install PaperMC plugins for Geyser and Floodgate. The download is failing

[FAILED] DietPi-Software | Checking URL: https://ci.nukkitx.com/job/GeyserMC/job/Floodgate/job/development/lastStableBuild/artifact/bukkit/target/floodgate-bukkit.jar
 - Command: curl -ILfvm 10 https://ci.nukkitx.com/job/GeyserMC/job/Floodgate/job/development/lastStableBuild/artifact/bukkit/target/floodgate-bukkit.jar

there is as well a report on the board https://dietpi.com/phpbb/viewtopic.php?p=29446#p29446

Joulinar on 12 Dec 2020

👍1

Indeed, the branch name has changed: https://ci.nukkitx.com/job/GeyserMC/job/Floodgate/
master should be fine now, @ravenclaw900 do you agree?

MichaIng on 12 Dec 2020

Yes, I do.

ravenclaw900 on 12 Dec 2020

Fixed: https://github.com/MichaIng/DietPi/commit/d2bbc962238745b7b4299320f3092d1393b6c8aa
Makes sense, matches Geyser-Spigot branch as well.

MichaIng on 12 Dec 2020

DietPi v6.41.1 has been pushed to beta branch: #3968

MichaIng on 12 Dec 2020

I have so far run my DietPi RaspiZero with the Pihole plugin and manually installed unbound flawlessly.
Because there is now an unbound plugin, I tested it and get timeout errors:

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353
dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353

Both command lines throw timeout errors.

What am I doing wrong?

omavoss on 15 Dec 2020

What files are in the Unbound config directory? ls /etc/unbound/unbound.conf.d Also, are you running Pi-hole at the same time?

ravenclaw900 on 15 Dec 2020

I restored my previous installation of unbound from the dietpi backup, now everything works again.

root@DietPiZero:~# ls /etc/unbound/unbound.conf.d
pi-hole.conf  qname-minimisation.conf  root-auto-trust-anchor-file.conf
root@DietPiZero:~#

Pi-hole running at the same time, yes.

My restored system runnig without errors:

root@DietPiZero:~# dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26483
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.    IN      A

;; ANSWER SECTION:
sigok.verteiltesysteme.net. 3600 IN     A       134.91.78.139

;; Query time: 111 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Di Dez 15 19:52:48 CET 2020
;; MSG SIZE  rcvd: 71

root@DietPiZero:~#

root@DietPiZero:~# dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50328
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 285 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Di Dez 15 19:53:31 CET 2020
;; MSG SIZE  rcvd: 57

root@DietPiZero:~#

I now install DiePi with Pi-hole and the unbound plugin to a new micro SD card and report back, thank you.

Sorry, I have to translate every post from German to English with DeepL and that takes time.

omavoss on 15 Dec 2020

Strange, those aren't the files that DietPi creates (maybe something left over from your previous manual installation). Glad it's working now, though.

ravenclaw900 on 15 Dec 2020

@ravenclaw900
probably a misunderstanding. @omavoss was running ubound already with an own installation. After switching to beta and a re-installation of ubound, it stopped working. Now he restored a backup to previous state. That's why it is working again. 😉

Joulinar on 15 Dec 2020

Ah, that is the previous file, then. Makes sense.

ravenclaw900 on 15 Dec 2020

@Joulinar @ravenclaw900
Yes, that's right. I am in the process of flashing another micro SD card with DietPi, then switching to beta and installing Pi-hole and Unbound. After that I will get back to you, it may take some time.

omavoss on 15 Dec 2020

Now I setup a new DietPi with PiHole and Unbound and my RaspiZero works whit this successfully:

root@DietPi:~# dig pi-hole.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> pi-hole.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            3457    IN      A       192.124.249.118

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Tue Dec 15 23:27:16 CET 2020
;; MSG SIZE  rcvd: 56

root@DietPi:~# dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47213
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 1 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Tue Dec 15 23:27:25 CET 2020
;; MSG SIZE  rcvd: 57

```
root@DietPi:~# dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41222
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;sigok.verteiltesysteme.net. IN A

;; ANSWER SECTION:
sigok.verteiltesysteme.net. 189 IN A 134.91.78.139

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Tue Dec 15 23:27:31 CET 2020
;; MSG SIZE rcvd: 71

root@DietPi:~#
````

DietPi is a great piece of software, many thanks!

omavoss on 15 Dec 2020

probably issue was because of the old installation. Good that it got sorted.

Joulinar on 16 Dec 2020

@MichaIng
One question on the new feature to notify on available apt packages. The location of the notification seems to be not fitting into the layout and I'm thinking if it is located on right place.

- 1 APT packages can be upgraded, run (sudo) "apt upgrade" or "apt full-upgrade".

because all phrases containing a hyphen are in a separate box. Except the apt information which is so close to useful commands 😉

 ─────────────────────────────────────────────────────
 DietPi v6.34.1 (beta) : 1 APT updates available
 ─────────────────────────────────────────────────────
 - Device model : RPi 3 Model B+ (armv7l)
 - Uptime : up 8 minutes
 - CPU temp : 41'C : 105'F (Optimal temperature)
 - LAN IP : 192.168.0.12 (eth0)
 - Info Test : !!! DEMO 32bit Image !!!
 ─────────────────────────────────────────────────────

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

  - 1 APT packages can be upgraded, run (sudo) "apt upgrade" or "apt full-upgrade".
 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@DietPi3:~#

not sure if you guys already discussed this 🤔

Joulinar on 16 Dec 2020

👍1

Yes you are right, I stumbled as well above this and then forgot about it again. The location is the same where the dietpi-update line appears, if one is available:

dietpi-update   : Run now to update DietPi from v6.34.-1 (dev) to v6.34.1.

Probably we should switch the APT upgrade line to:

apt upgrade     : Run now to apply xy available APT package upgrades

And with another empty line before below, like the first one has it. sudo would fit but no space before : then. I was thinking to show it in case if (( $UID )) automatically. Not sure if apt full-upgrade is worth to mention separately.

MichaIng on 16 Dec 2020

👍1

apt upgrade : Run now to apply xy available APT package upgrades

Ah yes that would be fit better from layout perspective to the lines below.

Joulinar on 16 Dec 2020

https://github.com/MichaIng/DietPi/commit/75a578c590f8a37d3d35a57f64d48b010018a176

MichaIng on 16 Dec 2020

Just loaded a fresh image on my Rock64
`````
https://dietpi.com/downloads/images/testing/DietPi_ROCK64-ARMv8-Buster.7z
```````

Got the following errors right after the first boot:
````
E: Failed to fetch https://armbian.hosthatch.com/apt/dists/stretch/main/binary-armhf/Packages.bz2
E: Some index files failed to download. They have been ignored, or old ones used instead.
`````

It came up 3 times and when I tried to re-run last command it did not work. Had to exit out of it.

Did this affect my initial install?

arpegius5555 on 17 Dec 2020

Also, when tryin to install pivpn:

Reference code: 5b644fb7-c79a-487a-8b64-8f345bf0b7fe

``````````````
APT install for: dnsutils net-tools bsdmainutils iptables-persistent

Command: apt-get -qq --allow-change-held-packages install dnsutils net-tools bsdmainutils iptables-persistent
Exit code:100
DietPi version: v6.34.1 (MichaIng/beta) | HW_MODEL: 43 | HW_ARCH: 3 | DISTRO: 4 │
Image creator: DietPi Core Team
Pre-image: ARMbian
Error log:
WARNING: The following packages cannot be authenticated! │
libnfnetlink0 libbsd0 bsdmainutils libip6tc0 libiptc0 libxtables12 libnetfilter-conntrack3 iptables libgeoip1 netfilter-persistent iptables-persistent net-tools
E: There were unauthenticated packages and -y was used without --allow-unauthenticated
`````````

arpegius5555 on 17 Dec 2020

There is currently a known issue with the Armbian repository mirrors: https://forum.armbian.com/topic/16504-bionic-apt-update-file-has-unexpected-size/
Please hit retry a few times, until it succeeds. It seems to be that when files are pulled from different mirrors (the sources.list entry is a mirror director, so you'll see it pulling files from different servers often), they fail the hashsum/size checks, as probably the mirrors are not 100% in sync at the same time. But the issue has been well recognised, so I assume there will be a solution soon.

MichaIng on 17 Dec 2020

@MichaIng
Today I started my test RPi1 and I got notified about an available update

dietpi-update : Run now to update DietPi from v6.34.0 (beta) to v6.34.1.

Ok just went strait to the update but got blocked due to an already running session of dietpi-update

root@DietPi1:~# dietpi-update
[ INFO ] DietPi-Update | Concurrent execution of DietPi-Update detected, retrying... (1/5)
[ INFO ] DietPi-Update | Concurrent execution of DietPi-Update detected, retrying... (2/5)
[ INFO ] DietPi-Update | Concurrent execution of DietPi-Update detected, retrying... (3/5)
[ INFO ] DietPi-Update | Concurrent execution of DietPi-Update detected, retrying... (4/5)
[ INFO ] DietPi-Update | Concurrent execution of DietPi-Update detected, retrying... (5/5)
[FAILED] DietPi-Update | Cancelled DietPi-Update due to concurrent execution
root@DietPi1:~#

I guess this is the apt check that is executed on boot?

root       420     1  0 14:41 ?        00:00:00 /bin/bash /boot/dietpi/postboot
root       423   420  0 14:41 ?        00:00:00 /bin/bash /boot/dietpi/dietpi-update 2

Not sure if this is a rar scenario or if it could lead to some irritations?

Joulinar on 17 Dec 2020

Yes exactly, DietPi update checks were always done at the end of boot as well, but taking significantly longer now that APT update checks are included. On first boot of a new image it is skipped btw, do it will not break first boot update.

I guess mostly in testing cases we'll run into this, as mostly testing images are booted and directly updated? On the other hand, the DietPi banner update hint shows up quickly 🤔. Actually it would be reasonable if APT update check was skipped when a DietPi update was found. The banner anyway shows the DietPi update info in this case, and not the APT update info. And DietPi update includes APT updates as well, of course. What you think?

MichaIng on 17 Dec 2020

yes that would be a good idea to skip apt update check if a DietPi update has been found. As you said. It dons't matter anyway as DietPi Update will perform the apt package update anyway

Joulinar on 17 Dec 2020

Done: https://github.com/MichaIng/DietPi/commit/4bcf7a62b8bf20a4a5de1c7c5d96fe1022be097c
Needed another change to assure that daily automated APT upgrades still work: https://github.com/MichaIng/DietPi/commit/54b6dc4f315479a1c1937cf288603ea13a5c9b56
I'm not 100% happy, it is a bid scattered, I'll likely merge everything in a cleaner better understandable way into the dietpi-update script, probably with next release, where other overdue changes to dietpi-update are urgently required.

MichaIng on 17 Dec 2020

There is currently a known issue with the Armbian repository mirrors: https://forum.armbian.com/topic/16504-bionic-apt-update-file-has-unexpected-size/
Please hit retry a few times, until it succeeds. It seems to be that when files are pulled from different mirrors (the sources.list entry is a mirror director, so you'll see it pulling files from different servers often), they fail the hashsum/size checks, as probably the mirrors are not 100% in sync at the same time. But the issue has been well recognised, so I assume there will be a solution soon.

Did that and seem to have gone into a loop, this keeps on repeating for the last 10 minutes, I may ctrl +c out of it

[ OK ] DietPi-Login | Connection test: https://deb.debian.org/debian/ [ OK ] Network time sync | Completed [ SUB1 ] DietPi-Update > Checking for available DietPi update [ INFO ] DietPi-Update | Checking mirror: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6 [ OK ] DietPi-Update | Using update server: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6 [ OK ] DietPi-Update | No update required, your DietPi installation is already up to date: [ INFO ] DietPi-Update | Current version : v6.33.3 [ INFO ] DietPi-Update | Latest version : v6.33.3 [ OK ] DietPi-Login | Connection test: https://deb.debian.org/debian/ [ OK ] Network time sync | Completed [ SUB1 ] DietPi-Update > Checking for available DietPi update [ INFO ] DietPi-Update | Checking mirror: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6 [ OK ] DietPi-Update | Using update server: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6 [ OK ] DietPi-Update | No update required, your DietPi installation is already up to date: [ INFO ] DietPi-Update | Current version : v6.33.3 [ INFO ] DietPi-Update | Latest version : v6.33.3 [ OK ] DietPi-Login | Connection test: https://deb.debian.org/debian/ [ OK ] Network time sync | Completed

arpegius5555 on 17 Dec 2020

What exactly did you do to land in this loop? This looks like the first run setup of a new DietPi image, but that one should exit the loop even if no update is available: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-update#L179
And you're on master branch instead of beta branch now?

Also what I recognised now, you downloaded the Buster image but the error message was:

E: Failed to fetch https://armbian.hosthatch.com/apt/dists/stretch/main/binary-armhf/Packages.bz2

Note: stretch 🤔

I was checking the image and the sources list entry was correct (deb http://apt.armbian.com buster main buster-utils buster-desktop), probably there is a larger issue with that mirror redirection than we though.

Btw, I uploaded a new image for ROCK64 (one real machine boot test outstanding). although for a different reason: https://dietpi.com/downloads/images/testing/DietPi_ROCK64-ARMv8-Buster.7z

MichaIng on 17 Dec 2020

What exactly did you do to land in this loop? This looks like the first run setup of a new DietPi image, but that one should exit the loop even if no update is available: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-update#L179
And you're on master branch instead of beta branch now?

Also what I recognised now, you downloaded the Buster image but the error message was:
E: Failed to fetch https://armbian.hosthatch.com/apt/dists/stretch/main/binary-armhf/Packages.bz2
Note: stretch 🤔

I was checking the image and the sources list entry was correct (deb http://apt.armbian.com buster main buster-utils buster-desktop), probably there is a larger issue with that mirror redirection than we though.

Btw, I uploaded a new image for ROCK64 (one real machine boot test outstanding). although for a different reason: https://dietpi.com/downloads/images/testing/DietPi_ROCK64-ARMv8-Buster.7z

I simply flashed this one to the eMMC,
https://dietpi.com/downloads/images/testing/DietPi_ROCK64-ARMv8-Buster.7z
booted it, and the error I mentioned earlier came

E: Failed to fetch https://armbian.hosthatch.com/apt/dists/stretch/main/binary-armhf/Packages.bz2 E: Some index files failed to download. They have been ignored, or old ones used instead.

Tried re run-command about 3 times and the 3rd time seems to have gone through, then I landed on the aforementioned loop.

I ctrl +c'ed out of it, rebooted and it seem to be fine.

I will flash it again in a couple hours with the new image you just provided

`````
https://dietpi.com/downloads/images/testing/DietPi_ROCK64-ARMv8-Buster.7z
``````

Thanks

arpegius5555 on 17 Dec 2020

👍1

Ok, so flashed it and booted fine, so far so good. I noticed a small error though only via HDMI, I noticed it will stay on the message for 5 to 10 seconds (meanwhile I was SSH'ing)

Also, while I was typing this note, I looked at the screen via HDMI and saw this:

It seems like she died right there... I'll try to restart

arpegius5555 on 18 Dec 2020

When trying to install pivpn:

`````
│ Selecting previously unselected package iptables-persistent.^M [
│ (Reading database ... ^M(Reading database ... 5%^M(Reading database ... 10%^M(Reading database ... 15%^M(Reading datab[
│ ... 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading database ... 35%^M(Reading database ... 40%^M([
│ database ... 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading database ... 60%^M(Reading database .[
│ (Reading database ... 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading database ... 85%^M(Reading [
│ database ... 90%^M(Reading database ... 95%^M(Reading database ... 100%^M(Reading database ... 20829 files and directo[
│ currently installed.)^M [
│ Preparing to unpack .../iptables-persistent_1.0.11+deb10u1_all.deb ...^M [
│ Unpacking iptables-persistent (1.0.11+deb10u1) ...^M [
│ Setting up netfilter-persistent (1.0.11+deb10u1) ...^M [
│ Created symlink /etc/systemd/system/multi-user.target.wants/netfilter-persistent.service -> [
│ /lib/systemd/system/netfilter-persistent.service.^M [
│ Setting up iptables-persistent (1.0.11+deb10u1) ...^M [
│ Can't locate object method "new" via package "Text::Iconv" (perhaps you forgot to load "Text::Iconv"?) at [
│ /usr/share/perl5/Debconf/Encoding.pm line 65.^M [
│ dpkg: error processing package iptables-persistent (--configure):^M [
│ installed iptables-persistent package post-installation script subprocess returned error exit status 29^M [
│ Processing triggers for systemd (241-7~deb10u5) ...^M [
│ Processing triggers for libc-bin (2.28-10) ...^M [
│ Errors were encountered while processing:^M [
│ iptables-persistent^M [
│ E: Sub-process /usr/bin/dpkg returned an error code (1)

```````````

I tried to re-run the command 3 times to no success.

arpegius5555 on 18 Dec 2020

try to install iptables-persistent manually

apt install iptables-persistent

once done, re-run PiVPN

Joulinar on 18 Dec 2020

Btw, let's stay with the discussion of this at the originating issue as it is not related to DietPi v6.34 😉: #3939

MichaIng on 18 Dec 2020

Beta v6.34.2 has been merged: #3981

MichaIng on 18 Dec 2020

One very small thing that I noticed, on the donate link in DietPi-Banner, there is an apostrophe at the end of it. ( Donate : https://dietpi.com/#donate'). @MichaIng, could you fix?

ravenclaw900 on 19 Dec 2020

👍1

Great find, fixed: https://github.com/MichaIng/DietPi/commit/e762627a471909ce0a979a5ce77958bcb4f03a7e

MichaIng on 19 Dec 2020

When enabling I2C; dietpi installs python-smbus and i2c-tools. python-smbus is deprecated (and also installs the old python2.7 fileset) so the script needs to be updated to install python3-smbus instead :-)

Trunkzeh on 20 Dec 2020

👍1

Good find. I checked all cases where this is enable as dependency and it's only PiJuice which uses Python 3 already and pulls i2c-tools and python3-smbus itself as dependency. I'll hence update the script as you said.
Done: https://github.com/MichaIng/DietPi/commit/44d3e96d6255dc65dd3242e52fc062ababd3561e
Changelog: https://github.com/MichaIng/DietPi/commit/bc3835826757c14fcd3ce79511cf852efd1bc697

MichaIng on 20 Dec 2020

🎉1

DietPi v6.34 has been released. Many thanks to all testers!

MichaIng on 20 Dec 2020

🎉3

Dietpi: Open Beta v6.34 | Please help testing and hardening the upcoming release

Related/solved issues: https://github.com/MichaIng/DietPi/issues?q=is%3Aissue+milestone%3Av6.34

Better formatted overview 😃: https://github.com/MichaIng/DietPi/pull/3960#issue-534513651

Most helpful comment

DietPi v6.34 has been released. Many thanks to all testers!

All 51 comments

DietPi v6.41.1 has been pushed to beta branch: #3968

Beta v6.34.2 has been merged: #3981

DietPi v6.34 has been released. Many thanks to all testers!

Related issues