Re: Repartitioning questions
On Wed, 8 Oct 2003 23:43:10 +0200, Tom <tom@abwaerts.be> penned:
> Hey ho,
>
> Due to some bad initial partitioning scheme, I'm now stuck with WinXP
> on C: (/dev/hda1) and a FAT32-partition on /dev/hda2. Then comes
> Debian, installed on some logical partitions.
>
> I would like to shrink the FAT-partition (which is way too big), and -
> of course - regain the freed space for Debian. For some reason or
> another, I think it's not quite possible to do just that.
It kind of depends, but resizing partitions is always slightly risky.
parted can do resizing in certain limited cases; you could buy
partitionmagic, but I personally have had it completely fubar my drive
once.
> Which is why I figured it might be easier to just back up as much as
> possible, repartition, and then copy the backups to where they came
> from.
>
> My question being: is it possible to just copy whole directory trees
> and put them back afterwards? I know that's not a problem at all with
> /home or /etc, but can I do the same with /var or /usr? Will
> everything still properly function afterwards (like, for example, dpkg
> & apt)? Or is it just a master plan to reach chaos, panic and
> disorder?
>
I'd be more concerned about Windows, which can have problems if certain
files aren't within the first X gigs (I don't remember what number X is;
maybe 8). AFAIK this still wasn't fixed as of XP.
I can't imagine you having a problem with /var and /usr moving *as long
as* you're not using them at the time. That means booting from another
disk (floppy, CD, other hard drive). Single-user mode might work, too
-- I'm not sure.
Here are my personal notes for switching hard drives. It's actually for
use when moving the contents of a smaller drive onto a larger drive, but
it may be helpful.
1. Partition the new hard drive. GNU's "parted" is pretty spiff.
http://www.gnu.org/software/parted/parted.html
http://www.gnu.org/manual/parted-1.6.1/html_mono/parted.html
2. Boot using a linux floppy. You don't want to deal with trying to
copy a system that's in motion. Copy your stuff over. Use "cp -a
orig/* new" to preserve symbolic links.
3. Edit lilo.conf carefully. All device values should be set to where
they *will* be after you boot, not to where they are now on the IDE
chain. (Maybe the new drive is currently at /dev/hdc, but if it will be
on the first IDE slot in the finished state, set the value to /dev/hda.)
Set "boot" to the drive to which you'll be writing the MBR. Set "root"
to the partition that will be set to "/". Make sure that "image" points
to a file that will point to a real location and will be within the
first 2G of the drive. (Not sure that is necessary, but why take
chances?)
If the new hard drive is not on the same spot on the IDE as it will be
when you're through, use the "-b" argument to lilo. (I.E., if your
lilo.conf says "boot=/dev/hda" but at the moment the new drive is on
/dev/hdc, use "lilo -b /dev/hdc" so that you don't clobber your old
drive.)
4. Edit fstab carefully. All device values should be set to where they
*will* be after you boot, not where they are now on the IDE chain.
5. Mount the new root partition somewhere. Mount any other partitions
that you will need for lilo (i.e., /etc and /boot) beneath it. Run
"chroot /new_root /sbin/lilo" (if the drive isn't in the location
specified in "boot" of lilo.conf, use the "-b" argument).
6. Reboot. Make sure the new drive is in the place specified in fstab
and lilo.conf.
Errors: If you get a lilo error, doublecheck "boot" and "root" in lilo.conf.
dd will cause the partition to think it's the size of the original
partition -- don't do this unless you're creating an identical copy on
an identical drive.
--
monique
Please respond to the group OR to my email, but not both. (Group preferred.)
Reply to: