Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm relatively new to Unix... or at least doing anything beyond ls.

I need to get to a partition that is larger than where I'm at to import a project that won't fit where I'm currently. Also I'm running Linux on a VM on Windows.

jack@ubuntu:~$ sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME   FSTYPE   SIZE MOUNTPOINT LABEL
sda              20G
ââsda1 ext4    15.7G /
ââsda2            1K
ââsda5 swap     4.3G [SWAP]
sdc              40G
ââsdc1 ext4      40G            work
sdb              20G
ââsdb1 ext4      20G /mnt/disk
jack@ubuntu:~$ sudo fdisk -l

Disk /dev/sda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000750e0

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048    32956415    16477184   83  Linux
/dev/sda2        32958462    41940991     4491265    5  Extended
/dev/sda5        32958464    41940991     4491264   82  Linux swap / Solaris
share|improve this question
1  
What exactly do you mean by "get to a partition"? Do you mean that you want to move your / directory to a new partition? Please rephrase your question so it's clearer. –  Joseph R. Aug 26 '13 at 17:40
1  
What files/drives/partitions are you wanting to move where? A new disk, from one partition to another on the same disk? The command out put is useful, but we actually need to know what your final goal is, to be able to provide a working answer. –  Drav Sloan Aug 26 '13 at 17:41
    
I think OP wants to know how to resize his virtual disk. I suppose we should assume he knows how to change the disk size in the hypervisor, but needs to know how to resize the partitions in Linux. –  derobert Aug 26 '13 at 17:53

1 Answer 1

up vote 3 down vote accepted

If you'd put the / partition at the end of sda, you'd have a trivial upgrade process:

  1. Shut the VM down, and resize the raw disk drive in the VM management interface.

  2. Boot into single user mode, resize the last partition to extend over the new space.

  3. Resize the filesystem.

Doing this to a partition sandwiched between two others is probably more trouble than it's worth.

Therefore, I recommend that you move part of the contents of your / partition to a new disk:

  1. Shut the VM down, and add another virtual disk.

    Size it to hold the existing contents of / that you want to move to the new disk, plus however much space you want left over. Say you're using 14 GiB of your 16 GiB /, and you want to move only /home, which is using 10 GiB. If you want double your current space, you'd make the new drive 20 GiB.

    You don't want to move any core OS directories: /bin, /boot, /etc, /root, most of /usr... It's safe to move /usr/share and /usr/local to other disks.

  2. Boot back up, preferably into single-user mode. (It will make later things easier if you don't have lots of background stuff running.)

    Then, figure out which /dev node your new disk got. There are many ways to do this. It's most likely /dev/sdb, but it might get /dev/sdc to be put after a previously-mapped optical drive, for example.

    We'll assume /dev/sdb for the purposes of explanation here.

  3. Use parted to partition this new virtual disk:

    # parted /dev/sdb
    (parted) mklabel gpt
    (parted) mkpart ext2 1 -1
    (parted) quit
    

    That takes over the entire virtual disk. This will allow you to use the much simpler resize process above if you run out of disk capacity again in the future.

    If you plan on moving lots of unrelated directories (e.g. /home, /var and /usr/local) it's best to create a separate virtual disk for each, rather than partition one big disk. Partitioning is a kind of hack we tolerate in the world of real disks. When you're dealing with VMs, you're freed from the costs of multiple independent hard disks.

  4. Create and mount the new filesystem(s) in temporary locations. I typically call them things like /mnt/newhome:

    # mkfs.ext4 /dev/sdb1
    # mkdir -m 400 /mnt/newhome
    # mount /dev/sdb1 /mnt/newhome
    
  5. Copy the current contents of the tree you want to transplant, being sure to copy permissions. There are several ways to do this:

    # cd /home
    # find . -print | cpio -pd /mnt/newhome
    OR
    # cp -aR * /mnt/newhome
    OR
    # rsync -a * /mnt/newhome
    
  6. Check that /mnt/newhome has plausible contents. Does df -h show approximately the same value as du -h /home, for example?

  7. Boot into single-user mode, if you aren't already.

  8. Move the old filesystem out of the way, then lay the new one over it:

    # cd /
    # mv home oldhome
    # mkdir -m 400 home
    # umount /mnt/newhome
    # mount /dev/sdb1 /home
    # chmod 755 home
    # chown root.root home
    

    The last two commands are just examples. Give the new mount point the same owner, group, and permissions as the old one. (Don't count on the copy command to get the permissions on this top-level directory right.)

  9. Say exit at the single-user mode prompt to continue booting into multi-user mode. (Or, init 5, if the normal runlevel is 5, for example.) Check that everything seems to be working with the new filesystem.

    (Don't reboot to do this test! The new filesystem won't automatically mount yet.)

  10. When you're satisfied that you've successfully moved that partition, adjust /etc/fstab to point to the new partition.

    (This is way outside the scope of this answer. The exact details vary even between Linuxes, and vary even more broadly among *ix in general.)

  11. Reboot normally. Check again. Does it all still work? Be certain you've got the new filesystem mounted, not the old one.

  12. When you're certain it's all moved and mounting correctly, free up the space taken by the old copy: rm -rf /oldhome.

If you have multiple filesystems to move, GOTO 2. :) (Or step 1, if you didn't add all the new virtual disks at once.)

If you're using a VM system that knows how to set up a sparse virtual disk (e.g. VMware) you don't have to worry about wasted space. Just follow its normal "shrink" process to reclaim the now-slack space.

There are other refinements. For example, you might want to give something like -L /home to the mkfs.ext4 command if your OS uses disk labels in /etc/fstab instead of partition names or UUIDs.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.