From owner-freebsd-arm@freebsd.org Mon Jul 11 13:54:16 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 0463BB84E6F for ; Mon, 11 Jul 2016 13:54:16 +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 B6AD216EE for ; Mon, 11 Jul 2016 13:54:15 +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 465D5775; Mon, 11 Jul 2016 09:54:14 -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 09:54:13 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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 13:54:16 -0000 On Jul 11, 2016, at 9:24 AM, Karl Denninger wrote: > 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). >>=20 >> 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. 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. :-) 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. ;-) Cheers, Paul.