Hi,
Is there any way to repartition the disk AFTER installing the system? I tried QTParted, but it doesn't repartition ext3 filesystems.
Thansk, Gustavo.
If you use Logical Volumn manager (LVM), then you can automatically resize the partition. Parted is suppose to do it for you, but I do not have a lot of faith in the tool, so what I usually do is create a new partition with the size I want, and copy the contents of the old partition to the new partition. After creating the new partition, update your fstab with the new partition and reboot your system with the new partition replacing the old. You can then mount the old partition to a temporary mount point and drop it. Do not unmount the old because the system knows about it until the reboot when it will point to the new partition. If it is not a critical partition like /var /boot /, /tmp, or swap, then you can just umount it and mount the new partition on the old mount point.
----- Original Message ----- From: "Gustavo Seabra" seabra@ksu.edu To: fedora-list@redhat.com Sent: Monday, November 22, 2004 11:30 AM Subject: Disk Partiotioning
Hi,
Is there any way to repartition the disk AFTER installing the system? I tried QTParted, but it doesn't repartition ext3 filesystems.
Thansk, Gustavo.
--
*Gustavo Seabra* http://www.ksu.edu/chem/personnel/faculty/grad/jvo/ortiz/people_seabra.html
- Graduate Student
E-Mail: seabra@ksu.edu mailto:seabra@ksu.edu Phone: (785) 532-6072 Chemistry Department http://www.ksu.edu/chem/ Kansas State University http://www.ksu.edu Manhattan, KS 66506-3701
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
Keith R. Evans wrote:
If you use Logical Volumn manager (LVM), then you can automatically resize the partition. Parted is suppose to do it for you, but I do not have a lot of faith in the tool, so what I usually do is create a new partition with the size I want, and copy the contents of the old partition to the new partition. After creating the new partition, update your fstab with the new partition and reboot your system with the new partition replacing the old. You can then mount the old partition to a temporary mount point and drop it. Do not unmount the old because the system knows about it until the reboot when it will point to the new partition. If it is not a critical partition like /var /boot /, /tmp, or swap, then you can just umount it and mount the new partition on the old mount point.
----- Original Message ----- From: "Gustavo Seabra" seabra@ksu.edu To: fedora-list@redhat.com Sent: Monday, November 22, 2004 11:30 AM Subject: Disk Partiotioning
Hi,
Is there any way to repartition the disk AFTER installing the system? I tried QTParted, but it doesn't repartition ext3 filesystems.
Thansk, Gustavo.
--
*Gustavo Seabra* http://www.ksu.edu/chem/personnel/faculty/grad/jvo/ortiz/people_seabra.html
- Graduate Student
E-Mail: seabra@ksu.edu mailto:seabra@ksu.edu Phone: (785) 532-6072 Chemistry Department http://www.ksu.edu/chem/ Kansas State University http://www.ksu.edu Manhattan, KS 66506-3701
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Thanks, Gustavo.
On Mon, 2004-11-22 at 10:47 -0600, Gustavo Seabra wrote:
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Not necessarilly, it depends mostly on your partition layout. What partitions have you defined - please give device (disk) names and mount points.
If you are in a situation where you can either temporarily delete a partition after having backed it up, or shrink an existing one to create a new one, then you should have some options available to you.
Do a "man resize2fs" and read that.
C. Linus Hicks wrote:
On Mon, 2004-11-22 at 10:47 -0600, Gustavo Seabra wrote:
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Not necessarilly, it depends mostly on your partition layout. What partitions have you defined - please give device (disk) names and mount points.
If you are in a situation where you can either temporarily delete a partition after having backed it up, or shrink an existing one to create a new one, then you should have some options available to you.
Do a "man resize2fs" and read that.
Thanks. I'm not at the computer I want to change now but, as soon as I get there (probably tonight) I'll check this and send to you. Thanks!
Gustavo.
C. Linus Hicks wrote:
On Mon, 2004-11-22 at 10:47 -0600, Gustavo Seabra wrote:
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Not necessarilly, it depends mostly on your partition layout. What partitions have you defined - please give device (disk) names and mount points.
If you are in a situation where you can either temporarily delete a partition after having backed it up, or shrink an existing one to create a new one, then you should have some options available to you.
Do a "man resize2fs" and read that.
Sorry, I just found a way to get the info. Here is the result of df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda3 4.9G 4.2G 427M 91% / /dev/sda1 99M 17M 78M 18% /boot none 125M 0 125M 0% /dev/shm /dev/sda2 12G 683M 11G 7% /home
What I'd like to do is to take a couple of Gigs from /home and put them into / (root). I believe I can backup and erase /home without problems, but how can I put this space into root?
Thanks
On Mon, 2004-11-22 at 11:46 -0600, Gustavo Seabra wrote:
Sorry, I just found a way to get the info. Here is the result of df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda3 4.9G 4.2G 427M 91% / /dev/sda1 99M 17M 78M 18% /boot none 125M 0 125M 0% /dev/shm /dev/sda2 12G 683M 11G 7% /home
What I'd like to do is to take a couple of Gigs from /home and put them into / (root). I believe I can backup and erase /home without problems, but how can I put this space into root?
I'd like to see the output of the "p" command from fdisk also, but this will be a somewhat complicated case. Since your root partition comes after your /home partition, you will have to move the contents of your root partition in order to make it bigger. It is doable, just more complicated. You decide whether the potential risk is worth it.
There are two posibilities dependent on whether or not you are able to backup your /home partition to off-line storage, like burning a CD.
Here's the basic outline if you can backup /home:
1. Back up your home partition. 2. Unmount /home and remove it (comment it out) from your fstab. 3. Delete the sda2 partition. 4. Create a new sda2 the size your new root partition should be. 5. Copy everything in sda3 to sda2. 6. Make a new entry in your grub.conf pointing to the new root. Be sure to preserve your existing entry in the grub menu. 7. Test to make sure you can boot the new root partition. Use the mount command to verify what device is mounted as your root partition. Make sure the system works properly - just remember you have no /home. 8. Assuming you booted successfully from the new root, you can now delete sda3 and create any new partitions you want, including your new /home. 9. Restore /home from your backup. 10. Update your fstab to reflect your new /home partition.
The above can be simplified if you like the existing paritions sizes and just want to switch them.
Here's the outline if you can't backup /home:
1. Unmount /home. 2. Use resize2fs to shrink the filesystem. I would shrink it to the size you want your new root to be. 3. Use fdisk to shrink the parition. 4. Decide how to proceed:
The safer way to proceed from here is to leave what is currently in your sda2 partition there, and just copy your root partition from sda3 into sda2 as well. Note that this will consolidate everything (except /boot) into one partition. You will want to create a /home/home directory and move all your user directories into it first. This will allow you to boot both new and old roots, but will alter disk allocation patterns (this should have a negligible negative effect). From here, it remains to create a new grub entry, test booting the new root, then deleting your old root, creating your new /home, then moving /home in your root partition to your new /home partition.
The risker way to proceed is to go ahead and create a new partition for /home and move it first. The risk here is that you must modify both you grub.conf and your fstab for your existing root in order to boot it successfully. The reason is that your partition names have changed because you now have two where there used to be one. So sda3 becomes sda4, your new /home is sda3 and your new root is sda2.
I have not outlined the rest of this process, but this much should give you an idea of the risk should you decide to proceed with it. If you are not comfortable with using resize2fs and/or fdisk, the potential for damaging your system beyond repair could be great. On the other hand, it could be a great learning opportunity.
Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Mon, 2004-11-22 at 10:47 -0600, Gustavo Seabra wrote:
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Not necessarilly, it depends mostly on your partition layout. What partitions have you defined - please give device (disk) names and mount points.
If you are in a situation where you can either temporarily delete a partition after having backed it up, or shrink an existing one to create a new one, then you should have some options available to you.
Do a "man resize2fs" and read that.
Sorry, I just found a way to get the info. Here is the result of df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda3 4.9G 4.2G 427M 91% / /dev/sda1 99M 17M 78M 18% /boot none 125M 0 125M 0% /dev/shm /dev/sda2 12G 683M 11G 7% /home
Instead of "df -h", "fdisk -l" would have been more useful. We want to see the actual partition layout of the partition table....
What I'd like to do is to take a couple of Gigs from /home and put them into / (root). I believe I can backup and erase /home without problems, but how can I put this space into root?
*IF* sda2 and sda3 are contiguous in the partition table (probably, but not guarenteed without looking at the actual allocation info) you might be able to resize(move) sda3 to the upper regions, re-size the partition sda3, then merge the new space onto the end of sda2. If you are lucky, you should then be able to expand sda2 into the re-claimed space. Not easy, but it should be straightforward if you know the right commands. If you have no experience doing this, I'd heartily recommend backing up the data in both sda2 & sda3 before attempting this for a first time!
Thanks
Good Luck!
Kevin J. Cummings wrote:
Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Mon, 2004-11-22 at 10:47 -0600, Gustavo Seabra wrote:
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Not necessarilly, it depends mostly on your partition layout. What partitions have you defined - please give device (disk) names and mount points.
If you are in a situation where you can either temporarily delete a partition after having backed it up, or shrink an existing one to create a new one, then you should have some options available to you.
Do a "man resize2fs" and read that.
Sorry, I just found a way to get the info. Here is the result of df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda3 4.9G 4.2G 427M 91% / /dev/sda1 99M 17M 78M 18% /boot none 125M 0 125M 0% /dev/shm /dev/sda2 12G 683M 11G 7% /home
Instead of "df -h", "fdisk -l" would have been more useful. We want to see the actual partition layout of the partition table....
What I'd like to do is to take a couple of Gigs from /home and put them into / (root). I believe I can backup and erase /home without problems, but how can I put this space into root?
*IF* sda2 and sda3 are contiguous in the partition table (probably, but not guarenteed without looking at the actual allocation info) you might be able to resize(move) sda3 to the upper regions, re-size the partition sda3, then merge the new space onto the end of sda2. If you are lucky, you should then be able to expand sda2 into the re-claimed space. Not easy, but it should be straightforward if you know the right commands. If you have no experience doing this, I'd heartily recommend backing up the data in both sda2 & sda3 before attempting this for a first time!
Thanks
Good Luck!
Thanks for you reply, and sorry it took me so long to answer. It took me some time to realize I needed the - in the su command to get this to work. But here it is: [root@patroclus ~]# fdisk -l
Disk /dev/sda: 18.2 GB, 18210037760 bytes 255 heads, 63 sectors/track, 2213 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/sda1 * 1 13 104391 83 Linux /dev/sda2 14 1511 12032685 83 Linux /dev/sda3 1512 2148 5116702+ 83 Linux /dev/sda4 2149 2213 522112+ 5 Extended /dev/sda5 2149 2213 522081 82 Linux swap
On Mon, 2004-11-29 at 06:32 -0600, Gustavo Seabra wrote:
Kevin J. Cummings wrote:
Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Mon, 2004-11-22 at 10:47 -0600, Gustavo Seabra wrote:
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Not necessarilly, it depends mostly on your partition layout. What partitions have you defined - please give device (disk) names and mount points.
If you are in a situation where you can either temporarily delete a partition after having backed it up, or shrink an existing one to create a new one, then you should have some options available to you.
Do a "man resize2fs" and read that.
Sorry, I just found a way to get the info. Here is the result of df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda3 4.9G 4.2G 427M 91% / /dev/sda1 99M 17M 78M 18% /boot none 125M 0 125M 0% /dev/shm /dev/sda2 12G 683M 11G 7% /home
Instead of "df -h", "fdisk -l" would have been more useful. We want to see the actual partition layout of the partition table....
What I'd like to do is to take a couple of Gigs from /home and put them into / (root). I believe I can backup and erase /home without problems, but how can I put this space into root?
*IF* sda2 and sda3 are contiguous in the partition table (probably, but not guarenteed without looking at the actual allocation info) you might be able to resize(move) sda3 to the upper regions, re-size the partition sda3, then merge the new space onto the end of sda2. If you are lucky, you should then be able to expand sda2 into the re-claimed space. Not easy, but it should be straightforward if you know the right commands. If you have no experience doing this, I'd heartily recommend backing up the data in both sda2 & sda3 before attempting this for a first time!
Thanks
Good Luck!
Thanks for you reply, and sorry it took me so long to answer. It took me some time to realize I needed the - in the su command to get this to work. But here it is: [root@patroclus ~]# fdisk -l
Disk /dev/sda: 18.2 GB, 18210037760 bytes 255 heads, 63 sectors/track, 2213 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/sda1 * 1 13 104391 83 Linux /dev/sda2 14 1511 12032685 83 Linux /dev/sda3 1512 2148 5116702+ 83 Linux /dev/sda4 2149 2213 522112+ 5 Extended /dev/sda5 2149 2213 522081 82 Linux swap
Looking at this information and your request above, I would recommend the following.
1. Backup anything in the / partition that you want to keep. This includes config files, customizations, mail, web site data, etc.
If you want to do a full backup/restore you may be able to do that by using tar and creating a file in /home of all the data in / (but not including /home and space permitting)
2. Boot from some live distro such as knoppix, and use qtparted to resize sda2 smaller by the amount you want. Then remove and recreate sda3 to fill the new larger space.
3. Reinstall, or restore the data for sda3.
These 3 steps should handle what you are asking for
Jeff Vian wrote:
On Mon, 2004-11-29 at 06:32 -0600, Gustavo Seabra wrote:
Kevin J. Cummings wrote:
Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Mon, 2004-11-22 at 10:47 -0600, Gustavo Seabra wrote:
That was my second mistake ;-) I didn't use LVM... The way I saw it is, since I only have one HD, why should I need LVM? Now, from your post, it seems that LVM has advantages even for single HD, is that right?
By the way, since I didn't use LVM, and wat to increase the size of / (root) taking space from /home, am I just screwed?
Not necessarilly, it depends mostly on your partition layout. What partitions have you defined - please give device (disk) names and mount points.
If you are in a situation where you can either temporarily delete a partition after having backed it up, or shrink an existing one to create a new one, then you should have some options available to you.
Do a "man resize2fs" and read that.
Sorry, I just found a way to get the info. Here is the result of df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda3 4.9G 4.2G 427M 91% / /dev/sda1 99M 17M 78M 18% /boot none 125M 0 125M 0% /dev/shm /dev/sda2 12G 683M 11G 7% /home
Instead of "df -h", "fdisk -l" would have been more useful. We want to see the actual partition layout of the partition table....
What I'd like to do is to take a couple of Gigs from /home and put them into / (root). I believe I can backup and erase /home without problems, but how can I put this space into root?
*IF* sda2 and sda3 are contiguous in the partition table (probably, but not guarenteed without looking at the actual allocation info) you might be able to resize(move) sda3 to the upper regions, re-size the partition sda3, then merge the new space onto the end of sda2. If you are lucky, you should then be able to expand sda2 into the re-claimed space. Not easy, but it should be straightforward if you know the right commands. If you have no experience doing this, I'd heartily recommend backing up the data in both sda2 & sda3 before attempting this for a first time!
Thanks
Good Luck!
Thanks for you reply, and sorry it took me so long to answer. It took me some time to realize I needed the - in the su command to get this to work. But here it is: [root@patroclus ~]# fdisk -l
Disk /dev/sda: 18.2 GB, 18210037760 bytes 255 heads, 63 sectors/track, 2213 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/sda1 * 1 13 104391 83 Linux /dev/sda2 14 1511 12032685 83 Linux /dev/sda3 1512 2148 5116702+ 83 Linux /dev/sda4 2149 2213 522112+ 5 Extended /dev/sda5 2149 2213 522081 82 Linux swap
Looking at this information and your request above, I would recommend the following.
- Backup anything in the / partition that you want to keep. This
includes config files, customizations, mail, web site data, etc.
If you want to do a full backup/restore you may be able to do that by using tar and creating a file in /home of all the data in / (but not including /home and space permitting)
- Boot from some live distro such as knoppix, and use qtparted to
resize sda2 smaller by the amount you want. Then remove and recreate sda3 to fill the new larger space.
- Reinstall, or restore the data for sda3.
These 3 steps should handle what you are asking for
Thanks Jeff,
All would work perfectly if it wasn;t for one detail: QTParted doesn't resize ext3 partitions, as all of my partitions (but swap) are. So, I'm starting to believe that, if I want more space in root, I'll really have to reinstall the system.
Thanks,
On Wed, 1 Dec 2004, Gustavo Seabra wrote:
MASSIVE snip here ...
All would work perfectly if it wasn;t for one detail: QTParted doesn't resize ext3 partitions, as all of my partitions (but swap) are. So, I'm starting to believe that, if I want more space in root, I'll really have to reinstall the system.
from the snip, your root partition is almost 5G(!) in size, and 91% full, while there's lots of room left in /home. for now, if you want to do this less painfully, just leave that filesystem alone and figure out what parts you can move out of there (/tmp, /var, and so on). then make the /home filesystem smaller and *create* a new filesystem or two in the freed-up space, and remount.
it's not the optimal solution (really, the root filesystem should be at most 512M with lots of additional filesystems taking care of the rest), but for now, trying the above is fairly easy and doesn't involve messing with the root filesystem.
rday
On Wed, 2004-12-01 at 10:19 -0600, Gustavo Seabra wrote:
All would work perfectly if it wasn;t for one detail: QTParted doesn't resize ext3 partitions, as all of my partitions (but swap) are. So, I'm starting to believe that, if I want more space in root, I'll really have to reinstall the system.
So turn off the journal. Read the tune2fs manpage.
C. Linus Hicks wrote:
On Wed, 2004-12-01 at 10:19 -0600, Gustavo Seabra wrote:
All would work perfectly if it wasn;t for one detail: QTParted doesn't resize ext3 partitions, as all of my partitions (but swap) are. So, I'm starting to believe that, if I want more space in root, I'll really have to reinstall the system.
So turn off the journal. Read the tune2fs manpage.
What do you mean by "turn off the journal"?
On Wed, 2004-12-01 at 13:28 -0600, Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Wed, 2004-12-01 at 10:19 -0600, Gustavo Seabra wrote:
All would work perfectly if it wasn;t for one detail: QTParted doesn't resize ext3 partitions, as all of my partitions (but swap) are. So, I'm starting to believe that, if I want more space in root, I'll really have to reinstall the system.
So turn off the journal. Read the tune2fs manpage.
What do you mean by "turn off the journal"?
The only difference between an ext2 filesystem and ext3 is that the ext3 has a journal. Turn off the journal and you have an ext2 filesystem. The tune2fs manpage tells you how to do that. If you don't trust that on one of your live filesystems, experiment by creating a new filesystem (you don't have to have a free disk partition to do this, you can do it with a filesystem in a file) and make sure you know what you are doing before doing it for real. After you finish resizing, you can turn the journal back on and convert back to ext3.
Note that you can only turn the journal off when the filesystem is not mounted or mounted read-only, so you will have to do that using a rescue CD or some such.
C. Linus Hicks wrote:
On Wed, 2004-12-01 at 13:28 -0600, Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Wed, 2004-12-01 at 10:19 -0600, Gustavo Seabra wrote:
All would work perfectly if it wasn;t for one detail: QTParted doesn't resize ext3 partitions, as all of my partitions (but swap) are. So, I'm starting to believe that, if I want more space in root, I'll really have to reinstall the system.
So turn off the journal. Read the tune2fs manpage.
What do you mean by "turn off the journal"?
The only difference between an ext2 filesystem and ext3 is that the ext3 has a journal. Turn off the journal and you have an ext2 filesystem. The tune2fs manpage tells you how to do that. If you don't trust that on one of your live filesystems, experiment by creating a new filesystem (you don't have to have a free disk partition to do this, you can do it with a filesystem in a file) and make sure you know what you are doing before doing it for real. After you finish resizing, you can turn the journal back on and convert back to ext3.
Note that you can only turn the journal off when the filesystem is not mounted or mounted read-only, so you will have to do that using a rescue CD or some such.
How do I make a "filesystem in a file" ?
I also had a couple of problems: I backed up everything in my "/" partition inside /home. Then I tried booting with the System Rescue CD or Knoppix. In the first, I couldn't access any of my permanent partitions. In the second, I could only mount them as "read-only", so I would not be able to restore the "/" partition after resizing it, or would I? I mean, I must be able to read/write there after I re-create it, don't I? And how am I going to define the mount point as "/" after re-creating it?
You see, I still have a lot to learn. I'm starting to believe that this is just too much for my present knowledge, and maybe I should just "patch" things up with symlinks to somewhere in /home, at least untill it's time to reinstall the whole system again... (I should probably do it in about a year max.)
On Thursday 02 December 2004 10:59, Gustavo Seabra wrote:
How do I make a "filesystem in a file" ?
I'll answer first: mine's best:-)
dd if=/dev/zero of=bigfile count=0 seek=$((4*1024)) bs=$((1024*1024)) ls -Shosag bigfile mke2fs -q -F bigfile ls -Shossag bigfile sudo mount -o loop bigfile /mnt
The last assumes you have sudo installed and configured.
You could, of course, mount it over /tmp and Bob's your uncle:-)
Be aware that this is a little more frail than a filesystem on a partition: you have two layers of stuff to write. It's good for 1) Short-term stuff 2) Throw-away stuff. Like /tmp. 3) ro stuff. Like /usr - just back it up each time you change it. 4) Self-education.
btw I created an ext2 filesystem like that, populated it and burned to to dvd.
On Thu, 2004-12-02 at 10:59, Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Wed, 2004-12-01 at 13:28 -0600, Gustavo Seabra wrote:
C. Linus Hicks wrote:
On Wed, 2004-12-01 at 10:19 -0600, Gustavo Seabra wrote:
All would work perfectly if it wasn;t for one detail: QTParted doesn't resize ext3 partitions, as all of my partitions (but swap) are. So, I'm starting to believe that, if I want more space in root, I'll really have to reinstall the system.
So turn off the journal. Read the tune2fs manpage.
What do you mean by "turn off the journal"?
The only difference between an ext2 filesystem and ext3 is that the ext3 has a journal. Turn off the journal and you have an ext2 filesystem. The tune2fs manpage tells you how to do that. If you don't trust that on one of your live filesystems, experiment by creating a new filesystem (you don't have to have a free disk partition to do this, you can do it with a filesystem in a file) and make sure you know what you are doing before doing it for real. After you finish resizing, you can turn the journal back on and convert back to ext3.
Note that you can only turn the journal off when the filesystem is not mounted or mounted read-only, so you will have to do that using a rescue CD or some such.
How do I make a "filesystem in a file" ?
I also had a couple of problems: I backed up everything in my "/" partition inside /home. Then I tried booting with the System Rescue CD or Knoppix. In the first, I couldn't access any of my permanent partitions.
Are they mounted??
check $mount
In the second, I could only mount them as "read-only",
you can remount it read - write $ mount -o remount,rw /path/to/mount
so I would not be able to restore the "/" partition after resizing it, or would I? I mean, I must be able to read/write there after I re-create it, don't I? And how am I going to define the mount point as "/" after re-creating it?
I don't follow. (actually I did't follow the thread)
if you're booted into Knoppix or the rescue-cd, just fire up
vim /mnt/???/etc/fstab
edit the line that says which is your "/" partition to point to the new place where your "/" resides.
You see, I still have a lot to learn. I'm starting to believe that this is just too much for my present knowledge,
Experience is the best teacher, but if you don't start, experience won't come a-running.
and maybe I should just "patch" things up with symlinks to somewhere in /home, at least untill it's time to reinstall the whole system again... (I should probably do it in about a year max.)
--
Gustavo Seabra - Graduate Student Chemistry Department Kansas State University
-- Ow Mun Heng Gentoo/Linux on D600 1.4Ghz Neuromancer 11:27:11 up 1:38, 6 users, 0.09, 0.15, 0.26
On Wednesday 01 December 2004 10:59 pm, Gustavo Seabra wrote:
How do I make a "filesystem in a file" ?
Read this nice article: "Building A Linux Filesystem From An Ordinary File" http://freshmeat.net/articles/view/1387/
On Wed, 2004-12-01 at 20:59 -0600, Gustavo Seabra wrote:
How do I make a "filesystem in a file" ?
Here's one way:
# touch filesys # mke2fs -j ./filesys 4000 mke2fs 1.35 (28-Feb-2004) ./filesys is not a block special device. Proceed anyway? (y,n) y mke2fs: Filesystem larger than apparent device size. Proceed anyway? (y,n) y max_blocks 4096000, rsv_groups = 500, rsv_gdb = 15 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 504 inodes, 4000 blocks 200 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=4194304 1 block group 8192 blocks per group, 8192 fragments per group 504 inodes per group
Writing inode tables: done inode.i_blocks = 32, i_size = 67383296 Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. # ls -l filesys -rw-r--r-- 1 root root 4096000 Dec 1 15:11 filesys # mount ./filesys /mnt/img -o loop
Now you can create files in your new filesystem, play with it, then unmount it and turn off journaling. Mount it again and verify that all your files are okay. Once you have done this, you have gained some experience and can do it with other filesystems.
Actually, this won't solve your problem with QTparted. It doesn't support resizing ext3 or ext2 filesystems. And from playing around with parted, I think you would run into "Filesystem has incompatible feature enabled" errors if you tried using it.
I think your best bet on resizing is my original suggestion. Use resize2fs to resize the filesystem, then use fdisk to resize the partition.
C. Linus Hicks wrote:
<snip>
Actually, this won't solve your problem with QTparted. It doesn't support resizing ext3 or ext2 filesystems. And from playing around with parted, I think you would run into "Filesystem has incompatible feature enabled" errors if you tried using it.
Because, as I learned a few months ago, the filesystem was created with "sparse superblocks", which is the default behavior. A workaround is to always include -O ^sparse_super in the options string for mke2fs. The partition will then be resizable by parted, qtparted or Partition Magic. A bit more disk space is consumed in overhead but at today's storage costs, I really couldn't care less. YMMV
I think your best bet on resizing is my original suggestion. Use resize2fs to resize the filesystem, then use fdisk to resize the partition.
Robert wrote:
C. Linus Hicks wrote:
<snip>
Actually, this won't solve your problem with QTparted. It doesn't support resizing ext3 or ext2 filesystems. And from playing around with parted, I think you would run into "Filesystem has incompatible feature enabled" errors if you tried using it.
Because, as I learned a few months ago, the filesystem was created with "sparse superblocks", which is the default behavior. A workaround is to always include -O ^sparse_super in the options string for mke2fs. The partition will then be resizable by parted, qtparted or Partition Magic. A bit more disk space is consumed in overhead but at today's storage costs, I really couldn't care less. YMMV
I only wish I could have done it before ;-)