Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I have an ext4 partition at the end of an hard drive, and want to resize it to the full disk size (the rest of the disk is empty). It's not the root partition, just a data partition, so it's no problem to unmount the partition. The machine has Ubuntu server running, and neither Screen, keyboard, mouse nor optical disk drive attached, so booting a live environment to use this approach would be a bit of a hassle and I'd like to avoid that.

Anybody know an easy way to do this? For me, this proves to be a far more difficult task than I had anticipated, but let me elaborate:

Of course the disks partitions were all unmounted during the following operations. I first tried via parted: I deleted the first partition which was not needed anymore, then wanted to resize or move the ext4 partition. But parted told me it wasn't able to do so, because of some filesystem features of ext4 (with a weird error message: "Error: File system has an incompatible feature enabled. Compatible features are has_journal, dir_index, filetype, sparse_super and large_file. Use tune2fs or debugfs to remove features." - so what are the incompatible features?); what I got from that, and as an answer on comments in another question, it is somehow not possible for parted to change the start of an ext4 partition.

Why can gparted, however, seemingly do the trick (see first linked question) but not parted?

Well, since I had enough space at the start of the drive left (more than the size of the partition to move) I thought I'd try another approach: create a second partition at the front, copy the contents from the one at the back to this one, then delete the old partition and resize the new to the full size. However, this also proved impossible: After creating the partition and copying the contents (via dd if=/dev/sdb2 of=/dev/sdb1), the partition can't be mounted ('missing journal superblock').

So at the moment I'm fresh out of ideas. I'll probably copy everything vital to another disk, delete all partitions again and create one big one. I'm wondering that this is such a problem - or am I overlooking the obvious?

share|improve this question
    
Please provide a complete transcript of all the commands you ran and the messages you got. You can use script and pastebinit with the -i flag for this. Then edit your question to provide either a link to the pastebin, or (if it's only a couple hundred lines or less) the text itself. ...Do you have SSH access to this server from another Ubuntu system (or any Unix-like system)? If so, you may be able to install gparted and run it via ssh -X. –  Eliah Kagan Jun 6 '12 at 7:53
    
I have ssh access, but no X Server installed (and neither need nor wish to do so), but I guess I'd need one to be able to run ssh -X, right? I'll try to provide the exact commands & error messages, but it might take a while to recreate them, I didn't take notes since nothing really vital is on that disk at the moment (for the most part, "just" the backup of backups). Basically I'm doing this out of curiosity - it must be possible, right? But I'm feeling more and more confident that copying the contents, deleting, and recreating is the simplest solution... –  RandolphCarter Jun 6 '12 at 8:02
    
For ssh -X, the X server has to be installed on the SSH client, not the SSH server. The vast majority of Unix-like systems with GUI's have what is needed to connect as an SSH client with -X (except Mac OS X, if you didn't install the X11 component). See en.wikipedia.org/wiki/X_server#Design for further explanation. –  Eliah Kagan Jun 6 '12 at 8:09
add comment

5 Answers

up vote 1 down vote accepted

It is a little bit time consuming, but it can be done if:

Assuming /dev/sdb1, and that the unallocated space is bigger than the amount of data from /dev/sdb1:

Before we start, let's create some mounting point directories in /mnt/:

mkdir /mnt/old && mkdir /mnt/new

The disk now looks like this:

[(.......UNALLOCATED.........)(xxxx /dev/sdb1 xxxxxx)]
  • e2fsck -f -y -v /dev/sdb1 #just to be sure that it is error free.
  • fdisk /dev/sdb
  • Press: n p 2 wq
  • mkfs.ext4 /dev/sdb2
    Now the disk looks like this:
