[zones-discuss] RH3U8 install failure in a branded zone
HI, Can anyone help. I have tried to install RHEL3U8 into a branded zone on NV50 x86 from a tarball of the install media but after untaring the tarball I get to the stage where it says Setting up the initial lx envirmonment and it fails with the message: Unable to symlink '/bin/sh' to path-to-zone.. It all exists, /bin/sh is there. The logfile doesn`t say anything of use other than repeating the above message. Any ideas ? Regards, Carl. This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: Restart: PSARC/2006/598 Swap resource control; locked memory RM improvements
On Sat, Nov 11, 2006 at 09:02:48PM -0800, Gary Winiger wrote:
First off, sorry for the stutter in the spec update mail.
The project team didn't supply a summary of the changes, so I'll be
asking for one in a follow on.
I've addressed your comments way below. Here is my change summary and case
discussion summary:
SUMMARY OF CHANGES
1. Change to the proposed uncommitted kstat names and statistics.
From the form:
zone:{zoneid}:vm
with statistics:
zonename
swap_reserved
max_swap_reserved
locked_memory
max_locked_memory
To the form:
caps:{zoneid}:swaprsev_zone_{zoneid}
caps:{zoneid}:lockedmem_zone_{zoneid}
caps:{zoneid}:lockedmem_project_{projid}
with statistics:
zonename
usage
value
This sets up a generic scheme for adding kstats to project and
zone rctls. A kstat is created per rctl, instead of per zone.
2. Addition of zonecfg(1m) minimums for setting zone.max-swap.
When setting zone.max-swap via zonecfg(1m), a minimum value will be
enforced:
global zone: 100M
non-global zone: 50M
Currently, this is about 20M more than is needed to boot after a
default installation.
3. Addition of zonecfg(1m) warnings when setting zone.max-swap and
zone.max-lwps on the global zone.
global:capped-memory set swap=200M
Warning: Setting capped swap on the global zone can impact
system availability.
SUMMARY OF CASE DISCUSSION:
The case disussion has focused on the problem that the zone.max-swap
rctl on the global zone can affect system availability. An identical
problem exists today with task/project/zone.max-lwps.
Solutions to this problem may involve one or more of:
- Exempting project 0 in the global zone from zone.* rctls.
- Preventing task/project.* rctls from being set on project 0
in the global zone.
- Modifying root's default project.
- Adding a new privilege to exempt a process from rctls.
- Updating system service manifests to drop the new privilege.
Solving this problem in a way that will prevent the global zone (on a
default system) from becoming unavailable due to a resource control setting
will require a signficant change to the system. I believe solving this
problem is outside the scope of the zone.max-swap case, and would be better
solved by another case which is not seeking patch binding.
To minimize this problem for zone.max-swap (and zone.max-lwps), I've instead
proposed zonecfg enhacements to assist the admin in configuring these rctls
safely.
1. This case proposes adding the following resource control:
INTERFACE COMMITMENT BINDING
zone.max-swap CommittedPatch
This control will limit the swap reserved by processes and tmpfs
mounts within the global zone and non-global zones. This resource
control serves to address the referenced RFE[6].
There was some considerable discussion on the global zone aspect
of this part of the proposal. Perhaps I missed in the spec how
the new proposal mitigates the risk of the global zone not being
able to administer the system.
DETAIL:
1. zone.max-swap resource control.
Limits swap consumed by user process address space mappings and
tmpfs mounts within a zone.
While a low zone.max-swap setting for the global zone can lead to
a difficult-to-administer global zone, the same problem exists
today when configuring the zone.max-lwps resource control on the
global zone, or when all system swap is reserved. The zonecfg(1m)
enhancements detailed below will help administrators configure
zone.max-swap safely.
Perhaps I misunderstood the interaction between project 0
and zone.max-lwps in the global zone. If a max-lwps is set
is project 0 bound by it?
Currently yes. zone.* rctls bound all processes in the global zone, regardless
of project. This is the issue that my other proposal is attempting to
address.
Perhaps a short summary of the offline discussion on project 0
and the project teams feeling that the discussions conclusions
might not be patch qualified. I realize the need for this project
to have a patch binding.
I've added this summary above.
2. swap and locked properties for zonecfg(1m) capped_memory
resource.
To prevent administrators from configuring a low swap limit that
will prevent a system from booting, zonecfg will not allow a
swap limit to be configured to less than:
Global zone: 100M
Non-global zone: 50M.
These numbers are based on the swap needed to boota zone after a
default installation.
[zones-discuss] Re: Restart: PSARC/2006/598 Swap resource control; locked memory RM improvements
Steve Lawrence wrote:
On Sat, Nov 11, 2006 at 09:02:48PM -0800, Gary Winiger wrote:
First off, sorry for the stutter in the spec update mail.
The project team didn't supply a summary of the changes, so I'll be
asking for one in a follow on.
I've addressed your comments way below. Here is my change summary and case
discussion summary:
SUMMARY OF CHANGES
1. Change to the proposed uncommitted kstat names and statistics.
From the form:
zone:{zoneid}:vm
with statistics:
zonename
swap_reserved
max_swap_reserved
locked_memory
max_locked_memory
To the form:
caps:{zoneid}:swaprsev_zone_{zoneid}
caps:{zoneid}:lockedmem_zone_{zoneid}
caps:{zoneid}:lockedmem_project_{projid}
with statistics:
zonename
usage
value
This sets up a generic scheme for adding kstats to project and
zone rctls. A kstat is created per rctl, instead of per zone.
2. Addition of zonecfg(1m) minimums for setting zone.max-swap.
When setting zone.max-swap via zonecfg(1m), a minimum value will be
enforced:
global zone: 100M
non-global zone: 50M
Currently, this is about 20M more than is needed to boot after a
default installation.
3. Addition of zonecfg(1m) warnings when setting zone.max-swap and
zone.max-lwps on the global zone.
global:capped-memory set swap=200M
Warning: Setting capped swap on the global zone can impact
system availability.
SUMMARY OF CASE DISCUSSION:
The case disussion has focused on the problem that the zone.max-swap
rctl on the global zone can affect system availability. An identical
problem exists today with task/project/zone.max-lwps.
Solutions to this problem may involve one or more of:
- Exempting project 0 in the global zone from zone.* rctls.
- Preventing task/project.* rctls from being set on project 0
in the global zone.
- Modifying root's default project.
- Adding a new privilege to exempt a process from rctls.
- Updating system service manifests to drop the new privilege.
Solving this problem in a way that will prevent the global zone (on a
default system) from becoming unavailable due to a resource control setting
will require a signficant change to the system. I believe solving this
problem is outside the scope of the zone.max-swap case, and would be better
solved by another case which is not seeking patch binding.
To minimize this problem for zone.max-swap (and zone.max-lwps), I've instead
proposed zonecfg enhacements to assist the admin in configuring these rctls
safely.
1. This case proposes adding the following resource control:
INTERFACE COMMITMENT BINDING
zone.max-swapCommittedPatch
This control will limit the swap reserved by processes and tmpfs
mounts within the global zone and non-global zones. This resource
control serves to address the referenced RFE[6].
There was some considerable discussion on the global zone aspect
of this part of the proposal. Perhaps I missed in the spec how
the new proposal mitigates the risk of the global zone not being
able to administer the system.
DETAIL:
1. zone.max-swap resource control.
Limits swap consumed by user process address space mappings and
tmpfs mounts within a zone.
While a low zone.max-swap setting for the global zone can lead to
a difficult-to-administer global zone, the same problem exists
today when configuring the zone.max-lwps resource control on the
global zone, or when all system swap is reserved. The zonecfg(1m)
enhancements detailed below will help administrators configure
zone.max-swap safely.
Perhaps I misunderstood the interaction between project 0
and zone.max-lwps in the global zone. If a max-lwps is set
is project 0 bound by it?
Currently yes. zone.* rctls bound all processes in the global zone, regardless
of project. This is the issue that my other proposal is attempting to
address.
Perhaps a short summary of the offline discussion on project 0
and the project teams feeling that the discussions conclusions
might not be patch qualified. I realize the need for this project
to have a patch binding.
I've added this summary above.
2. swap and locked properties for zonecfg(1m) capped_memory
resource.
To prevent administrators from configuring a low swap limit that
will prevent a system from booting, zonecfg will not allow a
swap limit to be configured to less than:
Global zone: 100M
Non-global zone: 50M.
These numbers are based on the swap needed to boota zone after a
[zones-discuss] Re: Zone's FAQ for patches is useless and should be
We are in the process of updating the FAQ right now. The updated version should be there next week. It's been 10 weeks now (not intending to critique the authors, who probably put the FAQ in their spare time). There has been 1-2 updates in the FAQ, but many areas are still outdated. 2 questions 1: Any plan to wiki this? 2. Any plan to update all contents to Nov 2006? thank you from Singapore e1 www.singanix.org This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Zone's FAQ for patches is useless and should be
If you would like to contribute QA, please send it and I will review it and put it in the FAQ. Iwan Rahabok wrote: We are in the process of updating the FAQ right now. The updated version should be there next week. It's been 10 weeks now (not intending to critique the authors, who probably put the FAQ in their spare time). There has been 1-2 updates in the FAQ, but many areas are still outdated. 2 questions 1: Any plan to wiki this? 2. Any plan to update all contents to Nov 2006? -- -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
