posted on 2016-11-18 18:54
These are some rough notes for colleague of mine, on how to make more swapspace available and resizing partitions in general. The workflow highly depends on the previously existing layout. Here's a shot on a manual on how to approach this.
This is mostly written from memory, so bear with me if you stumble upon errors. No guarantees for nothing below this line.
In case you need to resize a partition, as you do not have unpartitioned space available, you cannot enlarge the swap partition or add a second one, if you cannot shrink the filesystem (i know that's the case with XFS) on the partition which you want to shrink. Shrinking partitions is more like deleting the currently available partition and recreating it, only smaller. (Linux lets you do that, even if you make the partition smaller then the filesystem that should be in there, rendering the system unbootable in case you do this. Don't worry, it can be fixed by recreating the old partition schema, so you better backup the information good.)
If the stuff above is the case, you need to create a swapfile and use that. Of course you need enough free space on the filesystem.
There should not be a speed difference from what I heard (and honestly I am too lazy to test that), if you have enough free space in your filesystem, create the file with
mkswap it and fix
Enough tutorials are on google, this approach is the easiest, hands down.
But let's go on.
Also UEFI needs a bios boot partition. Basically:
espflags (sometimes also called
bios boot partition)
/boot/efiin your linux installation
The rest is as usual, like you can have a separate boot partition housing the
/boot mountpoint, or just using another large partition for
/ and everything else directly.
That's also the reason why you might have
/dev/sda5 after a fresh install.
The MBR is located on the first sector of a harddisk and 512k in size. During the boot process the executed boot code from the BIOS scans all disk in hope of finding a MBR or GPT. Due to the MBR's structure it can only store the information for four partition entries. Information for partitions of type 'primary' is stored directly in the MBR. Partitions cannot be larger then 2t, if you need that you either have to use a GPT instead or build a logical volume via LVM out of several MBR partitions. (Ok, in that case go for GPT...)
An extended partition points to another partitioning table in a VBR. That's like a MBR, but without boot code and located in the first sector of a partition depicted in the MBR.
You can delete the partitions as you please, and it's autmatically backupped to the end of the disk. Its 33 logical blocks in size (like 33 * 512b or 33 * 4k in disk size, depending on block size), and uses the first 33 and the last 33 blocks of the disk. (In comparison to the MBR, which uses only the first block on a disk.)
Maximum size are about 8 zebibytes or 9 zettabytes, which should do rather fine for the storage needs you have with five nines of probability.
Keep that in mind when you want to use a sofware raid and the raid superblock shall be stored at the end of the disk, depending on the version of the software raid metadata.
Resizing partitions is more or less just deleting a partition and recreating it with a different size. This can fail, rendering the system unbootable when the partition is smaller then the filesystem it shall contain. This can be fixed by deleting the partitioning info for the partition in question, and recreating it bigger again.
Nothing is destroyed here, unless you start recreating filesystems on your newly created partitions, keep that in mind prior to panicking.
Partition info's are just pointers to start and end of a partition, so the kernel knows where to look for filesystems relative to its start.
Also the absolute sizes are important. Best in sectors, bytes do work, too.
Copy the output of the commands below into a text editor and save it somewhere (when working over
ssh) or use your smartphone camera to make a picture.
Of course pen and paper work, too, but don't do anything without this information backed up. SERIOUSLY!
These will give the partition boundaries in sectors or bytes. I prefer sectors.
parted /dev/sdX u s p
parted /dev/sdX u b p
Don't read on unless you did this.
If you still do and fuck up, you can try
testdisk, but this will not work with more complex setups.
From my experience,
testdisk only works with like a 60% chance.
You can only use continuous space for creating new partitions.
I.e. if you have like a 1g swap partition which you want to enlarge, followed by a 100g root partition, you can shrink the root partition, but the new unallocated space will be located at the end of the disk.
If you cannot do that, you need to use LVM.
This would be the work without LVM being used:
resize2fs. Either to a particular size, or with the
-mflag to the minimum size. This may take time.
/etc/fstab, else no boot for you.
In case you have LVM in use:
Remember, if your system does not boot because you made partition(s) or logical volume(s) too small, that is fixable. But only as long as you did not kill any data on disk, i.e. by creating file systems.
pvresize /dev/sdXywill use all available space.)
lvextend -l +100%FREE /dev/mapper/<vg-lv-name>is what you want to use all available space.)
resize2fs /path/to/device, so either
/dev/sdXywithout lvm, or
/dev/mapper/<vg-lv-name>, to use all available space.)
For editing partitions
parted does work quite good, both for MBR/GPT partition tables.
gdisk also still do exist, if you want something with a fancy curses gui go with
Also there are are
sgdisk for the hacker types, according to the manpage.
parted commands cause immediate changes, whereas the others let you view your changes, but won't change anything until you write the changes to disk.
I really prefer using
parted non-interactively nowadays, though I cannot explain why.
All commands in as short as possible:
# show help parted /dev/sdX h # show help on particular command, may help greatly parted /dev/sda h <parted_command> # drop partition info parted /dev/sdX u s p # "unit sector print" parted /dev/sdX u s p free # "unit sector print free" parted /dev/sdX u b p # "unit byte print" # create new disklabel, read: MBR or GPT. # if you do this you basically delete the complete partitioning table # do only if you need to, and backupped the 'print' output above! parted /dev/sdX mkl msdos ## create MBR parted /dev/sdX mkl gpt ## create GPT # delete partition parted /dev/sdX rm <ID> # 1 or 2 or 3, depending which partition you want to edit # create partition # -a opt can be used with all commands listed here, but only has impact here # units can be mixedly used, like 2048s, 10GiB, 10GB, 100% parted -a opt /dev/sdX mkp # mkpart, -a opt is essential for optimal alignment! # show options parted /dev/sdX h set # enable/disable options (like boot flag) parted /dev/sdX set <ID> <OPTION> on # enable parted /dev/sdX set <ID> <OPTION> off # disable
If you can still boot, and have a shiny new partition (or logical volume) which you can use, finish:
/etc/fstab, i.e. create an entry so the system knows about the swapspace
This should be everything one may encounter. Good luck.
posted on 2016-06-11 10:38
fter resizing the the virtual harddisk of your virtual machine, several other steps are needed so you can utilize this additional space within the VM. This will only talk about increased sizing, which will usually just work. Unlike with downsizing, which are the same steps just in reverse order, but where you can easily kill your currently still running system. Handle downsizing with very, very much care.
This guide assumes you have a single partition, which is used by LVM, where in you have your filesystem(s) in different logical volumes.
I have a vm with hostname called 'test', which has a single disk (
/dev/vda), with a single partition (
/dev/vda1), which is used by lvm.
LVM volume groups are usually called like the hostname (best approach I know of, so here
test), and the logical volumes what they are used for (
swap), or where they are mounted (i.e.
var_lib_vz, not shown here).
root uses ext4 as file system.
Initially the disk size was 50G and was increased to 500G.
After the disk size was increased, you can see the available space on the device:
root@test:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 253:0 0 500G 0 disk +-vda1 253:1 0 50G 0 part +-test-root 252:0 0 14.3G 0 lvm / +-test-swap 252:1 0 976M 0 lvm [SWAP]
Use a partition manager of your choice (
cfdisk for disks with an MBR,
cgdisk for disks using a GPT, or
parted if you know what you are doing.), delete your partition.
Recreate it with the maximum size, reboot.
Then it should look like this, with adjusted partition size:
root@test:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 253:0 0 500G 0 disk +-vda1 253:1 0 500G 0 part +-test-root 252:0 0 49G 0 lvm / +-test-swap 252:1 0 976M 0 lvm [SWAP]
First make LVM format the addition free space: (It will 'partition' it so it can work with it, effectively splitting it into junks of like 4MB if I recall correctly.)
root@test:~# pvresize /dev/vda1 Physical volume "/dev/vda1" changed 1 physical volume(s) resized / 0 physical volume(s) not resized
Since the PV was already a member of the VG, no need to extend the VG.
Now for the actual volume:
root@test:~# lvextend -L 499G /dev/test/root Size of logical volume test/root changed from 49.04 GiB (12555 extents) to 499.00 GiB (127744 extents). Logical volume root successfully resized.
Here I specified it to be resized to 499GB. If I wanted to just use all available space, I'd do:
lvextend -l +100%FREE /dev/mapper/test-root root@test:~# lvextend -l +100%FREE /dev/mapper/test-root Size of logical volume test/root changed from 450.00 GiB (115200 extents) to 499.04 GiB (127755 extents). Logical volume root successfully resized.
-L is just easier to remember.
Lastly, resize the used filesystem:
root@test:~# resize2fs -p /dev/mapper/test-root resize2fs 1.42.13 (17-May-2015) Dateisystem bei /dev/mapper/test-root ist auf / eingeh�ngt; Online-Gr��en�nderung ist erforderlich old_desc_blocks = 1, new_desc_blocks = 32 Das Dateisystem auf /dev/mapper/test-root is nun 130821120 (4k) Bl�cke lang.
root@test:~# df -h Dateisystem Groesse Benutzt Verf. Verw% Eingehaengt auf udev 983M 0 983M 0% /dev tmpfs 201M 3.2M 197M 2% /run /dev/mapper/test-root 492G 2.3G 469G 1% / tmpfs 1001M 0 1001M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1001M 0 1001M 0% /sys/fs/cgroup
posted on 2015-08-07 18:34:25
To shrink a LVM partition, there are several steps to be reproduced:
If the volume is mounted, you will not be able to filesystem-check it, or even shrink it. So you can not simply shrink the root partition of your running live system. For this you will need a live disk (google for 'grml linux') and boot from this to make the changes.
So here something to copy paste from:
vgchange -a y e2fsck -f /dev/<volume_group>/<logical_volume> resize2fs /dev/<volume_group>/<logical_volume> <size-in-GB-MINUS-1GB>G lvreduce -L <size-in-GB>G /dev/<volume_group>/<logical_volume> resize2fs /dev/<volume_group>/<logical_volume> e2fsck -f /dev/<volume_group>/<logical_volume>
Usually you'd want to do this in order to create another volume / partition, but this is stuff for another blogpost.
View posts from 2017-07, 2017-05, 2017-04, 2017-03, 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10