Dietpi: Upgrade v6.25.3 -> v.6.30.0 fails: /DietPi/dietpi/func/dietpi-ramdisk: No such file or directory

[zerbes]

Details:

• Date | Tue 12 May 19:17:58 BST 2020
• Bug report | N/A
• DietPi version | v6.25.3 (MichaIng/master)
• Img creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi 3 Model B (armv7l) (index=3)
• Kernel version | #1253 SMP Thu Aug 15 11:49:46 BST 2019
• Distro | stretch (index=4)
• Command | /DietPi/dietpi/func/dietpi-ramdisk 1
• Exit code | 127
• Software title | DietPi-Update

Steps to reproduce:

running dietpi-update

Expected behaviour:

upgrade to v.6.30.0

Actual behaviour:

upgrade breaks with error "/DietPi/dietpi/func/dietpi-ramdisk: No such file or directory". I seems this happens during upgrade to 6.26.x already but i am not sure

Extra details:

• ...

Additional logs:

Log file contents:
/DietPi/dietpi/func/dietpi-globals: line 1316: /DietPi/dietpi/func/dietpi-ramdisk: No such file or directory

[Joulinar]

Hi,

many thanks for your report. pls can you provide following

ls -la /boot/dietpi/func/
ls -la /DietPi/dietpi/func/
ls -la /

[zerbes]

Thanks for the support.

Here we go:

ls -la /boot/dietpi/func/

total 283
drwxr-xr-x 2 root root  2560 Jun  2  2019 .
drwxr-xr-x 4 root root  4096 Jul  7  2019 ..
-rwxr-xr-x 1 root root  1427 May 12 19:04 change_hostname
-rwxr-xr-x 1 root root  1975 May 12 19:04 create_mysql_db
-rwxr-xr-x 1 root root  9893 May 12 19:04 dietpi-banner
-rwxr-xr-x 1 root root 13009 May 12 19:04 dietpi-benchmark
-rwxr-xr-x 1 root root 70097 May 12 19:04 dietpi-globals
-rwxr-xr-x 1 root root  4255 May 12 19:04 dietpi-led_control
-rwxr-xr-x 1 root root  9570 May 12 19:04 dietpi-logclear
-rwxr-xr-x 1 root root 20844 May 12 19:04 dietpi-obtain_hw_model
-rwxr-xr-x 1 root root  1549 May 12 19:04 dietpi-optimal_mtu
-rwxr-xr-x 1 root root  4306 May 12 19:04 dietpi-ramdisk
-rwxr-xr-x 1 root root  3106 May 12 19:04 dietpi-ramlog
-rwxr-xr-x 1 root root  7728 May 12 19:04 dietpi-set_cpu
-rwxr-xr-x 1 root root  3771 May 12 19:04 dietpi-set_curlftpfs
-rwxr-xr-x 1 root root 63378 May 12 19:04 dietpi-set_hardware
-rwxr-xr-x 1 root root  2701 May 12 19:04 dietpi-set_nfsclient
-rwxr-xr-x 1 root root  4351 May 12 19:04 dietpi-set_smbclient
-rwxr-xr-x 1 root root 25705 May 12 19:04 dietpi-set_software
-rwxr-xr-x 1 root root  4753 May 12 19:04 dietpi-set_swapfile
-rwxr-xr-x 1 root root  5690 May 12 19:04 dietpi-set_userdata
-rwxr-xr-x 1 root root  9217 May 12 19:04 dietpi-wifidb
-rwxr-xr-x 1 root root  3770 May 12 19:04 obtain_network_details
-rwxr-xr-x 1 root root  5223 May 12 19:04 run_ntpd

ls -la /DietPi/dietpi/func/

total 324
drwxr-xr-x 2 root root   480 May 12 19:04 .
drwxr-xr-x 4 root root   820 May 12 19:41 ..
-rwxr-xr-x 1 root root  1427 May 12 19:04 change_hostname
-rwxr-xr-x 1 root root  1975 May 12 19:04 create_mysql_db
-rwxr-xr-x 1 root root  9893 May 12 19:04 dietpi-banner
-rwxr-xr-x 1 root root 13009 May 12 19:04 dietpi-benchmark
-rwxr-xr-x 1 root root 70097 May 12 19:04 dietpi-globals
-rwxr-xr-x 1 root root  4255 May 12 19:04 dietpi-led_control
-rwxr-xr-x 1 root root  9570 May 12 19:04 dietpi-logclear
-rwxr-xr-x 1 root root 20844 May 12 19:04 dietpi-obtain_hw_model
-rwxr-xr-x 1 root root  1549 May 12 19:04 dietpi-optimal_mtu
-rwxr-xr-x 1 root root  4306 May 12 19:04 dietpi-ramdisk
-rwxr-xr-x 1 root root  3106 May 12 19:04 dietpi-ramlog
-rwxr-xr-x 1 root root  7728 May 12 19:04 dietpi-set_cpu
-rwxr-xr-x 1 root root  3771 May 12 19:04 dietpi-set_curlftpfs
-rwxr-xr-x 1 root root 63378 May 12 19:04 dietpi-set_hardware
-rwxr-xr-x 1 root root  2701 May 12 19:04 dietpi-set_nfsclient
-rwxr-xr-x 1 root root  4351 May 12 19:04 dietpi-set_smbclient
-rwxr-xr-x 1 root root 25705 May 12 19:04 dietpi-set_software
-rwxr-xr-x 1 root root  4753 May 12 19:04 dietpi-set_swapfile
-rwxr-xr-x 1 root root  5690 May 12 19:04 dietpi-set_userdata
-rwxr-xr-x 1 root root  9217 May 12 19:04 dietpi-wifidb
-rwxr-xr-x 1 root root  3770 May 12 19:04 obtain_network_details
-rwxr-xr-x 1 root root  5223 May 12 19:04 run_ntpd

