I have tried several time to update to latest version 7.300 from 7.202 .After 100 % it shows Up2date package Initialization Failed.
ASG Installed on VMware Server.
I had issues manually uploading and applying 7.300 to my 220 v1. Each time I would try to upload, it would not only time-out the process, but would cause instability and services would crash.
The problem for me was due to CPU and memory limitations with the 220 (512MB RAM max).
What finally work for me was:
1) Rebooted the Astaro to clear out any junk left from previous failed attempts.
2) Disabled IPS and the various proxy services (HTTP, SMTP, POP3, FTP, etc). I did this to free up as much memory and CPU as possible.
3) Uploaded up2date package to the 220. This can take 20-30 minutes. Once the file populated in the "up2date file" box, hit apply.
4) When CPU calmed down a little bit, installed 7.300.
5) When the update had completed and the 220 rebooted, Enabled the services I had disabled in step 2.
__________________ ACE v8/SCA v9.3
...still have a v5 install disk in a box somewhere.
I had issues manually uploading and applying 7.300 to my 220 v1. Each time I would try to upload, it would not only time-out the process, but would cause instability and services would crash.
The problem for me was due to CPU and memory limitations with the 220 (512MB RAM max).
What finally work for me was:
1) Rebooted the Astaro to clear out any junk left from previous failed attempts.
2) Disabled IPS and the various proxy services (HTTP, SMTP, POP3, FTP, etc). I did this to free up as much memory and CPU as possible.
3) Uploaded up2date package to the 220. This can take 20-30 minutes. Once the file populated in the "up2date file" box, hit apply.
4) When CPU calmed down a little bit, installed 7.300.
5) When the update had completed and the 220 rebooted, Enabled the services I had disabled in step 2.
__________________ ACE v8/SCA v9.3
...still have a v5 install disk in a box somewhere.
No luck after disabling all the services like http proxy etc. I'm running ASG on VMware. Memory utilization is less then 15% of 1GB, but CPU shoots 99%.
ASG has already downloaded package.
Every it fails with the same message as in my post earlier.
Any workaround, it seems to be issue with ASG running on VMware fro 7.300 Update.
I have updated a handful of VM systems to 7.300, I did have to increase the RAM on some of the demo units on my laptops so they could process the update, but 1gb should be enough.
You may need to remove the update package and import a fresh copy, there could be a problem with the download.
I am having the same problem also, on an ASG 120 with 512MB. It is failing during the rpm test function. Could this be because of low RAM? Or could it be a bad package download? If so, how do I remove the package so it will download it again?
There's lots of stuff here in the UBB if you search for "An error occured during the RPM pre-installation test", and the "auisys.plx --rpmargs --force" is the thing that will get you running again. Take not that this will install ALL locally available up2date packages in one go.
i had the same problem when updating a 220 from 7.104 to 7.30. it installed up to 7.202 and a half of 7.3!! the mail proxy had already been updated but it showed still 7.202. http proxy was broken and packetfilter was doing werid stuff... for example no dns queries anymore..
auisys.plx --rpmargs --force
fixed it it seems...
i used that command already a lot of times since i work with astaro.. whats the deal guys? why is patching that complicated?? :-/
There is a certain complexity to handling errors inside the up2date installation. The old behavior was to just not raise the system version in case an error occurred, because usually a) the goal is that no error should occur, so this would ensure that we could check it out whenever something failed and b) it's hard to automatically figure out what exactly caused the error and react accordingly. The problem in this special case is that the check which you are actually overriding with "--rpmargs --force" effectively prohibits the user to try installation again (once the package installation failed, every following installation will fail, too). We certainly underestimated the amount of cases where the first installation try would fail; very prominent amongst them are script timeouts because of high load environments, seemingly random failure of init scripts to bring services up/down, or the manual installation of RPMs causing problems.
Now, of course, we did address that problem, but as stated above it is the complexity of automatically handling errors when a plethora of error cases is possible, and the danger that failure to correctly handle it can render systems unusable, which keeps us from releasing it. The code change which is planned for this issue will make a re-installation of the package possible in cases where RPMs of the same package have already been installed (either in the last run, or a support package, or whatever reason). It will also reduce the cases where the system version is not increased due to an error during installation, but that comes with a price. Certain errors during the installation phase will now require a system reboot to ensure a sane environment. Because this can also happen for up2date packages which regularly would not require a reboot, we are reluctant to release it. Of course we could do it like a certain OS and just state in every up2date that it "may require a system restart" ... but I am pretty sure you wouldn't like that. So we're taking our time searching for improvements and working on the surroundings of the up2date process to reduce the probability of cases where a reboot would be required.
So, in my opinion, you're currently being faced with the lesser of two evils. We are aware of the situation, and are working on a solution, but as the up2date is one of the most vital parts of our system we want a stable solution which improves the situation for everyone, in every case.
