Hi Jack,
On 03/13/09 03:55, Jack wrote:
Include John this time.
Jack
Jack wrote:
Hi Jan,
I have another concern with several other utilities related to
storage management, they may also have this kind of problem as the
dlopen/dlsym mechanism is well used there.
I can name few of them, fcinfo, fcadm, luxadm, cfgadm(for FC related
stuffs),
I have verified that following packages are on the list of those
to be present in AI image:
SUNWfcprt - delivers fcinfo, fcadm
SUNWkvm - delivers cfgadm
SUNWluxop - delivers luxadm
and also emerging tools with new project, like sasinfo... I would
like include John Forte to get a whole picture of this.
I haven't found sasinfo in current IPS repo - is this already
available or planned to be delivered ?
My hope is to solve all these things in one shot :)
I agree, this would be better :-)
Thinking about those kind of problems in general, I am wondering if
following approach might be suitable to address them.
If any functionality is missing in AI image which is needed for
installation,
at this point bug should be filed for this against AI in
Development/installer/autoinstall category. We might develop more automatic
approach and processes to deal with this in future.
If any dependency of functionality already present in AI image is missing,
it is up to each team owning that technology to make sure that dependencies
are captured correctly - the reasoning for this is that owners of
technologies
have appropriate know how about how the dependency chain should look like -
then bug in Development/pkg/importer category should be filed to create
that dependency.
I have CCed IPS team, since they might have more input on this topic
and correct me when my information is not accurate.
Thank you,
Jan
Best regards,
Jack
jan damborsky wrote:
Hi Bing,
On 03/12/09 11:15, bing zhao wrote:
Hi Jan:
In fact that the libima.so.1 uses dlsym to call the functions of
the libsun_ima.so.1.
So that's why we can't see it with ldd. The iscsiadm can't run
successfully without it.
Thanks a lot for clarifying this.
I think that we should make SUNWiscsi dependent on SUNWima.
I agree - I have moved 7293 to the pkg/importer category and put
the explanation in the bug report, so that this dependency can
be created.
Best regards,
Jan
Regards,
Bing
jan damborsky wrote:
Hi Bing, Dave,
On 03/11/09 16:45, Dave Miner wrote:
bing zhao wrote:
Hi All:
First thanks Jan for help on my setup of AI server.
Now I am using AI for installation with opensolaris 2008.11.
When the AI service is running in background, I login as root
and want to run iscsiadm.
I find that the iscsi inititator CLI (iscsiadm) and the driver
(/kernel/drv/(amd64/)iscsi) have already existed.
But I can't run iscsiadm successfully, because that the CLI can
find below libs.
/usr/lib/libsun_ima.so.1
and
/usr/lib/64/libsun_ima.so.1.
They appear to not be be present in the build 109 AI image.
SUNWima seems to not be present.
Yes, SUNWima is currently not present in AI image.
Since I am not familiar with how iSCSI works, could
I please ask some questions in order to clarify this ?
Looking at iscsiadm itself, it doesn't seem to consume
libsun_ima.so.1 library directly:
# ldd -v /usr/sbin/iscsiadm | grep ima
find object=libima.so.1; required by /usr/sbin/iscsiadm
libima.so.1 => /usr/lib/libima.so.1
find version=libima.so.1
libima.so.1 (SUNW_1.0) => /usr/lib/libima.so.1
find object=libc.so.1; required by /usr/lib/libima.so.1
If it was, SUNWima would be pulled into AI image automatically
since we already have SUNWiscsi there (it delivers iscsiadm)
and IPS can recognize that type of dependency.
Since iscsiadm is not linked with libsun_ima.so.1 directly,
my question is how this library is consumed (by which mechanism) ?
Also, are there valid scenarios, where iscsiadm can work without
libsun_ima.so.1, or is libsun_ima.so.1 always required ?
I am asking, since if latter is the case then I would probably
suggest to transfer bug 7293 to IPS to make SUNWiscsi dependent
on SUNWima. The intent here is to identify and capture
dependencies moving toward correctly built IPS dependency chain
instead of need to resolve them manually.
At the time being SUNWiscsi depends on following packages:
# pkg contents -m SUNWiscsi | grep require
depend [email protected] type=require
depend [email protected] type=require
depend [email protected] type=require
I am not sure if the case reported here is the candidate for
this operation - trying to clarify :-)
Thanks !
Jan
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
