public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kerin Millar <kerframil@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Moving the system from one disk to another
Date: Mon, 05 Apr 2010 01:16:47 +0100	[thread overview]
Message-ID: <hpba5h$2v3$1@dough.gmane.org> (raw)
In-Reply-To: <20100405015156.35c47be3@matrix.inten.pl>

On 05/04/2010 00:51, Kacper Kopczyński wrote:
> Dnia 2010-04-04, o godz. 21:04:03
> Neil Bothwick<neil@digimed.co.uk>  napisał(a):
>
>> On Sun, 04 Apr 2010 20:35:11 +0100, Kerin Millar wrote:
>>
>>> Whichever way you go about it, ensure that no pseudo-filesystem or
>>> bind mounts are present within "/mnt/oldrootfs" at the time.
>>
>> Use the -x option with rsync to stop it descending into other
>> filesystems.
>>
>>
>
> AFAIK
>
> "mount --bind / /somewhere" and rsync'ing /somewhere/ instead of / would
> be more useful then "-x" option - stage1,2,3 has static /dev entries
> which should also be copied. Since udev mounts it with tmpfs, rsync
> with -x would skip those entries (static and from tmpfs).

Well, no, because my response was based on the fact that the duplication 
will be carried out from an alternate environment provided by a CD/DVD, 
as Meino clearly stated in the original post. Thus, bind mounts, 
pseudo-filesystems and chroots need not come into the equation 
whatsoever. Indeed, it's the very same concern that you express which 
resulted in my recommendation to avoid such shenanigans and keep it 
simple. Ergo, just mount the root filesystem - nothing else - and copy 
it as-is. Static /dev entries would be copied without issue, as would 
everything else. It really couldn't be simpler.

You post hinges on the notion that he would be performing the process 
while booted from the system he is duplicating, in which case your 
advice would, of course, be entirely sensible. Ergo, he would indeed be 
best advised to bind mount / to a temporary directory and use that as 
the source for the exact reasons that you mention. I personally would 
not recommend doing it under these circumstances but it can certainly be 
done (though I'd suggest dropping to runlevel 1 first).

Cheers,

--Kerin




  reply	other threads:[~2010-04-05  1:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-04 19:05 [gentoo-user] Moving the system from one disk to another meino.cramer
2010-04-04 19:09 ` covici
2010-04-04 19:35 ` [gentoo-user] " Kerin Millar
2010-04-04 20:04   ` Neil Bothwick
2010-04-04 23:51     ` Kacper Kopczyński
2010-04-05  0:16       ` Kerin Millar [this message]
2010-04-05  1:34     ` walt
2010-04-05  1:49       ` Kerin Millar
2010-04-05  7:03       ` Neil Bothwick
     [not found]         ` <201004051201.30038.michaelkintzios@gmail.com>
2010-04-05 11:10           ` Neil Bothwick
2010-04-06  2:51 ` [gentoo-user] " Dale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='hpba5h$2v3$1@dough.gmane.org' \
    --to=kerframil@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox