After an upgrade with reboot, the reboot failed. On the console I can see "waiting for process to finish: and a PID, but I can't access the console to check which process it is. If I enter the credentials, I receive "Invalid password" (or something similar). SSH also don't connect. Web GUI reboot does not work.
The Web GUI Dashboard after the upgrade is displaying the exact version of the upgraded system, but if you try to enter "System->Firmware" you got the screen with the small window "Waiting the reboot..." you usually get at the end of first phase of upgrade.
It seems that the main functionality of the firewall is maintained.
The only solution I found to bypass this situation was to kill the machine on power-on button. After the reboot all is working again: console, SSH, Web GUI...
On the first upgrade (from 24.7 to 25.1) it happened for the first time on both firewalls (backup and primary), later only on primary.
How to find the userid/password of the system during the upgrade process, to check what is behind the PID the shutdown is waiting for forever?
Regards, Walter
You need an administrator user to login to the console. Admin rights allow it to see other user processes.
#ps -aux to list all processes and their owners ?
Quote from: cookiemonster on April 30, 2025, 11:38:17 AMYou need an administrator user to login to the console. Admin rights allow it to see other user processes.
#ps -aux to list all processes and their owners ?
This is basic knowledge, a learned it decades ago on Unix (and Unix-like): HP-UX, Linux (Yggdrasil was the first distribution), Solaris... :-)
The problem is elsewhere: I have the root user credentials, but in this phase, between the non finished upgrade and a forced reboot, they are simple rejected on the console or SSH, at the end I got " Permission denied, please try again." message
So:
1. What is blocking the root logon during the upgrade?
2. Which process (and why) is stopping the shutdown process?
Next time I will try to do the upgrade (one which needs reboot) with the console logged on (on SSH and on VGA) to gather more data using the method you (also) suggested, if possible.
Until now, the problem was not destructive, but was very uncomfortable: You have to power-off and power-on the working system, which is the ICT approach to the world I like less.
.I am a bit baffled too then.
SSHd giving "Permission denied, please try again." suggests that is listening. Maybe disabled in "system | settings | administration" but could be an artifact of the unfinished upgrade but I'd find it strange. Non-listening would be more what I'd expect.
A login at the console (not ssh), now that is very strange. I've never experienced, even with a password-protected console?
All interesting none the less but I imagine the answer to 2. is perhaps one of the usual that has been documented here pretty extensively. Zenarmor has been until recently the main culprit. But it can also be a third-party repo.
Definitively a console open at upgrade time is what I'd go for.
On the next upgrade which needs reboot, I will be personally present, and try to collect (and write) as much as possible about the problem, working on the console. I could try to see if the SSH or web gui reboot have the same effect, never used last months :-).
I usually use Remmina for the SSH, so thinking now about your comment on the last incident, I cannot tell if SSH rejected my password, or the connection itself was dropped (not listening), I just did not get the session.
Next time I will try to manually ssh from my Linux terminal.
But on the VGA console I found this situation more than once, I am very confident in my claims. I usually never touch it, so it goes auto logoff. After a failed reboot on upgrade, pressing the console key you receive the login prompt, non successful until power-off/power-on.