Since we will be creating different images soon for the new installers, I believe it is important to fix the following bug:
5209 Enhancements to the mkrepo script http://defect.opensolaris.org/bz/show_bug.cgi?id=5209 The bug contains prior discussions on possible solutions. A problem we discovered recently (bug 6616) makes the previously discussed solution not as appropriate, so, I want to discuss how we should proceed with this. To summarize the current proposal on fixing this bug: 1) Replace the functionality of the mkrepo script by running the manifest-import service's start method using chroot to the bootroot's /. 2) The DC will further customize by applying a few user specified profiles that will disable certain services. 3) The configuration values that are currently hard coded into the "mkrepo" script will eventually be placed into a SMF profile, when Enhanced SMF profile is supported. For the time being, just leave them hard coded into a user provided finalizer script for configuring the bootroot. Item 2 and 3 sounds fine. I want to discuss item 1. The manifest-import script does many things, including handling removing services, taking snapshot of critical services, handling upgrades, importing manifests, applying profiles and finally, refreshing after all the changes. One functionality we use from the manifest-import script is pre-importing of all the services. The other functionality that we use is applying the generic profile and the platform profile. However, because of bug 6616, creating the link and applying the platform profile is certainly wrong here. So, that means the only thing we use the manifest-import script for is the finding and importing of manifests. All other functionality in the script is irrelevant for creating an image. As such, I don't think the DC should run the complete manifest-import script as is. Since we don't want to duplicate the code in manifest-import, I suggest that we file a RFE to request the manifest import functionality in manifest-import script be moved into a function. That way, DC can just call the function in the script without having to run the whole script. As for functionality of applying the generic profile and creating the link for platform specific profile, DC can apply the generic profile as well as any user specified profile. The creation of the platform specific profile link and applying the profile will have to be done at first boot. We can define a one-time SMF service to do it or move the code to live-fs-root or it's replacement. Your thoughts? --Karen
