Hi
seems to be a problem with zones under / file system.
I will look into this more tomorrow.

Enda

Philip Nelson wrote:
> Path /usr/local/zones, and the zonepath under it, are part of the 
> global zone's /usr/local filesystem.  They are not separate mounts.  
> On the system where the kernel patch worked, the zonepaths are 
> separate mounts.
>
> -Philip
>
> Enda O'Connor wrote:
>> Philip Nelson wrote:
>>> Enda O'Connor wrote:
>>>> Philip Nelson wrote:
>>>>> They're 755, all the way to /.
>>>>>
>>>>> Here's the actual error message a small zone gets:
>>>>>
>>>>> /usr/local/zones/[zonename]/lu/dev/.SUNW_patches_0909107281-1123512-000001035723188c/120011-14/SUNWbart/install/checkinstall:
>>>>>  
>>>>> /usr/local/zones/[zonename]/lu/dev/.SUNW_patches_0909107281-1123512-000001035723188c/120011-14/SUNWbart/install/checkinstall:
>>>>>  
>>>>> cannot open
>>>>> pkgadd: ERROR: checkinstall script did not complete successfully
>>>>> Dryrun complete.
>>>>> No changes were made to the system.
>>>> Hi Philip
>>>> what is the premissions on the directory structure containing the 
>>>> patch being added?
>>> 775.
>>>>
>>>> can you boot and halt the zone prior to running patchadd
>>>
>>> Yes--that's how I did it.
>>>
>>> I just patched a 6/01 server with containers, successfully this 
>>> time.  The only differences I can see are that the failing servers 
>>> are 6/06 instead of 6/01 (my earlier 6/01 problem was with a ZFS 
>>> zone root), and that the working 6/01 server has the container roots 
>>> mounted on their own UFS partitions.  The zone roots are still 
>>> permissions 700, but the underlying mount points (what you see if 
>>> you unmount the zone roots) are 755.  On the failing servers, the 
>>> zone roots are not mounted on their own partitions;  they are simply 
>>> part of the /usr/local partition.
>> hmm, need to test this locally to see what is up, suspect that the 
>> code in patchadd that mounts things up for installing the 120011 
>> patch is getting confused somewhere.
>> So just to be clear, /usr/local/zones is part of the root filesystem, 
>> it's not a seperate mount.
>>
>> Enda
>>>
>>> Any idea if nobody would be able to reference an underlying mount 
>>> point, and ignore the perms of the filesystem mounted on top of it?
>>>
>>> -Philip
>>>>
>>>> Enda
>>>>>
>>>>> -Philip
>>>>>
>>>>> Enda O'Connor wrote:
>>>>>> Philip wrote:
>>>>>>> I've run into difficulty installing sparc kernel patch 120011-14 
>>>>>>> from the Oct/03/07 recommended patch cluster onto 6/01 and 6/06 
>>>>>>> systems with non-global zones (whether small or large).
>>>>>>>
>>>>>>> As long as all non-global zones are halted (and don't have ZFS 
>>>>>>> roots), the patch installs all right in the global zone.  
>>>>>>> However, it gives a failure message for installation in the 
>>>>>>> non-global zones because user nobody can't read the zone roots 
>>>>>>> (due to the required 700 permissions on those directories).  If 
>>>>>>> I try to give nobody read access to those directories, the patch 
>>>>>>> fails anyhow because it can't boot the non-global zone (it fails 
>>>>>>> on the 700 perms check).  I can't run the patch with the zones 
>>>>>>> already started because the kernel patch requires them to be 
>>>>>>> halted (for deferred activation patching).  So, I'm boxed in.
>>>>>>>
>>>>>>> There are a couple other patches not installing into the 
>>>>>>> non-global zones because they fail a dependency check on the 
>>>>>>> kernel patch.  I'm hoping that the small zones are inheriting 
>>>>>>> the patches anyhow, but I don't know what to do with the big zones.
>>>>>>>
>>>>>>> Any thoughts?
>>>>>>>  
>>>>>>>  
>>>>>>> This message posted from opensolaris.org
>>>>>>> _______________________________________________
>>>>>>> zones-discuss mailing list
>>>>>>> zones-discuss@opensolaris.org
>>>>>>>   
>>>>>> Hi
>>>>>> wierd, my zonepaths are all 700 and it works fine, what is the 
>>>>>> permission of the parent of zonepath?
>>>>>>
>>>>>> Enda
>>>>>>
>>>>
>>>>
>>
>>

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to