On 09/16/10 10:54 AM, Janie Lu wrote:
[...]
The changes I made to both the default DC manifest and the AI
manifest are the same:
1. Specified 3 publishers in this order:
<main url="http://<machine>.sfbay/yf-on-nightly/"
publisher="on-nightly"/> <<<---Our repo.redist based on nv_143
<main url="http://<machine>.sfbay/yf-on-extra/"
publisher="on-extra"/> <<<---Our repo.extra based on nv_143
<main url="http://ipkg.sfbay/dev/"; publisher="opensolaris.org"/>
2. Deleted "entire" pkg from list of pkgs to install.
Looking at the /tmp/install_log, the 147 packages are expected
(anything starting with "pkg://opensolaris.org" is coming from ipkg,
and will be @147). The interesting, and odd ones, are the ones coming
from nv_145, which makes no sense to me.
I noticed that too and thought possibly those pkgs were only available
at nv_145 at the latest, but that's not the case. (eg libxaw7 is
available at nv_147 but install_log shows it would install nv_145)
Running with a blend of 143 and 147 packages has a high chance of
failure in any case, however - there's really no guarantee that this
blend will working. Too many things could have changed; cross
consolidation dependency failures are high.
You may have better success by explicitly installing
"pkg:/[email protected],5.11-0.143" in the AI manifest.
I tried this previously but hit the following error:
exec command: /usr/bin/pkg -R /a install
pkg:/[email protected],5.11-0.143:20100706T172436Z
pkg: No matching version of babel_install can be installed:
pkg://opensolaris.org/[email protected],5.11-0.143:20100706T172436Z:
This version is excluded by installed incorporation
pkg://opensolaris.org/consolidation/solaris_re/[email protected],5.11-0.147:20100827T055257Z
Unable to install pkg:/[email protected],5.11-0.143:20100706T172436Z in /a
It's the same root issue: solaris_re-incorporation is installed at
nv_147 and I need it to be nv_143 because our project bits are nv_143
based. This smells of an "entire" issue, but because "entire" is not a
package built and delivered by our project I can't specify to use
entire from our project repositories. More below.
In this case, re-adding "[email protected],5.11-0.143" to both the
original DC manifest and the AI manifest may help as well - that
would ensure that *everything* installs from 143. The only reason to
remove "entire" is if you're putting together an image based in part
on a build that's not yet available in ipkg.sfbay.
Since our project repo's do not deliver "entire", if I add entire back
in as a pkg to install then DC would grab entire from the
opensolaris.org publisher instead. Wouldn't all the subsequent
packages that "entire" ties together also be pulled from the
opensolaris.org publisher instead of our project publishers, thereby
basically creating a stock nv_143 image?
It shouldn't. "entire" (and the other incorporations) restrict based on
the build number, not the publisher. So ent...@143 will ensure all your
packages are build 143, but you should still get your custom ON
packages, as you have that as your preferred publisher.
I had followed Liane Praza's writeup
<http://blogs.sun.com/lianep/entry/testing_on_changes_with_opensolaris>
where it says " I also didn't install the |entire| package, as I'm
using ON development bits" but maybe I'm not interpreting that correctly.
The reason you have to avoid the entire package in her scenario is
because if you are testing the *latest* O/N bits, you're building an
image with newer ON bits than what the latest 'entire' package would
allow you to install. For example, with 147 as the latest in ipkg.sfbay,
if you built an ON @ build 148, the 'entire' package from ipkg would
restrict you to 147, and prevent you from installing the 148 ON - hence
the need skip installing entire. Since you're building 143 based bits,
there's an 'ent...@143' that will be able to properly restrict your build.
(With all that said, your scenario is one that has probably received
little to no experimentation, so you there may be other subtle issues
you hit).
- Keith
Thanks much,
Janie
- Keith
Both uname and osnet-incorporation reflect our nv_143 project bits*:**
*
#uname -a
SunOS dt92-418 5.11 yf-onnv-13.143:09/09/2010 sun4v sparc sun4v Solaris
# pkg info osnet-incorporation
Name: consolidation/osnet/osnet-incorporation
Summary: OS/Net consolidation incorporation
Description: This incorporation constrains packages from the OS/Net
consolidation.
State: Installed
Publisher: on-nightly
Version: 0.5.11
Build Release: 5.11
Branch: 0.143
Packaging Date: Fri Sep 10 08:22:39 2010
Size: 0.00 B
FMRI:
pkg://on-nightly/consolidation/osnet/[email protected],5.11-0.143:20100910T082239Z
DC Build Log available at:
http://re.west/gates/yf/builds/ONNV/yf-onnv-13.143/images/logs-build-iso/detail-log-2010-09-10-18-11-25
Can someone help point out what I'm missing?
Janie
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
