The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: sect2/screen
Context English State
<prompt>#</prompt> <userinput>bsdlabel -e <replaceable>devname</replaceable></userinput>
<replaceable>devname</replaceable> must be either the name of the disk, like <filename>da0</filename> for disks without a slice table, or the name of the slice, like <filename>ad0s1</filename>.
If there is already an <literal>a</literal> partition on the device from a pre-<filename>vinum</filename> root file system, it should be renamed to something else so that it remains accessible (just in case), but will no longer be used by default to bootstrap the system. A currently mounted root file system cannot be renamed, so this must be executed either when being booted from a <quote>Fixit</quote> media, or in a two-step process where, in a mirror, the disk that is not been currently booted is manipulated first.
The offset of the <filename>vinum</filename> partition on this device (if any) must be added to the offset of the respective root volume subdisk on this device. The resulting value will become the <literal>offset</literal> value for the new <literal>a</literal> partition. The <literal>size</literal> value for this partition can be taken verbatim from the calculation above. The <literal>fstype</literal> should be <literal>4.2BSD</literal>. The <literal>fsize</literal>, <literal>bsize</literal>, and <literal>cpg</literal> values should be chosen to match the actual file system, though they are fairly unimportant within this context.
That way, a new <literal>a</literal> partition will be established that overlaps the <filename>vinum</filename> partition on this device. <command>bsdlabel</command> will only allow for this overlap if the <filename>vinum</filename> partition has properly been marked using the <literal>vinum</literal> fstype.
A faked <literal>a</literal> partition now exists on each device that has one replica of the root volume. It is highly recommendable to verify the result using a command like:
<prompt>#</prompt> <userinput>fsck -n /dev/<replaceable>devname</replaceable>a</userinput>
It should be remembered that all files containing control information must be relative to the root file system in the <filename>vinum</filename> volume which, when setting up a new <filename>vinum</filename> root volume, might not match the root file system that is currently active. So in particular, <filename>/etc/fstab</filename> and <filename>/boot/loader.conf</filename> need to be taken care of.
At next reboot, the bootstrap should figure out the appropriate control information from the new <filename>vinum</filename>-based root file system, and act accordingly. At the end of the kernel initialization process, after all devices have been announced, the prominent notice that shows the success of this setup is a message like:
Mounting root from ufs:/dev/gvinum/root
Example of a <filename>vinum</filename>-based Root Setup
After the <filename>vinum</filename> root volume has been set up, the output of <command>gvinum l -rv root</command> could look like:
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)
The values to note are <literal>135680</literal> for the offset, relative to partition <filename class="devicefile">/dev/da0h</filename>. This translates to 265 512-byte disk blocks in <command>bsdlabel</command>'s terms. Likewise, the size of this root volume is 245760 512-byte blocks. <filename class="devicefile">/dev/da1h</filename>, containing the second replica of this root volume, has a symmetric setup.
The bsdlabel for these devices might look like:
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*)
It can be observed that the <literal>size</literal> parameter for the faked <literal>a</literal> partition matches the value outlined above, while the <literal>offset</literal> parameter is the sum of the offset within the <filename>vinum</filename> partition <literal>h</literal>, 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 <xref linkend="vinum-root-panic"/>. The entire <literal>a</literal> partition is completely within the <literal>h</literal> partition containing all the <filename>vinum</filename> data for this device.
In the above example, the entire device is dedicated to <filename>vinum</filename> and there is no leftover pre-<filename>vinum</filename> root partition.
The following list contains a few known pitfalls and solutions.
System Bootstrap Loads, but System Does Not Boot
If for any reason the system does not continue to boot, the bootstrap can be interrupted by pressing <keycap>space</keycap> at the 10-seconds warning. The loader variable <literal>vinum.autostart</literal> can be examined by typing <command>show</command> and manipulated using <command>set</command> or <command>unset</command>.
If the <filename>vinum</filename> kernel module was not yet in the list of modules to load automatically, type <command>load geom_vinum</command>.
When ready, the boot process can be continued by typing <command>boot -as</command> which <option>-as</option> requests the kernel to ask for the root file system to mount (<option>-a</option>) and make the boot process stop in single-user mode (<option>-s</option>), where the root file system 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.
At the prompt asking for a root file system to mount, any device that contains a valid root file system can be entered. If <filename>/etc/fstab</filename> is set up correctly, the default should be something like <literal>ufs:/dev/gvinum/root</literal>. A typical alternate choice would be something like <literal>ufs:da0d</literal> which could be a hypothetical partition containing the pre-<filename>vinum</filename> root file system. Care should be taken if one of the alias <literal>a</literal> partitions is entered here, that it actually references the subdisks of the <filename>vinum</filename> root device, because in a mirrored setup, this would only mount one piece of a mirrored root device. If this file system is to be mounted read-write later on, it is necessary to remove the other plex(es) of the <filename>vinum</filename> root volume since these plexes would otherwise carry inconsistent data.
Only Primary Bootstrap Loads
If <filename>/boot/loader</filename> 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 by pressing <keycap>space</keycap>. This will make the bootstrap stop in <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/boot.html#boot-boot1">stage two</link>. An attempt can be made here to boot off an alternate partition, like the partition containing the previous root file system that has been moved away from <literal>a</literal>.
Nothing Boots, the Bootstrap Panics
This situation will happen if the bootstrap had been destroyed by the <filename>vinum</filename> installation. Unfortunately, <filename>vinum</filename> accidentally leaves only 4 KB at the beginning of its partition free before starting to write its <filename>vinum</filename> header information. However, the stage one and two bootstraps plus the bsdlabel require 8 KB. So if a <filename>vinum</filename> partition was started at offset 0 within a slice or disk that was meant to be bootable, the <filename>vinum</filename> setup will trash the bootstrap.
Similarly, if the above situation has been recovered, by booting from a <quote>Fixit</quote> media, and the bootstrap has been re-installed using <command>bsdlabel -B</command> as described in <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/boot.html#boot-boot1"/>, the bootstrap will trash the <filename>vinum</filename> header, and <filename>vinum</filename> will no longer find its disk(s). Though no actual <filename>vinum</filename> configuration data or data in <filename>vinum</filename> volumes will be trashed, and it would be possible to recover all the data by entering exactly the same <filename>vinum</filename> configuration data again, the situation is hard to fix. It is necessary to move the entire <filename>vinum</filename> partition by at least 4 KB, in order to have the <filename>vinum</filename> header and the system bootstrap no longer collide.


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

Following checks are failing:
Unchanged translation: Spanish, Portuguese (Brazil)



The string uses three dots (...) instead of an ellipsis character (…)


Source information

Source string comment
(itstool) path: sect2/screen
no-wrap, read-only
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/vinum.pot, string 173