Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
You've pretty much already come to the right place.
At the top of the Linux Questions (LQ) web page in the right-hand column is a selection for Linux Forums. If you select that then scroll down a screen or two you'll see Linux Distributions; one of the sub-forums is Mint -- that would be the best place to post questions about Mint, including the problem you describe above which is kinda-sorta Mint-specific. The distribution-specif forums are useful because folks familiar with individual distributions typically look there first at questions being asked and you're liable to get good answers.
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.
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.
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.
Just a few links to aid you to gaining some knowledge & understanding;