From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5DD0013838B for ; Tue, 7 Oct 2014 07:40:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ED611E08EB; Tue, 7 Oct 2014 07:39:55 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 998E7E0883 for ; Tue, 7 Oct 2014 07:39:54 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for gentoo-user@lists.gentoo.org with esmtp (envelope-from ) id <1XbPNB-003Dsy-66>; Tue, 07 Oct 2014 09:39:53 +0200 Received: from zb3e1.pia.fu-berlin.de ([87.77.179.225] helo=TranscendTheRubicon.alshain.ring0) by inpost2.zedat.fu-berlin.de (Exim 4.82) for gentoo-user@lists.gentoo.org with esmtpsa (envelope-from ) id <1XbPNB-0003HU-4p>; Tue, 07 Oct 2014 09:39:53 +0200 Date: Tue, 7 Oct 2014 09:39:39 +0200 From: Hinnerk van Bruinehsen To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Gentoo SDcard updates tactics Message-ID: <20141007073939.GB19166@TranscendTheRubicon.alshain.ring0> References: <20141007032911.GA18442@solfire> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline In-Reply-To: <20141007032911.GA18442@solfire> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: 87.77.179.225 X-ZEDAT-Hint: A X-Archives-Salt: 1c209d03-45a7-42b4-a304-11e9bfb32a0d X-Archives-Hash: 4a1923a9547a5e94fcd3b8bb3af95420 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 07, 2014 at 05:29:11AM +0200, meino.cramer@gmx.de wrote: > Hi, >=20 > 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). >=20 > 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). >=20 > Will I get a technical identical working and valid copy of the first sdca= rd onto > the second sdcard if I rsync the relevant partition of the first onto > the second sdcard. >=20 > Or will I produce crap this way? Is this valid Gentoo-wise? >=20 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 t= he 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 & hostnam= e, 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 =66rom home). If you are careful this is a valid way of doing that. Another option that w= ould move quite a bit work from one machine to the other is just building binpkg= s 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 --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUM5i7AAoJEJwwOFaNFkYcIasH/1TpM4kwUGOVWdPF1DhQKNLU C8AV86WWxS6w1VU3ltp4YtSE8aCXTDp8WacpBLPMrEjpURWY3h/N+HXGWF0yS9RH 40xH8ISBqpYTi+kAhHRz6Vns3RgW73y044NOjXBZtbFBGQmTxQvfCdTv5G9RlVlJ vcoheKUEtpjG3cIugxa1Vn3nvQbJkmPLe/EuzZpvrlxx4dloYRZliKD82Fbp0zRg ZwZ4Gnge3kGoTz8bDIPbZvB96vtP/8pVE/XRKrDfD9fVYhE5VtIZaffxdmU8rTP/ 30OGKtPeUi+EDkI7z/dBiwq6xI/JYU7pOZn107muJNX1P55iQ0Os1SHfhw6RbM8= =Imkj -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW--