||01-06-2013 09:22 AM
Welcome to LQ!
has several useful Linux guides to help you.
is more than just Slackware links. Very good resource to help you through a Linux journey.
Be sure to look at LQ menu(s); Tutorials
and utilize Search
here at LQ since most of your questions probably have been answered.
You can use 'man command' to learn the usage. Plus details are very important. You can always learn more by following 'See also' at the end of the 'man pages'. :)
excerpt 'man gdisk';
gdisk - Interactive GUID partition table (GPT) manipulator
gdisk [ -l ] device
GPT fdisk (aka gdisk) is a text-mode menu-driven program for creation and manipulation of partition tables. It will automatically convert an old-style
Master Boot Record (MBR) partition table or BSD disklabel stored without an MBR carrier partition to the newer Globally Unique Identifier (GUID) Parti-
tion Table (GPT) format, or will load a GUID partition table. When used with the -l command-line option, the program displays the current partition ta-
ble and then exits.
GPT fdisk operates mainly on the GPT headers and partition tables; however, it can and will generate a fresh protective MBR, when required. (Any boot
loader code in the protective MBR will not be disturbed.) If you've created an unusual protective MBR, such as a hybrid MBR created by gptsync or
gdisk's own hybrid MBR creation feature, this should not be disturbed by most ordinary actions. Some advanced data recovery options require you to
understand the distinctions between the main and backup data, as well as between the GPT headers and the partition tables. For information on MBR vs.
GPT, as well as GPT terminology and structure, see the extended gdisk documentation at http://www.rodsbooks.com/gdisk/ or consult Wikipedia.
The gdisk program employs a user interface similar to that of Linux's fdisk, but gdisk modifies GPT partitions. It also has the capability of trans-
forming MBR partitions or BSD disklabels into GPT partitions. Like the original fdisk program, gdisk does not modify disk structures until you explic-
itly write them to disk, so if you make a mistake, you can exit from the program with the 'q' option to leave your partitions unmodified.
Ordinarily, gdisk operates on disk device files, such as /dev/sda or /dev/hda under Linux, /dev/disk0 under Mac OS X, or /dev/ad0 or /dev/da0 under
FreeBSD. The program can also operate on disk image files, which can be either copies of whole disks (made with dd, for instance) or raw disk images
used by emulators such as QEMU or VMWare. Note that only raw disk images are supported; gdisk cannot work on compressed or other advanced disk image
The MBR partitioning system uses a combination of cylinder/head/sector (CHS) addressing and logical block addressing (LBA). The former is klunky and
limiting. GPT drops CHS addressing and uses 64-bit LBA mode exclusively. Thus, GPT data structures, and therefore gdisk, do not need to deal with CHS
geometries and all the problems they create. Users of fdisk will note that gdisk lacks the options and limitations associated with CHS geometries.
For best results, you should use an OS-specific partition table program whenever possible. For example, you should make Mac OS X partitions with the
Mac OS X Disk Utility program and Linux partitions with the Linux gdisk or GNU Parted program.
Upon start, gdisk attempts to identify the partition type in use on the disk. If it finds valid GPT data, gdisk will use it. If gdisk finds a valid MBR
or BSD disklabel but no GPT data, it will attempt to convert the MBR or disklabel into GPT form. (BSD disklabels are likely to have unusable first
and/or final partitions because they overlap with the GPT data structures, though.) GPT fdisk can identify, but not use data in, Apple Partition Map
(APM) disks, which are used on 680x0- and PowerPC-based Macintoshes. Upon exiting with the 'w' option, gdisk replaces the MBR or disklabel with a GPT.
This action is potentially dangerous! Your system may become unbootable, and partition type codes may become corrupted if the disk uses unrecognized
type codes. Boot problems are particularly likely if you're multi-booting with any GPT-unaware OS. If you mistakenly launch gdisk on an MBR disk, you
can safely exit the program without making any changes by using the 'q' option.
The MBR-to-GPT conversion will leave at least one gap in the partition numbering if the original MBR used logical partitions. These gaps are harmless,
but you can eliminate them by using the 's' option, if you like. (Doing this may require you to update your /etc/fstab file.)
When creating a fresh partition table, certain considerations may be in order:
* For data (non-boot) disks, and for boot disks used on BIOS-based computers with GRUB as the boot loader, partitions may be created in whatever
order and in whatever sizes are desired.
* Boot disks for EFI-based systems require an EFI System Partition (gdisk internal code 0xEF00) formatted as FAT-32. The recommended size of this
partition is between 100 and 300 MiB. Boot-related files are stored here. (Note that GNU Parted identifies such partitions as having the "boot flag" set.)
* Some boot loaders for BIOS-based systems make use of a BIOS Boot Partition (gdisk internal code 0xEF02), in which the secondary boot loader is
stored, possibly without the benefit of a filesystem. (GRUB2 may optionally use such a partition.) This partition can typically be quite small
(roughly 32 to 200 KiB), but you should consult your boot loader documentation for details.
* If Windows is to boot from a GPT disk, a partition of type Microsoft Reserved (gdisk internal code 0x0C01) is recommended. This partition should
be about 128 MiB in size. It ordinarily follows the EFI System Partition and immediately precedes the Windows data partitions. (Note that old
versions of GNU Parted create all FAT partitions as this type, which actually makes the partition unusable for normal file storage in both Win-
dows and Mac OS X.)
* Some OSes' GPT utilities create some blank space (typically 128 MiB) after each partition. The intent is to enable future disk utilities to use
this space. Such free space is not required of GPT disks, but creating it may help in future disk maintenance. You can use GPT fdisk's relative
partition positioning option (specifying the starting sector as '+128M', for instance) to simplify creating such gaps.
excerpt 'man libblkid';
libblkid - block device identification library
cc file.c -lblkid
The libblkid library is used to identify block devices (disks) as to their content (e.g. filesystem type) as well as extracting additional information
such as filesystem labels/volume names, unique identifiers/serial numbers. A common use is to allow use of LABEL= and UUID= tags instead of hard-cod-
ing specific block device names into configuration files.
The low-level part of the library also allows to extract infomation about partitions and block device topology.
The high-level part of the library keeps information about block devices in a cache file and is verified to still be valid before being returned to the
user (if the user has read permission on the raw block device, otherwise not). The cache file also allows unprivileged users (normally anyone other
than root, or those not in the "disk" group) to locate devices by label/id. The standard location of the cache file can be overridden by the environ-
ment variable BLKID_FILE.
In situations where one is getting information about a single known device, it does not impact performance whether the cache is used or not (unless you
are not able to read the block device directly).
The high-level part of the library supports two methods to evaluate LABEL/UUID. It reads information directly from a block device or read information
from /dev/disk/by-* udev symlinks. The udev is preferred method by default.
If you are dealing with multiple devices, use of the cache is highly recommended (even if empty) as devices will be scanned at most one time and the
on-disk cache will be updated if possible.
In some cases (modular kernels), block devices are not even visible until after they are accessed the first time, so it is critical that there is some
way to locate these devices without enumerating only visible devices, so the use of the cache file is required in this situation.
The standard location of the /etc/blkid.conf config file can be overridden by the environment variable BLKID_CONF. For more details about the config
file see blkid(8) man page.
except 'man blkid';
blkid - locate/print block device attributes
blkid -L label | -U uuid
blkid [-dghlv] [-c file] [-o format]
[-s tag] [-t NAME=value] [device ...]
blkid -p [-O offset] [-S size] [-o format] [-s tag]
[-n list] [-u list] device ...
blkid -i [-o format] [-s tag] device ...
The blkid program is the command-line interface to working with the libblkid(3) library. It can determine the type of content (e.g. filesystem or
swap) that a block device holds, and also attributes (tokens, NAME=value pairs) from the content metadata (e.g. LABEL or UUID fields).
blkid has two main forms of operation: either searching for a device with a specific NAME=value pair, or displaying NAME=value pairs for one or more
'man command' is your friend learn to use it. :)
Two very useful quotes;
"Knowledge is of two kinds. We Know a subject ourselves, or we know where we can find information upon it."- Samuel Johnson
"You must look into people as well as at them."-Chesterfield
Learn by investigating & doing! Dig!