DietPi-Update | Another issue when updating to v6.20.5

[MichaIng]

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

Looks like either .update_stage is missing or setting .install_stage to 2 fails/is not saved until reboot.

But from code side there is no issue, similar to what happened with https://github.com/Fourdee/DietPi/issues/2458 just following the code logic, everything should work fine and did in all dev and beta cases. Only explanation in both cases is missed writes/syncs, file corruption, unusual shutdown, so RAMdisk failed (although then the update should just be offered again).

[MichaIng]

Most likely a DietPi-RAMdisk failure: https://github.com/Fourdee/DietPi/issues/2465#issuecomment-458576926

[MichaIng]

RAMdisk failure verified. It stops on shutdown after boot mount was already unmounted.

Solution so far:
Run dietpi-update but BEFORE reboot, stop ramdisk manually:
systemctl stop dietpi-ramdisk

Should actually not occur due to local-fs.target, needs investigation why systemd does not respect this order.

Whoever run into this issue:
Do you run a Jessie or Stretch image?

With v6.20.5 we removed After=boot.mount from RAMdisk service. However this is included in default sysinit.target which is always waited for when not overwriting systemd unit default dependencies. Only idea I have so far: Before=syslog.service rsyslog.service overwriting this on Jessie, similar to what happened with networking init.d service on Jessie. Although this should cause a dependency/order loop that we never faced on Jessie testing 🤔.

[docgalaxyblock]

Hi
I also have this issue with all of my PIs,
The update is stuck at 6.19.7, the solution from the forum didn't work...
The update works fine at my Odroids

[digitalcardboard]

Running 6.17 Stretch image on a RasPi with dietpi.txt, I eventually get to a point where DietPi-Update loops endlessly. This was after Ctrl-C to stop the boot looping, then I ran dietpi-update to update from 6.17 to 6.20.5, systemctl stop dietpi-ramdisk, and rebooted.

[Joulinar]

I tried to install from fresh 6.17 Stretch image on a RasPi. But somehow I end up in a loop. It always brings me back to the software selection screen where I just chose for Install without further packages. At the end it performs a reboot. After being back online, still the version is displayed at 6.17. As well it did not changed initial password and still require default one. Before entering software selection screen following error message appears

[ OK ] DietPi-Software | Root access verified.
[ OK ] DietPi-Software | RootFS R/W access verified.

