Hi Moinak, > Sarah Jelinek wrote: >> [...] >>>> >>>> ****Postinstall tasks. We wil likely need a postinstall service to >>>> handle these. >>>> pfinstall/libspmi currently do this for us automatically. >>>> 1. transferlist >>>> 2. create boot archive >>>> 3. XXX whatever else is in finish script. >>>> 4. Moving, copying the logs >>>> > > Other items: > > - Installgrub > - Set root password > - Setup additional user > - Mark Solaris partition as active > - Create failsafe archive We aren't creating a failsafe archive for Slim October. The other grub, solaris partition stuff happens in install-finish I think. I know the grub stuff does. As for the root and user passwords... we do that now in the orchestrator so no need to move it to postinstall for Oct. We can move this for the March release as it certainly belongs in postinstall. > > All these postinstall activities must occur after the Transfer module > has finished. The initial fdisk used to create the Solaris2 partition > must not mark it as active, otherwise the system can refuse to boot > if install is aborted midway. Understood.
> >> [...] >>>> -What to pass to TI: >>>> -disk name >>>> -use whole disk or not >>>> -pool name >>>> >>> - vtoc slice information >>> >> Yes, we need this. >> >> >>>> -What to pass to Transfer: >>>> -root pool name >>>> -dataset layout >>>> -locales chosen >>>> >>> - Mounted alternate root directory to write data, callback function >>> >> What do you mean by mounted alternate root to write data? Yes, we >> need to provide the call back function. >> > > The zpool must be mounted on a directory so that the > Transfer Module can copy the bits. Something like a > zpool import -R /<alt root dir> -f <poolname> > > The <alt root dir> has to be passed to the Transfer Module. Ok, I get it now. > >> [...] >>>> ****Changes for new Transfer module. Need to get api's to pass in: >>>> -Target data - including pool info, datasets >>>> -Language selection data - how are we going to handle this? >>>> download from repository? >>>> > > This is a question. A network connection may not be present > during install. In that case the Language packages can't be > downloaded. How do we handle this ? > We aren't installing locales for Slim October. So, we will just install C, which has to be on the liveCD and then if the user wants more locale support they must use the pkg() commands and get it from the respository. >>>> -Tools install, does this still happen with Slim? If not, we need >>>> to remove >>>> this from the orchestrator. >>>> > > I don't think we are having SunStudio or Netbeans on the CD. > SunStudio is not re-distributable in any case. > Ok, we need to remove this from the orchestrator then. >>>> -Need new milestones for target instantiation and transfer service >>>> -Disk partitioned, - estimated percentage of overall process time >>>> -VTOC created - estimated percentage of overall process time >>>> -zpool created - estimated percentage of overall process time >>>> -datasets created - estimated percentage of overall process time >>>> >>>> -Need new milestones for Transfer service actions >>>> -Total size of image we are transfering >>>> -Regular updates, percent of total installed >>>> > > Yes. > >>>> -Orchestrator will call TI and Transfer service. GUI will call >>>> om_perform_install. GUI will have to be modified to understand the >>>> new/additional milestones. >>>> >>>> TI notes: >>>> -Will TI create swap partition? So, size of partition will need to be >>>> passed in? >>>> >>>> Transfer service notes: >>>> -Progress/milestones for putting the data on disk. What will the >>>> format be for moving the data? >>>> If cpio we could: >>>> -Get the total number of files to be copied >>>> -Use -V to have cpio output a '.' for >>>> each file written. We could read the '.' and >>>> update with a milestone for so many dots. >>>> > > Yes. > >>>> -General questions: >>>> -Gate/repository available? >>>> -Build environment? >>>> -How to create livecd images? >>>> >>> - How will Orchestrator handle failure with TI and Transfer module? >>> >> I would assume we would handle the failures similar to how we handle >> them today with Dwarf. We have a mechanism to handle the failure via >> a callback. Is there something else you are thinking of here? >> >> >>> - Will there be a common install_log for TI, Orchestrator, and >>> Transfer Modules? >>> - Is transfer module a binary or a library function? >>> >>> > > It will be a library function. A callback function will be > required to provide progress updates. > Ok, good. Regards, sarah
