DietPi-Login | Gracefully handle multiple instances of password dialog

[vellanix]

I run the dietpi-update (9.13) and when I was asked to change the default password for root and dietpi users I pressed ESC (suppose to leave the old password).

The update process get finished but when I try to SSH I always get the warning:

WARNING: Concurrent execution of DietPi-Set_software detected

with the following screen:

I tried to kill the process, reboot, shutdown and more but I always get the warning when I ssh with root user.

Any hep?

thank you

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version
  G_DIETPI_VERSION_CORE=9
  G_DIETPI_VERSION_SUB=14
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  bookworm 0

• Kernel version | uname -a
Linux blade00 6.12.25+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  RPi (CM5) (aarch64)

• Power supply used | Original

• SD card used | eMMC

Steps to reproduce

run dietpi-update (9.13) and when ask for password change (user root and dietpi) press ESC

[MichaIng]

First of all, do not press ESC but ENTER/RETURN to confirm whiptail dialogues in general. ESC aborts them, respectively has the same effect as hitting the right button (if there is a right one).

You do have some autostart option enabled so that autologin happens on the local console/tty1? I.e. check dietpi-autostart and set it to "0" for now (confirm with ENTER/RETURN (or Ok button) 😉).

Since you aborted the password change earlier, the autologin on local console shows the same dialogue. But you probably do not have a screen/keyboard attached?

Hmm, I wonder how to enhance this. We want the default password to be changed in any case. But even if no screen and keyboard is attached, it is theoretically possible to enable autologin on the local console, and there it is treated as interactive login shell, no real way to know whether it is even accessible or not 🤔. I guess it is a rare case that the password was not changed in the first place, and that an autologin option was selected without any actual screen attached to the device (?), but looks like we should find a way to detect this, and prevent the whiptail dialogue. Or it needs to be able to kill and "take over" the concurrent process.

If for whatever reason the dialogue shows up on tty1 despite autologin disabled (needs to be investigated separately in case), kill the dietpi-login instance on tty1. Those whiptail dialogues themselves cannot be killed properly, which is very nasty indeed, but their parent shells need to be killed instead. Then hit "Retry" on the SSH dialogue, or if aborted, run exec bash or open a new SSH session to trigger a new dialogue.

[vellanix]

First of all: lesson learned!

Don't press that ESC button!

II had the autologin function active on the console; once disabled, the request to change the password returned and everything went smoothly.

Thank you for your help...
I promise not to press ESC again 😉

[MichaIng]

I promise not to press ESC again 😉

😄 not forbidden, just important to know that it is the no/cancel/abort/exit key, while for input boxes, menus etc, require a confirmation action to select/apply something, which is done by the ENTER/RETURN key, optionally switching to the bottom (left) button beforehand.

Okay, so my assumption was correct, and I guess it is a rare situation for users to run into. But indeed it is annoying if it happens, especially since whiptail dialogs are to hard to kill. I will think about a way so that any next prompt of this dialog, like from SSH, automatically kills any previous instance, or that it is offered to take over the other instance, the way it is done if automated first run setup fails, and you then login via SSH.