Tim Knitter wrote: > > > Stephen Hahn wrote: >> * Tim Knitter <[EMAIL PROTECTED]> [2008-03-28 21:46]: >>> >>> Stephen Hahn wrote: >>>> * Tim Knitter <[EMAIL PROTECTED]> [2008-03-28 16:59]: >>>>>> 3. Do you have ideas on how to make this portable to older Solaris >>>>>> releases and non-Solaris environments (Linux, Windows, etc.)? I'm >>>>> It is all based on the supported namespace <pool>/ROOT/<beName> >>>>> existing and it being a zfs dataset. So if either of those don't >>>>> exist then no recovery will happen. >>>> Is the "it being a zfs dataset" test really "it being a zfs dataset >>>> with the specific new feature we need", or is it not able to determine >>> The "it being a zfs dataset" refers to the target image. Either the >>> live system or the argument to pkg -R. If either of those resolve to >>> a zfs dataset resembling <pool>/ROOT/<beName> then recovery is >>> enabled. The specific new feature pkg(1) needs is the knowledge of >>> the namespace layout and the existence of libbe. I hope that answered >>> your question. >> >> I had thought that libbe relies on ZFS behaviour introduced after >> Build 79. Will a DP2 build (which has rpool/ROOT/preview2 as a >> pattern, but is Build 79 based) actually be able to run pkg/libbe >> correctly? >> > > The correct behavior of libbe relies on ZFS features introduce after > build 79. So the answer is a sad no. I'm going to request that libbe > provide an interface so libbe_glue and friends can query about the > availability of full functionality. >
After discussing this with Ethan it doesn't appear that this will work. There currently isn't a way for libbe to determine from libzfs if post 86 bits are installed. So updating P2 to P3 will still need to be done manually. We will need instructions similar to the ones on opensolaris: http://opensolaris.org/os/project/indiana/resources/update_guidelines . These instructions mention that the P2 version of SUNWipkg be installed before cloning at step 3.3. In order to allow this to happen for P2 -> P3, pkg(1) can't hard require the libbe_glue package SUNWinstall-libs, since SUNWinstall-libs requires SUNWzfs* which requires SUNWcsr and that will suck over incompatible changes. So I made pkg(1) dynamically import libbe_glue.so if it exists so we can get around this snafu. So after installing the P3 version of SUNWipkg on a P2 system, as described at step 8, and running the pkg -R /mnt image-update command, libbe_glue.so won't exist and no built-in recovery will be attempted allowing the image-update to succeed. Once the user reboots to their P3 system built-in recovery will be enabled and then going from P3 -> P4 will be handled by pkg image-update without special instructions. >> We expect to be able to upgrade from DP2 to the next release, so this >> is a required (presumably manual) test case. >> > > We would either have to automatically install the required zfs packages > and possible dependent packages or have the user do it before > image-updating, ugh. I need to verify that that is even a viable > workaround for DP2 though... > This is not viable as mentioned above. Thanks Tim > Thanks > Tim > >> Thanks >> Stephen >> > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
