Eric Schrock wrote:
> I'm fixing a SMF bug (6608098) that has ramifications for the read-only
> miniroot environment.  Are there any pointers or documents about how to
> build a custom miniroot and test the installer?
>
>   
I don't know of a canned procedure for the install testing,
but I can tell you how to build the miniroot.  It's slow
and takes a lot of disk space, but it's not hard. This is
how I do it, though maybe someone in the install group
has a recommendation for a less heavy-weight procedure.

1.  Get the cdkit tools from

/net/paradise.sfbay/export/tools/cdkit/Nevada

2.  Within that directory, see the file cdkit_manual.txt
for instructions.  For me it comes down to:

3. use the "cdkit BringoverBuildState <args>" command
to bring over the packages from a recent build of Nevada
(this is all the packages, not just ON) into a local 'staging'
directory.

4. create the build identifier, as described in cdkit_manual.txt.

5. within the staging directory you created in step 3, there
is a "pkgpool" directory.  In that directory, delete all the
ON packages and replace them with the packages from a
nightly build with the changes you want to test.

6.  use the command

cdkit BuildImage -t netinstall <staging-area> <target location of build>

to build the image. 

The miniroot will be in 
<target-location-of-build>/solaris_1.product/boot/x86.miniroot

This builds an entire netinstall image.  I don't know of a way (short
of hacking on the tools) to just build the miniroot.  But if you look
in the "logs" directory of your target build area, once you get
a "solaris_2.product" log file in there, you can kill the build because
the solaris_1.product directory will be complete, and that's all you need.
Check the return code at the end of each log file to make sure
it's 0.  If so, the miniroot should have been successfully built.

Repeat steps 5 and 6 as necessary to test and fix the ON code.

- Lori



Reply via email to