GPART(8) | MidnightBSD System Manager's Manual | GPART(8) |
gpart
— control
utility for the disk partitioning GEOM class
gpart |
add -t
type [-a
alignment] [-b
start] [-s
size] [-i
index] [-l
label] [-f
flags] geom |
gpart |
backup geom |
gpart |
bootcode [-b
bootcode] [-p
partcode -i
index] [-f
flags] geom |
gpart |
commit geom |
gpart |
create -s
scheme [-n
entries] [-f
flags] provider |
gpart |
delete -i
index [-f
flags] geom |
gpart |
destroy [-F ]
[-f flags]
geom |
gpart |
modify -i
index [-l
label] [-t
type] [-f
flags] geom |
gpart |
recover [-f
flags] geom |
gpart |
resize -i
index [-a
alignment] [-s
size] [-f
flags] geom |
gpart |
restore [-lF ]
[-f flags]
provider [...] |
gpart |
set -a
attrib -i
index [-f
flags] geom |
gpart |
show [-l |
-r ] [-p ]
[geom ...] |
gpart |
undo geom |
gpart |
unset -a
attrib -i
index [-f
flags] geom |
gpart |
list |
gpart |
status |
gpart |
load |
gpart |
unload |
The gpart
utility is used to partition
GEOM providers, normally disks. The first argument is the action to be
taken:
add
-t
type. The partition's
location, size, and other attributes will be calculated automatically if
the corresponding options are not specified.
The add
command accepts these
options:
-a
alignmentgpart
utility tries to
align start offset and partition
size to be multiple of
alignment value.-b
start-f
flags-i
index-l
label-s
size-t
typebackup
restore
action.bootcode
-b
bootcode) or write bootstrap code into a partition
(using -p
partcode and
-i
index).
The bootcode
command accepts these
options:
-b
bootcode-b
bootcode option is
scheme-specific in nature (see the section entitled
BOOTSTRAPPING below). The
bootcode file must match the partitioning
scheme's requirements for file content and size.-f
flags-i
index-p
partcode.-p
partcode-i
index. The size of
the file must be smaller than the size of the partition.commit
-f
flags option so that they are not committed, but
become pending. Pending changes are reflected by the geom and the
gpart
utility, but they are not actually written
to disk. The commit
action will write all pending
changes to disk.create
-s
scheme option.
The create
command accepts these
options:
-f
flags-n
entries-s
schemedelete
-i
index
option. The partition cannot be actively used by the kernel.
The command accepts these options:
-f
flags-i
indexdestroy
The destroy
command accepts these
options:
-F
-f
flagsmodify
-i
index
option. Only the type and/or label of the partition can be modified. Not
all partitioning schemes support labels and it is invalid to try to change
a partition label in such cases.
The modify
command accepts these
options:
-f
flags-i
index-l
label-t
typerecover
The recover
command accepts these
options:
-f
flagsresize
-i
index
option. If the new size is not specified it is automatically calculated to
be the maximum available from geom.
The resize
command accepts these
options:
-a
alignmentgpart
utility tries to
align partition size to be a multiple of the
alignment value.-f
flags-i
index-s
sizerestore
backup
action and read from standard input. Only
the partition table is restored. This action does not affect the content
of partitions. After restoring the partition table and writing bootcode if
needed, user data must be restored from backup.
The restore
command accepts these
options:
-F
-f
flags-l
set
The set
command accepts these
options:
-a
attrib-f
flags-i
indexshow
gpart list
.
The show
command accepts these
options:
undo
commit
action and
can be used to undo any changes that have not been committed.unset
The unset
command accepts these
options:
-a
attrib-f
flags-i
indexlist
status
load
unload
Several partitioning schemes are supported by the
gpart
utility:
APM
GEOM_PART_APM
kernel option.BSD
GEOM_PART_BSD
kernel option.BSD64
GEOM_PART_BSD64
kernel option.LDM
GEOM_PART_LDM
kernel option.GPT
GEOM_PART_GPT
kernel option.MBR
GEOM_PART_MBR
kernel option. The
GEOM_PART_EBR
option adds support for the Extended
Boot Record (EBR), which is used to define a logical partition. The
GEOM_PART_EBR_COMPAT
option enables backward
compatibility for partition names in the EBR scheme. It also prevents any
type of actions on such partitions.VTOC8
GEOM_PART_VTOC8
kernel
option.See glabel(8) for additional information on labelization of devices and partitions.
Partition types are identified on disk by particular strings or
magic values. The gpart
utility uses symbolic names
for common partition types so the user does not need to know these values or
other details of the partitioning scheme in question. The
gpart
utility also allows the user to specify
scheme-specific partition types for partition types that do not have
symbolic names. Symbolic names currently understood and used by
FreeBSD are:
apple-boot
!171
" for MBR,
"!Apple_Bootstrap
" for APM, and
"!426f6f74-0000-11aa-aa11-00306543ecac
"
for GPT.bios-boot
!21686148-6449-6E6F-744E-656564454649
".efi
!239
" for MBR, and
"!c12a7328-f81f-11d2-ba4b-00a0c93ec93b
"
for GPT.freebsd
!165
" for
MBR, "!FreeBSD
" for APM, and
"!516e7cb4-6ecf-11d6-8ff8-00022d09712b
"
for GPT.freebsd-boot
!83bd6b9d-7f41-11dc-be0b-001560b84f0f
"
for GPT.freebsd-swap
!FreeBSD-swap
" for APM,
"!516e7cb5-6ecf-11d6-8ff8-00022d09712b
"
for GPT, and tag 0x0901 for VTOC8.freebsd-ufs
!FreeBSD-UFS
" for APM,
"!516e7cb6-6ecf-11d6-8ff8-00022d09712b
"
for GPT, and tag 0x0902 for VTOC8.freebsd-vinum
!FreeBSD-Vinum
" for APM,
"!516e7cb8-6ecf-11d6-8ff8-00022d09712b
"
for GPT, and tag 0x0903 for VTOC8.freebsd-zfs
!FreeBSD-ZFS
" for APM,
"!516e7cba-6ecf-11d6-8ff8-00022d09712b
"
for GPT, and 0x0904 for VTOC8.Other symbolic names that can be used with
gpart
utility are:
apple-apfs
apple-core-storage
!53746f72-6167-11aa-aa11-00306543ecac
"
for GPT.apple-hfs
!175
" for
MBR, "!Apple_HFS
" for APM and
"!48465300-0000-11aa-aa11-00306543ecac
"
for GPT.apple-label
!4c616265-6c00-11aa-aa11-00306543ecac
"
for GPT.apple-raid
!52414944-0000-11aa-aa11-00306543ecac
"
for GPT.apple-raid-offline
!52414944-5f4f-11aa-aa11-00306543ecac
"
for GPT.apple-tv-recovery
!5265636f-7665-11aa-aa11-00306543ecac
"
for GPT.apple-ufs
!168
" for
MBR, "!Apple_UNIX_SVR2
" for APM and
"!55465300-0000-11aa-aa11-00306543ecac
"
for GPT.dragonfly-label32
!9d087404-1ca5-11dc-8817-01301bb8a9f5
"
for GPT.dragonfly-label64
!3d48ce54-1d16-11dc-8696-01301bb8a9f5
"
for GPT.dragonfly-legacy
!bd215ab2-1d16-11dc-8696-01301bb8a9f5
"
for GPT.dragonfly-ccd
!dbd5211b-1ca5-11dc-8817-01301bb8a9f5
"
for GPT.dragonfly-hammer
!61dc63ac-6e38-11dc-8513-01301bb8a9f5
"
for GPT.dragonfly-hammer2
!5cbb9ad1-862d-11dc-a94d-01301bb8a9f5
"
for GPT.dragonfly-swap
!9d58fdbd-1ca5-11dc-8817-01301bb8a9f5
"
for GPT.dragonfly-ufs
!9d94ce7c-1ca5-11dc-8817-01301bb8a9f5
"
for GPT.dragonfly-vinum
!9dd4478f-1ca5-11dc-8817-01301bb8a9f5
"
for GPT.ebr
!5
" for MBR.fat16
!6
" for MBR.fat32
!11
" for MBR.fat32lba
!12
" for MBR.linux-data
!131
" for MBR
and
"!0fc63daf-8483-4772-8e79-3d69d8477de4
"
for GPT.linux-lvm
!142
" for MBR and
"!e6d6d379-f507-44c2-a23c-238f2a3df928
"
for GPT.linux-raid
!253
" for MBR
and
"!a19d880f-05fc-4d3b-a006-743f0f84911e
"
for GPT.linux-swap
!130
" for MBR and
"!0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
"
for GPT.mbr
!024dee41-33e7-11d3-9d69-0008c781f39f
"
by GPT.ms-basic-data
fat16
, fat32
and
ntfs
in MBR. The scheme-specific type is
"!ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
"
for GPT.ms-ldm-data
!66
" for MBR,
"!af9b60a0-1431-4f62-bc68-3311714a69ad
"
for GPT.ms-ldm-metadata
!5808c8aa-7e8f-42e0-85d2-e1e90434cfb3
"
for GPT.netbsd-ccd
!2db519c4-b10f-11dc-b99b-0019d1879648
"
for GPT.netbsd-cgd
!2db519ec-b10f-11dc-b99b-0019d1879648
"
for GPT.netbsd-ffs
!49f48d5a-b10e-11dc-b99b-0019d1879648
"
for GPT.netbsd-lfs
!49f48d82-b10e-11dc-b99b-0019d1879648
"
for GPT.netbsd-raid
!49f48daa-b10e-11dc-b99b-0019d1879648
"
for GPT.netbsd-swap
!49f48d32-b10e-11dc-b99b-0019d1879648
"
for GPT.ntfs
!7
" for MBR.prep-boot
!65
" for MBR and
"!0x9e1a2d38-c612-4316-aa26-8b49521e5a8b
"
for GPT.vmware-vmfs
!251
" for MBR and
"!aa31e02a-400f-11db-9590-000c2911d1b8
"
for GPT.vmware-vmkdiag
!252
" for MBR
and
"!9d275380-40ad-11db-bf97-000c2911d1b8
"
for GPT.vmware-reserved
!9198effc-31c0-11db-8f-78-000c2911d1b8
"
for GPT.vmware-vsanhdr
!381cfccc-7288-11e0-92ee-000c2911d0b2
"
for GPT.The scheme-specific attributes for EBR:
The scheme-specific attributes for GPT:
bootme
gptboot
stage 1 boot loader will try
to boot the system from this partition. Multiple partitions can be marked
with the bootme
attribute. See
gptboot(8) for more
details.bootonce
bootme
attribute. When set, the
gptboot
stage 1 boot loader will try to boot the
system from this partition only once. Multiple partitions can be marked
with the bootonce
and
bootme
attribute pairs. See
gptboot(8) for more
details.bootfailed
gptboot
stage 1 boot loader and the
/etc/rc.d/gptboot start-up script. See
gptboot(8) for more
details.lenovofix
The scheme-specific attributes for MBR:
FreeBSD supports several partitioning schemes and each scheme uses different bootstrap code. The bootstrap code is located in a specific disk area for each partitioning scheme, and may vary in size for different schemes.
Bootstrap code can be separated into two types. The first type is
embedded in the partitioning scheme's metadata, while the second type is
located on a specific partition. Embedding bootstrap code should only be
done with the gpart bootcode
command with the
-b
bootcode option. The GEOM
PART class knows how to safely embed bootstrap code into specific
partitioning scheme metadata without causing any damage.
The Master Boot Record (MBR) uses a 512-byte bootstrap code image,
embedded into the partition table's metadata area. There are two variants of
this bootstrap code: /boot/mbr and
/boot/boot0. /boot/mbr
searches for a partition with the active
attribute
(see the ATTRIBUTES section) in the
partition table. Then it runs next bootstrap stage. The
/boot/boot0 image contains a boot manager with some
additional interactive functions for multi-booting from a user-selected
partition.
A BSD disklabel is usually created inside an MBR partition (slice)
with type freebsd
(see the
PARTITION TYPES section). It uses
8 KB size bootstrap code image /boot/boot, embedded
into the partition table's metadata area.
Both types of bootstrap code are used to boot from the GUID
Partition Table. First, a protective MBR is embedded into the first disk
sector from the /boot/pmbr image. It searches
through the GPT for a freebsd-boot
partition (see
the PARTITION TYPES section) and
runs the next bootstrap stage from it. The
freebsd-boot
partition should be smaller than 545
KB. It can be located either before or after other
FreeBSD partitions on the disk. There are two
variants of bootstrap code to write to this partition:
/boot/gptboot and
/boot/gptzfsboot.
/boot/gptboot is used to boot from UFS
partitions. gptboot
searches through
freebsd-ufs
partitions in the GPT and selects one to
boot based on the bootonce
and
bootme
attributes. If neither attribute is found,
/boot/gptboot boots from the first
freebsd-ufs
partition.
/boot/loader (the third bootstrap stage) is loaded
from the first partition that matches these conditions. See
gptboot(8) for more
information.
/boot/gptzfsboot is used to boot from ZFS.
It searches through the GPT for freebsd-zfs
partitions, trying to detect ZFS pools. After all pools are detected,
/boot/loader is started from the first one found set
as bootable.
The VTOC8 scheme does not support embedding bootstrap code.
Instead, the 8 KBytes bootstrap code image
/boot/boot1 should be written with the
gpart bootcode
command with the
-p
bootcode option to all
sufficiently large VTOC8 partitions. To do this the
-i
index option could be
omitted.
The APM scheme also does not support embedding bootstrap code.
Instead, the 800 KBytes bootstrap code image
/boot/boot1.hfs should be written with the
gpart bootcode
command to a partition of type
apple-boot
, which should also be 800 KB in size.
Actions other than the commit
and
undo
actions take an optional
-f
flags option. This option
is used to specify action-specific operational flags. By default, the
gpart
utility defines the
‘C
’ flag so that the action is
immediately committed. The user can specify
“-f
x
” to have
the action result in a pending change that can later, with other pending
changes, be committed as a single compound change with the
commit
action or reverted with the
undo
action.
The GEOM PART class supports recovering of partition tables only
for GPT. The GPT primary metadata is stored at the beginning of the device.
For redundancy, a secondary (backup) copy of the metadata is stored at the
end of the device. As a result of having two copies, some corruption of
metadata is not fatal to the working of GPT. When the kernel detects corrupt
metadata, it marks this table as corrupt and reports the problem.
destroy
and recover
are the
only operations allowed on corrupt tables.
If one GPT header appears to be corrupt but the other copy remains intact, the kernel will log the following:
GEOM: provider: the primary GPT table is corrupt or invalid. GEOM: provider: using the secondary instead -- recovery strongly advised.
or
GEOM: provider: the secondary GPT table is corrupt or invalid. GEOM: provider: using the primary only -- recovery suggested.
Also gpart
commands such as
show
, status
and
list
will report about corrupt tables.
If the size of the device has changed (e.g., volume expansion) the secondary GPT header will no longer be located in the last sector. This is not a metadata corruption, but it is dangerous because any corruption of the primary GPT will lead to loss of the partition table. This problem is reported by the kernel with the message:
GEOM: provider: the secondary GPT header is not in the last LBA.
This situation can be recovered with the
recover
command. This command reconstructs the
corrupt metadata using known valid metadata and relocates the secondary GPT
to the end of the device.
NOTE: The GEOM PART class can detect the same partition table visible through different GEOM providers, and some of them will be marked as corrupt. Be careful when choosing a provider for recovery. If you choose incorrectly you can destroy the metadata of another GEOM class, e.g., GEOM MIRROR or GEOM LABEL.
The following
sysctl(8) variables can
be used to control the behavior of the PART
GEOM
class. The default value is shown next to each variable.
gpart
GEOM class. When this variable is enable and
new size of provider is detected, the schema metadata is resized but all
changes are not saved to disk, until gpart commit
is run to confirm changes. This behavior is also reported with diagnostic
message: GEOM_PART: (provider) was automatically
resized. Use
`gpart commit (provider)` to save changes or `gpart undo
(provider)`
to revert
them.PART
GEOM class
verifies all generic partition parameters obtained from the disk metadata.
If some inconsistency is detected, the partition table will be rejected
with a diagnostic message: GEOM_PART: Integrity check failed
(provider, scheme).ms-ldm-data
(see the
PARTITION TYPES section). If
this variable set to 1 each component of the mirrored volume will be
present as independent partition. NOTE: This may break a
mirrored volume and lead to data damage.Exit status is 0 on success, and 1 if the command fails.
The examples below assume that the disk's logical block size is 512 bytes, regardless of its physical block size.
In this example, we will format ada0 with the GPT scheme and create boot, swap and root partitions. First, we need to create the partition table:
/sbin/gpart create -s GPT ada0
Next, we install a protective MBR with the first-stage bootstrap code. The protective MBR lists a single, bootable partition spanning the entire disk, thus allowing non-GPT-aware BIOSes to boot from the disk and preventing tools which do not understand the GPT scheme from considering the disk to be unformatted.
/sbin/gpart bootcode -b /boot/pmbr ada0
We then create a dedicated freebsd-boot
partition to hold the second-stage boot loader, which will load the
FreeBSD kernel and modules from a UFS or ZFS
filesystem. This partition must be larger than the bootstrap code (either
/boot/gptboot for UFS or
/boot/gptzfsboot for ZFS), but smaller than 545 kB
since the first-stage loader will load the entire partition into memory
during boot, regardless of how much data it actually contains. We create a
472-block (236 kB) boot partition at offset 40, which is the size of the
partition table (34 blocks or 17 kB) rounded up to the nearest 4 kB
boundary.
/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0 /sbin/gpart bootcode -p /boot/gptboot -i 1 ada0
We now create a 4 GB swap partition at the first available offset, which is 40 + 472 = 512 blocks (256 kB).
/sbin/gpart add -s 4G -t freebsd-swap ada0
Aligning the swap partition and all subsequent partitions on a 256 kB boundary ensures optimal performance on a wide range of media, from plain old disks with 512-byte blocks, through modern “advanced format” disks with 4096-byte physical blocks, to RAID volumes with stripe sizes of up to 256 kB.
Finally, we create and format an 8 GB
freebsd-ufs
partition for the root filesystem,
leaving the rest of the slice free for additional filesystems:
/sbin/gpart add -s 8G -t freebsd-ufs ada0 /sbin/newfs -Uj /dev/ada0p3
In this example, we will format ada0 with the MBR scheme and create a single partition which we subdivide using a traditional BSD disklabel.
First, we create the partition table and a single 64 GB partition, then we mark that partition active (bootable) and install the first-stage boot loader:
/sbin/gpart create -s MBR ada0 /sbin/gpart add -t freebsd -s 64G ada0 /sbin/gpart set -a active -i 1 ada0 /sbin/gpart bootcode -b /boot/boot0 ada0
Next, we create a disklabel in that partition (“slice” in disklabel terminology) with room for up to 20 partitions:
/sbin/gpart create -s BSD -n 20 ada0s1
We then create an 8 GB root partition and a 4 GB swap partition:
/sbin/gpart add -t freebsd-ufs -s 8G ada0s1 /sbin/gpart add -t freebsd-swap -s 4G ada0s1
Finally, we install the appropriate boot loader for the BSD label:
/sbin/gpart bootcode -b /boot/boot ada0s1
Create a VTOC8 scheme on da0:
/sbin/gpart create -s VTOC8 da0
Create a 512MB-sized freebsd-ufs
partition
to contain a UFS filesystem from which the system can boot.
/sbin/gpart add -s 512M -t freebsd-ufs da0
Create a 15GB-sized freebsd-ufs
partition
to contain a UFS filesystem and aligned on 4KB boundaries:
/sbin/gpart add -s 15G -t freebsd-ufs -a 4k da0
After creating all required partitions, embed bootstrap code into them:
/sbin/gpart bootcode -p /boot/boot1 da0
If a
Device
busy error is shown when trying to destroy a partition table,
remember that all of the partitions must be deleted first with the
delete
action. In this example,
da0 has three partitions:
/sbin/gpart delete -i 3 da0 /sbin/gpart delete -i 2 da0 /sbin/gpart delete -i 1 da0 /sbin/gpart destroy da0
Rather than deleting each partition and then destroying the
partitioning scheme, the -F
option can be given with
destroy
to delete all of the partitions before
destroying the partitioning scheme. This is equivalent to the previous
example:
/sbin/gpart destroy -F da0
Create a backup of the partition table from da0:
/sbin/gpart backup da0 > da0.backup
Restore the partition table from the backup to da0:
/sbin/gpart restore -l da0 < /mnt/da0.backup
Clone the partition table from ada0 to ada1 and ada2:
/sbin/gpart backup ada0 | /sbin/gpart restore -F ada1 ada2
The gpart
utility appeared in
FreeBSD 7.0.
Marcel Moolenaar <marcel@FreeBSD.org>
September 3, 2019 | midnightbsd-3.1 |