After manually deleting the "bad" 6.304, I manually kicked off another up2date... this one worked.. and it was GPG signed at 8:50EST.. so they "re-rolled" it... bad thing is I have about 7 customer ASGs to update, who wants to bet they all prefetched a "bad" 6.304 package? Argh! (I be a pirate now)
After manually deleting the "bad" 6.304, I manually kicked off another up2date... this one worked.. and it was GPG signed at 8:50EST.. so they "re-rolled" it... bad thing is I have about 7 customer ASGs to update, who wants to bet they all prefetched a "bad" 6.304 package? Argh! (I be a pirate now)
Bruce, if you monitor all your systems with ACC you can start a up2date prefetch from there on all systems with a couple clicks, ASL/ASG will detect that the md5sum changed and redownload the update.
If not, just log into each one and prefetch the update again.
No need to delete the "bad" update.
If you want long enough, ASL/ASG will do this on its own.
It should do this on it's own. If the downloader notices that the file that is offered by the server has a different checksum than the one that you have locally, it assumes that the file is broken, and will remove it automatically before downloading the new one.
I understand what you're saying... but since Astaro was changing the images that morning (from my understanding... too bad they aren't testing those when they deploy them to the various up2date servers... we've had this problem before), my box was probably randomly hitting a server that had not had it's package updated... so Astaro support told me what to do to force it, and it did involve manually deleting the bad package.
