Re: Migrate OS to smaller drive?

2010-04-13 Thread Sjoerd Hardeman

Clive McBarton schreef:

Sjoerd Hardeman wrote:

Clive McBarton schreef:

Sjoerd Hardeman wrote:

mount the new device (mount -odev /dev/newdevice), and do a
 rsync -ax / /media/newdevice.

What exactly is the advantage of this approach over cp -a or mv?

Added to the points others make the don't cross filesystem
borders-option (-x), which makes it useful for the task at hand. Then
again, now probably somebody will reply that cp can do that too...


Indeed. The option for cp even has exactly the same name as the option
for rsync, namely -x or --one-file-system.
That indeed makes sense, but I was to lazy to look in the manpages. I 
guess I am a rsync fanboy ;)


Sjoerd



signature.asc
Description: OpenPGP digital signature


Re: Migrate OS to smaller drive?

2010-04-12 Thread Mark
On Sat, Apr 10, 2010 at 2:12 PM, vr debian-u...@iotk.net wrote:

 What's the best mechanism to migrate a working bootable system from one
 drive to a smaller capacity drive?


How about Clonezilla, clone mode, not image mode?

Mark


Re: Migrate OS to smaller drive?

2010-04-12 Thread Sjoerd Hardeman

Ron Johnson schreef:

On 2010-04-12 03:14, Sjoerd Hardeman wrote:

Ron Johnson schreef:

On 2010-04-11 15:54, Sjoerd Hardeman wrote:

Ron Johnson schreef:

On 2010-04-11 08:11, Clive McBarton wrote:

Sjoerd Hardeman wrote:

mount the new device (mount -odev /dev/newdevice), and do a
 rsync -ax / /media/newdevice.

What exactly is the advantage of this approach over cp -a or mv?

I would have suggested mv. It has the useful property that you can
easily spot aborted transfers by the fact that the original device is
not empty afterwards.
One note is that I've had issues where symlinks remain pointing to 
the old drive.  (That was a long time ago, though, and maybe I did 
something

wrong.)

I thought symlinks keep point via a file location memo, like look at
/usr/share/the/file/you/want, which is the old location just after
copying, but the new location when you boot from your new device and
that becomes root.



Note how at the bottom or this example bar/shoe still points to 
../snuffle/shoe/.  When you try to cp -axv / /some/new/root the 
same thing will happen.   In /usr/bin all the symlinks to 
/etc/alternatives will still point to the *current* /etc/alternatives 
not to /some/new/root/etc/alternatives.
As expected, thus. So when change your fstab to let /some/new/root 
become / then all the symlinks are as they should be.




There's only one way to find out...
Well, I once migrated with these options from an almost broken hard 
drive to a working one, and I didn't run into problems with symlinks. SO 
most likely, it just works


Sjoerd




signature.asc
Description: OpenPGP digital signature


Re: Migrate OS to smaller drive?

2010-04-12 Thread Stephen Powell
On Sun, 11 Apr 2010 23:44:07 -0400 (EDT), thib wrote:
 
 Well, as I said in another branch of the thread, you can shrink most 
 filesystems, including all extfs (I think the only bad boy here is XFS), 
 look at resize2fs(8) from e2fsprogs for these.

vr, it looks like you've already received plenty of suggestions, but
I just thought I'd mention that I have developed a migration procedure
that you may be able to adapt to your situation.  I have a web page
which I developed for how to use a high-performance disk driver
under Debian for the s390 platform.  As it turns out, the high performance
driver doesn't work with the type of disks supported by the Debian
installer; so that means installing to one type of disk and then
migrating to another type of disk after the install.  Perhaps the
migration procedure documented therein can be adapted to your purposes.
The low-level formatting and partitioning steps are quite different
on this platform from PCs.  But creating the file systems and copying
the data are relatively platform independent.  You'll have to discern
what is platform specific and either disregard or adapt it.  But
anyway, here's the link, in case you find it useful.

   http://www.wowway.com/~zlinuxman/diag250.htm

