[OmniOS-discuss] pkg(5) in alternate roots

[Jim Klimov]

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20150701/f08316f8/attachment-0001.html>