Dietpi: Open beta v6.17 | Please help to improve stability before next release

[MichaIng]

New open beta launched: Please help bullet-prove testing the upcoming DietPi release!

€€: Beta v6.17.9 is up with several fixes: https://github.com/Fourdee/DietPi/pull/2166 https://github.com/Fourdee/DietPi/pull/2167

€: Beta v6.17.7 is up, which fixed a few issues and resolved the need to manually rerun dietpi-update to apply v6.16 => v6.17 patch, see below.
Related PR: https://github.com/Fourdee/DietPi/pull/2150

---

We just started public beta testing:

• https://twitter.com/DietPi_/status/1051493658971779072
• https://github.com/Fourdee/DietPi/blob/beta/BRANCH_SYSTEM.md

We hope much of you can help to test v6.17 before we push it to release branch. Note that the new "beta" branch can be considered as stable as the prior "master" (release) branch. We internally run the same careful tests before pushing changes from active development into beta branch. So the purpose of the new system is not to outsource in-dev testing, but to further improve release stability and avoid hotfix releases, like sometimes needed in the past.
The vast possible combinations of SBC devices, distro versions, configurations and installed software titles has grown too large to internally test every single of them.

Of course we appreciate, if testers have a special eye on the features we add/change with this release. Check out the current changelog: https://github.com/Fourdee/DietPi/blob/beta/CHANGELOG.txt

How to apply the beta branch on your system: https://github.com/Fourdee/DietPi/blob/beta/BRANCH_SYSTEM.md

If you find any bugs, please open a separate issue, mentioning "beta" in the header, e.g.
Beta v6.17 | Software title foo fails to install

Use this thread for general feedback or questions about our new beta program.

Happy testing 🥂!

---

Known issues

Urgent

• [x] When flashing a new image and set beta branch (in dietpi.txt) before first boot, dietpi-update will as always run automatically. But since for v6.17 a second manual update run is needed, this is still outstanding when you log in the first time: https://github.com/Fourdee/DietPi/issues/2140#issuecomment-430000467, https://github.com/Fourdee/DietPi/issues/2144
  Please. to avoid any issues, do switch to beta branch only AFTER first run setup and first login has been done! DietPi-Software could otherwise run into inconsistencies between v6.17 DietPi code and still outstanding incremental patches. We will fix this issue with the next beta/rc version.
  €: Fixed, for beta v6.17.6 with: https://github.com/Fourdee/DietPi/pull/2145

DietPi functionality

• DietPi-Globals | G_* functions are not available via sudo: https://github.com/Fourdee/DietPi/issues/2135
• DietPi-Config | Enabling WiFi + Ethernet adapters, both on different subnets, breaks WiFi connection: https://github.com/Fourdee/DietPi/issues/2103
  
  
  
  • Current workaround is to disable the adapter that is not in use (not for internet connection).
  
  

DietPi visual

• [x] DietPi-Update | Whiptail menus during central part of update process show wrong dimensions: https://github.com/Fourdee/DietPi/issues/2105
  €: Fixed, for beta v6.17.6 with: https://github.com/Fourdee/DietPi/pull/2146

SBC/device related

• RPi | LXAppearance (on LXDE desktop) hangs on dbus-launch: https://github.com/Fourdee/DietPi/issues/1791#issue-325031923
• Pine64 | Enable Bluetooth add-on module: https://github.com/Fourdee/DietPi/issues/528
• Odroid XU4 | Xorg (e.g. desktops) fail to start: https://github.com/Fourdee/DietPi/issues/2130
• Odroid C2 | Kodi GPU acceleration does not work on Stretch images: https://github.com/Fourdee/DietPi/issues/1814
• Odroid C2 | HotSpot does not work with (some?) WiFi adapters: https://github.com/Fourdee/DietPi/issues/1955
• [x] WaveShare32 | Input axis are inverted: https://github.com/Fourdee/DietPi/issues/803
  €: Fixed for beta v6.17.8 with: https://github.com/Fourdee/DietPi/commit/ef03b05e819fb9e145877d5207908a596ecae3be

Software title related

• OpenBazaar | Client connection fails: https://github.com/Fourdee/DietPi/issues/1090
• Node-RED | Pre-installed modules cannot be updated via webUI: https://github.com/Fourdee/DietPi/issues/2073
• SiCKRAGE | Fails to install on some systems due to external python issue: https://github.com/Fourdee/DietPi/issues/2126
• Raspimjpeg | With Lighttpd, streaming mjpeg does not work: https://github.com/Fourdee/DietPi/issues/1747
• OMPD/MyMPD | Updating database stucks in loop: https://github.com/Fourdee/DietPi/issues/2156

---

Open for discussion

• [x] Pi-hole | Show blocking page for clients? https://github.com/Fourdee/DietPi/issues/2007
  €: We will implement a choice menu, but forwarded to v6.18 to not further delay v6.17 release.