-- 
  .''`. Stephen Powellzlinux...@wowway.com
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/488551811.2636611271086298336.javamail.r...@md01.wow.synacor.com



Re: Migrate OS to smaller drive?

2010-04-12 Thread Clive McBarton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sjoerd Hardeman wrote:
 Clive McBarton schreef:
 Sjoerd Hardeman wrote:
 mount the new device (mount -odev /dev/newdevice), and do a
  rsync -ax / /media/newdevice.
 What exactly is the advantage of this approach over cp -a or mv?
 Added to the points others make the don't cross filesystem
 borders-option (-x), which makes it useful for the task at hand. Then
 again, now probably somebody will reply that cp can do that too...

Indeed. The option for cp even has exactly the same name as the option
for rsync, namely -x or --one-file-system.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvDqfcACgkQ+VSRxYk4409OSwCfQUbrWYLwoNQME/98sIdFSzNd
Y+4AnRkojnSeHm77jVJzPi1g497+U+Yp
=VbRe
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc3a9f7.6090...@web.de



Re: Migrate OS to smaller drive?

2010-04-11 Thread Clive McBarton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sjoerd Hardeman wrote:
 mount the new device (mount -odev /dev/newdevice), and do a
  rsync -ax / /media/newdevice.

What exactly is the advantage of this approach over cp -a or mv?

I would have suggested mv. It has the useful property that you can
easily spot aborted transfers by the fact that the original device is
not empty afterwards.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvBymgACgkQ+VSRxYk440+GBQCgq0EvrFUI7Hm4A8Q73ncz7KTF
51UAn0weYuo1nka6TqTxggBp4Y/tzA8O
=QZnM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc1ca69.4080...@web.de



Re: Migrate OS to smaller drive?

2010-04-11 Thread Eduardo M KALINOWSKI

On 04/11/2010 10:11 AM, Clive McBarton wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sjoerd Hardeman wrote:
   

mount the new device (mount -odev /dev/newdevice), and do a
  rsync -ax / /media/newdevice.
 

What exactly is the advantage of this approach over cp -a or mv?
   


Over mv? That you keep the original files.

Over cp? That you can resume from where you left off in case the 
transfer is stopped for any reason.



--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec

Eduardo M KALINOWSKI
edua...@kalinowski.com.br


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc1ca98.4070...@kalinowski.com.br



Re: Migrate OS to smaller drive?

2010-04-11 Thread Clive McBarton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eduardo M KALINOWSKI wrote:
 mount the new device (mount -odev /dev/newdevice), and do a
   rsync -ax / /media/newdevice.
  
 What exactly is the advantage of this approach over cp -a or mv?

 
 Over mv? That you keep the original files.

Of course. But in this case the OP said migrate.

 Over cp? That you can resume from where you left off in case the
 transfer is stopped for any reason.

Useful point. With cp you'd have to start over.

What are the disadvantages of rsync? E.g., doesn't it compress and
decompress everything, hence hogging the CPU and possibly slowing transfers?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvBzscACgkQ+VSRxYk4409N6QCg2H+F4XhpS/eRmSUaxiFAZG5v
nNUAoL1+BijzOvhecWOzULmWvIBJ2Nyb
=FU3d
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc1cec7.7030...@web.de



Re: Migrate OS to smaller drive?

2010-04-11 Thread Ron Johnson

On 2010-04-11 08:11, Clive McBarton wrote:


Sjoerd Hardeman wrote:

mount the new device (mount -odev /dev/newdevice), and do a
 rsync -ax / /media/newdevice.


What exactly is the advantage of this approach over cp -a or mv?

I would have suggested mv. It has the useful property that you can
easily spot aborted transfers by the fact that the original device is
not empty afterwards.


One note is that I've had issues where symlinks remain pointing to 
the  old drive.  (That was a long time ago, though, and maybe I did 
something wrong.)


tar might also work, given the appropriate flags.

--
Dissent is patriotic, remember?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc1e301.8020...@cox.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread Ron Johnson

On 2010-04-11 08:29, Clive McBarton wrote:


Eduardo M KALINOWSKI wrote:

mount the new device (mount -odev /dev/newdevice), and do a
  rsync -ax / /media/newdevice.
 

What exactly is the advantage of this approach over cp -a or mv?
   

Over mv? That you keep the original files.


Of course. But in this case the OP said migrate.


O.  Remind me never to have you work on my computer.

Never destroy the original until you know the copy works!


Over cp? That you can resume from where you left off in case the
transfer is stopped for any reason.


Useful point. With cp you'd have to start over.

What are the disadvantages of rsync? E.g., doesn't it compress and
decompress everything,


Only if you want it to.


   hence hogging the CPU


You won't be doing anything else at the time...


and possibly slowing transfers?


Hah.  Speeding up transfers is more likely, since the wire is always 
the bottleneck, and compression means it will be carrying more bits 
per bit.


--
Dissent is patriotic, remember?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc1e472.8060...@cox.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread thib
Others suggested using filesystem-level tools, which is really fine. 
Alternatively, you can shrink the filesystem and move the entire block at once.


Each method probably has its pros and cons.

-thib


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc22782.8060...@stammed.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread Sjoerd Hardeman
Clive McBarton schreef:
 Sjoerd Hardeman wrote:
 mount the new device (mount -odev /dev/newdevice), and do a
  rsync -ax / /media/newdevice.
 
 What exactly is the advantage of this approach over cp -a or mv?
Added to the points others make the don't cross filesystem
borders-option (-x), which makes it useful for the task at hand. Then
again, now probably somebody will reply that cp can do that too...

Sjoerd



signature.asc
Description: OpenPGP digital signature


Re: Migrate OS to smaller drive?

2010-04-11 Thread Clive McBarton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ron Johnson wrote:
Never destroy the original until you know the copy works!

In my earlier days I would have avoided mv for exactly that reason. But
when copying (including rsync), you cannot easily see that it worked
from the emptyness of the original file system. And comparing large
filesystem trees (not just 4GB as in this case) is trickier than most
people realize. At least a simple diff -r will be far from doing it.
Maybe you have some good way of comparing FS trees?

hence hogging the CPU
 
 You won't be doing anything else at the time...

The OP didn't say that. Maybe you would do it that way. Maybe me too.
Not that it matters once compression is disabled.


 and possibly slowing
 transfers?
 
 Hah.  Speeding up transfers is more likely, since the wire is always the
 bottleneck, and compression means it will be carrying more bits per bit.

There's no mention of wire transfer anywhere in this thread, and in fact
for most people the upload of 4GB would be too much anyway. I presume
he has both drives build into the same computer. Note that he talks
about migrating / .

Cases of remote transfer (transferring / to a remote machine, which must
hence already have a / ) are theoretically possible but probably not
relevant here.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvCNrwACgkQ+VSRxYk440/d8wCgkOhMNQfa7OTWUEtcdCKJ5mdr
H20AoNgy5CYLmTdy1Ki1DK4dj58uIe/r
=CzO1
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc236bc.1050...@web.de



Re: Migrate OS to smaller drive?

2010-04-11 Thread Sjoerd Hardeman
Ron Johnson schreef:
 On 2010-04-11 08:11, Clive McBarton wrote:

 Sjoerd Hardeman wrote:
 mount the new device (mount -odev /dev/newdevice), and do a
  rsync -ax / /media/newdevice.

 What exactly is the advantage of this approach over cp -a or mv?

 I would have suggested mv. It has the useful property that you can
 easily spot aborted transfers by the fact that the original device is
 not empty afterwards.
 
 One note is that I've had issues where symlinks remain pointing to the 
 old drive.  (That was a long time ago, though, and maybe I did something
 wrong.)
I thought symlinks keep point via a file location memo, like look at
/usr/share/the/file/you/want, which is the old location just after
copying, but the new location when you boot from your new device and
that becomes root.

Sjoerd



signature.asc
Description: OpenPGP digital signature


Re: Migrate OS to smaller drive?

2010-04-11 Thread thib

Clive McBarton wrote:

Ron Johnson wrote:

Never destroy the original until you know the copy works!


In my earlier days I would have avoided mv for exactly that reason. But
when copying (including rsync), you cannot easily see that it worked
from the emptyness of the original file system. And comparing large
filesystem trees (not just 4GB as in this case) is trickier than most
people realize. At least a simple diff -r will be far from doing it.
Maybe you have some good way of comparing FS trees?

 [snip]


Including rsync?  I'd say that's the exact purpose of rsync.

Anyway, there are many filesystem comparison tools if one wants to do it 
manually, like dirdiff.  For file contents, just hash and re-hash.


-thib


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc23ba5.7030...@stammed.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread thib

Sjoerd Hardeman wrote:

I thought symlinks keep point via a file location memo, like look at
/usr/share/the/file/you/want, which is the old location just after
copying, but the new location when you boot from your new device and
that becomes root.


A tool that tries to be too smart could try to relocate it.

Not sure how it would work out though;  you'd probably have to be inside the 
new system, copying files from the old one, and not the other way around.


-thib


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc23c70.60...@stammed.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread Ron Johnson

On 2010-04-11 15:53, Clive McBarton wrote:


Ron Johnson wrote:

Hah.  Speeding up transfers is more likely, since the wire is always the
bottleneck, and compression means it will be carrying more bits per bit.


There's no mention of wire transfer anywhere in this thread, and in fact


Yes, wire is slang for network cables, but SATA cables are actual 
wires too and orders of magnitude slower than CPU/RAM transfer.


--
Dissent is patriotic, remember?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc24655.80...@cox.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread Ron Johnson

On 2010-04-11 15:54, Sjoerd Hardeman wrote:

Ron Johnson schreef:

On 2010-04-11 08:11, Clive McBarton wrote:

Sjoerd Hardeman wrote:

mount the new device (mount -odev /dev/newdevice), and do a
 rsync -ax / /media/newdevice.

What exactly is the advantage of this approach over cp -a or mv?

I would have suggested mv. It has the useful property that you can
easily spot aborted transfers by the fact that the original device is
not empty afterwards.
One note is that I've had issues where symlinks remain pointing to the 
old drive.  (That was a long time ago, though, and maybe I did something

wrong.)

I thought symlinks keep point via a file location memo, like look at
/usr/share/the/file/you/want, which is the old location just after
copying, but the new location when you boot from your new device and
that becomes root.



Note how at the bottom or this example bar/shoe still points to 
../snuffle/shoe/.  When you try to cp -axv / /some/new/root the 
same thing will happen.   In /usr/bin all the symlinks to 
/etc/alternatives will still point to the *current* 
/etc/alternatives not to /some/new/root/etc/alternatives.


$ mkdir foo/snaggle snuffle/shoe
$ cd foo
$ ln -sf ../snuffle/shoe .
$ dir
total 44
drwxr-xr-x   3 me me  4096 2010-04-11 17:12:44 ./
drwxr-xr-x 206 me me 36864 2010-04-11 17:12:04 ../
lrwxrwxrwx   1 me me15 2010-04-11 17:12:44 shoe - ../snuffle/shoe/
drwxr-xr-x   2 me me  4096 2010-04-11 17:12:04 snaggle/

$ cd ..
$ cp -av foo bar
`foo' - `bar'
`foo/snaggle' - `bar/snaggle'
`foo/shoe' - `bar/shoe'

