DietPi-RAMdisk | Replace with vmtouch to use native fs caching

[MichaIng]

Status: Review

ToDo:

• Create runtime stat/flag files in /run/dietpi

Commit list/description:

• DietPi-RAMdisk | Remove script due to replacement with vmtouch

[Joulinar]

@MichaIng
let me know of you need testing

[MichaIng]

Okay, everything ready from my side:

• DietPi-RAMdisk is history
• Migration during update has been tested with several older images, should be failsafe
• Migration for Jessie systems is blocked, has been tested with one older and one newer Jessie image as well
• vmtouch is installed instead, locking DietPi scripts and dietpi.txt in RAM to preserve execution and parsing performance of RAMdisk. However it can be freely configured via /etc/default/vmtouch to lock anything or nothing or do another of its features instead. As well it is totally optional and can be disabled (systemctl disable vmtouch) or purged (apt purge vmtouch) without affecting DietPi functionality, only our scripts might be a bid slower when executed rarely and the first time during boot.

Do not write runtime files to disk, I moved those to a new runtime tmpfs dir /run/dietpi which do not need to be boot-persistent. This complies with Debian defaults, FHS etc as well:

• Runtime files, required during service or system runtime: /run
• Temporary files, e.g. per-script files, expected to be removed after usage: /tmp

[Joulinar]

@MichaIng
Did a test on a Stretch as well as Buster VM. Both updates to v6.29 finished as follow:

[  OK  ] DietPi-Update | Incremental patching to v6.29.0 completed
[ SUB2 ] DietPi-Update > Completed
[ INFO ] DietPi-Update | Current version : v6.29.0
[ INFO ] DietPi-Update | Latest version  : v6.29.0
[  OK  ] DietPi-Survey | Sending survey data
[ SUB3 ] DietPi-Services > restart
[  OK  ] DietPi-Services | restart : airsonic
[  OK  ] DietPi-Services | restart : cron
Terminated
root@DietPiVM3:~# 

All fine, except the Terminated at the end 😄

Not sure if this is something but I found this on journalctl on both systems.

Mar 06 22:24:16 DietPiVM3 systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Mar 06 22:24:16 DietPiVM3 systemd[1]: Mounting /tmp...
Mar 06 22:24:16 DietPiVM3 systemd[1]: Mounted /tmp.

[MichaIng]

@Joulinar
Many thanks for testing. Yes the termination is expected. Due to the changes it is required to restart DietPi-Update (new code) from within the patch_file. When the child instance has finished, the parent instance must be terminated to not finish another time with old code. However I'll add some message that this is expected.

Done: 9895c3d + edafa69

tmp.mount: Directory /tmp to mount over is not empty

We clear the /tmp dir when creating new images, however it can happen by times that something is written to the non-tmpfs /tmp dir when it mounts late at boot or unexpectedly unmounts or such. To solve:

mkdir /mnt/root
mount /dev/sda1 /mnt/root
rm -Rfv /mnt/root/tmp/{,.??,.[^.]}*
umount /mnt/root
rmdir /mnt/root

[Joulinar]

@MichaIng
looks good now

[  OK  ] DietPi-Update | Incremental patching to v6.29.0 completed
[ SUB2 ] DietPi-Update > Completed
[ INFO ] DietPi-Update | Current version : v6.29.0
[ INFO ] DietPi-Update | Latest version  : v6.29.0
[  OK  ] DietPi-Survey | Sending survey data
[ SUB3 ] DietPi-Services > restart
[  OK  ] DietPi-Services | restart : redis-server
[  OK  ] DietPi-Services | restart : mariadb
[  OK  ] DietPi-Services | restart : php7.3-fpm
[  OK  ] DietPi-Services | restart : lighttpd
[  OK  ] DietPi-Services | restart : logitechmediaserver
[  OK  ] DietPi-Services | restart : cron
[  OK  ] DietPi-Services | ncc maintenance:mode --off
[  OK  ] DietPi-Patch | Everything done! Terminating the obsolete DietPi-Update parent instance...
Terminated
root@DietPiVM1:~#

Question: should there be an automated reboot initiated?

[MichaIng]

@Joulinar

Question: should there be an automated reboot initiated?

Nope, only on first boot, if this is the firstrun update and the image is pre-v6.20.

[Joulinar]

Roger that