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. 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. 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
