On 06/07/07, Dave Miner <[EMAIL PROTECTED]> wrote: > Shawn Walker wrote: > > On 06/07/07, Dave Miner <[EMAIL PROTECTED]> wrote: > >> Ian Murdock wrote: > >> > Alberto Ruiz wrote: > >> >> 2007/7/5, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <[EMAIL > >> >> PROTECTED] > >> >> <mailto:[EMAIL PROTECTED]>>: > >> >> SMF is not overkill for indiana. > >> >> > >> >> it might be overkill to instantiate quite the number of SMF > >> services > >> >> that > >> >> a full-blown solaris installation does at first-boot, but SMF > >> itself is > >> >> incredibly useful. ;) > >> >> > >> >> I think that a lot of people find SMF frustrating because they think > >> >> it's slow due to the prohibitive number of services that Solaris and > >> >> Solaris Express boot by default. Maybe we should try to keep as > >> less as > >> >> possible services for Indiana? Does that makes sense? > >> > > >> > Is this something we should add to the list, i.e., investigate > >> > the services started at boot time to determine which aren't > >> > necessary and can be removed? I haven't noticed a problem > >> > with speed here aside from the first boot (which does take an > >> > inordinately long time--what on earth is it doing exactly?). > >> > > >> > >> It's importing all of the xml service manifests from /var/svc/manifest > >> into the SMF repository. The SMF team is working on performance > >> improvements there, so you might follow up with them on the plans there > >> and see if the community here can help accelerate it. I'd approach it > >> that way, as limiting services usually means limiting functionality. > >> The Secure-by-Default project took care of the low-hanging fruit here > >> already, IMHO. > >> > >> Moinak and I have pretty well whittled down the live CD case already, > >> which is the one place where it actually matters a lot how much you > >> start at boot. > > > > Would it be possible for "standard" installations (i.e. non-custom) > > that use a pre-defined installation profile to get a pre-built > > manifest index installed instead of having to build one? > > > > I can understand why we would have to dynamically build one for custom > > installs, but "standard ones" I would think we could build the index > > ahead of time. > > > > > You can (and we do exactly that in Live Media), but then you can run > into flag day problems, where you need to build that repository with the > same version of the OS, and it really clashes with all the stated > desires here to have lots of flexibility in choosing functionality. CR > 6351623 is the main one which covers manifest import speed. I suspect > getting the fix Liane has suggested there implemented would cover this > well enough for a while.
If the pre-built index were done for the "standard" installation profiles, you wouldn't have to worry about the customisation angle. I'm going to bet a lot of people go with the "full install" option for Indiana. I know I usually do for Solaris, RedHat, Ubuntu, etc. I think many users will pick a basic default, and then customise later. Obviously there are problems to fix with the SMF index building, and they should be, but I can't think of a good reason to have the first boot wait for an index build that we don't need to do. Ideally whatever builds the install image could build the indexes for each installation profile somehow. I know it probably isn't simple, but I certainly not insurmountable... -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ "Beware of bugs in the above code; I have only proved it correct, not tried it. " --Donald Knuth _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
