Friday Mar 05, 2010

OpenSolaris IPS Workspace Build & Test Run

With the switch to IPS packages in being build directly in ON (and it's been a while since I did an ON build), I tried out the new build/test sequence. All in all, pretty smooth. After building my workspace, I went the route of using pkg.depotd and stood up a package repository for the repo.redist area of my workspace. The steps for this are described nicely in README.pkg. As are the pkg commands to setup the publisher.

The rest of this should be old-hat to folks that have done image-updates before. The actual upgrade:

$ pfexec pkg uninstall entire PHASE ACTIONS Removal Phase 54/54 PHASE ITEMS Reading Existing Index 8/8 Indexing Packages 1/1

So far so good...

$ pfexec pkg image-update --be-name on-nightly DOWNLOAD PKGS FILES XFER (MB) Completed 224/224 3251/3251 105.8/105.8 PHASE ACTIONS Removal Phase 1639/1639 Install Phase 1845/1845 Update Phase 7060/7060 PHASE ITEMS Reading Existing Index 8/8 Indexing Packages 224/224 Indexing Packages 224/224 Optimizing Index... PHASE ITEMS Indexing Packages 791/791 A clone of opensolaris_133 exists and has been updated and activated. On the next boot the Boot Environment on-nightly will be mounted on '/'. Reboot when ready to switch to this updated BE.

And after the reboot, am I running the bits from my workspace?

$ uname -v onnv-ips

Given when I cloned the gates, I'm running an snv_135 base, plus a few pushes. When build 136 rolls around, I plan to return to updating from the development repository and keep all the consolidations up to date.

:wq

Monday Feb 22, 2010

OpenSolaris Build 133 Update Snag With /contrib

Build 133 of OpenSolaris released last week. Last Friday I went to perform my update, but hit a problem - Update Manager told me that my current boot environment couldn't be updated. It was late in the day and I didn't muster the energy to tackle the problem. Refreshed from the weekend, today I did.

For debugging, I switched to the pkg CLI. I started with what (more or less) the GUI is doing:

# pkg image-update --be-name opensolaris_133 WARNING: pkg(5) appears to be out of date, and should be updated before running image-update. Please update pkg(5) using 'pfexec pkg install SUNWipkg' and then retry the image-update.

Oh, ok. Simple enough, update SUNWipkg.

# pkg install SUNWipkg DOWNLOAD PKGS FILES XFER (MB) Completed 1386/1386 11351/11351 452.4/452.4 pkg: Requested "install" operation would affect files that cannot be modified in live image. Please retry this operation on an alternate boot environment.

Ok. So not so simple. And what really grabbed my attention is that an update of SUNWipkg touched 1386 packages. A short Google search later, I'd found the cause of my woes:
    Bug 13233 - /contrib packages should not depend on "entire"
A reasonably new issue, but I'd been fortunate not to hit it before. Prior to last week, the only package I had installed from /contrib was dmidecode which I ported. But I'd recently added a few packages. Thankfully, the bug report includes a command to find installed packages that depend on "entire":

# pkg contents -Ho pkg.name,action.raw -t depend | grep fmri=entire@ | cut -f1 arp-scan ettercap-NG fping netdiscover

After removing those packages, my update sailed smoothly:

# pkg uninstall arp-scan ethercap-NG fping netdiscover ... # pkg image-update --be-name opensolaris_133 DOWNLOAD PKGS FILES XFER (MB) Completed 1386/1386 11351/11351 452.4/452.4 PHASE ACTIONS Removal Phase 9289/9289 Install Phase 49290/49290 Update Phase 17307/17307 PHASE ITEMS Reading Existing Index 8/8 Indexing Packages 1386/1386 Optimizing Index... PHASE ITEMS Indexing Packages 1438/1438

It's an inconvenience to reinstall the /contrib packages, so I'm waiting a bit longer and watching the bug report. The bug is active and /contrib may be cleaned up in short order.

:wq

About

user9148476

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today