[zones-discuss] IPKG Brand for S10/SX:CE
Has any one invested time trying to get IPKG branded zones working on S10/SX:CE? I'm starting down that road and have had fairly good progress to date but would love to collaborate. benr. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
On Thu, Apr 23, 2009 at 12:49 PM, Ben Rockwood b...@cuddletech.com wrote: Has any one invested time trying to get IPKG branded zones working on S10/SX:CE? I'm starting down that road and have had fairly good progress to date but would love to collaborate. Yes, I have done an ipkg zone on SXCE. My motivation was to be able to use AI to install the 2008.11 preview on an LDom. My notes appear below. I believe that they are fairly complete for initial bootstrapping. Note that there is a bit of git r done in it, rather than generating appropriate source code fixes. What do you perceive as the motivation for ipkg zones on S10? If I squint just right, I think that I can see the mapping of packages, patches, update releases, etc. to IPS constructs. Is this what you have in mind, or something else? I assume that with SXCE your plan of attack would be to leverage the work done for the opensolaris distro for ips branded zones. Is that a reasonable assumption? Anyway, here was my first run through this effort. Starting point is a SXCE 108 T5120 with SUWNCXall, zfs root 1. Get pkg-gate from mercurial $ hg clone ssh://a...@hg.opensolaris.org/hg/pkg/gate destination directory: gate requesting all changes adding changesets adding manifests adding file changes added 1040 changesets with 13427 changes to 7444 files 4779 files updated, 0 files merged, 0 files removed, 0 files unresolved 2. Build pkg $ export PATH=$PATH:/apps/studio12/SUNWspro/bin $ cd gate/src $ make $ make packages 3. Install packages # cd gate/packages # pkgadd -d . all 4. Fake global zone's notion of entire Modify /usr/lib/brand/ipkg/pkgcreatezone. Just before the point where it would error out, force it to match the SXCE build of the global zone. entire_fmri=ent...@0.5.11,5.11-0.108 if [[ -z $entire_fmri ]]; then fail_incomplete $f_no_entire fi 5. Create the zone # zonecfg -z ipkg ipkg: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:ipkg create -t SUNWipkg zonecfg:ipkg set zonepath=/zones/ipkg zonecfg:ipkg set autoboot=false # set up network as well zonecfg:ipkg verify zonecfg:ipkg commit zonecfg:ipkg exit 6. Install the zone # export http_proxy=insert proxy here # zoneadm -z ipkg install -P opensolaris.org=http://pkg.opensolaris.org/dev/ A ZFS file system has been created for this zone. pkg: No image found. Publisher: Using opensolaris.org (http://pkg.opensolaris.org/dev/). done. root ...Refreshing Catalog Sanity Check: Looking for 'entire' incorporation. Installing: Core System (output follows) DOWNLOADPKGS FILES XFER (MB) Completed 26/26 2790/2790 52.48/52.48 PHASEACTIONS Install Phase 6147/6147 Installing: Additional Packages (output follows) DOWNLOADPKGS FILES XFER (MB) Completed 32/32 5449/5449 31.63/31.63 PHASEACTIONS Install Phase 7083/7083 PHASE ITEMS Indexing Packages 60/60 Note: Man pages can be obtained by installing SUNWman Postinstall: Copying SMF seed repository ... done. Postinstall: Applying workarounds. Done: Installation completed in 576 seconds. Next Steps: Boot the zone, then log into the zone console (zlogin -C) to complete the configuration process 7. Configure the zone # zoneadm -z ipkg boot ; zlogin -C ipkg [Connected to zone 'ipkg' console] Hostname: ipkg Loading smf(5) service descriptions: 1/68 8. Install installadm, java These steps could be done more efficiently... it was trial and error to get the packages I needed. r...@ipkg:~# pkg install SUNWinstalladm-tools DOWNLOADPKGS FILES XFER (MB) Completed 13/13 1641/1641 9.43/9.43 PHASEACTIONS Install Phase 2175/2175 PHASE ITEMS Reading Existing Index 9/9 Indexing Packages 74/74 I did the same for SUNWless, SUNWmkcd, SUNWrsync. I forget whether I needed to this for SUNWdsd or not. Import the services... r...@ipkg:~# svcadm restart manifest-import Beyond this I got into a fair amount of trial and error, specifically related to getting AI and DHCP to work. This isn't really needed for a generic ipkg zone, however. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Wow! Thanks Mike, this was really helpful. Its almost exactly the same as my experience. My first attempt was actually to create the zone root by hand by creating a partial image into which I installed 'entire', but that got messy and instead I hacked up the brand scripts in the same way you described. Your experience was more clean than mine, though. I'm testing on snv_89. It looks like I smacked into bug 6733450, which I got around by replacing (updating) brand.dtd.1, but I also short-circuited the ZFS root for the zone, so pkg installs fail. It looks like my takeaway for now is that you can do it, you and I have both gotten it to work, but you need to be running at least snv_98 to do it right. I think with a couple of conditionals in the scripts we might be able to make this fairly clean. One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. benr. Mike Gerdts wrote: On Thu, Apr 23, 2009 at 12:49 PM, Ben Rockwood b...@cuddletech.com wrote: Has any one invested time trying to get IPKG branded zones working on S10/SX:CE? I'm starting down that road and have had fairly good progress to date but would love to collaborate. Yes, I have done an ipkg zone on SXCE. My motivation was to be able to use AI to install the 2008.11 preview on an LDom. My notes appear below. I believe that they are fairly complete for initial bootstrapping. Note that there is a bit of git r done in it, rather than generating appropriate source code fixes. What do you perceive as the motivation for ipkg zones on S10? If I squint just right, I think that I can see the mapping of packages, patches, update releases, etc. to IPS constructs. Is this what you have in mind, or something else? I assume that with SXCE your plan of attack would be to leverage the work done for the opensolaris distro for ips branded zones. Is that a reasonable assumption? Anyway, here was my first run through this effort. Starting point is a SXCE 108 T5120 with SUWNCXall, zfs root 1. Get pkg-gate from mercurial $ hg clone ssh://a...@hg.opensolaris.org/hg/pkg/gate destination directory: gate requesting all changes adding changesets adding manifests adding file changes added 1040 changesets with 13427 changes to 7444 files 4779 files updated, 0 files merged, 0 files removed, 0 files unresolved 2. Build pkg $ export PATH=$PATH:/apps/studio12/SUNWspro/bin $ cd gate/src $ make $ make packages 3. Install packages # cd gate/packages # pkgadd -d . all 4. Fake global zone's notion of entire Modify /usr/lib/brand/ipkg/pkgcreatezone. Just before the point where it would error out, force it to match the SXCE build of the global zone. entire_fmri=ent...@0.5.11,5.11-0.108 if [[ -z $entire_fmri ]]; then fail_incomplete $f_no_entire fi 5. Create the zone # zonecfg -z ipkg ipkg: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:ipkg create -t SUNWipkg zonecfg:ipkg set zonepath=/zones/ipkg zonecfg:ipkg set autoboot=false # set up network as well zonecfg:ipkg verify zonecfg:ipkg commit zonecfg:ipkg exit 6. Install the zone # export http_proxy=insert proxy here # zoneadm -z ipkg install -P opensolaris.org=http://pkg.opensolaris.org/dev/ A ZFS file system has been created for this zone. pkg: No image found. Publisher: Using opensolaris.org (http://pkg.opensolaris.org/dev/). done. root ...Refreshing Catalog Sanity Check: Looking for 'entire' incorporation. Installing: Core System (output follows) DOWNLOADPKGS FILES XFER (MB) Completed 26/26 2790/2790 52.48/52.48 PHASEACTIONS Install Phase 6147/6147 Installing: Additional Packages (output follows) DOWNLOADPKGS FILES XFER (MB) Completed 32/32 5449/5449 31.63/31.63 PHASEACTIONS Install Phase 7083/7083 PHASE ITEMS Indexing Packages 60/60 Note: Man pages can be obtained by installing SUNWman Postinstall: Copying SMF seed repository ... done. Postinstall: Applying workarounds. Done: Installation completed in 576 seconds. Next Steps: Boot the zone, then log into the zone console (zlogin -C) to complete the configuration process 7. Configure the zone # zoneadm -z ipkg boot ; zlogin -C ipkg [Connected to zone 'ipkg' console] Hostname: ipkg Loading smf(5) service descriptions: 1/68 8. Install installadm, java These steps could be done more efficiently... it was trial and error to get the packages I needed.
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Ben Rockwood wrote: One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. Ben, The sysevent service should not run in the ngz. This is delivered in a hollow pkg with svr4 pkging. You might take a look at my p2v webrev for opensolaris. http://cr.opensolaris.org/~gjelinek/webrev.p2v/ In the p2v script there is a fix_smf() function which looks at the IPS pkgs to determine which SMF services should be deleted inside the zone. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Ben Rockwood wrote: One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. Sorry, I sent a pointer to the wrong webrev. It should be: http://cr.opensolaris.org/~gjelinek/webrev.6793/ Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Jerry Jelinek wrote: Ben Rockwood wrote: One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. Ben, The sysevent service should not run in the ngz. This is delivered in a hollow pkg with svr4 pkging. You might take a look at my p2v webrev for opensolaris. http://cr.opensolaris.org/~gjelinek/webrev.p2v/ In the p2v script there is a fix_smf() function which looks at the IPS pkgs to determine which SMF services should be deleted inside the zone. Excellent! That explains things. I know that syseventd doesn't run in zones, but in the past I've seen SMF scripts simply exiting if it was in a ngz, I wasn't sure how this was handled. Thanks! benr. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
On Thu 23 Apr 2009 at 01:06PM, Ben Rockwood wrote: Jerry Jelinek wrote: Ben Rockwood wrote: One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. Ben, The sysevent service should not run in the ngz. This is delivered in a hollow pkg with svr4 pkging. You might take a look at my p2v webrev for opensolaris. ... Excellent! That explains things. I know that syseventd doesn't run in zones, but in the past I've seen SMF scripts simply exiting if it was in a ngz, I wasn't sure how this was handled. Well, it doesn't actually explain why you're in this situation. Jerry-- shouldn't it be the case that we don't even deliver this into the ipkg zone? I was surprised by Ben's mail initially because IPS support for variants should mean that the sysevent service is not delivered in the zone when installed: $ zonename global $ pkg search /var/svc/manifest/system/sysevent.xml INDEX ACTIONVALUE PACKAGE path file var/svc/manifest/system/sysevent.xml pkg:/sunw...@0.5.11-0.111 $ pkg contents -m SUNWcsd | grep sysevent.xml file 59577d5adb8f6609814cf693b79f80001ebe3b6c chash=86217745abacf6ada215c19c29b411567a3422e2 group=sys mode=0444 -opensolaris.zone=global ... -variant.opensolaris.zone=global So I'm perplexed how this service could wind up in the zone-- unless the variant isn't getting set properly in the image? Or perhaps the mixing of a very new version of SUNWipkg with older repository contents is causing this to not work right... I'm not certain. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Dan Price wrote: On Thu 23 Apr 2009 at 01:06PM, Ben Rockwood wrote: Jerry Jelinek wrote: Ben Rockwood wrote: One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. Ben, The sysevent service should not run in the ngz. This is delivered in a hollow pkg with svr4 pkging. You might take a look at my p2v webrev for opensolaris. ... Excellent! That explains things. I know that syseventd doesn't run in zones, but in the past I've seen SMF scripts simply exiting if it was in a ngz, I wasn't sure how this was handled. Well, it doesn't actually explain why you're in this situation. I missed you too Dan. Still got that charm. So I'm perplexed how this service could wind up in the zone-- unless the variant isn't getting set properly in the image? Or perhaps the mixing of a very new version of SUNWipkg with older repository contents is causing this to not work right... I'm not certain. Stated earlier, I'm using the 89 Dev repository on SX:CE snv_89. Thats my issue. We can see that Mike used the same method I did but he did it on 108 and had a much cleaner experience. My hunch at this point is that anything 98 or newer should be pain free, but I think 101 (to align with 2008.11) is probly a safer bet. benr. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Ben Rockwood wrote: So I'm perplexed how this service could wind up in the zone-- unless the variant isn't getting set properly in the image? Or perhaps the mixing of a very new version of SUNWipkg with older repository contents is causing this to not work right... I'm not certain. Stated earlier, I'm using the 89 Dev repository on SX:CE snv_89. Thats my issue. We can see that Mike used the same method I did but he did it on 108 and had a much cleaner experience. My hunch at this point is that anything 98 or newer should be pain free, but I think 101 (to align with 2008.11) is probly a safer bet. To follow up to Dan's question and your response. Maybe I misunderstood, but I thought you were using a hacked up install script that was actually installing the global zone image into the zone. That would explain why you're not getting the right zone variants and have to fix up the SMF services. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
On Thu 23 Apr 2009 at 03:16PM, Ben Rockwood wrote:
Excellent! That explains things. I know that syseventd doesn't run in
zones, but in the past I've seen SMF scripts simply exiting if it was in
a ngz, I wasn't sure how this was handled.
Well, it doesn't actually explain why you're in this situation.
I missed you too Dan. Still got that charm.
...
My hunch at this point is that anything 98 or newer should be pain free,
but I think 101 (to align with 2008.11) is probly a safer bet.
So it turns out that you've stumbled upon a previously undiscovered
bug in our zone support in pkg(5). Thanks for finding this.
The summary is that variant-aware versions of SUNWipkg don't honor
the older opensolaris.zone={global|non-global} tags. The introduction
of variants altered those tags (in builds published since then) as
follows:
opensolaris.zone=global -- variant.opensolaris.zone=global
Normally this would be OK because we introduced variant support along
with publication of variant tags at the same time, IIRC in build 106,
when SPARC support came in.
However, we will eventually have to backpublish the current version of
SUNWipkg into the 'release' repo in order to allow folks running on
release to update to the next significant release version (2009.H1 as
it's being called). And it's this same mixing of old and new which is
causing you problems here.
If you run on 106+ all should be well. Bart is doing us a favor and
looking into how to fix this. In all likelihood we'll teach the
packaging client to recognize that opensolaris.zone=global is present,
but that variant.opensolaris.zone=global is missing, and to then
fill in what is missing.
I've filed http://defect.opensolaris.org/bz/show_bug.cgi?id=8392 to
cover this issue. If you monitor the status, it'll let you know when it
makes sense to pull a new version of the pkg-gate and try out the fix.
Thanks guys!
-dp
--
Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Dan Price wrote: I've filed http://defect.opensolaris.org/bz/show_bug.cgi?id=8392 to cover this issue. If you monitor the status, it'll let you know when it makes sense to pull a new version of the pkg-gate and try out the fix. Thanks guys! Sweet, thanks Dan! benr. ___ zones-discuss mailing list zones-discuss@opensolaris.org
