Release v6.30

[MichaIng]

v6.30

(10/05/30 Hotfix)

Changes / Improvements / Optimisations

• DietPi-Software | qBittorrent: Changed default download file permissions so that Sonarr/Radarr/Lidarr/.. are able to manipulate the downloads after import. Many thanks to @compdealer for doing this suggestion: DietPi-Software | qBittorrent: Set 775 permissions/002 UMask by default on install #3524

Bug Fixes

• DietPi-Config | Resolved an issue where on RPi3/4/Zero W onboard WiFi could not be enabled. Many thanks to @elitearmedforce for reporting this issue: RPi 3 b+ Wifi Hardware not found #3510
• DietPi-Drive_Manager | Resolved an issue on Raspberry Pi where, after running DietPi-Drive_Manager, the root file system was mount read-only. Many thanks to @Adsouza98 for reporting this issue: RootFS is currently Read Only (R/O) mounted. Aborting... #3511
• DietPi-Banner | Resolved an issue where non-root users were unable to download a new MOTD (message of the day). Many thanks to @PeterLacknase and @fnsnyc for reporting this issue: dietpi-update fails to set files/file permissions in /run/dietpi #3505, Welcome screen on NanoPi NEO2 (aarch64) after 6.29.2 update #3520
• DietPi-Boot | Resolved an issue where non-root users were unable to read or update DietPi-internal network info, which lead to e.g. error messages on login. Many thanks to @PeterLacknase for reporting this issue: dietpi-update fails to set files/file permissions in /run/dietpi #3505
• DietPi-Update | Resolved an issue where on DietPi pre-v6.16 system some DietPi scripts were accidentally removed during update. Many thanks to @Vec7or and @Littis for reporting this issue: dietpi-ramlog: No such file or directory #3509, Update to 6.29.2 failed #3513

[MichaIng]

@Joulinar
Anything urgent I forgot?

[Joulinar]

Within the forum we have some message that sonarr and radarr have issues after the update. Not sure what is the cause. All have different symptoms.

https://dietpi.com/phpbb/viewtopic.php?f=11&t=7598

But more important to have Drive Manager fixed as well as the missing files

[MichaIng]

@Joulinar
I had a look into it. Indeed doesn't look like an obvious bug our side, especially since the DietPi update does not touch existing Sonarr/Radarr/Lidarr/Jackett instances and the errors are so very different. Probably it is/was a faulty mono version. Sometimes the many APT package updates and/or service restarts trigger errors that have nothing to do with the actual update but e.g. a faulty APT package or existing disk corruption that becomes apparent due to physically moved data, server restart or such. So I'll not defer v6.30 until tomorrow, but we'll keep investigating those issues of course 👍.

[Joulinar]

@MichaIng
yap I assume the same. Possibly due to apt or the triggert restart some issue came into the picture that are unknown before.

I know it's wrong place but maybe we can think on some apt update/upgrade and do a restart, before going to implement new DietPi Release. But honestly I even have no idea how to implement in theory, because users would need to be involved actively and test their application after apt and right before DietPi update. I guess it would be way to complicated and far away from DietPi philosophy to take a lot of load from users and automate as much as possible. 🤔

[MichaIng]

@Joulinar
There is an open request, planned for next release, to do daily automated APT upgrades via dietpi-update, optionally of course.
So one can do update checks only, or automated APT update && upgrade afterwards. This basically is a lightweight replacement for unattended-upgrades which for our end does not randomly block APT.
I think many users do not regularly upgrade their APT packages, and then the DietPi update contains a high amount of them, raising the risk that something does not end smoothly. This feature would keep the amount of upgraded packages per session low, and if any issue appears it can quickly be associated with the last daily APT upgrades.

[Joulinar]

@MichaIng
probably it can be combined with automatic restarts? Just to have it activated as well. Maybe the user can select a time window. Not sure if this is wise idea. 🤔

[PeterLacknase]

I don't know you in person and i don't know your goals. But as a BSD-guy and on the Linux side rather a "veteran" i'd highly urge you to stay away from too much "automatism". systemd is annoying enough. :-)

Automated daily updates are possibly ok for desktops. (And even there ... if somebody writes his scientific thesis or has to finish some business papers it's better to have a "potentially missing feature" or a "not that annoying bug" than an "up to date incompatibility".)

It's better imho to just check if apt updates are required before dist-upgrade. If so, stop the process. Give a warning/recommendation to update packages via apt by hand. If something breaks it won't break the dist-upgrade (and leave an even bigger mess behind).

Just my 2 cents.

[MichaIng]

@Joulinar
The daily update (check) is done as cron job, where time can be chosen via dietpi-cron. Generally APT upgrades are designed a way that a system restart is not required. For this reason also DietPi updates do not force a restart anymore. However of course for testing (before release) restart must be part of the schedule.

@PeterLacknase
Of course this will be an optional feature (disabled by default), for systems and users where some service/process downtime is not a big issue. The DietPi update does and will always include an APT upgrade as first step. This is the only way to assure that our scripts can use external commands and e.g. parse output reliably, when all systems are brought onto the same APT stage. apt-get dist-upgrade is btw not included and we will never do this aside from first boot of a fresh image. It is simply too risky and should only be done with full user attention since it can remove conflicting packages.
E.g. on Raspbian testing suite I regularly run into situations where PHP, MariaDB, the webserver or once even important system core packages would have been removed by a dist-upgrade since a package was updated in the repo but not all packages that are either dependencies or dependants of it. Raspbian repo maintainers do not pay much attention on testing suite repo consistency compared to Debian.