Here's a few observations while using <target>:
- In the S11 Express AI Guide, Example 4-18 doesn't work as advertised.
Seems to have a typo too:
<target>
<target_device>
<swap no_swap"true"/> <!-- Should be <swap no_swap="true"/>, right? -->
</target_device>
</target>
Either way, when adding the manifest, it won't validate - complains that
<swap> needs a zvol tag, no matter what. Same issue for the <dump> tag.
- A common case we're going to be handling is where we'll be targeting disks
that either have a standard VTOC (slice 0 is very small, and other slices
exist), or were re-VTOCed sometime in the past, and the <target> is going
to have to delete all of the slices, then recreate slice 0 if you want to
dedicate the whole disk to rpool.
Here's what I finally got to work, which I thought was at least
non-intuitive. An example of this might be handy in the manual going forward:
<target>
<target_device>
<disk>
<disk_name name="c3t1d0" name_type="ctd"/>
<slice name="0" action="delete"/>
<slice name="1" action="delete"/>
<slice name="3" action="delete"/>
<slice name="4" action="delete"/>
<slice name="5" action="delete"/>
<slice name="6" action="delete"/>
<slice name="7" action="delete"/>
<slice name="0" is_root="true" force="true"/>
</disk>
</target_device>
- What's the current way to eliminate the creation of /export and /export/home?
- What's the current way to create /var as part of the BE, rather than being
shared? The idea being to set a refquota on /var so that / can grow without
bound, but /var could not.
GM
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
