Keith Mitchell wrote: > Hi, > > Sarah Jelinek wrote: >> Hi Alok, >> >>> Currently the Caiman architecture supports two types >>> of installers - a LiveCD based GUI and AI. Each of these >>> installation environments are different in that >>> one is a desktop based environment while the other is >>> not. As a result, they are both built on a different >>> set of packages with AI being built on a significantly >>> smaller set. >>> >>> As we provide more installation environments in the future >>> (text based interactive install, a media based AI and possibly a >>> network based text install), I think there are a couple of high >>> order issues that need to be sorted out. >>> >>> a) What kind of an image should these new installers >>> (text, media based AI) be based on? Since both these >>> installers are not going to offer a desktop installation >>> environment, does it make sense to base them on the >>> same set of packages as AI? I think it would be a >>> reasonable starting point. >> >> Certainly, starting with the AI packages, and adding what is >> necessary to support a text based installer would make sense as a >> starting point. As for the AI media based installer, I would think >> that it would be almost the same in terms of image contents as the >> current AI image. The text based installer might require a few more >> packages to support the ncurses interface. It looks like Jan's >> initial research shows we can take the AI base image and make it >> bootable from media. > I was under the impression that the reason AI has such a smaller > package set is because it runs the installation from an IPS repo. In > that sense, using it as the base for the text installation makes > little sense - all the desired packages should be included on the > media. If the packages included on the current liveCD don't cover the > set of packages needed by the text installer, then more should be > added - and of course, the text installer doesn't have to install > every package included on the liveCD either. > > I see two separate issues here - the set of packages needed to boot > and run a desired installation type, and the set of packages a user of > a specific installer will want on their system as the (minimum) > default - customizable via current methods (IPS after installation) > and future enhancements (the package "groups" we've been talking about > lately). >> >> >>> >>> b) Assuming some of these installers get delivered as >>> part of the same AI image, how should the selection >>> between which installer to use be made? The two obvious >>> choices are to provide them via the GRUB menu or as a >>> separate menu item that comes up as part of boot (kind of >>> like the keyboard and language selection menu in the >>> current LiveCD installer). I think one of the underlying >>> requirement here is to allow this to be scriptable. Also, >>> a consistent user experience on both sparc and x86 would >>> be nice. A separate menu items seems better on both counts. >>> >> With a media based install, interactive user input is certainly >> reasonable. A separate menu seems appropriate as well. How would you >> propose a consistent user experience on sparc and x86? I assume you >> are proposing to not use GRUB on x86, and use a separate menu item as >> part of boot up for both platforms? Or something like that? My >> personal opinion on this is that GRUB is the expected user interface >> for choosing the thing to boot from. I wouldn't think we would want >> to change that. For SPARC, we can add a selection menu, and of course >> allow for command line options that would indicate which one to boot. > I agree that GRUB would be the desired option for x86. If anything, > the boot/installer selection should mimic an installed system for the > given architecture - not necessarily be identical between both > architectures, in this case.l I would expect that the user experience for the media-based text installer would be to boot directly into the installer or to a simple text-based program that lists the functions provided on the disk e.g. gparted and install. No reason to include GRUB as I don't see a need for boot options. I don't expect that we would include both the text-based and GUI installers on the same media.
Frank >> >>> c) AI and the LiveCD currently share the implementation >>> for the live-fs-root SMF method and it has been pointed >>> out that that's not very maintainable. The addition >>> of more installers to the mix, I think just exacerbates >>> the problems. It seems appropriate to restructure >>> live-fs-root as part of the media based AI and text install >>> work. Or, can be done as part of a bug fix? For example - >>> >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=9549 >>> >>> What do people think about some of these issues? >> I agree we should restructure live-fs-root as part of the work for >> the media based AI and text installers. It needs to be done, and for >> the future for a text based network installer as well. And for >> replication and recovery... > Agreed. > > - Keith >> >> thanks, >> sarah >> **** >>> >>> Thanks, >>> Alok >>> _______________________________________________ >>> c