$ dir bar
total 44
drwxr-xr-x   3 me me  4096 2010-04-11 17:12:44 ./
drwxr-xr-x 207 me me 36864 2010-04-11 17:13:54 ../
lrwxrwxrwx   1 me me15 2010-04-11 17:12:44 shoe - ../snuffle/shoe/
drwxr-xr-x   2 me me  4096 2010-04-11 17:12:04 snaggle/

--
Dissent is patriotic, remember?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc24b54.5060...@cox.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread thib

Ron Johnson wrote:
Yes, wire is slang for network cables, but SATA cables are actual 
wires too and orders of magnitude slower than CPU/RAM transfer.


This is true, but isn't relevant to what you suggested.
Think about it some more.

...

Oh yes.

We'll never talk about this again, I promise.

-thib

PS  I'll tell you something embarrassing about me if you find a SATA 
controller that can inflate.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc26019.4080...@stammed.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread Ron Johnson

On 2010-04-11 18:49, thib wrote:

Ron Johnson wrote:
Yes, wire is slang for network cables, but SATA cables are actual 
wires too and orders of magnitude slower than CPU/RAM transfer.


This is true, but isn't relevant to what you suggested.
Think about it some more.

...

Oh yes.

We'll never talk about this again, I promise.

-thib

PS  I'll tell you something embarrassing about me if you find a SATA 
controller that can inflate.




