Urs Rau schrieb: > Michael, > > Michael Chinn wrote: >> One solution I used when rolling out a 40mb module was use a 2 stage >> loader/installer with wpkg. Our reason was to cater for field operators >> who only connect for short periods then go away for weeks at a time. >> eg:- >> Package Loader - Copies the installer to the machine using something >> like Robocopy, stores it in %windir%\temp, tests for file on succeed >> Package Installer - Depends on Loader, runs installer from %temp%, tests >> for program installation, if space is an issue deletes zip file from >> temp and creates a 0 length package.zip so that loader doesnt repeat >> >> One of the benefits of robocopy is you can control the download rate and >> retry on fail. >> > > Thanks so much for this. This 'work-around' will make it work, even if > we choose to install even bigger pkgs like MS Office etc. Your > suggestion is much appreciated. How about trying to find out what causes the load? How much memory is used/free/used for buffers? I once had a series of Fujitsu-Siemens servers which apparently didn't like increased disk reads/network transfers - something screwed with the interrupts, and the server was practically unresponsive. Disabling ACPI was a workaround, and upgrading to a newer kernel fixed the issue. Although, it may be hard to reproduce the load in production environment? :) -- Tomasz Chmielewski http://wpkg.org wpkg-users mailing list wpkg-users at lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users |