• [x] SiCKRAGE/SickChill | Stay with SiCKRAGE or switch to fork SickChill (or support both)? https://github.com/Fourdee/DietPi/pull/2143
  €: We will stay with SiCKRAGE for now. However we are open to implement SickChill as an alternative separate software title, if requested by users: https://github.com/Fourdee/DietPi/pull/2143#issuecomment-430021566

[Millichrome]

I will this a go on my test 3B+ board.

[MichaIng]

@Fourdee
I summed up all open bugs/known issues above.
Since we are in open beta phase, besides recent/urgent and newly reported issues, we could also have a look on older issues with lower priority.

Either stop with new features/larger enhancements until release, or do not merge them into current beta. So we use the beta phase to calm down dev a bid and instead concentrate on stability, testing and fixing. What you think?

[Millichrome]

I successfully updated my ASUS tinker board to 16.17 beta. It runs PLEX, qbittorrent, Samba and Pi-hole. Not seeing any issues so far, all applications are working well.

I did have an issue when installing a fresh image of 16.17 beta on my 3B+. I downloaded the latest Raspberry Pi image and changed the channel to "beta" in dietpi.txt. However, when I connected via SSH, the terminal showed that I was running 16.16 beta:

I updated to 16.17 beta without any issues. Haven't got a chance to test out any applications, but I was thinking of running a home media centre off the Pi.

[MichaIng]

@Millichrome
Thanks for this report.

Indeed I imagine an issue when installing a fresh image and directly switch to beta branch:

• Currently when updating pre-v6.17 to v6.17, dietpi-update needs to be rerun manually to apply the new versioning system.
• The new DietPi code is already in place then, but the incremental patches were not yet done. So we manually set version string to v6.16.0 to allow second dietpi-update run applying the incremental patches as well.
• When flashing a pre-v6.17 image, on first boot dietpi-update will automatically run, but of course the second manual run is still outstanding. Since dietpi-software will pop up already and offer configuration/software install, even that incremental patches are missing, this can lead to issues.

@Fourdee
We need to do a version check on first run after initial dietpi-update run. If subversion string is (still) lower than 17, we either need to automatically do a second update or prompt info to user to do so.

• I would prefer to do that automatically. Actually first run update could simply be a while loop that rechecks available update until none available any more. Only risk is for some reason a unlimited loop, if something goes wrong with version string/var update 🤔.
• Hmm also practically not trivial to implement, since new code is only in place, after first run update already done and install stage already set to 1 (finished). Checked the code. Should be possible to set .update_stage to -1 (when .install_stage < 1) when patch_file applies now versioning system. Since dietpi-update is terminated, it does not apply value 0, so dietpi-software does not apply value 1, so first run update is re-triggered. But hmm, no reboot triggered then, dietpi-software first-run install can be done, which is not good 🤔.
• Actually best would be, if we could somehow trigger a second dietpi-update 1 run without reboot between both. When applying new versioning system and (( $(</DietPi/dietpi/.install_stage) < 1 )), do sed -i '\|/DietPi/dietpi/dietpi-update 1|a\/DietPi/dietpi/dietpi-update 1' /DietPi/dietpi/dietpi-software. Hmm does not work, since current dietpi-software code already loaded of course 🤔.
  - Ah waaaaait: G_EXIT_CUSTOM in patch_file can be added to restart dietpi-update. Since /tmp/DietPi-Update has already removed prior to G_EXIT_CUSTOM, this will work. We can use this also for interactive (non-firstrun) updates to v6.17 😃! We could pgrep for "dietpi-update 1" to decide if we run it forcefully (non-interactively) as well or not. €: Fixed, was finally not too hard: https://github.com/Fourdee/DietPi/pull/2145

---

Check why (beta) is shown in DietPi banner:

• It is somehow right, because at least beta code is already applied, but somehow wrong because incremental patches still missing. And looks confusing because there is no v6.16.0 beta 😆.
• https://github.com/Fourdee/DietPi/blob/beta/dietpi/patch_file#L46-L49
  Perhaps we should skip those G_GIT* value estimation. The values from dietpi.txt are "target" values, not "current" values. dietpi-globals will apply "Fourdee" and "master" as default init, which leads to no branch is shown in banner, so no confusion. dietpi-update of course will still apply the branch, configured in dietpi.txt, so it's really just about the visual strings shown in banner and during update and does not affect anything else. €: Included in: https://github.com/Fourdee/DietPi/pull/2145

[Millichrome]

I see, so it's a purely visual thing. I do remember thinking that the installation process felt a bit more involved than a stable image. :)

[MichaIng]

@Millichrome
Jep issues are unlikely, but theoretically possible, especially when you choose several software titles for install on first login and/or the image has a very old DietPi version. Also if I checked to code right, currently a reboot after first run update is missing.
So theoretically code with missing incremental patches can lead to issues during dietpi-software applying initial setup and installs.

