Google Answers Logo
View Question
Q: Need to move /usr out of root into it's own file system on Fedora Linux ( Answered 5 out of 5 stars,   1 Comment )
Subject: Need to move /usr out of root into it's own file system on Fedora Linux
Category: Computers > Operating Systems
Asked by: curiousadmin-ga
List Price: $20.00
Posted: 15 Sep 2005 09:52 PDT
Expires: 15 Oct 2005 09:52 PDT
Question ID: 568383
How do I make /usr it's own file system?  Current it's all under the
root file system.  Linux host is running Fedora.

Request for Question Clarification by maniac-ga on 15 Sep 2005 17:01 PDT
Hello Curiousadmin,

I see a few options at this point:

[1] Move /usr to a currently empty partition (or second disk) and fix
the fstab file to use it at the new location.

[2] Rebuild the system from installation media (assuming you can move
the files you want to keep to another system or another disk). If you
have a spare disk drive, I can make some suggestions on how to set up
the copying so it won't take too long (a few hours - depending on how
much stuff you have).

[3] If you have free space, it MAY be possible to use "parted" to
repartition the disk. See
for an example of resizing a partition. This might be a good thing to
try before [2] if you already have a good backup of the files you want
to keep.

Based on what I described, which alternative do you want to try / have
explained as a complete answer?


Clarification of Question by curiousadmin-ga on 16 Sep 2005 07:48 PDT
Thank you maniac.   Disks in machine are currently all allocated. 
i.e.  Several Partitions have allocated all of the space.  But, there
is free space on 2 of the partitions.  Many GBs free.  So, I want to
reduce the size of one of those partitions, add a new
partition/Filesystem and then move /usr to that new FS.   How to do

So I had already looked into using "parted" before you answer, but
decided it was to hard to use on the command line.  Next I found
qt-parted on the web.   However, it
required building and the make command failed!  Next I retrieved a
full copy of knoppix and burned that to a CD becuase it has qt-parted
on the CD.    It would work however, becuase knoppix booted and
mounted the existing file systems.

1.  So, I need to find a way to boot knoppix without mounting the
exisint file sytems (one moment to RTFM).
2.  Then I'll be ready to make a new ext3 File system and move /usr to
the new area.  How to do that was my original question.  On boot up
/mnt/root or something has my original /usr.  Then I need to copy data
to a new /usr1 or something.  Then change the fstab table.  SImpy not
clear on the exact steps to perform, but I think I have the basic road

Clarify step 2 if you can.  Thank you.

Clarification of Question by curiousadmin-ga on 16 Sep 2005 07:50 PDT
darn spell checker.  i.e. Should be qtparted would NOT work because
original FS were mounted and "busy"

Request for Question Clarification by maniac-ga on 16 Sep 2005 20:15 PDT
Hello Curiousadmin,

I don't see a quick and easy way to do this (my [3]) but it does
appear to be feasible, just not with parted.

