Well, it'd still be wrong, but, is /etc/name_to_sysnum in the solaris 9 host modified? If not, modifying and rebooting should make things "better" but not right.
On Tue, Nov 11, 2008 at 2:57 AM, Andersson, Johan <[EMAIL PROTECTED]> wrote: > Hi Agin > > More info about the problem with Openafs in solaris 9 containers: > > The global host is selix030gh > # uname -a > SunOS selix030gh 5.10 Generic_127111-06 sun4u sparc SUNW,Sun-Fire-V445 > # > # zoneadm list -icv > ID NAME STATUS PATH BRAND IP > 0 global running / native shared > 1 selix030lte01 running /export/vm/selix030lte01 native shared > 2 selix030lte03 running /export/vm/selix030lte03 native shared > 3 selix030lte02 running /export/vm/selix030lte02 native shared > 4 selix030lte04 running /export/vm/selix030lte04 solaris9 shared > - vgtemplate installed /export/vm/vgtemplate native shared > # > > selix030lte04 [8:38am] [/usr/afsws/bin] -> fs sysname > Bad system call > selix030lte04 [8:38am] [/usr/afsws/bin] -> uname -a > SunOS selix030lte04 5.9 Generic_Virtual sun4u sparc SUNW,Sun-Fire-V445 > selix030lte04 [8:40am] [/usr/afsws/bin] -> > > # zonecfg -z selix030lte04 > zonecfg:selix030lte04> info > zonename: selix030lte04 > zonepath: /export/vm/selix030lte04 > brand: solaris9 > autoboot: true > bootargs: > pool: > limitpriv: > scheduling-class: > ip-type: shared > fs: > dir: /afs > special: /afs > raw not specified > type: lofs > options: [] > net: > address: XX.XX.XX.XX > physical: bge0 > attr: > name: hostid > type: string > value: XXXXXX > attr: > name: machine > type: string > value: sun4u > zonecfg:selix030lte04> > > selix030lte01 [8:40am] [/usr/afsws/bin] -> fs sysname > Current sysname is 'sun4x_510' > selix030lte01 [8:40am] [/usr/afsws/bin] -> uname -a > SunOS selix030lte01 5.10 Generic_127111-06 sun4u sparc SUNW,Sun-Fire-V445 > selix030lte01 [8:40am] [/usr/afsws/bin] -> > > # zonecfg -z selix030lte01 > zonecfg:selix030lte01> info > zonename: selix030lte01 > zonepath: /export/vm/selix030lte01 > brand: native > autoboot: true > bootargs: > pool: > limitpriv: > scheduling-class: > ip-type: shared > inherit-pkg-dir: > dir: /lib > inherit-pkg-dir: > dir: /platform > inherit-pkg-dir: > dir: /sbin > inherit-pkg-dir: > dir: /usr > fs: > dir: /afs > special: /afs > raw not specified > type: lofs > options: [] > net: > address: XX.XX.XX.XX > physical: bge0 > zonecfg:selix030lte01> > > Best Regards > > //JA > > > -----Original Message----- > From: Derrick Brashear [mailto:[EMAIL PROTECTED] > Sent: den 6 november 2008 16:24 > To: Chas Williams (CONTRACTOR) > Cc: Douglas E. Engert; Andersson, Johan; [email protected] > Subject: Re: [OpenAFS] Opneafs in solaris 9 containers > > Seems like a special case of exporter objects for virtualized platforms might > work here. > > On Thu, Nov 6, 2008 at 10:11 AM, Chas Williams (CONTRACTOR) <[EMAIL > PROTECTED]> wrote: >> In message <[EMAIL PROTECTED]>,"Douglas E. Engert" writes: >>>The AFS cache manager is not aware of zones, and I would not expect it >>>to be aware of containers either. I suspect that the container code >>>does not know anything about @sys and may be producing the output of >>>pwd, If a file access needed, the server kernel with AFS does map it >>>to sun4x_510. >> >> you might be able to fix this without too much trouble. you can get >> the zone for a vnode, VTOZ. hopefully containers would have something >> similar (or just use the same mechanism). you would then need to find >> a way to figure out what kernel is running in the zone/container or >> just let the cache manager set a sysname on a per zone basis. >> >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > > > -- > Derrick > -- Derrick _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
