public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
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





      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