we have found out that in some cases the authentication daemon gets not restarted properly. So far this seems to only happen on slower machines.
Can you give us information what kind of hardware has been used (CPU, RAM, RAM/SWAP usage) in the system where the login was no longer possible after the reboot?
as an alternative to rebooting you can also log into the box via SSH and do /etc/init.d/aua start
This will start the authentication daemon and the login is than possible again.
I think we found the issue: for slower boxes the default timeout for stopping the authentication daemon was not sufficient and in combination with a race condition while (re-)starting it may result in the scenario you described. All mentioned workarounds are valid (reboot or restart the daemon), nevertheless we changed the initscript within the package for users who did not install it yet. In case you already installed it, don't worry - everything should continue working normally. We'll readd this little change also in the next package to make sure everyone is running the same version of the scripts.
Marcel, I haven't installed the update yet, but it looks like my firewall has already downloaded it. Can I delete it and re-download? I'm running on a PIII with 512MB so I'm betting that may be a "slower box". [:P]
Marcel, I haven't installed the update yet, but it looks like my firewall has already downloaded it. Can I delete it and re-download?
I'm running on a PIII with 512MB so I'm betting that may be a "slower box". [:P]
Thanks,
Barry
Barry,
I'm also using a PIII-600 with 630 MB of RAM, and it went smooth?
we have seen ASG220 work and some other ASG220 not. I assume this depends how the RAM/SWAP usage is.
If the box uses SWAP, than it is very likley to swap-out the authentication daemon process, as it is most of the time only needed to authenticate the admin loggin in.
Now if this process should be stopped, the process need to be swapped in, (means copied back from disk to ram) and this can take a while.
If your box is using SWAP and your RAM consumption is relativly high, than it likely to have this issue.
For example my ASG120 (512MB RAM) worked perfectly, but this system didn't use any swap.
I hope that makes a bir more understandable and predictable.
Marcel, I haven't installed the update yet, but it looks like my firewall has already downloaded it. Can I delete it and re-download?
You shouldn't need to do anything to achieve this. The next time your machine connects to the up2date servers, it will notice that the md5sum of the up2date package has changed and fetch the new package.
This did not fix my problem. After the reboot the machine had an error "Trying zeroconf on eth3". Machine was locked, couldn't even use front panel buttons. Waited ten minutes then rebooted. Machine was no longer connectable, was pingable on the original IP address (0.1 when my network is 1.1). Did a factory reset, installed last backup file. Backup rebooted and box was not connectable. Factory reset again, currently trying to reconfigure from scratch, but DNAT to an "Additional Address" on an interface is not possible. What now?