[(xxxxxx /dev/sdb2 xxxxxxxxxx)(xxxx /dev/sdb1 xxxxxx)]
  • mount /dev/sdb2 /mnt/new && mount /dev/sdb1 /mnt/old
  • mv /mnt/old/* /mnt/new/ (You will get an error about lost+found, you can ignore it)
  • cd / && umount /mnt/old && umount /mnt/new
  • cfdisk /dev/sdb
  • Delete sdb1
  • Choose write
  • Delete sdb2
  • Choose write
  • Create new, choose the whole size available.
  • Write and quit.
  • e2fsck -f /dev/sdb1
  • resize2fs /dev/sdb1 Now the disk looks like this:
[(xxxxxxxxxxxxxxxxxxx /dev/sdb1 xxxxxxxxxxxxxxxxxxx)]
  • mount /dev/sdb1 /your/mount/point

FINISHED!

share|improve this answer
    
Oh, I forgot to mention that I have tested this solution. :) –  Frantique Jun 6 '12 at 9:38
add comment

Here's how I've done it on headless machines with SSH access only: use VNC and get gparted to do it. Use openbox for a minimal environment, and remove it all once done if this is one time only.

sudo apt-get install vnc4server openbox gparted
vnc4server       #set a password, create initial config
vnc4server -kill :1
sed -i -e 's/x-window-manager/openbox-session/g' ~/.vnc/xstartup
vnc4server

Open port 5901 incoming, and access with a VNC client. Right-click to start the terminal within openbox, and you'll be able to run any GTK+ apps, including gparted. apt-get remove and autoremove if you want to when you're done.

share|improve this answer
1  
Thanks! Any idea why gparted can do it but not the command-line based parted? They should be based on the same library (libparted) as far as I know, so why the different functionality? –  RandolphCarter Jun 6 '12 at 8:36
1  
I can't look into this right now, but I would assume that while libparted provides this functionality, parted may not expose it while gparted does. Maybe try one of the other text front-ends like python-parted (IIRC)? –  izx Jun 6 '12 at 8:44
    
Sounds promising, I'll give it a try in the evening! –  RandolphCarter Jun 6 '12 at 8:51
    
Although it actually sounds a bit paradoxical for linux - there is a graphical tool which does the job but none for the command line ;) –  RandolphCarter Jun 6 '12 at 9:01
add comment

I went in the GUI direction:

1) Run the a live linux CD (Mint in my case)

2) Connect to Internet

3) Get gparted

sudo apt-get install gparted

4) After you've done all resizing in the neat gparted GUI, run the boot-repair.

5) https://help.ubuntu.com/community/Boot-Repair Basically comes down to getting it and dunning it:

sudo add-apt-repository ppa:yannubuntu/boot-repair && sudo apt-get update

sudo apt-get install -y boot-repair && boot-repair

6) Select the fixing of common options and select NO if it asks you if your drive is a removable (well if it isn't).

Solved my problem.

share|improve this answer
add comment

First of all, BACKUP THE DATA! (Jut to be sure...)

Because parted doesn't support ext4, you should use resize2fs.

cfdisk /dev/sdx
  • Delete the partition. YES, DELETE IT! (I know, it sounds weird, but trust me, the data will remain there, just DON'T USE mkfs.ext4!)
  • and recreate it with the size you want. You need to start it at the exact same point as it was the original. The end point can move around. If you miss this, you will loose the data!
resize2fs /dev/sdxY

Without giving any other parameters to resize2fs, the filesystem will be extended to the partition's size.


About the incompatible features: it is the extents which is used by ext4.

share|improve this answer
    
As is stated in the question, nyarlathotep's partition starts at the end of the drive, so the starting point has to be moved and the technique you propose will not work without data loss. –  Eliah Kagan Jun 6 '12 at 7:50
    
yes, unfortunately doesn't help me (start can't stay the same) –  RandolphCarter Jun 6 '12 at 8:05
    
Ok, give me a few minutes to think again, I missed the moving starting point, sorry... –  Frantique Jun 6 '12 at 8:16
add comment

First, I would have done as Frantique did, except I would have moved with rsync as it is designed to make copy with all attributes intact. The command mv wouldn't do that.

But if I really wanted to do serious work, as I would move stuff anyway, I would have moved the data to a LVM2 volume, as that makes it so easy to manage volumes, disks and partitions in the future.

As if you would like to add more space, just add a disk to the volume group. Add, remove or resize partitions, just do that to the logical volume. No need to think about physical layout. To remove data from a disk that is starting to report lots of errors, just add a new disk, and then move data from the faulty one, and then remove the disk from the volume. All data moved from one disk to another.

share|improve this answer
    
I have vaguely thought in the direction of LVM as well, but I know too little about it at the moment to make any use of it ;). But I guess sooner or later I'll look into it –  RandolphCarter Jun 6 '12 at 13:44
    
It isn't that hard. You have physical volumes, which are where you store data. Usually a parititon with type set to 8e. They are put into a volume group, which contine one or more physical volumes. You can think of this as a logical disk. From a volume group you can create logical volumes, which you can think of as partitions. It's them you make file systems in and mount. Here is an introduction (from a good site): debian-administration.org/articles/410 –  Anders Jun 6 '12 at 20:09
add comment

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.