Merging partitions in Debian

Question

I have recently inherited someone else's problem with a linux server. This is one of those all in one debian based lamp setups. It recently ran out of storage and no one seems to know anything about linux in general here. I have managed to expand the drive in VMWare and created the partition as seen in the image below. The challenge is to merge the root partition /dev/sda1 with /dev/sda4.

Note: the Start - End blocks are not back to back and I can't afford much downtime on this server. /dev/sda3 can probably be merged too but not important.

UPDATED: df -h output

UPDATED 2: fdisk -l output

Answer 1

I have no idea as to what sort of setup you have on your end. Maybe you use RAID or not, SAN, NAS or not as each of these would complicate things.

For now, I'm assuming you are using a single traditional hdd having partitions.

There's usually a reason why people have different partitions, for instance some people might think or have rationale to have databases for different datasets for security purposes and alike. I would urge you to research a bit more before taking a course of action and if possible to talk to the people why they did what they did beforehand.

Having said the above and assuming you have good reasons to do the changes, what I would do is backup all the data to an external drive, use a Debian Live CD or whatever you can get hands on, use gparted and do the partitions as you like, slip/copy the data making sure that any hard links or symlinks which might be pointing to the different partitions are linked correctly on a spare server with the same configuration excuding the hdd but have the filesystem if possible. I do hope you have some sort of tests to tell if things are working correctly.

If everything goes smoothly, just shut down the server, put the new disk in with the data and put it to live service.

It usually is a good idea to update Debian and whatever applications are being used when you are doing this but that would entail some time kept aside for testing how the data performs as kernel updates, security patches make the whole thing better.

I would also urge you to do some documentation so you can refer notes in case somthing does go wrong down the line as memory tends to become blurred over period of time as well as put the reasons as to why you are doing what you are doing.

All of these are just pointers to what good practices are and what you should be aware of. I, for one have never been in favor of in-situ repartitioning as any damage costs are simply not worth it.

Answer 2

/dev/sda1 is a primary partition, and /dev/sda4 is a logical partition locate in an extended partition. Besides they are non-contiguous which would make a merge operation problematic. Maybe you could create a clean slate by deleting /dev/sda3 and /dev/sda4 (after having backup the data) and then with gpart merge the now unallocated space with the /dev/sda1. Maybe it would be necessary to remove the whole extended partition in order to create such clean slate of unallocated space.

After a second glimpse, I noted that that extended partition is only 1046529 blocks which means that /dev/sda4 is a primary partition. But that does not really matter. Mainly in order to extend sda1 you would need contiguous unallocated space. Instead of gpated you could use fdisk to delete and recreate the partition: fdisk /dev/sda -u (-u shows sizes of partition tables in sector for uniformity), and then use resize2f in order to resize to a new size.

Answer 3

Right all you need is 1GB of space to get a day (you say that in a comment)?

Easy way (i think) is to clear your old logs, if they are not important by:

cd /var/log/
rm *.gz
cd /var/log/apache2
rm *.gz
(etc) 

Or just moving your old logs to another place

mkdir /mnt/pendrive
mount /dev/sdc1 /mnt/pendrive
cd /var/log/
mv *.gz /mnt/pendrive
cd /var/log/apache2
mv *.gz /mnt/pendrive/myfunnyapache2folder
(etc)

Or if for some unknow reason, you dont want to do it, we can try moving /var/log to another partition until you get everything fine!

First stop your services: service rsyslog stop; service apache2 stop ; service mysql stop, etc

fdisk /dev/sda (change sda to your disk device or pendrive)

n (using n command create your 1GB partition and save fdisk with w command, and just quit fdisk)

Check with fdisk -l (L lowercase) what partition device your 1gb partition assumed, for example /dev/sda5

Now, mount /dev/sda5 or your partition number (created by fdisk) as your new /var/log...

mkdir /tmp/log 
mkfs.ext4 /dev/sda5 - Assumed /dev/sda5 as the new empty partition. This will destroy all that in /dev/sda5 if you select the wrong partition, this is the empty partition you created in fdisk!
mount /dev/sda5 /tmp/log       
mv /var/log/* /tmp/log 
umount /tmp/log
mount /dev/sda5 /var/log      
ls /var/log     - Now you have time to think again... 

After that you will be able to restart your services: service rsyslog start; service apache2 start; service mysql start, etc...

Yes it can be dangerous if you dont pay attention in what you are doing, but less than trying to resize or merge partitions on a running system.

If you really dont have any more space on your hard drive, create a ramdisk partition (you can found how to do that in google), but you will lost your log data if the server restarts....

You can compress non-rotated log data too, with gzip, like that gzip filename, and other text files, that you probably will not need right now!