ls -la /

total 71
drwxr-xr-x 21 root root  4096 May 15  2018 .
drwxr-xr-x 21 root root  4096 May 15  2018 ..
drwxr-xr-x  2 root root  4096 Sep  9  2019 bin
drwxr-xr-x  5 root root  3072 Jan  1  1970 boot
drwxr-xr-x 14 root root  3400 May 12 19:04 dev
drwxrwxrwt  3 root root   120 May 12 19:04 DietPi
drwxr-xr-x 74 root root  4096 May  3 12:03 etc
drwxr-xr-x  3 root root  4096 May 15  2018 home
drwxr-xr-x 17 root root  4096 Mar 10  2019 lib
drwx------  2 root root 16384 Mar 13  2018 lost+found
drwxr-xr-x  7 root root  4096 Aug  5  2018 mnt
drwxr-xr-x  4 root root  4096 Jul  2  2018 opt
dr-xr-xr-x 92 root root     0 Jan  1  1970 proc
drwx------  5 root root  4096 Jul  2  2018 root
drwxr-xr-x 19 root root   580 May 12 19:41 run
drwxr-xr-x  2 root root  4096 Sep 29  2019 sbin
drwxr-xr-x  2 root root  4096 Mar 20  2018 srv
dr-xr-xr-x 12 root root     0 Jan  1  1970 sys
drwxrwxrwt  8 root root   180 May 12 22:00 tmp
drwxr-xr-x 10 root root  4096 Mar 20  2018 usr
drwxr-xr-x 12 root root  4096 Jul  2  2018 var

[Joulinar]

hmm strange, as you can see on your output, the file is there. So it should have been working. Can you try again?

[zerbes]

I restored the system from a backup i made before the upgrade, so i can try once more tomorrow

[salemdar]

I also have the same problem with Asus Tinker Board S on a fresh install. No dietpi-ramdisk and when I check the directory, there is really no dietpi-ramdisk.

As a short term solution, is it possible to disable auto update on first boot?

[Joulinar]

@salemdar
What version of DietPi you are running? What file system you checked?

[salemdar]

@Joulinar
I used to have stretch 6.20 something, maybe 6.25. I don't exactly remember. I wanted to go buster, so I downloaded the image from the website, flashed it, and got this error.

[Joulinar]

What file system you checked?

[salemdar]

@Joulinar
What do you mean by file system? Asus tinker board s has a 16GB eMMC and it is EXT4.

[Joulinar]

your statement was, that you checked a directory, which on? and what is you current version of DietPi?

[salemdar]

@Joulinar
I don't have a current version, I am trying a fresh install. I download this image, unzip and flash it to the device with etcher. Then I proceed to boot it, ssh into it, it starts installing/updating all the way to the latest version. Then I get this error.
When I ls -la /boot/dietpi/func/ or ls -la /DietPi/dietpi/func/, I really don't see a dietpi-ramdisk file.

[Joulinar]

try the following

