From: meino.cramer@gmx.de
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Gentoo SDcard updates tactics
Date: Tue, 7 Oct 2014 18:01:40 +0200 [thread overview]
Message-ID: <20141007160140.GC3826@solfire> (raw)
In-Reply-To: <20141007073939.GB19166@TranscendTheRubicon.alshain.ring0>
Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> [14-10-07 17:23]:
> On Tue, Oct 07, 2014 at 05:29:11AM +0200, meino.cramer@gmx.de wrote:
> > Hi,
> >
> > There are two SDcards of the same brand and model.
> > The first one cariies a not so current Gentoo Linux.
> > The second one is empty.
> > Now the first one is image-copied to the second one with dd,
> > which copies the contents of the whole device (not the partitions).
> >
> > Then the first one is put into my embedded system, boots up and
> > the normal eix-syn/emerge/compiel is done to update the system (whch
> > takes a longer time becaus this is an embedded system).
> >
> > Will I get a technical identical working and valid copy of the first sdcard onto
> > the second sdcard if I rsync the relevant partition of the first onto
> > the second sdcard.
> >
> > Or will I produce crap this way? Is this valid Gentoo-wise?
> >
>
> Moin (again),
>
> this will work quite well, at least if you take care (I used this way for
> moving my systems to new drives or even via network to different boxes (in the
> latter case CFLAGS and kernel config will become important again, as you can
> imagine)).
> Ideally you should run rsync with the option to remove files not found on the
> source drive (otherwise you'll likely clutter the target with stale files
> (especially documentation but also older library versions).
> You will also need to change the configs (at least static network & hostname,
> possibly more) so that both systems don't clash, at least if you plan to run
> both on the same network.
> The "rm" option of rsync is potentially dangerous (e.g. you can delete files
> from home).
> If you are careful this is a valid way of doing that. Another option that would
> move quite a bit work from one machine to the other is just building binpkgs on
> one host and use the other one as binhost. That way (if you use identical
> /etc/portage dirs) you can quite savely use portage and nonetheless negate the
> use of compiling (there will still be the load of dependency resplution,
> extracting etc).
>
> WKR
> Hinnerk
Moin Hinnerk, ;)
Good points...I have not thought deep enough about it - I think
(recursion?)...
Currently the "master card" is being updated via eix/emerge...and
then... :)
Best regards,
Meino
prev parent reply other threads:[~2014-10-07 16:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 3:29 [gentoo-user] Gentoo SDcard updates tactics meino.cramer
2014-10-07 4:29 ` Alec Ten Harmsel
2014-10-07 7:49 ` Neil Bothwick
2014-10-07 7:39 ` Hinnerk van Bruinehsen
2014-10-07 16:01 ` meino.cramer [this message]
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=20141007160140.GC3826@solfire \
--to=meino.cramer@gmx.de \
--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