I have a knoppix live CD as well but I don't see what you mean by #1
(in my testing the only partition used at boot is the swap partition).
Knoppix does put icons on the display (in my case - one for my /boot
partition, and one for /) but those are not mounted until you click on
them (or right click / select mount). You can confirm this behavior
two ways:
 - right click (to bring up a menu, see the "mount" option in the
lower half of the menu)
 - bring up a terminal window (the black icon next to "home" in the
bottom menu bar and enter
    the output of df should not list your hard disks

To unmount a disk partition (if mounted), there are two methods:
 - right click (to bring up a menu, select the "unmount" option in the
lower half of the menu)
 - from the terminal window, enter
      umount /mnt/hda1  (or whatever partition you need to unmount)
    If you get an error from umount, enter
      sudo /bin/sh
    and try again.

If you need to move or resize a swap partition, you will need to do something like
  swapoff -a
to stop using the swap partition(s).

The symptom I have seen in my testing is that both qt-parted and
parted refuse to manipulate the ext2 (or ext3) partitions. The resize
menu is grayed out in qt-parted. If I run parted, and attempt to
"check" a partition prior to a resize, it complains with an error
  No implementation: This ext2 filesystem has a rather strange layout!
  Parted can't resize this (yet).
This may be a known problem - the but mailing list has a message
indicating that ext3 is not supported.

The alternative I found after some further testing is a combination of
  fdisk (the disk partitioning tool)
for a "brief" explanation of the steps which in your case would be something like
 [1] e2fsck -f (partition to shrink)
      to force a file system check (resize2fs checks this is done...)
 [2] resize2fs (partition to shrink) (new size)
      to make the file system smaller
 [3] fdisk (to shrink the partition, create the new one)
      I can provide the steps for an example if needed
 [4] create the new file system
      (tell me the type and I can fill this in too)
 [5] fix /etc/fstab

This is certainly a sequence that can be screwed up - so a backup of
the system is something I strongly recommend before starting.

If you want a "step by step" sequence, please provide:
 [1] The output of the "print" command in fdisk. Something like
  fdisk /dev/hda
is adequate. Repeat this for each disk to be repartitioned.
 [2] Identify the partition to reduce the size (and to what size)
 [3] How big the new partition should be (though I assume its the size
of the reduction)


Clarification of Question by curiousadmin-ga on 16 Sep 2005 22:14 PDT

I'm sorry I didn't spell this out on the 1st msg.  This should help.

fdisk -l (only showing disk I want help with)

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of
16065 * 512 = 8225280 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1        1044     8385898+  82  Linux swap
/dev/sdb2            1045       30401   235810102+  83  Linux

/dev/sdb2 is the partion I want to shrink.  Reduce the size to
something like "end of 25000 instead of current 30401" and from the
leftover "5000" eventually create 1 or 2 new partitions to host the
new /usr or /var FS.

I just gave you both sdb1 and sdb2 for completness.  I have about 140
GB free on /dev/sdb2.  I want to shrink enough to have 2 new partions
for something like /usr = 10 GBs and /var = 10 GBs.  So I'll have
plenty of free space for that once /dev/sdb2 is shrunk some.

That sdb2 partition has a label /data1.  I have no idea where that's
set.  It's reflected in /etc/fstab.  Somewhere I realized the /data1
is another name for /dev/sdb2, I think from the output of the "df"
command... it's very late!!

And by the way, FS type is to remain ext3.

Current partial /etc/fstab 

LABEL=/data1            /data1                  ext3    defaults        1 2
/data1                  /home/user1/data1     none    rw,bind 0 0
/data1                  /home/user2/data1     none    rw,bind 0 0

Current partial "df"

/dev/sdb2             222G   33G  178G  16% /data1
/data1                222G   33G  178G  16% /home/user1/data1
/data1                222G   33G  178G  16% /home/user2/data1

I think that's all you'd need.  Yes?  Now what do I do? I assume something like.
a. Delete the FS on /dev/sdb2
b. Use part-ed to shrink the partition or just fdisk is fine too --
and delete and create the partition.
c. Label it somehow.
d. Run mksfs.etx3 or whatever it's called.
e. Put stuff in /etc/fstab.  But, I should be able to use what is
there already, yes?

But, please clarify the exact steps just to shrink the /dev/sdb2. 
(p.s. I already screwed it up before writing this, so a full redo is
OK. :-(  )

I have tape backups of /data1 to restore.  No problem there.

Thank you!
Subject: Re: Need to move /usr out of root into it's own file system on Fedora Linux
Answered By: maniac-ga on 17 Sep 2005 14:25 PDT
Rated:5 out of 5 stars
Hello Curiousadmin,

OK. Based on some testing, the following steps should do the job for
you. The first few steps do the file system resizing and adjusting the
partition sizes / create the new one(s).


I've marked a few steps with (* and #a/#b) if the file system is
really messed up. From the numbers you mention, it appears you want
about 40G for the new partition. The /data1 partition will be about
180G after this is done. Adjust the numbers (e.g., 171G, +180G) if you
want different sizes.

[1] Verify that the partition to shrink (/dev/sdb2) is not mounted.
Use umount if necessary.

[2] (* not needed) e2fsck -f /dev/sdb2
to check the file system / verify it is in a consistent state. -f
forces the check. See
for more options if desired.

[3] (* not needed) resize2fs -p /dev/sdb2 171G
Resize the file system to the desired size. I suggest a size about 5%
smaller than 180G because you don't have to get the partition size
exactly right (and you will quickly resize to use all the space in
step 5a). This took a several minutes on my system (3G) but with the
33G used on your system it could be an hour or so. I suggest not
stopping this step once started (or it will corrupt your file system).
for more options if desired.

[4] fdisk /dev/sdb
to print the partition table / confirm what you have already reported.
to delete the second partition
    1045 (should be the default value)
to create the second primary partition with size 180G (slightly less usable)
to print the table / note the last cylinder of the second partition
    [last cylinder of 2nd partition + 1] (should be the default value)
    [last cylinder of the disk]  (should be the defaut value)
to create the third primary partition sized to take the rest of the
disk. If you want two partitions instead of one, you can create a 3rd
and 4th primary partition if desired. Just repeat the steps using the
appopriate values.
to write the partition table. You will get a few messages before fdisk
exits and you are back to the command line prompt. For explanations of
fdisk, the man page at
is not nearly as helpful as a tutorial in the Gentoo handbook at
or the Linux partition HOWTO at
Both of the latter explain the commands once you run fdisk much better
than the man page does.

NOTE: before 4a, e2fsck -f /dev/sdb2 may be necessary (it was not in my testing).

[5a] (* not needed) resize2fs -p /dev/sdb2
to resize the partition on sdb2 to use the entire space. On my system
this was pretty quick - but you may see a message about adding inodes.

[5b] (*) mke2fs -j -L /data1 /dev/sdb2
If the partition was messed up, just rebuild it with this command
line. This turns on journaling (ext3) and sets the file system label
to /data1. You may want to review
for additional options. 

[6] mke2fs -j -L /usr /dev/sdb3
to create the file system (type ext3) on the new partition. Repeat
with a different label if you create two partitions instead of one.
The label by the way is optional but can help in case you move
partitions / add disks by avoiding the use of physical disk partition

At this point, you have the partitions set up the way you want them
but the new one will not be mounted at start up and the new partition
does not have the contents desired.


Adjust the command line parameters (e.g., sdb4 for sdb3, var for usr)
if you need to repeat the commands for more than one partition.

To move the contents at this point, you need to mount the old & new
partitions at a temporary location. Something like
  mkdir /tmp/sdb2
  mkdir /tmp/sdb3
  mount -t ext3 /dev/sdb2 /tmp/sdb2
  mount -t ext3 /dev/sdb3 /tmp/sdb3
should do the job. The first two steps create empty directories to act
as mount points and the last two steps mount the drives in the
corresponding directories.

To copy the files, I suggest using a bulk copy program such as rsync.
Yes - I know it is a program normally used to copy files across the
network, but it works just fine locally as well. There are a LOT of
options to rsync, but the simplest method is something like
  rsync -a /tmp/sdb2/usr/ /tmp/sdb3
which will copy all the files from the old partition at /usr/ (and
recursively all sub directories) in "archive mode" which preserves
ownership, permissions, time stamps, etc. The only thing this does NOT
do is to preserve hard links (a single file located at more than one
spot in the hierarchy). If you must preserve hard links, use
  rsync -aH /tmp/sdb2/usr/ /tmp/sdb3
but the documentation indicates it is MUCH slower. Another note - be
sure to include the trailing slash on the source directory - it is
described in the man page as well, but this forces the contents of
/usr/ to appear in /tmp/sdb3 (and not in /tmp/sdb3/usr).

If you have a backup / restore program you could use that instead to
copy the files.

After copying the files and confirming they are correct - you should
probably remove them from the old location. Use
  \rm -rf /usr
[be VERY careful with entering this command...]
to remove the files from the old location. 

FIXING /etc/fstab

Now - the changes to the fstab file are pretty straight forward. See
for an explanation of the fields in the file.

The lines you showed should be kept as-is. For the new partition(s),
you need to add lines like these:

LABEL=/usr            /usr                  ext3    defaults        1 2

The LABEL= parameter refers to the file system label added above. The
/usr parameter refers to where the file system will be mounted. This
should be an empty directory (but if not empty its contents are
ignored after the mount is done). The ext3 parameter refers to the
file system type. Now "defaults" mean that the default mount options
are used. See
for explanations of the mount options. The last two options refer to
when the file system is dumped (for backups) and when it is mounted at
start up (in this case, after the root partition).


At this point, unmount the partitions, and I suggest you check them
one last time before you reboot.

  umount /tmp/sdb2
  umount /tmp/sdb3
  e2fsck -f /dev/sdb2
  e2fsck -f /dev/sdb3

to complete the file system checks. Then reboot (a variety of methods).


At this point, your system should be up and running OK with the new
partitions. Please make a clarification request if you have ANY
problems with the steps described or if any step is unclear. I would
be glad to follow up as needed.

Good luck with your work.

curiousadmin-ga rated this answer:5 out of 5 stars and gave an additional tip of: $15.00
Great work.  More in the future.

Subject: Re: Need to move /usr out of root into it's own file system on Fedora Linux
From: bozo99-ga on 15 Sep 2005 12:38 PDT
This depends slightly on your current disk layout and the one that you
want to reach and on the tools you have.   Why do you want to do this

Assuming the box has just one HD and it's all used your plan might go
something like this using no special s/w but dump and restore (which
I'm going to assume you are familiar with).  I assume you have another
box on your local network with loads of disk space (and if not how do
you normally do your backups ?!).  There is s/w for resizing
filesystems if you wanted to go that way.

1- write down what you want your disk to look like at the end and what
it looks like now (print fdisk -l output)  (there's always a chance
you'll want to return to this point if you screw up)
2- limit activity (users log off, stop cron and services) then use
dump to back up all filesystems to some remote host you'll be able to
use later
3- check step 2 succeeded
4- boot from removable media (Knoppix is good, haven't tried Fedora rescue stuff)
5- repartition the disk (using fdisk or disk druid) and restore the
filesystems from above, but using an interactive restore where you
extract the former root partially in two places
6- run the lilo program if you use LILO (no need if you use grub)

Reboot and try to look relaxed till you see it come up.
Throw away paper from step 1.

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  

Google Home - Answers FAQ - Terms of Service - Privacy Policy