Sundar Yamunachari wrote: > Moinak Ghosh wrote: >> The Transfer Module Func. Spec. can be downloaded from >> here: >> >> http://www.opensolaris.org/os/project/livemedia/files/transfermod.pdf >> >> It is currently in the Livemedia files section as I do not have >> access to the Caiman files section. The document should soon >> get moved to the Caiman files page. >> >> Regards, >> Moinak. >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> > Moinak, > > - Section 1 last bullet: > "For the Slim Install initial delivery only a fresh install scenario > is being considered at this time. Upgrade is left as a subsequent > activity. However based on the approach of a LiveCD based installer, > upgrades are typically handled via the packaging system and not > directly via the LiveCD. So for the purposes of the Transfer Module > upgrades are out of scope." > > If slim is planning to use cpio to transfer the contents and not > pkgadd, how will the upgrade work using the packaging system? The > current upgrade works because the information is stored in pkg > database and other places under /var/sadm. The upgrade algorithm uses > these information to decide what needs to be upgraded. > > - Section 2 first point: > "Copy the LiveCD contents to disk. This is essentially a straight cpio > of the LiveCD contents from > it's mounted location. The files of course get decompressed as they > are read." > > I assume the cpio archive is created from the contents of the > package. What happends to packaging scripts? pre and post install > scripts and class action scripts? is the pkg database part of the cpio > archive?
As mentioned elsewhere, the LiveCD represents an installed system with fully populated package metadata. All of this is copied over the harddisk. The Transfer Module does not need to worry about which packaging system is being used (well almost, except for locale stuff). Whatever be the system it will copy all packaging metadata as well. > > - Section 2 second point: > "Copy some basic settings from the LiveCD environment to disk. These > include Keyboard selection, Locale selection (on a multi-locale > CD/DVD), Xorg config file if any, the etc/path_to_inst file, the SMF > seed repository, the etc/devices/devid_cache." > > How does the locale stuff works with transfer module? In the > current install, the locale packages corresponding to the list of > packages to be installed will be selected and installed. Locale setup is out of scope for October. However this is one place which needs to be worked out going forward. This is the only place where packages will have to be fetched. They can be fetched from a network repository. But if the LiveCD environment does not have network connectivity during install this action must be postponed for later. Additionally the user can be provided the option of indicating an alternate source of packages, like another CD/DVD or a USB pendrive etc. > > - Section 2 additional tasks: The following may be needed. > > . Do you have any logfiles (or any other files needed for > debugging) created as part of transfer module to be moved to the disk? Yes. > . Creating menu.lst file This is part of the postinstall service invoked by the Orchestrator. > > Section 5 Interfaces: > > - The api TM_abort_operation() could be changed to TM_abort_transfer() > or TM_cancel_transfer() to clearly indicate that the transfer is > aborted/canceled. Okay. > - How do you set the debug? Currently I have considered an environment variable. Would an API interface be more logical ? > - Can you expand on the nvlist parameters with the NAME and TYPE of > each parameter? Okay, I will update the document. > - Is there any error code returned by TM_perform_transfer() in the > case of error? Yes. It will return either a success of failure. The log file will contain an error message in the event of a failure. Are you thinking of multiple error codes ? > - Are you planning to use the same callback structures defined in > orchestrator? Otherwise how can I get the callback information? Yes, same ones. Regards, Moinak. > > Thanks, > Sundar > > > > > >
