How To Resize ext3 Partitions Without Losing Data

Version 1.0
Author: Falko Timme

This article is about resizing ext3 partitions without losing data. It shows how to shrink and enlarge existing ext3 partitions and how to merge two ext3 partitions. This can be quite useful if you do not use LVM and you realize that your existing partitioning does not meet your actual needs anymore.

There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Preliminary Note

(I run all the commands in this tutorial as the root user, so make sure you're logged in as root. If you are on a Ubuntu system, you can become root like this:

sudo su

)

I have tested this on a Ubuntu Edgy Eft desktop system that has all files in one large partition (around 10 GB, device /dev/sda1). The partitioning looks like this:

df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.5G  4.1G  4.9G  46% /
varrun                 94M  132K   94M   1% /var/run
varlock                94M     0   94M   0% /var/lock
udev                   10M   52K   10M   1% /dev
devshm                 94M     0   94M   0% /dev/shm
lrm                    94M   18M   77M  19% /lib/modules/2.6.17-10-generic/volatile

The partition that is to be resized must be unmounted when we do the resizing; obviously this is not possible if this is the partition that holds all important system files like in this example. Therefore we download a Live Linux-CD such as Knoppix from which we boot later on (if you have physical access to the system). If it is a remote system that you don't have physical access to, you need a rescue system on that system (a lot of hosting companies offer dedicated servers with rescue systems nowadays) that you can boot into (instead of Knoppix), and this rescue system must have the following tools: fdisk, umount, fsck, tune2fs, e2fsck, resize2fs.

If the partition that you want to resize doesn't hold any system files (such as /home partitions, partitions for backups, etc.), you don't need a Knoppix Live-CD or a rescue system, because all steps can be run from the original system.

If you want to resize partitions on production systems, please back up your data before, because it is possible you lose all your data if you don't calculate the size of your new partition correctly (especially when shrinking a partition)! You have been warned! Tutorials about backups can be found here: https://www.howtoforge.com/taxonomy_menu/1/34

I'm going to resize /dev/sda1 in this tutorial. If your partition is named differently, please replace /dev/sda1 with your own device (e.g. /dev/hda5, /dev/sdb3, etc.).

2 Shrinking An ext3 Partition

This chapter is about shrinking an ext3 partition. I want to shrink /dev/sda1 in this example. First we gather some details on our original system:

df

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              9859036   4234908   5123304  46% /
varrun                   95480       132     95348   1% /var/run
varlock                  95480         0     95480   0% /var/lock
udev                     10240        52     10188   1% /dev
devshm                   95480         0     95480   0% /dev/shm
lrm                      95480     17580     77900  19% /lib/modules/2.6.17-10-generic/volatile

df -B 4k

Filesystem           4K-blocks      Used Available Use% Mounted on
/dev/sda1              2464759   1058727   1280826  46% /
varrun                   23870        33     23837   1% /var/run
varlock                  23870         0     23870   0% /var/lock
udev                      2560        13      2547   1% /dev
devshm                   23870         0     23870   0% /dev/shm
lrm                      23870      4395     19475  19% /lib/modules/2.6.17-10-generic/volatile

df -h

fdisk -l

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1247    10016496   83  Linux
/dev/sda2            1248        1305      465885    5  Extended
/dev/sda5            1248        1305      465853+  82  Linux swap / Solaris

fdisk -s /dev/sda1

10016496