You're absolutely correct.  This time...

--
Dissent is patriotic, remember?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc26996.9030...@cox.net



Re: Migrate OS to smaller drive?

2010-04-11 Thread vr
On Sun, 11 Apr 2010 19:30:14 -0500, Ron Johnson ron.l.john...@cox.net
wrote:
 On 2010-04-11 18:49, thib wrote:
 Ron Johnson wrote:
 Yes, wire is slang for network cables, but SATA cables are actual 
 wires too and orders of magnitude slower than CPU/RAM transfer.
 
 This is true, but isn't relevant to what you suggested.
 Think about it some more.
 
 ...
 
 Oh yes.
 
 We'll never talk about this again, I promise.
 
 -thib
 
 PS  I'll tell you something embarrassing about me if you find a SATA 
 controller that can inflate.
 
 
 You're absolutely correct.  This time...
 

I've used dd to push a copy of a working system onto larger drives in the
past. So my misuse of the term migrate is me actually doing a copy of the
working system to a new, larger device and then zap the original.

I'd hoped there was a block by block way to do it so I didn't have to set
up the partitions  filesystems ahead of time but I suppose that part won't
be too painful.

The system is relatively idle during these types of surgeries because I
boot from a live CD so the data on disk isn't churning.

Thanks to all who responded, it gave me a lot to consider for this type of
project. Like doing proper diffs afterwards to make sure everything landed
on the new device properly!


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/f6af5a3f47ea48bd1e0f695949793...@192.168.0.66



