How do I add more space?

hmm. the "home" drive, where websites are stored, should expand to 20GB (assuming you've got the physical HD space). but ships nearly "empty"

I'm thinking this might be a problem with how the partitions are setup ... I think mysql db files live in /var/lib/mysql. Not sure I like this ... but will have to address in the next version

Here's some background and a potential solution. Drupalpro is a nearly vanilla install of ubuntu, except that drupalpro user is allowed to run sudo without a password. Also open office and a few other programs have been removed .. to decrease image size. And finally a BUNCH of usefull applications installed that are useful for web development.

The solution for the current version of Drupalpro (or even Quickstart bete) is to move the mysql data diriectory off of the / (root) partition and onto the /home partition. here's a quick guide that will work: http://askubuntu.com/questions/224/how-to-i-move-mysql-data-files-onto-d...

to be clear, the root partition is not designs to grow very large. and is was an oversight until now that importing / creating a large db i going to cause the system to blowup

In encountered the same problem. Creating an extra website with qc failed due to not enough disk space. moving the mysql data dir fixed it. Now my root partition has 700mb available, still fill very 'tight', hope it will be enough...

ok, good to know. makes sense to me. I've been stupid busy the last two months with personal matters... but am shooting to have a new version of Drupalpro out based on a couple of different flavors of Ubuntu ... and I'll fix this partitioning issue with it.

I've also run into the issue of too little space for MySQL. It really ought to be on /home or somewhere else it can grow.
I can try moving it around etc. but would rather use Mike's proper solution in the forthcoming version of DrupalPro. Mike how is it looking up -- is there a beta3 or something we can try out already try out now or soon?

Hi @Vacilando -- I'm shooting for a new release by mid-July. It'll be a final release, and also a new one based on 13.04

Awesome, Mike! Would be great if you could update this ticket at that time so that we notice the new release asap. Looking forward!

Any news on the new release, @Mike?

sadly no, but its really high on my list right now. just have a client project that needs to get launched first ... hopefully late next week or the week after.

Another friendly poke :-)

SCROLL DOWN FOR THE SOLUTION

Actually, neither the Disk Usage Analyzer (see screenshot in post above) nor the Disk Utility (see table below) can provide visually clear data about this occurence ('lack of space').

Disk Utility
--------------------
Drive /dev/sda, Volume /dev/sda1: 6.4GB (/, bootable root)
Drive /dev/sdb, Volume /dev/sdb1: 0.5GB (SWAP)
Drive /dev/sdc, Volume /dev/sdc1: 21.0GB (/home)

