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

Comments:

I hit the same problem. I was able to get around it by doing:

pfexec pkg image-update --accept -f -v

This build a new update image but disabled the Contrib repository and the HomeLife repository. I re enabled the repositories after booting into the new image.
Everything is working well.

Posted by Ralph Ellis on February 22, 2010 at 12:34 PM PST #

Thanks for the tip, Ralph...I was wary of using -f. But I'll give that a try next time.

Posted by Scott Davenport on February 23, 2010 at 02:21 AM PST #

The -f option does disable the safety checks which is not the ideal way to go. However, since the process creates a new boot image, you are protected from problems. If the newly created image does not work well, you just delete it and take a step backwards.
Because I had a large number of programs installed from the Contrib and HomeLife repositories, I did not want to manually edit them all out to do an upgrade.

Posted by Ralph Ellis on February 23, 2010 at 11:24 AM PST #

Post a Comment:
Comments are closed for this entry.
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