But I found a solution I guess, that even allows to skip the manual second update run, when applying beta on fully installed systems. Will play around with this now 😃.

[Millichrome]

Possible bug:
WiFi installation doesn't start with a fresh beta image on my 3B+. The device didn't appear on the router WiFi client list during multiple checks after initialization.

Beta image installation via etherenet works great. I can switch to WiFi only after completing the installation via ethernet.

Trying a fresh Etcher image didn't help. I have previously installed DietPi via WiFi with older stable releases.

QOL issue?
After installing a fresh beta image via ethernet for a second time, I noticed that the installation takes a while to initialize. I believe it took at least 10 min for my device to appear on the etherent client list. No idea if this is related to my setup or something about DietPi. I think it's fine if this is related to beta processes, but it felt long for a stable release.

[MichaIng]

@Millichrome
As of what I mentioned above and added to OT: Did you try to install via WiFi but master branch first, then apply beta update after first run setup?

It's too late now for me to go through it, but since we did some changes about WiFi with the last two releases, I think the missing reboot after initial update might lead to code inconsistencies.

About second Ethernet attempt:

• Did you use DietPi-Automation actually (configure dietpi.txt to automatically install software on first boot)?
• Do you have a chance to follow the init process on screen? Would be helpful to know which step exactly takes so long.

---

Btw, I finished a PR to apply the second dietpi-update execution automatically: https://github.com/Fourdee/DietPi/pull/2145
This should avoid mentioned potential issues.

I want to finish another visual issue with whiptail menus inside patch_file (done) and maybe we manage to fix one or another bug, listed in OT, before merging next RC into beta.

---

Next beta v6.17.6 is up, OT updated accordingly.

[Millichrome]

@MichaIng

I was able to do WiFi install using the master branch, but not the beta branch.

The ethernet install was for a clean image. No additional applications or modification other than setting the channel to beta.

I will try out the 6.17.7 version advertised by the dietpi-update and report back.

[Fourdee]

Beta in final stages of testing.

Pending 2+ days of additional testing, we'll release v6.17. Outstanding issues without a quick/viable fix will be moved to v6.18 to prevent delaying v6.17 further.

[dynobot]

Tried to run the beta on Odroid C2 in order to see if the Ethernet issues were resolved. No luck.
Once after the install and reboot I lost my network connection via Ethernet. Dead in the water now.

[dynobot]

Tried to run the beta on Odroid C2 in order to see if the Ethernet issues were resolved. No luck.
Once after the install and reboot I lost my network connection via Ethernet. Dead in the water now.

Found the problem.....at least for me.

The Ethernet was not broken....it IP address changed !!

I looked on my router and saw a new IP address, I ssh'd into it and behold.....it was the Odroid C2.

Next I tried connecting to wifi using a dongle.....worked fine.

Rebooted and wifi connected no problem
Rebooted again just for kicks and it worked without a hitch.

[dynobot]

Spoke too soon....wifi worked long enough for me to ssh into the Odroid then it died. It seems to be coming on and off....not only the wifi but the USB ports. I can see my connected DAC turning on and off too.

Seeing that both the DAC and the Wifi seem to be cycling on and off I unplugged the DAC's power which it gets from the USB ports. Now my wifi seems to be okay. Looks like the Odroid has some power issues concerning its USB ports.

[Fourdee]

@dynobot

Looks like the Odroid has some power issues concerning its USB ports.

Interesting, if you are already running a 5V/2A PSU (official HK, or, RPi), might be worth investing in a mains powered USB hub, eg:
https://www.amazon.co.uk/Belkin-Ultra-Powered-Power-Supply/dp/B0061RSACG

Also, when instability occurs, check dmesg for any errors/issues at the end lines. Might give some more info.

[MichaIng]

@dynobot

IP address changed

Interesting, the Odroid receives its IP via DHCP I believe? This is something the DHCP server decides and there is nothing you can do about it on the client, besides changing the MAC address. But this is nothing we do DietPi side. What we did with v6.13 -> v6.14 patch is resetting the device ID, but this is nothing a DHCP server should even be able to recognize (?).

Usually a DHCP server reserves assigned IPs for a certain lease time. If the DHCP client is up the same IP should be extended automatically. So not sure what could have caused a change in your case. But to be sure you should, if possible, configure your router to assign a fixed IP to the Odroid. In many cases it is as well possible to simply disable the DHCP client and configure the system use a static IP within the DHCP IP range. In my case this works great at least, so one background process less on the machine 🙂.

[Fourdee]

Thanks to everyone for helping with the Beta test, we really appreciate your support!

Marking this as completed, pending v6.17 release today.

[MichaIng]

NB: The last beta is identical to current master (release), so you don't need to actively change branches and reapply the update.
You will then see an update notification, once we open up the next beta phase. Feel free to re-join next beta phase then by applying the update or switch to master branch to stay with current release and mute beta update notifications.