A partition software like GParted (Gnome Partition Editor, to be found on http://gparted.sourceforge.net/ or Synaptic/Apt) does a better displaying job. However, it cannot resize partitions as long as it is being started respectively used within a running operating system. Unmounting actively used partitions/volumes is, then, not possible either.

Anyhow, I don't think it is a good solution to adjust the MySQL settings resp. move the MySQL data (see the in comment#3 mentioned link http://askubuntu.com/questions/224). For one simple reason: it is not the only potential cause for filling up the root-partition/volume. There can be all kinds of causes/reasons, e.g. updating Ubuntu! Generally, though, it obviously makes sense to use a dedicated partition for pure data storing purposes.

Resizing the existing/original virtual drive/disk/image [resp. drive/disk/image file] via command line does not work. This functionality is not yet implemented for the VMDK-format (Virtualbox 4.2.18).
$ VBoxManage modifyhd "path/to/DrupalPro (32bit)-disk1.vmdk" --resize 12000

What also does NOT work is the pure CLI-conversion of the first drive (with its root partition sda1) into the VDI-format in combination with a following modification.
$ VBoxManage clonehd "path/to/DrupalPro (32bit)-disk1.vmdk" "path/to/DrupalPro (32bit)-disk1.vdi" --format VDI
$ VBoxManage modifyhd "path/to/DrupalPro (32bit)-disk1.vdi" --resize 12000

One should assume this was an easy solution, but it isn't. The reason being that, after replacing the VMDK-drive with the VDI-drive in the hypervisor (Virtualbox GUI), the new VDI-drive's sda1-partition (root) won't be expandable to the full space of the VDI-drive (resp. cannot acquire the new, unallocated space) -- it is active and mounted, hence unchangable!
Additional combinatory experiments, e.g. with both formats (original VMDK and cloned VDI) parallely, then detaching/replacing the VMDK-drive from/in the virtual SATA-controller of the hypervisor didn't work out as well; actually for the obvious reason that an identical clone confuses the system (2 boot flags, 2 same system labels, same UUID, 2 identical mount points).

Even the creation and attaching of a brand-new and totally empty VDI-drive with double the size of the original [via hypervisor] didn't work. Why? GParted doesn't let one copy the data from sda1, although formatting sdd1 is allowed!
In addition to this, dding via command line, as shown in the code section below, doesn't seem to work either: It increases the size of the used space on the new partition sdd1 to the maximum . Btw, this whole thing is not even bootable. And repairing it seems nonsensical to me ('once screwed, always screwed') -- even though it might be just the partition table (fixing possible with gpart).
$ dd if=/dev/sda1 of=/dev/sdd1 bs=4096 conv=notrunc,noerror

However, one could try cping the partition content, obviously after ext4-formatting and mounting the new VDI-drive. But, when I think about this option some old and overly complicated memories about the file fstab and the topic UUID arise. So, no, no, no-go!

W H A T   W O R K S ?

STEP#1

• /foo/oracle/virtualbox$ VBoxManage clonehd "path/to/DrupalPro (32bit)-disk1.vmdk" "path/to/DrupalPro (32bit)-disk1.vdi" --format VDI
• /foo/oracle/virtualbox$ VBoxManage modifyhd "path/to/DrupalPro (32bit)-disk1.vdi" --resize 12000

STEP#2

• Start/Boot GParted Live (to be found on http://gparted.sourceforge.net/livecd.php) with the cloned and modified VDI-drive attached.
  Hint: In order to achieve this, you need to attach the ISO file of GParted Live to a Linux virtual machine first (freshly generated), namely as a disc/dvd.
• Resize.
• Shut down.
• Detach the redundant old drive (VMDK-disk1).
  Detach the new drive (VDI-disk1), then re-attach it. Now it should be at port 0 of the SATA-controller!
• Start your Drupalpro and be happy!

An alternative way, as described somewhere on http://forums.virtualbox.org, would be to use GParted Live and attach the old VMDK-drive as well as a new, completely empty VDI-drive (should one really prefer a more static approach, one could choose an empty VMDK-drive instead) created by the hypervisor (in the virtual machine's section 'storage management' or however this is called in English).
-> Basically, instead of   c l o n i n g   [via hypervisor] one   c o p i e s   [from within the 'live disc'].

Disclaimer: No garantee for perfection or (= implicit boolean OR) completeness.

Updating status.

Resizing the root partition is also a viable solution, as documented in #1960544-19: How do I add more space?. I've done similar things in the past with other VM's. I haven't verified all the documentation in #19, but on the surface the concepts are correct.

However, I'm also sticking with my original assessment #1960544-3: How do I add more space? as the likely culprit and easiest solution: move the mysql db to the home partition. It's not without its own hardships, but take a snapshot, and follow one of the many tutorials. (IMO, Ubuntu updates will not fill up the root partition -- and old cruft can/should be cleaned)

Bottom line, I'm not going to fix THIS exact problem solution in #3 or #19 both will fix it -- I'm truly sorry if you've encountered it. However, in the next version of Drupalpro I've switched to using Logical Volume Manager -- I was originally concerned about performance, but have researched and found it should have no real impact and the benefits include solving this problem. I hope to have a beat release od Drupalpro available very soon. I was actively working on last week, but am busy again until next week. Hopefully by month end.

Step #19 worked for me as well, This saved me a lot of trouble, Thnx!
I took me a while to figure out that STEP#1 doesn't work when your using the commandline as an administrator...
I needed more space to install many other things to get the latest omega (7.4) theme with sass working.

I just did #3 which is just moving the mysql database to another directory. I moved the default mysql data files (/var/lib/mysql) to /home/mysql

The /home folder can contain up to 20gb of files. This is assuming your db won't grow to that big.

Another option was to move the mysql folder to a shared folder which resides on the host computer, but i didn't try this as I'm not sure if the permissions would be an issue or not...

I followed this tutorial: http://www.ubuntugeek.com/how-to-change-the-mysql-data-default-directory...

Was pretty straight forward and completed in about 30 minutes. Just read carefully and use common sense.