That link you posted looks like a very ugly hack type solution.
However, according to the man page, gdisk, which is used to convert MBR -> GPT, also has an option in the "recovery & transformation" menu (press r to get that) to convert GPT -> MBR; the g key will:
Convert GPT into MBR and exit. This option converts as many partitions
In current versions of parted, resizepart should work for the partition (parted understands 100% or things like -1s, the latter also needs -- to stop parsing options on the cmdline). To determine the exact value you can use unit s, print free. resize2fs comes afterwards for the filesystem.
Old versions of parted had a resize command that would resize both ...
Use fdisk for drives that are < 2TB and either parted or gdisk for disk > 2TB. The actual difference has to do with the partitioning formats that these tools are manipulating.
For disks < 2TB you're often using MBR (Master Boot Record). For disks > 2TB you're using GPT (GUID Partitioning Table). Here's a good article that covers the differences as ...
Being unable to properly script parted (it asked for confirmation because the partition was mounted and contrary to other answers I found did not understand -1s or 100%), I just found the growpart tool which does exactly this.
Usage is simple: growpart /dev/sda 3 (and then resize2fs /dev/sda3, or another appropriate command for the used filesystem type).
It's correct in principle but you might consider reducing it to a single parted call.
parted --script /device \
mklabel gpt \
mkpart primary 1MiB 100MiB \
mkpart primary 100MiB 200MiB \
Your alignment issue is probably because you use MB instead of MiB. You should not need an actual align-check command when creating partitions on MiB ...
Most of the previous respondents are correct when they say that you can usually do what you need with a GPT partition table layout, but since there are valid reasons for wanting to use MBR, I think I will just answer your question instead of assuming you are wrong for asking.
To get rid of the GPT, you need to remember that with this format, there is a ...
The primary reason to use gparted or parted is if the new disk is bigger than 2TB. But you probably will not be able to effectively set that up from a 32 bit system.
If you want to run the new disk from your old system. Stay with a disk smaller than 2TB. You should be able to partition, format and run that from you old computer using fdisk for partitioning.
I use fdisk. before to apply this I recommend to work with a live CD or USB and back up your data.
First check if any bootable partition is present like in my system wich "/dev/sda1" is the bootable partition :
fdisk -l /dev/sda
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track,...
If you don't want to fiddle with dd, gdisk can do:
$ sudo gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
BSD: not present
APM: not present
Found valid GPT with protective MBR; using GPT.
Command (? for help): ?
b back up GPT data to a file
w write table to disk and exit
x extra ...
There’s probably a more specific duplicate somewhere, but I can’t find it.
The reason df isn’t showing any extra space is that it measures the free space inside the file system; it doesn’t care about partitions, logical volumes etc. So far, you’ve resized the disk and the partition; you also need to resize the file system:
sudo resize2fs /dev/sda1
The extended and logical partitions make sense only with msdos partition table. It's only purpose is to allow you to have more than 4 partitions. With GPT, there are only 'primary' partitions and their number is usually limited to 128 (however, in theory there is no upper limit implied by the disklabel format). Note that on GPT none of the partitions could ...
Number Start End Size File system
468GB 520GB 52.4GB Free Space
Well, as you can see Start is 468GB and End is 520GB. Now, parted defaults to MB so you'll have to specify the unit:
unit GB mkpart primary ntfs 468 520
or append unit suffix to the start/end numbers:
mkpart primary ext2 468GB ...
The space reserved before is known as partition alignment; 1MiB is reserved by default by parted.
It is reserved usually for performance reasons, either in physical media or in VMs.
see Partition Alignment
Partition alignment is understood to mean the proper alignment of partitions to the reasonable boundaries of a data storage device (such as a hard ...
I think parted only accepts absolutes, not x+y.
You could do it like this: (+ interpreted by shell)
# parted /dev/loop0 unit mib mkpart primary $start $(($start+$size))
# parted /dev/loop0 unit mib print free
Model: Loopback device (loopback)
Disk /dev/loop0: 1000MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Use gdisk /dev/sda
Note: /dev/sda is in the case of the person who asked this question but change it to your drive name.
Once you are inside with gdisk use:
x extra functionality (experts only)
then when you type p to see all the options, you will see this:
Expert command (? for help): ?
a set attributes
c change partition GUID
d display the ...
Use the command kpartx to create a loopback device that can then be formatted.
kpartx -a /path/to/imagefile.img # Presents partitions from the image file
mkfs.vfat /dev/mapper/loop0p1 # Format partition 1
mkfs.ext3 /dev/mapper/loop0p2 # Format partition 2
kpartx -d /path/to/imagefile.img # Unmaps the partitions from the image file
Related kpartx ...
Try to align to eMMC erasure block size. It usually equals 0.5, 1, 2, 4, 8 MiB depending on eMMC datasheet. If you find block size alignment too much memory wasting, then stick to the page size, generally found in the range of 4..16 KiB.
Try to make partition sizes and borders a multiple of erasure block size, so when file system writes to the first or last ...
To create an image with multiple partitions, a solution that doesn't require any fancy tools or root access is to first create the filesystems, then concatenate them.
truncate -s $IMAGE_ROOTFS_ALIGNMENT disk
truncate -s $BOOT_SPACE_ALIGNED part1
cat part1 >>disk
truncate -s $ROOTFS_SIZE part2
cat part2 >>disk
That message is normal, if your (virtual) disk magically became larger.
GPT partition table is both at the start and at the end of the disk. It's supposed to make it more resilient against failure.
When you "fix" this issue it will simply re-write the GPT backup header at the new end of your disk. This does not affect existing partitions in any way at all, ...
The real limitation is that the fdisk tool in the util-linux package doesn't support GPT-type partition tables, which you can find on any disk. However, they're commonly found on disks greater than 2 GiB, because the old MBR-type partition tables don't support sizes that large.
The easiest fix is, as the error suggested, to just use the GNU Parted software ...
For some reason your kernel fails to read the partition table:
[ 8775.030291] end_request: I/O error, dev sdb, sector 0
[ 8775.030300] quiet_error: 30 callbacks suppressed
[ 8775.030306] Buffer I/O error on device sdb, logical block 0
[ 8775.033781] ldm_validate_partition_table(): Disk read failed.
Thus, it can't create devices for partitions as it did ...
I ran into issues when I attempted to use the other answer. What worked for me was to use the percentages approach like this instead:
$ parted /dev/sdf --script -- mkpart primary 0% 100%
There's an issue with parted and the way that it deals with the alignment of the partitions. These 2 articles discuss the issue a bit:
Red Hat Enterprise Linux 6 - ...
Parted prompts and goes into an interactive mode when you do not provide enough information to create the partition with the command. The following will create a partition that spans the entire disk and will not prompt for filesystem type:
mkpart primary 1 -1
In my experience fdisk is more powerful (especially in the advanced mode), but it can leave your disk in a somewhat weird state.
For example fdisk will allow your partitions to lie out of order unless you specifically tell it to reorder them, most other tools (and unless i'm very mistaken parted is one of them) will make assumptions that you want everything ...
If resizepart does not work, you might have to resort to rm and mkpart to achieve the same thing.
Of course, this would require you to parse the partition table first in order to determine partition type and start offset. Unless you already know the necessary values. After all you had to get the 166016512B from somewhere too.
parted has the --machine ...