Isn't is useful for people to know how to copy or clone a boot environment? We don't clarify in the command itself that the create command actually does clones. I think we need to explain that in the document. Barbara
On 10/24/08 11:14, Tim Knitter wrote: > Hi Barbara - Here are my comments. > > p5: > > "A boot environment is an image that is bootable" > > I don't think using "image" is good to define what a boot environment is > since there is no definition of what "image" is in the doc either. > > A boot environment is an installed, bootable instance of an operating > system... > > mount or unmount -> mount, unmount, list > > Should probably add the list sub-command here as well. > > p6 bullet 1: > > "After successfully completing the changes" -> After successfully completing > the > update > > The above paragraph talks about updating so "changes" should be replaced with > "update" > > p10: > > Note ? You must be root on your system to use the beadm utility. > > Nit: > We could also mention that beadm is part of the "Software Installation" > profile and a user who is allowed to be part of this profile can use pfexec > to execute beadm. > > p11: > > 3 Review the information that is displayed. > > Is this to be filled in later? > > p12: > > "How to Clone a Boot Environment" > > Since we don't have a clone subcommand, and this section is talking about > "Creating a Boot Environment", this could be rewritten to say: How to Create > a New Boot Environment > > Using clone in the examples doesn't seem right to me even though a clone is > what the resultant "beadm create" command creates. IMO all examples should > remove clone and replace with creating a new Boot Environment to be > consistent. > > p13: > > "Creating a New, Cloned Boot Environment Dataset (BE2)" > > This implies that we are creating a single dataset but the example shows many > datasets. Please revise. Something like: Creating a New Boot Environment with > Multiple Datasets (BE2) > > "The following example illustrates the dataset in a newly created boot > environment." > > dataset -> datasets > > "The original dataset in this example is BE1." > > original dataset -> original Boot Environment > > "The new boot environment, BE2, is contained in its > own dataset. The new boot environment can also contain separate datasets for > traditional file > systems, such as /var or /opt." > > -> > > The new boot environment, BE2, contains separate datasets cloned from BE1. If > BE1 contains separate datasets for traditional file systems, such as /var or > /opt, then those datasets are also cloned. > > Creating a Clone With Shared File Systems > -> > Creating a New Boot Environment With Shared File Systems > > The following example illustrates the dataset > -> > The following example illustrates the datasets > > p14: > > rpool/export/ remove trailing '/' > > How to Clone an Inactive Boot Environment > -> > How to Create a Boot Environment from an Inactive Boot Environment > > p15: > > $ beadm create beName at snapshot > > The example uses "snapshot" but the text talks about "snapshotdescription". > Please use one or the other throughout this section. > > "If you have an older snapshot of an environment that you want to use as > default in the GRUB > menu, for example, you would copy that snapshot, making a new boot > environment that can be activated, and then booted, from the GRUB menu." > > This paragraph seems confusing and is not needed for this example. Please > remove. > > p16: > > "You can change an inactive boot environment into an active environment." > > active environment -> active boot environment > > General note... Part of the document talks about "upgrade" and other parts of > it mention "update". Please be consistent throughout. "Upgrade" should be > replaced with "update" and it should be clear that an update happens via "pkg > image-update". > > p17: > > "The boot environment is mounted but remains inactive. You can update the > packages this > mounted, inactive boot environment." > -> > The boot environment is mounted but remains inactive. > > The next section talks about updating the BE so the last sentence should be > removed or modified to mention the next section. > > p18: > > "Destroying Unneeded Boot Environments" > > Is "unneeded" really needed here? :-) It isn't mentioned in the text below it > and seems unnecessary. > > General note... The doc talks about filesystems and datasets interchangeably. > A filesystem is a type of dataset so it should be used sparingly and dataset > used instead in most cases. e.g. > > "See the following example, where BE1 and BE2 share the rpool/export and > rpool/export/home file systems. The datasets for BE1, BE2, and the shared > file systems > include the following: > > rpool/ROOT/BE1 > rpool/ROOT/BE1/opt > rpool/ROOT/BE2 > rpool/ROOT/BE2/opt > rpool/export > rpool/export/home > > In this example all these can either be referred to as datasets or > filesystems. Datasets being the more appropriate since we don't know what the > backing store is and it is assumed to be a file system in your example. If we > just mention "dataset" then there is no need to mention "filesystem" > > p19: > > " If you want to rename the active environment, first, make a different > environment > active." > -> > If you want to rename the active boot environment, first, make a different > boot environment > active. > > "If the new name already is in use" > -> > If the new name is already in use > > Is that more correct grammar? Not sure. > > p23: > > "The boot environment has a copy of rpool/zones/z1. The copy is > rpool/zones/z1/ROOT/zbe-1." > > has -> creates > zbe-1 -> zbe > > zbe-1 would be the name of the second zone. > > > "The copy of zone z1 for the new boot environment has its root dataset at > rpool/zones/z1/ROOT/zbe-2" > > zbe-2 -> zbe-1 > > Maybe it would be better to start this example with the original BE being > opensolaris instead of opensolaris-1 and opensolaris-1 being the second BE, > then the zones dataset names won't be conflicting. > > Thanks > Tim > > Barbara.Lundquist at Sun.COM wrote: > >> Ethan, Evan, Tim, >> >> Here's a final review draft of the snap upgrade document: >> >> http://www.opensolaris.org/os/project/caiman/files/snapupgrade2.pdf >> >> We got alot of useful edits - I think the overall layout of the document is >> much improved with the new intro and the overall document more divided >> into "chunks". >> >> Remember this doc will actually be delivered as an HTML document with >> separate HTML pages for each section. Each "how to" section will be on >> its own subpage. >> >> I'll need any final comments by COB this Friday. >> >> Thank you! >> Barbara >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20081024/16e29685/attachment.html>
