From owner-freebsd-arm@freebsd.org Mon Jul 11 15:20:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D308B920D4 for ; Mon, 11 Jul 2016 15:20:35 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1600D1AC4 for ; Mon, 11 Jul 2016 15:20:34 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id D8E8278D; Mon, 11 Jul 2016 11:20:33 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld From: Paul Mather In-Reply-To: Date: Mon, 11 Jul 2016 11:20:33 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0979D126-85A1-4AD2-B99D-C0D1272E5A16@gromit.dlib.vt.edu> References: <4876c9e05d5.30c7197a@mail.schwarzes.net> <20160711050802.4743251.48194.8248@gmail.com> <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:20:35 -0000 On Jul 11, 2016, at 10:00 AM, Karl Denninger wrote: > On 7/11/2016 08:54, Paul Mather wrote: >> On Jul 11, 2016, at 9:24 AM, Karl Denninger = wrote: >>=20 >>> On 7/11/2016 07:51, Paul Mather wrote: >>>> On Jul 11, 2016, at 1:08 AM, Russell Haley = wrote: >>>>=20 >>>>> Sorry about the top post.=20 >>>>>=20 >>>>> If your not trying to learn about the build process and=E2=80=8E = you don't have a custom build requirement, why not use a prebuilt image = move on to validating the running OS instead of repeating what the build = server does? >>>>>=20 >>>>> I would think there is more value in finding anomalies in your = favorite applications. =46rom my understanding there have been big = changes to the fundamentals of the OS (i.e hard float, compiler = upgrades, byte alignments etc). >>>> Speaking for myself, I just find the build{world,kernel} + = install{kernel,world} + mergemaster sequence of updating the system a = much more ingrained and normal method of doing things. It seems = "natural" to me to update my FreeBSD/arm systems the same way I update = my FreeBSD/amd64 systems. >>>>=20 >>>> Besides, if I overwrote my SD card with a new install image, I'd = lose all my settings (e.g., users, custom /usr/local/etc/pkg/repos/ = repository, swap partition on SD card, /etc/fstab changes to make /tmp = bigger[*], etc.). It's more natural for me to use the standard update = technique than redo those changes from scratch each time I update the = OS. (I'm using SaltStack to configure more and more, but even getting a = minion set up means it's easier to update the standard way than start = with a fresh install image and have to re-bootstrap SaltStack.) >>>>=20 >>>> Cheers, >>>>=20 >>>> Paul. >>>>=20 >>> The reason I do the "crossbuild" + "rsync" thing is that it gives me = the >>> ability to do the buildworld/buildkernel/installworld/installkernel >>> paradigm to a "holding directory" on a very fast machine, then rsync = the >>> results. (Mounting the holding directory via NFS works as well but = I >>> see no real advantage to that over using rsync) >>>=20 >>> That means I don't lose anything I did to the machine after install >>> (e.g. users, etc) and in addition I can put local patches on the = source >>> tree if required, but I still get a reasonable build time. >> I've successfully done cross building on a fast FreeBSD/amd64 machine = but have always had to move the SD card physically to that machine to do = the install{kernel,world} + mergemaster phase. The reason for this is = when I tried rsyncing to copy to the FreeBSD/arm system the rsync = application would not handle file flags (noschg, etc.) properly and = rsyncing would fail, even though I'd built it with the file flags patch = enabled. Going by what you say above, that appears to work properly = now, so I may re-try that. >>=20 >> I've also not had luck cross building on a fast FreeBSD/amd64 system = and then trying to install on FreeBSD/arm by NFS mounting the src and = obj crossbuild directories and doing an install{kernel,world} + = mergemaster on the FreeBSD/arm system. When I posted about this I = believe the reason is that the build systems gets confused about the = change in build and install paths. There may also be something about = the build/install toolchain, too. I forget. I just remember it didn't = seem to work for me when I tried it and asked about it on this mailing = list. :-) >>=20 >> If someone were to do a little "fastest way to update your = FreeBSD/arm OS without having to move the SD card physically to the = build system" HOWTO, that would be great. ;-) >>=20 >> Cheers, >>=20 >> Paul. > You do need to tell rsync to handle the schg flags -- for example: >=20 > rsync -av --force-schange --fileflags -I -e 'ssh -p > ' 'karl@newfs:/pics/CrossBuild/nfsroot/' / Thanks for the tip about --force-schange. I'd used --fileflags to no = effect but didn't know about --force-schange. I'll have to try that. Cheers, Paul.