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
next prev parent 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