apt install git
git clone https://github.com/MichaIng/DietPi.git Dietpi
rm -r /boot/dietpi/func/*
cp -r Dietpi/dietpi/func/* /boot/dietpi/func/
rm -r Dietpi
apt purge git
reboot

[MichaIng]

@Joulinar
Git is btw not required, the archive can be downloaded manually:

cd /tmp
get https://github.com/MichaIng/DietPi/archive/master.tar.gz
tar xf master.tar.gz
rm master.tar.gz
cp -a DietPi-master/dietpi/func/* /boot/dietpi/func/
rm -R DietPi-master

However actually that breaks the expected update path and there might be unwanted side effects. I'll run a test install. Since this is the second similar report there seems to be still a bug or at least instability. DietPi-Update should restart itself with the new code which should not call DietPi-RAMdisk anymore.

[MichaIng]

Found it, please do not do any of the mentioned steps, the error can and should be ignored.

[  OK  ] DietPi-Update | Incremental patching to v6.30.0 completed
[ SUB2 ] DietPi-Update > Completed
[ INFO ] DietPi-Update | Current version : v6.30.0
[ INFO ] DietPi-Update | Latest version  : v6.30.0
[  OK  ] DietPi-Survey | Setting in /boot/dietpi.txt adjusted: SURVEY_OPTED_IN=1
[  OK  ] DietPi-Survey | Sending survey data
[  OK  ] DietPi-Patch | Everything done! Terminating the obsolete DietPi-Update parent instance...


 DietPi-Update
─────────────────────────────────────────────────────
 Mode: Completed

[ INFO ] DietPi-Update | Current version : v6.24.3
[ INFO ] DietPi-Update | Latest version  : v6.30.0
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
chdir: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
[  OK  ] DietPi-Survey | Sending survey data
[FAILED] DietPi-Update | /DietPi/dietpi/func/dietpi-ramdisk 1

As can be seen from the first lines, the update has finished completely successfully. What fails is the termination of the obsolete parent process. This is due to a "bug" that has been fixed meanwhile: https://github.com/MichaIng/DietPi/commit/1e52d1348a678b422959f3cb12db30a6065f430b#diff-c613a85da508fb885b67c34f9661e243L469-R471

Details

We piped the output of the update into tee to write it to log file and keep console output. However as fast as a process output is piped, it looses it's ability to control the shell, while the target process becomes the main attached process. Since the incremental patches, which are also responsible for killing the obsolete parent update process, runs in this pipe, it cannot terminate anymore. v6.26 fixes this by using redirect into subshell where tee runs inside, so the incremental patch process stay the main attached process while the pipe target (tee) is a child process only.

Solution

So this error must be ignored, choosing exit will continue normally with DietPi-Software and there is no issue left with the failing parent update process. This is a v6.25 only issue, and there is technically no chance to solve it from within the patch file. So only solution IMO is to update the images, which I anyway wanted to do. Will now concentrate on getting the testing images stable and updating the stable images as well.

[salemdar]

@MichaIng thank you. But the when I ignore the error, it asks me to install absolute minimum dietpi and it ignores the configurations I made in dietpi.txt, like installing some software etc.

I guess updating the image is really the best solution. Not to pressure, but do you have an ETA for that?

[MichaIng]

@salemdar
Hmm that should not have an influence on dietpi.txt settings. The new dietpi-software is called in both cases. You need to take care that AUTO_SETUP_AUTOMATED=1 is set to have software installed automatically. Otherwise you can simply select required software again. However I'm currently rebuilding the image.

[MichaIng]

Image ready, would be great if you could do a test boot, before I move it to stable, just to be sure everything is fine with bootloader and kernel: https://dietpi.com/downloads/testing/DietPi_ASUSTB-ARMv7-Buster.7z

[salemdar]

@MichaIng
I have just tested it. The fix works, thanks a lot!

I have a different problem though:
ping -c 1 -W 5 dns9.quad9.net command fails with 100% packet loss. Funny enough when I run the same command in my normal machine's terminal, it works fine.
Even funnier, pinging 1.1.1.1 or even google.com works fine in dietpi. When I change that command to ping -c 1 -W 5 1.1.1.1, installation proceeds just fine. Only downside is that it breaks auto install.

[Joulinar]

you can adjust following settings in dietpi.txt

# General connection and DNS testing
# - IP to ping when checking network connectivity. Default: 1.1.1.1 (Cloudflare DNS, should be very fast world-wide)
CONFIG_CHECK_CONNECTION_IP=1.1.1.1
# - Domain to ping when checking DNS resolver. Default: one.one.one.one (Cloudflare DNS domain, see above)
CONFIG_CHECK_DNS_DOMAIN=one.one.one.one

even more fun fact that we switched from Cloudflare one.one.one.one to Quad9 dns9.quad9.net with the last release as we had users out who had issues using Cloudflare

[salemdar]

@Joulinar
I just realized that I was just using my outdated dietpi.txt. I saw those new fields in the new file. The new file works just fine with Quad9.
I love how you guys try to expose more and more variables and try make everything configurable. Thanks a lot, really 👍
I am planning to build an intel i5 nuc, and I can't wait to try dietpi on that machine :)

[MichaIng]

Then native PC images need update as well, as they are as well on v6.25 currently. Quick fix is of course to adjust the dietpi-update script on them directly and only, however a new image is not that much more work.

[salemdar]

@MichaIng
Couldn't we somehow automatise image building and refresh the images automatically at least in each minor version? Then it can install the patch versions on first boot as it does now.

[MichaIng]

@salemdar
We're working on making the build scripts ready for automation, but it is not yet the case. Especially currently we're upgrading all images to be based on Debian Buster and different base images, and this requires a lot of changes and testing, not so trivial, and we're a small spare-time team only. But I already had an eye on the GitHub workers, not sure how much traffic they allow (downloading + uploading base + final image) and if they allow nested virtualization so that ARM images can be build on them. Otherwise our server would require quite some upgrade to be capable of that.