Hello all,
Due to my split-root configurations, I often do OI/OmniOS upgrades in a pre-created cloned BE (automated by https://github.com/jimklimov/illumos-splitroot-scripts since the generic beadm/zfs clone do a poor job with customized zfs attributes on child datasets). As part of an upgrade, I do a chroot into the mounted new BE to use the pkg(5) "in place" (and with altroot of "/") and if this fails - I fall back to alternate root (-R) with the unchanged pkg(5) version installed in the original BE. In either case, I pass the "--deny-new-be" parameter to pkg(5). (relevant code snippet is presented below in this message) However there are some packages whose upgrades seem to require a "non-Live BE" installation. And even though I install to an alternate BE, they fail. Is there some way around this, beside fixing pkg(5) itself? For example, recently I got the state below: the pkg program got updated in the new BE, but it could not be used via chroot due to "live image" concerns, and the old pkg(5) in original BE did not suffice for the upgrades. A reboot into the new BE and another upgrade request fixes this, but that's kind of unwieldy. And installing new pkg into old BE goes somewhat against the purpose of BEs (unchanged old state I can roll back into - thus including escape from broken pkg(5) as any other bit of system software). Screenshot from the script: ===== Updating PKG software itself Packages to update: 1 DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 1/1 16/16 0.3/0.3 303k/s PHASE ITEMS Removing old actions 1/1 Updating modified actions 18/18 Updating package state database Done Updating package cache 1/1 Updating image state Done Creating fast lookup database Done Reading search index Done Updating search index 1/1 ===== Updating the image with new PKG software via chroot pkg update: The proposed operation cannot be performed on a live image. ===== Updating the image with old PKG software via altroot WARNING: pkg(5) appears to be out of date, and should be updated before running update. Please update pkg(5) by executing 'pkg install pkg:/package/pkg' as a privileged user and then retry the update. ===== Updating the image with old PKG software via altroot and allowed refresh WARNING: pkg(5) appears to be out of date, and should be updated before running update. Please update pkg(5) by executing 'pkg install pkg:/package/pkg' as a privileged user and then retry the update. The corresponding part of the script (and exact command-lines involved) are here: ... { echo "===== Updating PKG software itself" ### This clause should fail if no 'pkg' updates were available, or if a ### chrooted upgrade attempt with the new 'pkg' failed - both ways fall ### through to altroot upgrade attempt if /usr/bin/pkg -R "$BENEW_MNT" update --no-refresh --accept --deny-new-be --no-backup-be pkg; then \ echo "===== Updating the image with new PKG software via chroot" chroot "$BENEW_MNT" /usr/bin/pkg -R / image-update --no-refresh --accept --deny-new-be --no-backup-be else false; fi; } || \ { echo "===== Updating the image with old PKG software via altroot" /usr/bin/pkg -R "$BENEW_MNT" image-update --no-refresh --accept --deny-new-be --no-backup-be; } || \ { echo "===== Updating the image with old PKG software via altroot and allowed refresh" /usr/bin/pkg -R "$BENEW_MNT" image-update --accept --deny-new-be --no-backup-be; } ... Essentially, what I want is for pkg(5) to correctly guess, or be told by the caller, that it in fact does not modify a "live" image and so can do anything dangerous it would please to do. Thanks in advance, Jim Klimov
_______________________________________________ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
