Wiki code for Build/Install OpenSolaris (Part 2)

Hide Line numbers
1: == Building and Installing OpenSolaris (Part 2) ==
2: 
3: **Author: Rich Teer**
4: **Introduction**
5:  This is the second of two articles in which we describe how to build and install OpenSolaris. The [[first article>>Community Group tools.building_opensolaris]] provides all the necessary background information (terminology, where to get the tools, and so on) and describes a basic compilation and installation. There are circumstances under which the steps we performed in the first article will be insufficient for our needs; this article describes what we must do to address this shortcoming.
6:  This article assumes that readers are familiar with the contents of the first article~-~-or at the very least know how to acquire the OpenSolaris source code, build it, and Install it. For the sake of consistency, this article will deal with the same version of code the first one did, even though newer versions have been made available between the two publication dates.
7:  Note that while these articles were accurate at the time they were written, OpenSolaris is continually evolving. For the most recent details, please consult [[the ON Developers Reference>>Community Group on.devref_toc]].
8: **A Brief Recap**
9:  In the first article we defined much of the terminology we encounter when dealing with OpenSolaris. We also described how to obtain the source code and other bits necessary to compile it, and finally, we described the steps necessary to perform a simple compilation and installation of OpenSolaris. These steps are:
10: 
11: 1. Obtain the source code, closed binaries, compilers and build tools from www.opensolaris.org or one of its mirrors.
12: 1. Install the ON build tools and Sun Studio compilers into /opt and add their directories to our PATH.
13: 1. Unpack the source and closed binaries tar balls.
14: 1. Copy and edit the opensolaris.sh script.
15: 1. Build the source code using the nightly script.
16: 1. Install the resulting new kernel using the Install script.
17: 1. Reboot using the new kernel.
18: 
19:  These steps are fine if all we want to do is build and test a new kernel, but there are times when they are insufficient: we either want to install some new userland components, or our newly built kernel is incompatible with the userland libraries and applications that are currently installed. The latter scenario is referred to as a Flag Day. Another example of a Flag Day is when we need to update a library and a command that relies on that library at the same time.
20: **Flag Days**
21:  A //Flag Day// is when newer versions of one or more system packages must be installed before we can use our new version of the ON components. When they occur, Flag Day notices will be posted on the OpenSolaris web site, at www.opensolaris.org/os/community/onnv. These notices will contain instructions for building or installing the newer required software, which may not be compatible with the usual Solaris packaging tools. In particular, the use of the BFU utility, which is the focus of this article, to update components renders those components unupgradable with the standard Solaris packages. If this is cause for concern, then using the latest Solaris Express release is probably the best approach. Indeed, using BFU is recommended only for active developers of the ON code (or those who must live on the very bleeding edge).
22: **A BFU Primer**
23:  The process by which we install all the new bits of ON is referred to as //BFU//, which is an abbreviation of Blindingly Fast Upgrade (or Bonwick-Faulkner Upgrade, after the original developers, Jeff Bonwick and Roger Faulkner). BFU uses a set of cpio archives to directly overwrite the existing components of the system (which is why the usual Solaris packaging tools can no longer be used once we’ve performed a BFU); these archives are created as part of the nightly build process, which we described in the previous article.
24:  Before we can use BFU to install our newly compiled components, we must define three environment variables. These are:
25: FASTFS This would usually be /opt/onbld/bin/`uname -p`/fastfs.
26: BFULD This would usually be /opt/onbld/bin/`uname -p`/bfuld.
27: GZIPBIN This would usually be /bin/gzip.
28:  Setting these in our shell’s start-up dot file (e.g., .profile) is probably the most convenient way to set these environment variables, especially if we plan to BFU frequently. The opensolaris.sh environment file we described in the previous article also sets these variables. Using bldenv opensolaris.sh (having first copied this file from usr/src/tools/env/opensolaris.sh and editing as necessary) before we run bfu is probably best. It is a good idea to get into the habit of updating our copy of opensolaris.sh with each new source delivery, because this will enable us to pick up any new environment variables automatically.
29: **Using BFU to Install ON**
30:  Using BFU to install the ON parts of OpenSolaris is a relatively simple task: invoke the bfu command with a single argument, which is the path of the archive to install.
31:  In the previous article we used $HOME/open_solaris/build-17/testws as our workspace directory. Assuming we’re still in the same directory, we can run bfu like this:
32: 
33: {{{
34: # bfu `pwd`/archives/`uname -p`/nightly
35: 
36: }}}
37: 
38:  Note that because system files are overwritten, bfu must be run as root. Also, ensure that /opt/onbld/bin is in root’s PATH.
39:  Here’s some of the output from bfu:
40: 
41: {{{
42: # bfu `pwd`/archives/`uname -p`/nightly
43: Copying /opt/onbld/bin/bfu to /tmp/bfu.1100
44: Executing /tmp/bfu.1100 /home/rich/open_solaris/build-17/testws/archives/i386/nightly
45: 
46: Loading /home/rich/open_solaris/build-17/testws/archives/i386/nightly on /
47: 
48: Creating bfu execution environment ...
49: /tmp/bfu.1100[2261]: /net/onnv.eng/export/gate/public/bin/acr: cannot open
50: chmod: WARNING: can’t access /tmp/bfubin/acr
51: Verifying archives ...
52: Performing basic sanity checks ...
53: /etc/svc/repository.db: passed integrity check
54: Disabling kernel module unloading ... moddebug: 0 = 0x20000
55: Quiescing init ...
56: Unmounting /lib/libc.so.1 ...
57: Disabling sendmail temporarily ...
58: Disabling remote logins ...
59: Disabling syslog temporarily ...
60: Killing httpd ...
61: Disabling fmd temporarily ...
62: Killing nscd ...
63: Turning on delayed i/o ...
64: Filesystem Mode
65: / safe
66: /usr safe
67: 2423 blocks
68: 
69: Saving configuration files in /bfu.child ... 4464 blocks
70: Removing init.d links ... done.
71: Removing obsolete rc.d scripts ... done.
72: Preserving user-installed perl modules...
73: cp: cannot access /usr/perl5/site_perl/5.8.3/*
74: Removing perl 5.8.3 packages
75: Removing perl 5.8.3 from /var/sadm/install/contents
76: Removing perl 5.8.3 from /usr/perl5
77: Extracting ufs modules for boot block ... 410 blocks
78: Extracting generic.usr ... 269143 blocks
79: Extracting i86pc.usr ... 410 blocks
80: Extracting generic.lib ... 34359 blocks
81: Extracting generic.sbin ... 1420 blocks
82: Extracting generic.kernel ... 108072 blocks
83: Extracting generic.root ... 3962 blocks
84: Extracting i86pc.root ... 6790 blocks
85: Extracting i86pc.boot ... 2430 blocks
86: 
87: Removing duplicate kernel binaries ...
88: 
89: Simulating SUNWcry* installation...
90: 
91: Cleaning up old Kerberos GSS-API mechanisms...
92: 
93: [... Conflict info (see later) omitted for brevity ...]
94: 
95: Create /platform/i86pc/boot_archive
96: updating /platform/i86pc/boot_archive...this may take a minute
97: 
98: For each file in conflict, your version has been restored.
99: The new versions are under /bfu.conflicts.
100: 
101: MAKE SURE YOU RESOLVE ALL CONFLICTS BEFORE REBOOTING.
102: 
103: To install resolved changes required for reboot in the boot
104: archive, invoke ’bootadm update-archive’
105: 
106: Removing obsolete smf services ...
107: Disabling unneeded inetd.conf entries ...
108: Connecting platform and name service profiles ...
109: Marking converted services as enabled ...
110: cp: cannot access /net/greenline.eng/meta0/smf/post-5090532/sysidtool.xml
111: bfu: could not copy /net/greenline.eng/meta0/smf/post-5090532/sysidtool.xml
112: cp: cannot access /net/greenline.eng/meta0/smf/post-5090532/kdmconfig.xml
113: bfu: could not copy /net/greenline.eng/meta0/smf/post-5090532/kdmconfig.xml
114: Upgrade of orac took 2:09.
115: Turning off delayed i/o and syncing filesystems ...
116: Filesystem Mode
117: / safe
118: /usr safe
119: 
120: Entering post-bfu protected environment (shell: ksh).
121: Edit configuration files as necessary, then reboot.
122: 
123: }}}
124: 
125:  When the BFU procedure (which takes about two minutes on the author’s Acer Ferrari 3400 laptop) completes, we are left in a newly-created subshell. This is because it’s possible that the new commands and libraries will not be compatible with the old, currently running, kernel. The new subshell has its PATH set to /tmp/bfubin and LD_LIBRARY_PATH set to /tmp/bfulib. These directories contain old versions of commands and libraries that are commonly needed to resolve problems and reboot the system. (The errors about accessing /net/greenline.eng are due to bug 4865419 in bfu.sh, and can be ignored.) Note that neither init nor shutdown should be used to reboot the system after BFUing; use the reboot command instead.
126:  Notice that the bfu output talks about resolving conflicts. These can be identified in the bfu output by looking for lines similar to the following:
127: 
128: {{{
129: NEW conflict: boot/grub/menu.lst
130: NEW conflict: boot/solaris/bootenv.rc
131: NEW conflict: boot/solaris/devicedb/master
132: update: etc/.login
133: update: etc/aggregation.conf
134: NEW conflict: etc/auto_home
135: update: etc/auto_master
136: update: etc/bootrc
137: 
138: }}}
139: 
140:  These conflicts //must// be resolved before the system is rebooted if brickification is to be avoided.
141: **Resolving Conflicts**
142:  Every machine running Solaris has numerous configuration files, many of which get modified from a default installation. Examples of these configuration files include /etc/auto_home, /etc/nsswitch.conf, and /etc/path_to_inst. The bfu command keeps a list of these files, which is called the //conflicts database//.
143:  When BFU overwrites a configuration file, a copy of the current file is first saved under /bfu.child. A copy of the new file (from the cpio archive) is also placed under /bfu.parent, having moved the previous bfu’s /bfu.parent (if it exists) to /bfu.ancestor (the latter is, essentially, a grand parent). The files under these directories are referred to as the //child//, //parent//, and //ancestor// respectively.
144:  When bfu has finished extracting the cpio archives, it diffs the various versions of these files and follows these rules:
145: 
146: * If the file is unchanged (i.e., the parent and child are the same), nothing is reported as there is nothing to do.
147: * If the file was accepted from the parent during the previous run of BFU (i.e., the child is the same as the ancestor), then the parent is automatically accepted at this time and the file is marked as "update: ". This is also what happens the first time we run BFU and one of the other rules doesn’t apply.
148: * If the file is the same as the beginning of the previous file, BFU assumes that a user added lines to the end (in other words, the child consists of the parent plus concatenated lines). The child version is restored and the file is marked "restore: ".
149: * If the parent and child differ, but the parent and ancestor are the same, then the conflict is deemed to be old, and the file is marked "old: ".
150: * Finally, if the parent and child differ, and the parent and ancestor differ too, then conflict is deemed to be new and the file is marked "NEW: ".
151: 
152:  So, a conflict that is NEW refers to a file that was different from the default, and the default has been updated. To resolve this, whatever changes were introduced in the new build must be ported to the existing file.
153:  Although we could possibly accept the parent without further investigation, doing so will lose all our customizations from the child. A lot of these customizations are performed by class action scripts from non-ON packages, so blindly accepting the parent can lead to many lost hours. Conflicts should therefore be resolved, either manually or automatically. We’ll describe how to do this later, but we should say that if not all conflicts can be resolved automatically (or we decide to resolve them manually), it is a very good idea to have a proper baseline conflicts database. And this can be accomplished by installing a BFU archive corresponding to the release currently on our system.
154:  When we BFU to the same build that we have already installed by other means, we can safely ignore all conflicts because we know that our current configuration files work. A reboot must be performed prior to BFUing to a newer build.
155: **Automatic Conflict Resolution**
156:  Most, if not all, conflicts can be resolved automatically using a script called acr. This script is usually invoked in the post-BFU protected environment; when called in this manner, no command line options are necessary. (For more specialized applications acr accepts one or two command line parameters. The first specifies the name of an alternate root directory, and the second is the name of the directory containing the BFU archives.)
157: acr uses a file called conflict_resolution.gz, which is created whenever nightly is run with the -a option, and is stored in the directory containing the BFU archive. The acr script lists the files it is processing on standard out, and places detailed results in a file called allresults, which is stored in a subdirectory of /tmp. The following is an example acr invocation:
158: 
159: {{{
160: bfu# acr
161: Getting conflict resolution information from /home/rich/open_solaris/build-17/testws/archives/i386/nightly/conflict_resolution.gz: 590 blocks
162: Building command list for the class action scripts:
163: 
164: Begin processing files
165: PROCESSING etc/devlink.tab
166: PROCESSING etc/driver_classes
167: PROCESSING etc/security/device_policy
168: PROCESSING etc/path_to_inst
169: PROCESSING etc/shadow
170: PROCESSING etc/vold.conf
171: PROCESSING etc/rmmount.conf
172: PROCESSING etc/inet/hosts
173: PROCESSING etc/inet/ipnodes
174: PROCESSING var/spool/cron/crontabs/root
175: PROCESSING etc/passwd
176: PROCESSING etc/inet/inetd.conf
177: PROCESSING etc/default/init
178: PROCESSING etc/remote
179: PROCESSING etc/nsswitch.conf
180: PROCESSING etc/inet/services
181: PROCESSING etc/security/auth_attr
182: PROCESSING etc/security/exec_attr
183: PROCESSING etc/security/prof_attr
184: PROCESSING etc/user_attr
185: PROCESSING etc/vfstab
186: PROCESSING etc/auto_home
187: PROCESSING etc/datalink.conf
188: PROCESSING boot/grub/menu.lst
189: PROCESSING etc/krb5/krb5.conf
190: PROCESSING etc/openwin/server/etc/OWconfig
191: PROCESSING kernel/drv/sd.conf
192: PROCESSING boot/solaris/bootenv.rc
193: PROCESSING boot/solaris/devicedb/master
194: See /tmp/acr.Yda49i/allresults for more information.
195: 
196: }}}
197: 
198:  And this is the corresponding allresults file:
199: 
200: {{{
201: bfu# cat /tmp/acr.Yda49i/allresults
202: PROCESSING etc/devlink.tab
203: RETURN CODE : 0
204: PROCESSING etc/driver_classes
205: RETURN CODE : 0
206: PROCESSING etc/security/device_policy
207: RETURN CODE : 0
208: PROCESSING etc/path_to_inst
209: RETURN CODE : 0
210: PROCESSING etc/shadow
211: RETURN CODE : 0
212: PROCESSING etc/vold.conf
213: RETURN CODE : 0
214: PROCESSING etc/rmmount.conf
215: RETURN CODE : 0
216: PROCESSING etc/inet/hosts
217: RETURN CODE : 0
218: PROCESSING etc/inet/ipnodes
219: RETURN CODE : 0
220: PROCESSING var/spool/cron/crontabs/root
221: RETURN CODE : 0
222: PROCESSING etc/passwd
223: RETURN CODE : 0
224: PROCESSING etc/inet/inetd.conf
225: RETURN CODE : 0
226: PROCESSING etc/default/init
227: RETURN CODE : 0
228: PROCESSING etc/remote
229: RETURN CODE : 0
230: PROCESSING etc/nsswitch.conf
231: RETURN CODE : 0
232: PROCESSING etc/inet/services
233: RETURN CODE : 0
234: PROCESSING etc/security/auth_attr
235: RETURN CODE : 0
236: PROCESSING etc/security/exec_attr
237: RETURN CODE : 0
238: PROCESSING etc/security/prof_attr
239: RETURN CODE : 0
240: PROCESSING etc/user_attr
241: RETURN CODE : 0
242: PROCESSING etc/vfstab
243: RETURN CODE : 0
244: PROCESSING etc/auto_home
245: RETURN CODE : 0
246: PROCESSING etc/datalink.conf
247: RETURN CODE : 0
248: PROCESSING boot/grub/menu.lst
249: RETURN CODE : 0
250: PROCESSING etc/krb5/krb5.conf
251: RETURN CODE : 0
252: PROCESSING etc/openwin/server/etc/OWconfig
253: Converting old OWconfig file to new format.
254: RETURN CODE : 0
255: PROCESSING kernel/drv/sd.conf
256: RETURN CODE : 0
257: PROCESSING boot/solaris/bootenv.rc
258: RETURN CODE : 0
259: PROCESSING boot/solaris/devicedb/master
260: RETURN CODE : 0
261: 
262: }}}
263: 
264:  The allresults file should be examined to ensure that to errors occurred during the acr process. If any errors do occur, the conflicts must be resolved manually. An acr failure might also be indicative of a bug in one or more upgrade scripts, so a posting to the opensolaris-bugs mailing list might be a good idea.
265: **Manual Conflict Resolution**
266:  We manually resolve conflicts by diffing the ancestor and parent versions of the file in question. More generally, we run the following command
267: 
268: {{{
269: bfu# diff /bfu.ancestor/$file /bfu.parent/$file
270: 
271: }}}
272: 
273:  and apply the diffs manually (note that if this is the first time we run BFU, /bfu.ancestor will not exist, hence our earlier recommendation about creating a baseline conflicts database). For many files a shortcut can be used. Given that most changes are additions or modifications, and that the BFU process leaves us in a directory called /bfu.conflicts, simply running
274: 
275: {{{
276: bfu# pw
277: /bfu.conflicts
278: bfu# diff $file /$file
279: 
280: }}}
281: 
282:  and ensuring that all the diffs point to the right (i.e., ">" rather than "<") will do the job. Here’s an example:
283: 
284: {{{
285: bfu# diff boot/solaris/bootenv.rc /boot/solaris/bootenv.rc
286: 5d4
287: &#x3c; # CDDL HEADER START
288: 7,10c6
289: &#x3c; # The contents of this file are subject to the terms of the
290: &#x3c; # Common Development and Distribution License, Version 1.0 only
291: &#x3c; # (the "License"). You may not use this file except in compliance
292: &#x3c; # with the License.
293: ---
294: &#x3e; #pragma ident "@(#)bootenv.rc 1.34 05/04/15 SMI"
295: 12,26d7
296: &#x3c; # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
297: &#x3c; # or http://www.opensolaris.org/os/licensing.
298: &#x3c; # See the License for the specific language governing permissions
299: &#x3c; # and limitations under the License.
300: &#x3c; #
301: &#x3c; # When distributing Covered Code, include this CDDL HEADER in each
302: &#x3c; # file and include the License file at usr/src/OPENSOLARIS.LICENSE.
303: &#x3c; # If applicable, add the following below this CDDL HEADER, with the
304: &#x3c; # fields enclosed by brackets "[]" replaced with your own identifying
305: &#x3c; # information: Portions Copyright [yyyy] [name of copyright owner]
306: &#x3c; #
307: &#x3c; # CDDL HEADER END
308: &#x3c; #
309: &#x3c; #pragma ident "@(#)bootenv.rc 1.35 05/06/08 SMI"
310: &#x3c; #
311: 38a20,22
312: &#x3e; setprop prealloc-chunk-size 0x2000
313: &#x3e; setprop bootpath /pci@0,0/pci-ide@11,1/ide@0/cmdk@0,0:a
314: &#x3e; setprop console ’text’
315: 
316: }}}
317: 
318:  In this example, the important diff lines point to the right, so we’re OK.
319:  Although this process works most of the time, there are a few exceptions which we detail below. These exceptions are etc/name_to_major, etc/security/*_attr, and /etc/path_to_inst.
320:  The file etc/name_to_major maps device names to their major numbers; each device //must// have a unique major number. Diffing the ancestor with the parent is a good starting point; the device name is important but the major number may vary. Ideally, devices that are no longer supported should be removed, but leaving them in is usually harmless. When in doubt, leave them in.
321:  New devices should be added with an unused major number—preferably the one from the diffs if it is available.
322:  When we’re finished, we can check our changes by running two sort commands:
323: 
324: {{{
325: bfu# sort -k1,1 /etc/name_to_major | sort -uc -k1,1
326: bfu# sort -k2n /etc/name_to_major | sort -uc -k2n
327: 
328: }}}
329: 
330:  The first command reports the first duplicated device name, and the second command reports the lowest duplicated major number. Both commands should result in no output before rebooting. (The kernel will warn about such conflicts when rebooting, but by then it is likely to be too late...)
331:  The etc/security/*_attr files are modified quite a lot by class-action scripts, so there can be a big difference between the parent and child versions. This means that the diff shortcut we described previously won’t be very effective, although the more general diff of the parent and ancestor can still be useful.
332:  The final exception is /etc/path_to_inst. Unless we know exactly what we’re doing, this file shoudl not be touched.
333:  Generally, only conflicts that are marked as NEW need to be examined.
334: **BFU and Zones**
335:  If the machine we’re BFUing hosts zones in addition to the global one, we have some more work to do. Because the contents of the global zone are copied each time we create a zone (unless that zone is "sparse"), we must ensure that the contents of the all the non-global zones are consistent with the global zone. Fortunately, BFU handles this for us, by updating each zone after the global zone has been updated. Because each zone may have configuration files that differ from the global zone’s, each zone has its own set of conflict management directories. Note that it is a good idea to shut down all zones before BFUing, because this ensures that any dependancies that might be violated by the new files won’t break them (the zones). It is also a good idea to rerun bfu if we add a new zone after BFUing, to ensure that the new zone gets updated.
336:  It is not possible to BFU a single zone. If we want to test userland changes in a zone, we must manually copy the files from our build workspace into that zone.
337:  Conflicts must be resolved in the global zone and then in each non-global zone prior to rebooting. Resolving conflicts in a zone works in the same way as in the global zone, but because many files will be identical to their global-zone counterparts many files won’t need to me manually merged: copying the file form the global zone will be sufficient.
338:  When all conflicts in the global and all non-global zones have been resolved, we can reboot the system. Note that the system //must// be rebooted before any non-global zone is rebooted.
339: **BFUing Without Building**
340:  So far this article has assumed that we will be BFUing using archives we built ourselves (as a side effect of building OpenSolaris). What happens if we want to use the latest and greatest bits, without compiling them? Fortunately, pre-built BFU archives are available. To BFU without building from source, we need to download the BFU archive and ON build tools corresponding to the release we want to BFU to. We should also be aware that if there is an appreciable difference between our current build and the one we wish to BFU to, we might need to BFU several times.
341:  Let’s look at an example, BFUing our recently BFUed Build 17 system to Build 18. As in Part 1 of this series, we’ll assume that we’ve downloaded the two required files into a directory called $HOME/open_solaris/build-18, and that our current directory is that directory. For convenience, we’ll refer to this directory as $OPEN_SOL.
342:  First we’ll unpack the BFU archive:
343: 
344: {{{
345: $ bzip2 -dc opensolaris-bfu-20050720.i386.tar.bz2 | tar xf -
346: 
347: }}}
348: 
349:  This will create a directory called archives-20050720, which contains the BFU archive (the name of this file and similar ones will change with each release). We must now become root and install the ON build tools.
350: 
351: {{{
352: # cd /tmp
353: # bzip2 -dc $OPEN_SOL/SUNWonbld-20050720.i386.tar.bz2 | tar xf -
354: # cd onbld
355: # pkgadd -d . SUNWonbld
356: 
357: }}}
358: 
359:  For brevity, we’ve omitted the output from pkgadd. Next we BFU, using a command similar to our previous example (having first ensured that FASTFS, BFULD, and GZIPBIN have been defined appropriately, and that /opt/onbld/bin is in our PATH):
360: 
361: {{{
362: # bfu $OPEN_SOL/archives-20050720/`uname -p`
363: 
364: }}}
365: 
366:  Next we resolve any conflicts (in this example, there are none), and reboot:
367: 
368: {{{
369: bfu# acr
370: No conflicts to resolve.
371: bfu# reboot
372: updating /platform/i86pc/boot_archive...this may take a minute
373: 
374: }}}
375: 
376:  The message about updating /platform/i86pc/boot_archive is x86 specific. Assuming all goes well, our machine will boot the new build (in this case, Build 18). We can check (as always) by logging in and running uname:
377: 
378: {{{
379: $ uname -a
380: SunOS orac 5.11 opensol-20050720 i86pc i386 i86pc
381: 
382: }}}
383: 
384: **Summary**
385:  This article has described how we can use BFU to update our version of OpenSolaris, either from source that we built ourselves or from BFU archives we download from the opensolaris.org web site or elsewhere. To illustrate the former we BFUed to the Build 17 we built in the previous article, and we BFUed from Build 17 to Build 18 as an example of the latter.
386:  The steps we used to BFU from source we built ourselves are:
387: 
388: 1. Ensure the FASTFS, BFULD, and GZIPBIN environment variables are set appropriately.
389: 1. Run the bfu command as root from our workspace directory, passing the name of the archive as the command line option. More often than not, this will be `pwd`/archives/`uname -p`/nightly.
390: 1. Resolve any conflicts using the acr script.
391: 1. Resolve any remaining conflicts manually.
392: 1. Reboot using the reboot command (rather than init or shutdown).
393: 
394:  The steps required to install pre-built BFU archives are similar:
395: 
396: 1. Download the BFU archive and ON build tools for the build we want to BFU to from the opensolaris.org web site or one of its mirrors.
397: 1. Unpack the BFU archive.
398: 1. Install the ON build tools.
399: 1. Ensure the FASTFS, BFULD, and GZIPBIN environment variables are set appropriately.
400: 1. Run the bfu command as root, passing it the name of the BFU archive we unpacked in step 2.
401: 1. Resolve any conflicts using the acr script
402: 1. Resolve any remaining conflicts manually
403: 1. Reboot using the reboot command.
404: 
405:  We also warned that once it has been BFUed, the normal methods for updating the system (e.g., patches or Upgrade installs) cannot subsequently be used: a fresh install or another BFU is required. Finally, we stated that BFU is intended for active OpenSolaris developers only; regular mortals are probably best served using Solaris Express.
406: **Recommended Reading**
407:  The opensolaris.org web site contains several documents, including the //OpenSolaris Developer’s Reference//. Also, be sure to check out details regarding the OpenSolaris Tools Community site and specifically the Sun Studio download site at [[opensolaris.org/os/community/tools/sun_studio_tools/>>Community Group tools.sun_studio_tools]]. The author’s book, //Solaris Systems Programming// [Teer 2005], is essential for readers wishing to work with the userland OpenSolaris code, and //Solaris Internals //[Mauro and McDougall 2001] by Jim Mauro and Richard McDougall should be on every OpenSolaris kernel hacker’s bookshelf. The community blogs at [[www.opensolaris.org/os/blogs/>>Main.blogs]] are another great source of information.
408: 
409:  [Mauro and McDougall 2001]: //Solaris Internals//, ISBN 0-13-022496-0. See [[www.solarisinternals.com/>>http://www.solarisinternals.com/]] for more details.
410:  [Teer 2005]: //Solaris Systems Programming//, ISBN 0-201-75039-2. See [[www.rite-group.com/rich/ssp/>>http://www.rite-group.com/rich/ssp/]] for more details.
411: **Author’s Bio**
412: //Rich Teer is an independent Solaris consultant who has been an active member of the Solaris community for more than ten years. He is the author of the best-selling Sun Microsystems Press book, //Solaris Systems Programming//, and several Solaris-related articles. He was a member of the OpenSolaris pilot program, and currently serves on the OpenSolaris Community Advisory Board (CAB). Rich lives in Kelowna, British Columbia, with his wife, Jenny, and their canine child, Judge. His web site can be found at //[[www.rite-group.com/rich>>http://www.rite-group.com/rich]]//.
413: //
OpenSolaris

Top Menu

Wiki code for Build/Install OpenSolaris (Part 2)

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group tools Pages
