vinum-root.html

FreeBSD操作系统的详细使用手册

<pre class="SCREEN">
Mounting root from ufs:/dev/vinum/root
</pre>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN26448" name="AEN26448">17.9.3 Example of a Vinum-based Root
Setup</a></h2>

<p>After the Vinum root volume has been set up, the output of <tt class="COMMAND">vinum l
-rv root</tt> could look like:</p>

<pre class="SCREEN">
...
Subdisk root.p0.s0:
        Size:        125829120 bytes (120 MB)
        State: up
        Plex root.p0 at offset 0 (0  B)
        Drive disk0 (/dev/da0h) at offset 135680 (132 kB)

Subdisk root.p1.s0:
        Size:        125829120 bytes (120 MB)
        State: up
        Plex root.p1 at offset 0 (0  B)
        Drive disk1 (/dev/da1h) at offset 135680 (132 kB)
   
</pre>

<p>The values to note are <var class="LITERAL">135680</var> for the offset (relative to
partition <tt class="FILENAME">/dev/da0h</tt>). This translates to 265 512-byte disk
blocks in <tt class="COMMAND">disklabel</tt>'s terms. Likewise, the size of this root
volume is 245760 512-byte blocks. <tt class="FILENAME">/dev/da1h</tt>, containing the
second replica of this root volume, has a symmetric setup.</p>

<p>The disklabel for these devices might look like:</p>

<pre class="SCREEN">
...
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   245760      281    4.2BSD     2048 16384     0   # (Cyl.    0*- 15*)
  c: 71771688        0    unused        0     0         # (Cyl.    0 - 4467*)
  h: 71771672       16     vinum                        # (Cyl.    0*- 4467*)
   
</pre>

<p>It can be observed that the <var class="LITERAL">"size"</var> parameter for the faked
<var class="LITERAL">"a"</var> partition matches the value outlined above, while the <var
class="LITERAL">"offset"</var> parameter is the sum of the offset within the Vinum
partition <var class="LITERAL">"h"</var>, and the offset of this partition within the
device (or slice). This is a typical setup that is necessary to avoid the problem
described in <a href="vinum-root.html#VINUM-ROOT-PANIC">Section 17.9.4.3</a>. It can also
be seen that the entire <var class="LITERAL">"a"</var> partition is completely within the
<var class="LITERAL">"h"</var> partition containing all the Vinum data for this
device.</p>

<p>Note that in the above example, the entire device is dedicated to Vinum, and there is
no leftover pre-Vinum root partition, since this has been a newly set-up disk that was
only meant to be part of a Vinum configuration, ever.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN26469" name="AEN26469">17.9.4 Troubleshooting</a></h2>

<p>If something goes wrong, a way is needed to recover from the situation. The following
list contains few known pitfalls and solutions.</p>

<div class="SECT3">
<h3 class="SECT3"><a id="AEN26472" name="AEN26472">17.9.4.1 System Bootstrap Loads, but
System Does Not Boot</a></h3>

<p>If for any reason the system does not continue to boot, the bootstrap can be
interrupted with by pressing the <b class="KEYCAP">space</b> key at the 10-seconds
warning. The loader variables (like <var class="LITERAL">vinum.autostart</var>) can be
examined using the <tt class="COMMAND">show</tt>, and manipulated using <tt
class="COMMAND">set</tt> or <tt class="COMMAND">unset</tt> commands.</p>

<p>If the only problem was that the Vinum kernel module was not yet in the list of
modules to load automatically, a simple <tt class="COMMAND">load vinum</tt> will
help.</p>

<p>When ready, the boot process can be continued with a <tt class="COMMAND">boot
-as</tt>. The options <var class="OPTION">-as</var> will request the kernel to ask for
the root filesystem to mount (<var class="OPTION">-a</var>), and make the boot process
stop in single-user mode (<var class="OPTION">-s</var>), where the root filesystem is
mounted read-only. That way, even if only one plex of a multi-plex volume has been
mounted, no data inconsistency between plexes is being risked.</p>

<p>At the prompt asking for a root filesystem to mount, any device that contains a valid
root filesystem can be entered. If <tt class="FILENAME">/etc/fstab</tt> had been set up
correctly, the default should be something like <var
class="LITERAL">ufs:/dev/vinum/root</var>. A typical alternate choice would be something
like <var class="LITERAL">ufs:da0d</var> which could be a hypothetical partition that
contains the pre-Vinum root filesystem. Care should be taken if one of the alias <var
class="LITERAL">"a"</var> partitions are entered here that are actually reference to the
subdisks of the Vinum root device, because in a mirrored setup, this would only mount one
piece of a mirrored root device. If this filesystem is to be mounted read-write later on,
it is necessary to remove the other plex(es) of the Vinum root volume since these plexes
would otherwise carry inconsistent data.</p>
</div>

<div class="SECT3">
<h3 class="SECT3"><a id="AEN26492" name="AEN26492">17.9.4.2 Only Primary Bootstrap
Loads</a></h3>

<p>If <tt class="FILENAME">/boot/loader</tt> fails to load, but the primary bootstrap
still loads (visible by a single dash in the left column of the screen right after the
boot process starts), an attempt can be made to interrupt the primary bootstrap at this
point, using the <b class="KEYCAP">space</b> key. This will make the bootstrap stop in
stage two, see <a href="boot-blocks.html#BOOT-BOOT1">Section 12.3.2</a>. An attempt can
be made here to boot off an alternate partition, like the partition containing the
previous root filesystem that has been moved away from <var class="LITERAL">"a"</var>
above.</p>
</div>

<div class="SECT3">
<h3 class="SECT3"><a id="VINUM-ROOT-PANIC" name="VINUM-ROOT-PANIC">17.9.4.3 Nothing
Boots, the Bootstrap Panics</a></h3>

