Sarah Jelinek wrote: > Frank Ludolph 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. >>> >>> 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. > > Why wouldn't we want to include both text based and AI on the same > media? And allow the user to choose? VMC is using a bootable AI media > to do its installation in to the VM, but a user could easily want to > do this on a local system as well. As an example, bug 415 would be a situation where having both GUI and text install on the same media would be desirable. User tries to use GUI, but hardware or drivers don't support booting to liveCD (which the user doesn't discover until trying). Instead of downloading an entire new media, just reboot into the text installer. http://defect.opensolaris.org/bz/show_bug.cgi?id=415
Is this scenario worth worrying about? Or, would the better solution be to, on failure to boot into GUI, fall back into a text installer (instead of giving an explicit option)? > > sarah > ***** >> >> 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 >> >
