Jim,
Thank you.
Thanks Jim. It looks like the packaging scripts want to find the
kernel
objects in a sub-directory called i386 (relative to where they are
now).
So what I did was make once - package scripts complain. Then copy the
files (things in kernel/drv and kernel/mdb) into i386 sub-directories
that I created. Then make again and the packages get made. I had
messed with the package editing script but it was easier just to copy
the files. I couldn't find any reference to putting things in a i386
directory anywhere - seems like there was an amd64 directory, though.
I think that was all I had to do but it is all on my home machine
and I
don't have access to it right now.
I used your install.sh script and it worked great (had to CD into the
right spot in the package directory first).
I have a 2-machine mirror working and am now trying to figure out how
this could be used in our situation. I'm thinking of buying the
JES and
am trying to figure out how to leverage everything (including to
purchase the mirror software).
It bugs me that I can't "check up" on the remote filesystem at will as
it needs to stay unmounted. I don't know much about ZFS - could the
remote filesystem stay mounted r/o if I use ZFS ? That way I could
look
at some kind of heartbeat file on the remote site.
A means to check up on the remote file system, is to configure the
SNDR remote secondary volume(s), as an II master volume. Then create
an II independent, dependent, or compact dependent shadow volume of
this II master volume. Since a snapshot volume is point-in-time copy,
thus it is frozen in time, one can mount and access this snapshot
copy of the file system.
Just remember to unmount (or zpool export) the file system mounted on
the shadow volume, prior to taking a new point-in-time copy.
Your video was great - I used it to help me with my UFS mirror. I
forgot that I needed sndradm -u to get things rolling and watching
the
video helped me.
Thank you.
Let me know if you want me to test anything or if you have any
advice on
how to deploy.
Continue to let everyone on [storage-discuss] know what you are up
to, how it is going and ask anyone question that you may have.
Jim
Thanks,
Jim
On Tue, 2007-04-03 at 11:35 -0400, Jim Dunham wrote:
Jim,
OK - editing Makefile.i386 in /export/build/avs/src/sun_avs/uts/
i386 fixed the build
problems:
#DEF_BUILDS = $(DEF_BUILDS64)
#ALL_BUILDS = $(ALL_BUILDS64)
DEF_BUILDS = $(DEF_BUILDS32)
ALL_BUILDS = $(ALL_BUILDS32)
Is this the correct change?
Although above is one area in which the build files are defective in
handling a 32-bit only build, there are a couple of other changes
needed
elsewhere. I am looking into them now, and hope to have a set of
updated
packages soon.
Regards,
Jim Dunham
But now package building fails:
## Building pkgmap from package prototype file.
ERROR in prototype:
no object for <usr/kernel/drv/i386/nsctl> found in root
directory
no object for <usr/kernel/drv/i386/sdbc> found in root directory
no object for <usr/kernel/drv/i386/nskern> found in root
directory
no object for <usr/kernel/drv/i386/ncall> found in root
directory
no object for <usr/kernel/misc/i386/spuni> found in root
directory
no object for <usr/lib/mdb/kvm/i386/nsctl.so> found in root
directory
no object for <usr/lib/mdb/kvm/i386/sdbc.so> found in root
directory
pkgmk: ERROR: unable to build pkgmap from prototype file
## Packaging was not successful.
*** Error code 1
dmake: Fatal error: Command failed for target `install'
Current working directory /export/build/avs/src/sun_avs/pkg/host
*** Error code 1
The following command caused the error:
cd host; pwd; /opt/SUNWspro/bin/dmake -m parallel -j 10 install
dmake: Fatal error: Command failed for target `host'
The objects are not in the directories referenced - take away the
last "i386" in
the binary path and the package is created.
Any assistance appreciated.
Jim
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