<p>This situation will happen if the bootstrap had been destroyed by the Vinum
installation. Unfortunately, Vinum accidentally currently leaves only 4 KB at the
beginning of its partition free before starting to write its Vinum header information.
However, the stage one and two bootstraps plus the disklabel embedded between them
currently require 8 KB. So if a Vinum partition was started at offset 0 within a slice or
disk that was meant to be bootable, the Vinum setup will trash the bootstrap.</p>

<p>Similarly, if the above situation has been recovered, for example by booting from a
``Fixit'' medium, and the bootstrap has been re-installed using <tt
class="COMMAND">disklabel -B</tt> as described in <a
href="boot-blocks.html#BOOT-BOOT1">Section 12.3.2</a>, the bootstrap will trash the Vinum
header, and Vinum will no longer find its disk(s). Though no actual Vinum configuration
data or data in Vinum volumes will be trashed by this, and it would be possible to
recover all the data by entering exact the same Vinum configuration data again, the
situation is hard to fix at all. It would be necessary to move the entire Vinum partition
by at least 4 KB off, in order to have the Vinum header and the system bootstrap no
longer collide.</p>
</div>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="VINUM-ROOT-4X" name="VINUM-ROOT-4X">17.9.5 Differences for
FreeBSD 4.X</a></h2>

<p>Under FreeBSD 4.X, some internal functions required to make Vinum automatically scan
all disks are missing, and the code that figures out the internal ID of the root device
is not smart enough to handle a name like <tt class="FILENAME">/dev/vinum/root</tt>
automatically. Therefore, things are a little different here.</p>

<p>Vinum must explicitly be told which disks to scan, using a line like the following one
in <tt class="FILENAME">/boot/loader.conf</tt>:</p>

<pre class="PROGRAMLISTING">
vinum.drives="/dev/<var class="REPLACEABLE">da0</var> /dev/<var
class="REPLACEABLE">da1</var>"
</pre>

<p>It is important that all drives are mentioned that could possibly contain Vinum data.
It does not harm if <span class="emphasis"><i class="EMPHASIS">more</i></span> drives are
listed, nor is it necessary to add each slice and/or partition explicitly, since Vinum
will scan all slices and partitions of the named drives for valid Vinum headers.</p>

<p>Since the routines used to parse the name of the root filesystem, and derive the
device ID (major/minor number) are only prepared to handle ``classical'' device names
like <tt class="FILENAME">/dev/ad0s1a</tt>, they cannot make any sense out of a root
volume name like <tt class="FILENAME">/dev/vinum/root</tt>. For that reason, Vinum itself
needs to pre-setup the internal kernel parameter that holds the ID of the root device
during its own initialization. This is requested by passing the name of the root volume
in the loader variable <var class="LITERAL">vinum.root</var>. The entry in <tt
class="FILENAME">/boot/loader.conf</tt> to accomplish this looks like:</p>

<pre class="PROGRAMLISTING">
vinum.root="root"
</pre>

<p>Now, when the kernel initialization tries to find out the root device to mount, it
sees whether some kernel module has already pre-initialized the kernel parameter for it.
If that is the case, <span class="emphasis"><i class="EMPHASIS">and</i></span> the device
claiming the root device matches the major number of the driver as figured out from the
name of the root device string being passed (that is, <var class="LITERAL">"vinum"</var>
in our case), it will use the pre-allocated device ID, instead of trying to figure out
one itself. That way, during the usual automatic startup, it can continue to mount the
Vinum root volume for the root filesystem.</p>

<p>However, when <tt class="COMMAND">boot -a</tt> has been requesting to ask for entering
the name of the root device manually, it must be noted that this routine still cannot
actually parse a name entered there that refers to a Vinum volume. If any device name is
entered that does not refer to a Vinum device, the mismatch between the major numbers of
the pre-allocated root parameter and the driver as figured out from the given name will
make this routine enter its normal parser, so entering a string like <var
class="LITERAL">ufs:da0d</var> will work as expected. Note that if this fails, it is
however no longer possible to re-enter a string like <var
class="LITERAL">ufs:vinum/root</var> again, since it cannot be parsed. The only way out
is to reboot again, and start over then. (At the ``askroot'' prompt, the initial <tt
class="FILENAME">/dev/</tt> can always be omitted.)</p>
</div>
</div>

<div class="NAVFOOTER">
<hr align="LEFT" width="100%" />
<table summary="Footer navigation table" width="100%" border="0" cellpadding="0"
cellspacing="0">
<tr>
<td width="33%" align="left" valign="top"><a href="vinum-config.html"
accesskey="P">Prev</a></td>
<td width="34%" align="center" valign="top"><a href="index.html"
accesskey="H">Home</a></td>
<td width="33%" align="right" valign="top"><a href="l10n.html"
accesskey="N">Next</a></td>
</tr>

<tr>
<td width="33%" align="left" valign="top">Configuring Vinum</td>
<td width="34%" align="center" valign="top"><a href="vinum-vinum.html"
accesskey="U">Up</a></td>
<td width="33%" align="right" valign="top">Localization - I18N/L10N Usage and Setup</td>
</tr>
</table>
</div>

<p align="center"><small>This, and other documents, can be downloaded from <a
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/">ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/</a>.</small></p>

<p align="center"><small>For questions about FreeBSD, read the <a
href="http://www.FreeBSD.org/docs.html">documentation</a> before contacting &#60;<a
href="mailto:[e-mail]">[e-mail]</a>&#62;.<br />
For questions about this documentation, e-mail &#60;<a
href="mailto:[e-mail]">[e-mail]</a>&#62;.</small></p>
</body>
</html>