Hi James, I think by far the best thing is to forward these to the pkg-discuss mailing list (they're cc'd). Fairly certain that some of the problems you've seen are very easily fixed, but I don't know what questions to ask, sorry.
cheers, James On Thu, 25 Jun 2009 10:50:25 -0700 "James C. Liu" <[email protected]> wrote: > Wow! Thanks James Mc. > > Here's a list of problems with IPS installer (GUI). > > Conditions: > - two x86 systems, one a small shuttle xpc, the other a toshiba > laptop, both with 1.X GHz Celerons > - 2 GB memory both systems > - both have SATA drives > > Nevada Installation - Full minus OEM stuff but w/ most I18/L10N puts > about 12 GB of unpacked packages on each system in about 45 minutes. > Not bad. > > Under OpenSolaris 2009.06 FCS, initial install of the CD/USB image > takes about 18 minutes USB stick and 25 minutes CD. > > But subsequently, to get development and application environments > takes about 6+ hrs. Why? > > 1. A number of packages in the IPS repository are not x86 > architecture. The GUI stops and prints detailed errors. > About 2 dozen of these interspersed in all the packages > make it impossible to select ALL categories and ALL packages > and install ALL. So I need to manually go through and > de-select those that don't pass muster. Can't tool just bypass > skip and recompute dependencies? > > 2. Mid-way through updates/installs of new stuff, I can > no longer install -SOME- of the selected packages. There is > no warning. Instead, I need to read the details carefully > and realize that only 10% of the selected packages I want > updated are actually going to download and install. After > a certain point, the GUI tells me I can't even update/install, > but need to UPDATE ALL. It takes quite some tries to get to > this fully saturated install state. The first time this > happens is about 900MBs after new installs occurs. I am then > forced to generate OpenSolaris-1 boot. > > 3. Depending on the order of installs, about 600MB or 1.2GB > into further installs, I encounter the same error as in 2. > And am forced again to UPDATE-ALL. This generates OpenSolaris-2 > boot environment. > > 4. On one of my systems, where I installed Applications first > then System category next, I actually had to repeat install for > OpenSolaris-3 boot environment. > > 5. After two updates, I find that quite a few packages I thought > I had installed were actually skipped in Apps, System, Development > categories due to skipping in step 2 that I had not noticed. So > I manually go down and select ALL to update/install then when > the GUI has errors, I need to read the details yet again and > de-select the bad packages. > > All the while, the packages are brutally slow to download and > appears to constantly stall during download phase. I'm informed > of a percentage complete, but no real information as to why > I'm stalling. And the update-phase in an "UPDATE-ALL" situation > is brutally slow as well. It could be updating stale > dependency checks, but that seems really flawed as the installation > phase should be amortizing this cost at the point of installation. > And this was done both at 4pm in the afternoon and 9pm in the > evening and sometimes at 4am in the morning. Can the internal > ipkg.sfbay server be that slow all the time? > > Total time averages about 6.5 hrs to install what used to take > about 45 minutes. I thought IPS was supposed to be faster. > I'd personally take a DVD and be done with it in the same time > if that would decrease network latency problems. > > ----------- > A couple of things I was thinking: > > 1. most folks on windows/linux expect default behaviour to > download packages for update without intervention. If we could > just bypass bad packages and automatically recompute dependencies > without the bad package, that would be ideal. The guarantee we > need to provide is when the user clicks the update/install button, > it happens, so he doesn't leave, then come back hours later only > to find that it stalled 5 minutes into the operation. > > 2. Buddy-boot/auto-share/torrent - our server is bogged down a lot > and they are changing and updating, if snoops on the latency are > any indications. I need to have an onboard repository that is > auto-configured to cache and share the packages with anyone else. > Rather than having the default to go back to opensolaris or ipkg.sfbay > to get packages, we should download meta-data manifest and share > what we've archived, and archive the packages. Currently, there > is some signing and secure-auth that requires me to read a manual > and then install my own repository to serve up packages. That's > too much burden, IMO for customers who will balk at the idea. RPMs > are indivdually signed and verifiable. I often have used up2date > or apt and archived them and re-installed on all my home systems > without issues and no documentation. It was intuitive and saved > tonnes of bandwidth and fast too. If we had some feature to share > downloads easily, that would be great. > > I know I'm missing something... but will send later if I think > of it. > > -James > +------------------------------------------------+ > | James C. Liu, Ph.D. | > | Solaris x86 IHV OEM Engineering | > | Sun Microsystems, Inc. | > | 17 Network Circle, UMPK-17-207 | > | Menlo Park, CA 94025, USA | > | +1-650-786-5179 Direct, +1-650-786-5747 FAX | > +------------------------------------------------+ > > > > Susan Scheufele wrote: > > Hi James L., > > > > James McP. would like to hear about your "takes 10x as long" problems > > with installing the OpenSolaris packages onto your whiteboxes, and he > > offered to help! > > > > -Susan James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