Re: Migrate OS to smaller drive?

2010-04-11 Thread Stan Hoeppner
vr put forth on 4/11/2010 8:49 PM:

 I've used dd to push a copy of a working system onto larger drives in the
 past. So my misuse of the term migrate is me actually doing a copy of the
 working system to a new, larger device and then zap the original.
 
 I'd hoped there was a block by block way to do it so I didn't have to set
 up the partitions  filesystems ahead of time but I suppose that part won't
 be too painful.
 
 The system is relatively idle during these types of surgeries because I
 boot from a live CD so the data on disk isn't churning.

The last system (server) I migrated was from a 40GB IDE to a 500GB SATA on a
new add-in PCI SATA card.  Once I got the sata_sil and libata drivers
squared away, new partitions created on the new drive, I stopped all the
necessary potential problem child daemons, and used cp -a to move
everything over, one directory at a time.  I chose this method based on
advice I received here.  I confirmed correct copying of each dir as I went.

I even did this in runlevel 2 via an SSH session instead of single user mode
(I don't like the limited 80x25 physical console).  Last thing I changed was
/etc/fstab on the new drive, ran LILO, powered down, decabled the old drive,
powered up, changed the boot device order, the system booted from the SATA
drive, and everything worked, with a couple of exceptions in /dev/ which
aren't actually created automatically on each boot as I'd previously
thought.  Once I manually created these devs everything worked fine and has
since.  Previously the system was basically just a Postfix firewall/gateway,
and now I've also got Dovecot, Lighty, Samba, and all other kinds of servers
running successfully.  It's amazing what new life a fresh fast big disk can
breath into an old server.  Due to an unknown problem with the old IDE drive
I was only getting 7MB/s transfer rate out of it.  I'm getting 80MB/s with
the new drive. :)  The machine has a completely different character now,
quick and responsive.

I was actually very surprised at how smoothly the cp -a migration went.
This easy migration is just one of the many reasons I love Linux.  And I
find more reasons all the time. ;)

-- 
Stan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc28ed0.7050...@hardwarefreak.com



Re: Migrate OS to smaller drive?

2010-04-11 Thread thib

vr wrote:

[snip]

I'd hoped there was a block by block way to do it so I didn't have to set
up the partitions  filesystems ahead of time but I suppose that part won't
be too painful.


Well, as I said in another branch of the thread, you can shrink most 
filesystems, including all extfs (I think the only bad boy here is XFS), 
look at resize2fs(8) from e2fsprogs for these.


Again, the solution is not necessarily better nor simpler, just different.


The system is relatively idle during these types of surgeries because I
boot from a live CD so the data on disk isn't churning.


That's good, and I'd say that's even necessary if you don't have 
snapshotting tools (LVM2 is good at it).



[snip]


-thib


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4bc29707.8050...@stammed.net



Migrate OS to smaller drive?

2010-04-10 Thread vr
What's the best mechanism to migrate a working bootable system from one
drive to a smaller capacity drive?

e.g. take this 226G filesystem

df -h
FilesystemSize  Used Avail Use% Mounted on
/dev/sdb1 226G  4.1G  210G   2% /
tmpfs 3.0G 0  3.0G   0% /lib/init/rw
udev  3.0G  244K  3.0G   1% /dev
tmpfs 3.0G 0  3.0G   0% /dev/shm

and transfer it onto say a 32G drive?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/3cc33b52b344d44be33167a82fe30...@192.168.0.66



Re: Migrate OS to smaller drive?

2010-04-10 Thread Sjoerd Hardeman
vr schreef:
 What's the best mechanism to migrate a working bootable system from one
 drive to a smaller capacity drive?
 
 e.g. take this 226G filesystem
 
 df -h
 FilesystemSize  Used Avail Use% Mounted on
 /dev/sdb1 226G  4.1G  210G   2% /
 tmpfs 3.0G 0  3.0G   0% /lib/init/rw
 udev  3.0G  244K  3.0G   1% /dev
 tmpfs 3.0G 0  3.0G   0% /dev/shm
 
 and transfer it onto say a 32G drive?
mount the new device (mount -odev /dev/newdevice), and do a
 rsync -ax / /media/newdevice.
Then do a chroot /media/newdevice, grub-install /dev/newdevice

Sjoerd



signature.asc
Description: OpenPGP digital signature