Karen Tung wrote: > Alok Aggarwal wrote: >> Hi Sarah, Keith, >> >> On Mon, 6 Jul 2009, Sarah Jelinek wrote: >> >>> 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. >>> >>> That's true. I am assuming a few things: >>> >>> 1. We provide enough on the bootable text image to install from the >>> image. Starting with the AI packages is a starting point, then we >>> need to look at what other packages we need to provide. The target >>> audience for the text based installer on sparc is sparc servers, >>> which is different than the x86 audience(I would think), so we also >>> need to think about that. >>> >>> 2. We do plan in a follow on phase to enable IPS installs from the >>> text based installer. This would enable a more minimal media, we >>> could produce the same media for AI and text based in this case. >> >> That is a good point. With a purely media based text >> install, the list of packages would be closer to the >> LiveCD than to AI. > Actually, no. If we just want to be able to run the > media base text installer, the list of required packages > should be closer to AI. As I discussed in the other > email, LiveCD has a lot of stuff that we include for > people to try, which is not needed for running the > installer. >> >> When the support for IPS installs arrives in the text >> installer, the list of packages would be closer to AI. >> >> So, given that I think we can't really have a singular >> image that is able to do - network booted AI, media booted AI, >> media based text install and IPS based text install. > Well, we certainly can have 1 single image for everything. > There's no technical difficulty there. > The more important question is whether we want to or does it > make sense too. > > I think we should talk about our target user, and how they > will be using these images to do their work/solve their problem, > and then, decide on how many image and what kind of installer(s) > should be included in each image.
I agree that we need to understand our target users. I believe that Frank has indicated that the text installer for SPARC is targeted toward server installs. x86 is a different thing. I can see that users might want to have both the text installer and the GUI on the same image for x86. There is no reason we cannot have one image that contains the GUI and text installer. What's on the image doesn't have to dictate what we install, in particular since we are adding installing from IPS as a choice. Let's talk about this more today in the meeting. sarah **** > > --Karen >> >> Is it then fair to say that we'll want one image for >> network booted AI, media based AI and IPS based text install? >> And, a separate one for LiveCD and media booted text install? >> >>>> 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). >>> >>> Yes, I see it this way as well. We have a bootable media so even if >>> initially we installed from that media, we would get a bootable >>> system(minimum). >>> >>> >>> thanks, >>> sarah >>> ***** >>> >>>>> >>>>> >>>>>> >>>>>> 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 >> >> Yes, that's what I was proposing initially. >> >>>>> 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. >> >> The one issue I'll note with providing choices as part >> of the grub menu is that how would you script it? I'm >> thinking in terms of the VMC project using a media booted >> AI image and wanting to script it such that booting from >> media is performed versus booting from the network. >> >> Alok >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