[ OK ] DietPi-Software | Initialized database
[ OK ] DietPi-Software | Reading database completed
/DietPi/dietpi/dietpi-software: line 16151: /DietPi/dietpi/.update_stage: No such file or directory
/DietPi/dietpi/dietpi-software: line 16151: ((: == -1 : syntax error: operand expected (error token is "== -1 ")
[ OK ] DietPi-Software | Connection test: http://raspbian.raspberrypi.org/raspbian
[ OK ] DietPi-Run_ntpd | systemctl restart systemd-timesyncd
[ INFO ] DietPi-Run_ntpd | NTPD: Waiting for completion of systemd-timesyncd (1/60)
[ OK ] DietPi-Run_ntpd | NTPD: systemd-timesyncd synced
[ OK ] NTPD: time sync | Completed
/DietPi/dietpi/dietpi-software: line 16174: /DietPi/dietpi/.update_stage: No such file or directory
/DietPi/dietpi/dietpi-software: line 16174: ((: == -1 : syntax error: operand expected (error token is "== -1 ")

I tried to break the loop by exiting the software selection screen and to run dietpi-update manual but it did not solved it. Now I'm in new loop after reboot. After login, the following message is passing by quite fast again and again.

DietPi-Update
─────────────────────────────────────────────────────
Mode: Checking for DietPi updates

[ INFO ] DietPi-Update | Checking mirror: https://raw.githubusercontent.com/Fourdee/DietPi/master/dietpi/server_version-6
[ OK ] DietPi-Update | Using update server: https://raw.githubusercontent.com/Fourdee/DietPi/master/dietpi/server_version-6

[ INFO ] DietPi-Update | Current version : v6.20.5
[ INFO ] DietPi-Update | Latest version : v6.20.5
[ OK ] DietPi-Update | No updates required, your DietPi installation is up to date.

[ OK ] DietPi-Login | Connection test: http://raspbian.raspberrypi.org/raspbian
[ OK ] Root access verified.
[ OK ] NTPD: time sync | Completed
[ OK ] DietPi-Update | Root access verified.
[ OK ] DietPi-Update | RootFS R/W access verified.

I just can break it using Ctrl-C

[MichaIng]

@digitalcardboard
Did the solution with systemctl stop dietpi-ramdisk then solve the update issue, so no dietpi-software loop or error about missing .update_stage on login anymore?

I will then push a hotfix update to revert the change we did to the RAMdisk systemd unit.

[MichaIng]

Okay just pushed the mentioned changes + a possible first run loop fix as v6.20.6 hotfix update.

This will redo the update, as if you were still on v6.19.7 to assure all steps are done now as expected. Please apply this patch and report back if now all the issues are solved.
Btw. sorry that this means the possibly time consuming reinstalls are redone as well 🤔.

[digitalcardboard]

@digitalcardboard
Did the solution with systemctl stop dietpi-ramdisk then solve the update issue, so no dietpi-software loop or error about missing .update_stage on login anymore?

I will then push a hotfix update to revert the change we did to the RAMdisk systemd unit.

FWIW, it stopped the boot loop, but not the DietPi-Update loop. I'm working on a new project and I'm not far along so I'll try it and report back. My other option was to not update, but I was trying to use dietpi.txt to automate the deploy.

[MichaIng]

@digitalcardboard
This was with update to just merged v6.20.6?

Two update runs are expected.

• First run if /DietPi/dietpi/.update_stage still exists, it will be removed: https://github.com/Fourdee/DietPi/blob/master/dietpi/patch_file#L76
  • If /DietPi/dietpi/.install_stage is 1 (v6.19.7 situation) it will apply the value 2 and restart the update. This will then exit after the 2nd run has finished: https://github.com/Fourdee/DietPi/blob/master/dietpi/patch_file#L48-L50
  • If /DietPi/dietpi/.install_stage is 2 already, it skips the restart, thus should finish.
• If /DietPi/dietpi/.update_stage was already removed, it skips the restart as well.

[Joulinar]

ok I was able to run clean install from v6.17 > v6.20.6

during install process I was ask 2 times for reset default password. And during last reboot, it got stucked (hold) waiting for some process to finish. I simple deplug power and restarted my Pi. Than the boot was finishing on v6.20.6

[MichaIng]

@Joulinar
Jep, asking two times for passwords indeed is currently the case, when update is done on first run (on all our images currently). It does no harm, but indeed something we need to resolve.

You don't know exactly on which process the boot stuck, do you? Was is still during kernel message prompts already systemd or already during DietPi boot scripts?

[Joulinar]

Well I should have done a picture before deplug power. My fault. But as far as I remeber it was during DietPi-Boot. I have seen the messages for a "valid network connection found" and than something with stopping time sync ???? And than the message that it will wait (hold) for some process to finish.

let me do some test with my Pi. Maybe I can reproduce. Will keep you posted.

[digitalcardboard]

A clean run for me with v6.17 to v6.20.6 using dietpi.txt. Thanks for the quick help!

[MichaIng]

@Joulinar
Okay, jep most likely it was waiting for time sync to finish. However if first run setup (dietpi-software step after login) went fine then time sync was re-triggered anyway and is fine.

@digitalcardboard
Thanks for reporting back 👍.

[Joulinar]

@MichaIng there you go. It happen once the final update to v6.20.6 finsihed and system was going to reboot.

currently it's on 5 minutes waiting. If I would power down and reboot, it would finish in secounds.

[MichaIng]

@Joulinar
Ah nice thanks for this. Hmm this is not a DietPi script. [ OK ] Started DietPi-Boot means this one has finished completely.

n180211 not found. seems to be the key here. Seems some expected kernel module is missing, we need to do some web search. So this happens on every boot? And if you cancel, DietPi login prompt appears and services start up as expected?
EDIT: Ah you can't cancel this, so no chance to finish boot currently?

[Joulinar]

@MichaIng no I'm not able to cancel. I need to deplug power completly and than put power on again. It's failing just first time. But the error messege [n180211 not found.] is there always.

this is how the next boot looks like.

[MichaIng]

@Joulinar
Ah okay. Still, the "Starting Hold until..." message is still there as well, only it seems to finish this time quickly.

I see you have splash screen enabled. During web search I found plymouth related with this, which is responsible for boot splash screens.

disable_splash=1 in /boot/config.txt should resolve it, but disable the splash as well of course. However not required, if this Hold state is finished quickly now.

n180211 not found. is related to a 802.11n WiFi adapter and seems to be a firmware/driver issue with this. Are you connected via Ethernet or WiFi?
Perhaps this message is also expected on RPi3 when internal WiFi adapter is disabled. I have only RPi2 here, so can't say.

[Joulinar]

I'm connected via Ethernet. WiFi should be disabled. I just run the default image after creating my SD card using Ether. I did not changed anthing on configs before. Just power it on :)

[MichaIng]

@Joulinar
Hmm, interesting, can you paste output of:

grep 'disable_splash=' /DietPi/config.txt
grep 'disable_splash=' /boot/config.txt

This should be 1 (so splash disabled) on default image, new and v6.17 and way older as well. However no harm if splash is active.
Ah wait, hehe maybe I mixed up those RPi logo with the rainbow full screen splash in boot. Now that I remember, I think those are two different things 🤔.

[Joulinar]

root@DietPi:~# grep 'disable_splash=' /DietPi/config.txt disable_splash=1
root@DietPi:~# grep 'disable_splash=' /boot/config.txt disable_splash=1

btw your guess regarding n180211 not found. was correct. It's related to WiFi. But it just appears as long as WiFi is disabled. If I enable WiFi, message is gone during reboot. As soon as WiFi is disabled again, message n180211 not found. will be back. Looks more like a feature than a bug. :)

[MichaIng]

@Joulinar
Jep seems so. Perhaps something can be done to prevent the system to even look for this module, but cosmetic only, no harm then and expected.

About the splash/plymouth thing, yeah seem to be two different things, the RPi logo and what disable_splash triggers. However no harm then as well.

I will mark this topic as closed, since the update issues are resolved. If anyone still faces issues, feel free to post them here again, so we will re-investigate.