Then we shut down the system and boot into our Knoppix Live-CD (or your rescue system) (if the partition you want to resize doesn't hold any system files, you can do everything from the original system; the steps are the same, just omit booting into Knoppix/your rescue system).

shutdown -r now

After Knoppix has booted, open a terminal and become root by running

su

/dev/sda1 should be unmounted by default, but you can run

umount /dev/sda1

to go sure.

Then run

fsck -n /dev/sda1

The output looks like this:

fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: clean, 159037/1254176 files, 1095299/2504124 blocks

Next we remove the journal from /dev/sda1, thus turning it into an ext2 partition:

tune2fs -O ^has_journal /dev/sda1

The output looks like this:

tune2fs 1.38 (30-Jun-2005)

Then run

e2fsck -f /dev/sda1

e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 164178/1254176 files (0.6% non-contiguous), 1051617/2504124 blocks

Now we resize our file system with resize2fs. resize2fs can resize ext2 file systems, but not ext3 file systems, that's why we had to turn /dev/sda1 to ext2. Currently, 4.1GB are used on /dev/sda1 (see the df -h output above), So it's safe to shrink it from 10GB to about 6GB (if you make it smaller than 4.1GB, you will lose data!). Therefore we run

resize2fs /dev/sda1 6000M

The output is as follows:

resize2fs 1.38 (30-Jun-2005)
Resizing the filesystem on /dev/sda1 to 1536000 (4k) blocks.
The filesystem on /dev/sda1 is now 1536000 blocks long.

Please take note of the amount of blocks (1536000) and their size (4k). We need that soon.

Now we delete our /dev/sda1 partition (don't be afraid, no data will be lost) and create a new, smaller one (but still big enough to hold our resized file system!). We can do this with fdisk:

fdisk /dev/sda

(Yes, it's /dev/sda, not /dev/sda1.)

The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Type m to get a list of all commands:

Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Now we delete partition no. 1 (/dev/sda1):

Command (m for help): d
Partition number (1-5): 1

Next we create a new /dev/sda1 partition. It was a primary partition before, so we choose p again, and again it is our partition no. 1:

Command (m for help): n
Command action
l logical (5 or over)
p primary partition (1-4)
p
Partition number (1-4): 1

Now comes the crucial part - we are asked about the size of the new partition. The first cylinder is no problem, it is the one from the fdisk -l output at the beginning of this chapter (1).

First cylinder (1-1305, default 1): 1

But we don't have a value for the last cylinder of our new partition. Fortunately, we can specify the size in kilobytes (K), so we calculate the size like this:

We multiply the amount of blocks from the resize2fs output (1536000) by the size of a block (4k), and to go sure the partition is big enough, we add 3 to 5% to it (3% was enough for me, but if you want to go sure take 5%):

1536000 * 4k * 1.03 = 6328320k

So we prepend that value with a + sign and replace the small k with a capital one (K) and enter it:

Last cylinder or +size or +sizeM or +sizeK (1-1247, default 1247): +6328320K

Our original /dev/sda1 had the bootable flag (see the fdisk -l output from the beginning of this chapter), so we must add it to our new /dev/sda1 again:

Command (m for help): a
Partition number (1-5): 1

Now let's write our new partition table and exit fdisk:

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Now we reboot the system, and again we boot into our Knoppix system (rescue system; original system if resized partition doesn't hold system files):

shutdown -r now

Become root again (on Knoppix run

su

)

and then run this:

fsck -n /dev/sda1

The output should look like this:

fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: clean, 159036/765536 files, 1047239/1536000 blocks

Then we create the journal on our new /dev/sda1, thus turning it into an ext3 partition again:

tune2fs -j /dev/sda1

tune2fs 1.38 (30-Jun-2005)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.

Now we are done. Shut down the system and boot into the original system:

shutdown -r now

If everything goes well, the original system will boot up, and no data has been lost. Now we can gather some details about our new partitioning and compare them with the information we collected at the beginning of this chapter:

df

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              6047868   4224140   1639408  73% /
varrun                   95480       132     95348   1% /var/run
varlock                  95480         0     95480   0% /var/lock
udev                     10240        52     10188   1% /dev
devshm                   95480         0     95480   0% /dev/shm
lrm                      95480     17580     77900  19% /lib/modules/2.6.17-10-generic/volatile

df -B 4k

Filesystem           4K-blocks      Used Available Use% Mounted on
/dev/sda1              1511967   1056035    409852  73% /
varrun                   23870        33     23837   1% /var/run
varlock                  23870         0     23870   0% /var/lock
udev                      2560        13      2547   1% /dev
devshm                   23870         0     23870   0% /dev/shm
lrm                      23870      4395     19475  19% /lib/modules/2.6.17-10-generic/volatile

df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             5.8G  4.1G  1.6G  73% /
varrun                 94M  132K   94M   1% /var/run
varlock                94M     0   94M   0% /var/lock
udev                   10M   52K   10M   1% /dev
devshm                 94M     0   94M   0% /dev/shm
lrm                    94M   18M   77M  19% /lib/modules/2.6.17-10-generic/volatile

fdisk -l

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         789     6337611   83  Linux
/dev/sda2            1248        1305      465885    5  Extended
/dev/sda5            1248        1305      465853+  82  Linux swap / Solaris

fdisk -s /dev/sda1

view as pdf | print

Share this page:

Sub pages

41 Comment(s)

Add comment

Comments

By: dilino

Many thanks. Works like a charm!

By: Anonymous

No. It appears that resize3fs may not support ext3 in any way for some or all of the 2.4.xx kernel series. The man page says it supports 'onlne' (ie while mounted) resizing of ext3 with 2.6.xx - implying (I thought) but not saying that it swould support umounted resizing of ext3 for other kernel series.

Certainly it borked ext3 filesystems several times on the 2.4.31 kernel in my tests - clearly it had destroyed the journal. fsck reported lots of errors and the data was maimed or gone.

This could mean that removing the journal before resizing and recreating it afterwards is the way to go in this case - I will try that.

Suggest: Try it out on test partitions before trying this on real data with the 2.4.xx kernel.

I'm also looking for another tool.

By: Anonymous

Uhhh.. who the hell is running 2.4 kernels in 2009? If you want to run unsupported ancient kernels then go ahead - but it's not the fault of current software.

resize2fs works fine for ext3. Stop trying to scare people.

By: Anonymous

Off topic:

This is a common but uninformed misconception about 2.4.xx. The 2.4 kernel series is still in development with the last stable release on 2009-08-13.

There is better driver support for hardware in 2.6.xx and these kernels have significantly different internals but it would be a misnomer to describe 2.4.xx as obsolete just yet. Less popular, yes.

By: linuxuser

I have followed all steps mentioned in the article ...good article thanks for that.

My initial size of / partition was 14GB by command 'df -kh'

I reduced it by 5GB by following all steps and now when I do 'df -kh '

my size of / partition is 9GB ....its OK...but when I do check it by command

#fdisk -s /dev/sda1 .......its again showing 14GB....

Thats why I am so confused... and still no one has given answer for it.

Any help should be appreciated.

Thanks.

By: Wayan

it' work.

sda7 210Gb to 180Gb, only display 175Gb

df -h
Filesystem            Size Used Avail Use% Mounted on
/dev/sda5             9.7G 2.0G 7.3G 21% /
/dev/sda8             996M   55M 890M   6% /tmp
/dev/sda7             175G   49G 118G 30% /home
/dev/sdb1             227G 163G   53G 76% /backup
/dev/sda3             9.7G 7.9G 1.4G 86% /usr
/dev/sda2             9.7G 8.8G 425M 96% /var
/dev/sda1              99M   23M   72M 24% /boot
tmpfs                 2.0G 7.9M 2.0G   1% /dev/shm

Problem can't detect free space.

fdisk /dev/sda

The number of cylinders for this disk is set to 30515.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n
No free sectors available

By: Anonymous

Embedded devices :P And for me as regular user, it is my router with custom firmware based on linux 2.4..

By:

"resize2fs can resize ext2 file systems, but not ext3 file systems" That's strange, looking at resize2fs man page that starts like: "The resize2fs program will resize ext2 or ext3 file systems." and includes even this: "As of this writing, the Linux 2.6& kernel supports on-line resize for filesystems mounted using ext3 only." So ext3 seems to be supported better than ext2, not vice versa!

By:

Support for ext3 was added to resize2fs in version 1.19, more than 7 years ago. There is no reason to convert to ext2 first unless you are running a REALLY old system.

By: Austin

For ext3 only growing can be done online; for reducing ext3 you have to unmount filesystem and to remove journal too, removing journal drives ext3 to ext2 - that`s author mentioned, and that`s right. Nice article ("for text users").

By:

The command: resize_reiserfs /dev/hda4 will resize a partition image in /dev/hda4 (which is smaller than /dev/hda4) to fill out the partition. It takes one or two seconds. Jade @ http://m.domaindlx.com/LinuxHelp/

By: Fish Diesel

Yeah, but messing with REISER could kill you (pun intended).

By:

Hey, this howto is great. I don't do resizing of partitions often enough to remember all the necessary steps. ;) One comment I have though: you describe above a security margin of 3%-5%. But in fact, computers are precise. So when the filesystem is n 4k-Byte-Blocks, then indeed the partiton size can be set exactly to that length. In my case, the blocks given with the ext2 resizer were 4k blocks. The blocks given in fdisk were 1k blocks. So all I had to do to get the right partition size is to multiply the block number given from resize2fs by 4 to have it fitting exactly. I ran a `fsck -f` on the filesystem afterwards without problems. To verify my claim you can resize2fs on your 3%-5% larger filesystem and then take the number of blocks returned by resize2fs, multiply them by 4 and you will see your actual partition size in fdisk.

By: Anonymous

The way I get around this is to shrink the filesystem to less than my final desired size, then resize the partition to the final size, and issue one last resize2fs to expand the filesystem to fill the paritition. This is one more step, and is more time consuming if you have a large partition, but it reduces the chance of making an error in the size calculation.

By:

I'm afreaid this failed - I got a kernel panic and dont have any more time to spare in a recovery - I HAVE to do a re-install...

Too bad...

Click!

Thor

By: Thor

Hi,

I have to say that this article was written for the more seasoned user, I tried it only "two" days adter a very-first-"virgin" install - usefull as the info is, it should NOT be tried by inexperienced users, yet...

Nonetheless, briliant article! Belongs in a "bible" of sorts!

Thanks for this info!

Thor

By: Fedesh03

Worked fine for me. Thanks a lot!

By: Anonymous

Thank you for this how-to, it work great for me

By: Anonymous

Once you've booted of knopix, why not just use gparted?

It's got a nice graphical interface, never failed me, and takes care of resizing file system and partition all in one?

By: Anonymous

For one, gparted doesn't support LVM

By: Bill Pringlemeir.

I found the 'calculation' and fudge of 3-5% to not work for me. I did the following, instead of 'resize2fs /dev/sda1 600M', I ran 'resize2fs -M /dev/sda1'. This makes a minimum size. This can take some time. Then I ran fdisk and re-partitioned. After this fsck (which failed using the other method complaining about a mis-match between the device and file system sizes.), I re-ran 'resize2fs /dev/sda1', resizing the ext2 filesystem to use the full size of the allocated partition. I then re-ran the fsck command and followed all the steps. The 2nd resize doesn't take long (for me). This method allows all disk space to be used.

By: Cuervo79

It works great with primary partitions but not for extended. Do you know how to solve for the those?

By: David Greaves

Dangerous HOWTO.

All the messing about significantly increases risk of dataloss; use gparted and do it right.

For lvm it's trivial, just:

lvextend /dev/xenvg/everything -L +5G
resize2fs /dev/xenvg/everything

By:

I'd just like to say that this information allowed me to merge 2 partitions and ths make use of some unused space.

For historical reasons I had a 1Tb disk wih a 150Gb partition (/dev/sda8) followed by a 750Gb partions (/dev/sda9). sda8 was mostly unused, but sda9 was filling up.

The procedure I used was:

1, Move as much as possible from sda9 to sda8

2. Shrink sda9 and create a new empty partition (sda10).

3. Move as much as possible from sda9 to sda10.

4 Shrink sda9 and create a new empty partition (sda10 again, te old sda10 got renumber to sda11!).

5. Move as much as possinle from sda9 to new sda10.

6. Repeat until sda9 is empty.

7. Merge sda8 with sda9 and resize.

8 Move contents of the next partition (sda12 as I recall) to the expanded sda8.

9. Repeat for each partition until sda8 covers all the space of the old sda8+sda9.

10. Fix up mount points and references. :-)

Thanks for documenting the process. It definitely helped me out!

By: Arnd

Thanks for the great HOWTO!

Knoppix does not work for me cos i got a console-only system (nslu2) where i wanted to resize. I do not have a LVM on it and im happy to, bacause i need a real physical partition for DRBD (if i'm right...)

So the HOWTO worked just well - a bit risky i think, but with a proper backup....

Greez

Arnd

By: Anonymous

this looks very confusing.. i couldnt do it...

By: noob

Why does the resize2fs command took so long? even more than 15minutes..

By: Anonymous

It's literally moving all the bits on disk so that they are in the right place after the resize. Given that disks don't fill up linearly, the section at the end could be full.

By: Anonymous

Hey so, I just followed your tutorial on a non-critical system. I was using a gparted rescue CD to do the work. I had 2 partitions. a primary and a swap. I wanted to shrink the primary, trash my swap, and recreate both at a smaller size and location.

resizing the fs worked just fine and dandy. but then I got to the part where you say to delete and recreate partitions. I did this all through fdisk as described, but after I wrote the partition table, I went into gparted to view everything and make sure it worked right, well guess what, my sda1 partition was completely empty. Just straight up showed as blank. When I tried to mount it, I got all the regular unrecognized fs type errors you get when you try to mount an unfortmatted partition.

I don't think I skipped a step, but maybe I did. Seriously though, what is up with that?!

By: Anonymous

Hi,

What's the purpose we run fsck -n /dev/sda1?

Why I got error after it.

The superblock could not be read or does not describe a correct ext2 filesystem. ..........

Thanx!

By: Andrew B

Didn't work for me. Any ideas?

[[email protected] ~]# umount /opt/iress_ftp
[[email protected] ~]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              6190664   3231964   2644232 56% /
none                    517268         0    517268   0% /dev/shm
/dev/sda2             10309828    794716   8991396   9% /opt
/dev/sda3              3099292    741312   2200544 26% /var
[[email protected] ~]# fsck -n /dev/sdb1
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/iress_ftp: clean, 664/30277632 files, 53626986/60548889 blocks
[[email protected] ~]# tune2fs -O ^has_journal /dev/sdb1
tune2fs 1.35 (28-Feb-2004)
[[email protected] ~]# fdisk /dev/sdb

The number of cylinders for this disk is set to 45689.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): d
Selected partition 1

Command (m for help): 1
1: unknown command
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Command (m for help): p

Disk /dev/sdb: 375.8 GB, 375809638400 bytes
255 heads, 63 sectors/track, 45689 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-45689, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-45689, default 45689):
Using default value 45689

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[[email protected] ~]# partprobe
[[email protected] ~]# resize2fs /dev/sdb1
resize2fs 1.35 (28-Feb-2004)
resize2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
[[email protected] ~]# e2fsck -f /dev/sdb1
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

[[email protected] ~]# e2fsck -f /dev/sdb
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

[[email protected] ~]# e2fsck -b 8193 /dev/sdb1
e2fsck 1.35 (28-Feb-2004)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

[[email protected] ~]# dumpe2fs /dev/sdb1
dumpe2fs 1.35 (28-Feb-2004)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock

By: gedeef

Thanks for this article.
I had to share a big partition with ext4 fs from a netboot on my server and had only an old version of parted, not handling ext4. And no way to upgrade it on the reasd-only rescue system. I followed these instructions (except for the 'margin', 3% of 1 TB is much space !!!, I simply added about 1Mo, just in case...) and it worked perfectly.

By: wndrr

This HOWTO is dangerous. Ditto. It *might* work for a primary partition but it would fail for an extended partition. In my case, it did. The step right after writing the table, And seeing all the other comments of things gone wrong, I should have been more careful. Now trying to savage my partition with TestDisk... wish me luck, i need it.

By: Anonymous

I'm sorry to hear about your bad luck. I actually skipped the comments for I cared not for the contents of the partition or the whole drive really. I even skipped the parts of turning off the journalling seeing as I was figuring in seven years they'd be able to get it to work with more than just ext2. And also when I had to create the new partition it was originally partition number 8 turned into 10 and then I had to figure out what the beginning was seeing as I deleted the OLDER partition 8 previously then I just input what was shown before deleting it and instead of doing complicated math I just hit +8000M seeing as I'd resized it to 8000M and it was the same number so why not. I even skipped fsck -s by accident. What does it do ?

The number of inodes seems to be lower than they were if I remember correctly but 0.5M is still more than I'll ever need can someone tell me if this is correct ? Because in mkfs.ext4 it says that you can't change the number of inodes once the process is finished.

Boy this stinks. Wish something had gone wrong for me seeing as all valuables are off that drive. Hopefully you are able to recover some stuff! I'm wondering I have no tech background but if it was the tuning of the system that messed it up. Oh and in case it's not clear anything over 4 isn't a primary so no clue how I got it to work. Wait did you say extended ? You mean logical right ? Not the partition that gets created to create logical partitions and seems to just be a container for them right ? Hmm...maybe this is a different case then ? Primary/Logical is alright to change but not Extended ?

By: PeLu

Seams like this page is outdated (?). I used this to resize my root partition on ubuntu 12.04 and it was working good BUT:

When fdisk ask you for cylindars according to the guide.. it will ask you for Sectors instead and it looks like it calculates the default values for you that you could use

My LiveUSB disn't find fack but instead I could use fsck.ext4.

Great guide hower!

By: Anonymous

God kills a kitten each time you use sudo su.

Please learn to RTFM and use sudo -i instead.

By: Peter, Switzerland

Not much more to say than thank you for the perfect solution. I tried this on a raspberry PI+. Had a Rasbian OS on a SD-Card added to the USB-Port. Followed the instruction exactly as outlined and everything worked well on first try. Resized a linux (Raspian) ext3 Partition (second Part.on SD) from 15.1GB down to 7.1GB. It booted without any problems.

Really good and clean, thanks.
Peter

By: bryan

my df shows this now:

Filesystem Size Used Avail Use% Mounted on

rootfs 46G 27G 17G 63% /

/dev/root 46G 27G 17G 63% /

at what point did you mean to add that step?

By: Ejaz

Dear Falko, i want

/dev/root 20G 17G 1.5G 93% /

Extend to 100GB as you can see my space going Redline and my websites giving me problems to load... please help me for linux...

Thanks in Advance

By: K

Dear,

May i know if i use "D" to delete root partition into fdisk command. after that, use "N" for create new partition for increase the volume.the data will keep into partition or deleted?

thanks

By: Varun

doesnt work for me please help

Log in or Sign up

On this page