From owner-freebsd-arm@freebsd.org Tue Dec 8 15:55:14 2015 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 216FA9D30F3 for ; Tue, 8 Dec 2015 15:55:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFC8A1038 for ; Tue, 8 Dec 2015 15:55:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgcc31 with SMTP id c31so22028993qgc.3 for ; Tue, 08 Dec 2015 07:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=R0+sVJJl1NBTLugjb7zkay2LWBMtm2RzdLdig1cPMbg=; b=TIMCrnqRHTZG6rnhZqSh2bZ9DLtDRIG10oJ2O//saUKBowkAAuaKt2REu8ZP3kC4Ok 2pT1uBwMhnygqLqA2FHlqT2xVcFsm/xtAKh1JXlqsAZPoJgu+jNkiY4+oI2Vn1lHc5CV 3FYaFoAM5UCbBmV8VTFRlveucfaZTHD1cOLIEvLU8G0JSg3smgi+1qravnMytTvi+T7H 26tyT6bDxcePnVWyOigGW0LLlprlmi8/af8t70nZc2cqPRyyjKM1GwgHWnuV/PMJkWam U3rjZWCy6Ho3z5RoBTxvJw73kxDHUgK86oqnQGDIt6s0egFw1klqg0iUt1in07jgLrwD SCEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R0+sVJJl1NBTLugjb7zkay2LWBMtm2RzdLdig1cPMbg=; b=Cxa1Tx1UvdrBKdPNAuH8EkIa7jNN5JfcARWIjysXxsaAeZ2s1CqUYWi5dQQZlcp87v 0Q3js2kWX8FrxW68vntqbWtqJvONe7PxG50WkuHtLruwb9/yQBwJctFXHIa61ryNwlav veFKJlOZZkWN164XRmGXw+5Lx/a0xgk6rxOChsJ5OyJDPRgyZwbUTeeF3UPcOQ/ZKJQ4 Ae3xv8r8uNGimWTIXAEnw1Cgvmt9yIblgF/xIBczabdYd4eIp7RnCsQnzNsGXAdBje40 bnTTBEmIImbKm2ExyLUKhL3BifgxQpyVkx6Xf08FhLxnX/j4UIJ6FY0/PeYvB5mUgR7z pbaQ== X-Gm-Message-State: ALoCoQlEdhOX7kwXXQFgZPcuku4ujehDbuz4VEonEFmbr1BMU7VO6GCcB+wQv+Zp/eP5s11tzsvVb/lBUbaBjFAjDAO0Lgu0Gg== MIME-Version: 1.0 X-Received: by 10.140.176.143 with SMTP id w137mr6068104qhw.20.1449590112866; Tue, 08 Dec 2015 07:55:12 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Tue, 8 Dec 2015 07:55:12 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:4d3f:8eba:ea86:7700] In-Reply-To: <5666F37C.4060908@denninger.net> References: <5666F37C.4060908@denninger.net> Date: Tue, 8 Dec 2015 08:55:12 -0700 X-Google-Sender-Auth: x1ezv3dnZu_UVXyeXk0lgNus6jk Message-ID: Subject: Re: Updating / keeping current strategies? From: Warner Losh To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:55:14 -0000 On Tue, Dec 8, 2015 at 8:13 AM, Karl Denninger wrote: > What are people doing in this regard with devices like the Raspberry Pi2? > > Build times for a "make buildworld" are measured in (many) hours to a > day or more and require a USB-attached disk for temporary storage, as > the ramdisk for /tmp that is typically mounted blows up due to lack of > space and SD cards are slow enough on writes (especially small writes) > as to make the process virtually impossible. But even with a > USB-attached disk the process is ridiculous in terms of consumed > walllclock time. > > Further, "make installworld" sometimes fails inexplicably. > > Kernel builds are a bit more reasonable, only requiring a couple of hours. > > I'm wondering what the best option is to not only build current code on > a regular basis (since -CURRENT is a "work in progress") but also to > deploy and update existing devices. What are people doing that has a > history of working well? > I've been updating for years. But usually building on another machine and then installing to the media of the embedded machine via NFS. This mostly works and isn't too sucky. But there are problems with this approach, since high write work loads tend to bog down the embedded box due to crappy storage being used (eg SD cards, USB attachment or both). You may have noticed some commits to nanobsd I've been making lately. I'm moving all my local boards over to nanobsd with a ping-pong partition. I'd create a new image for a new partition, splat it on to the 'pong' partition, adjust the active flags and reboot. NanoBSD has supported this operation for a while, and this works well in the hand-built images I've done. I'm polishing off the rough edges for this by making it possible to dynamically resize the first time. FreeBSD supports this for one partition today. But it doesn't provide a good way to do a divide by 2. The support in FreeBSD for writing MSDOS partitions as a regular user is also weak, so there's bits from mtools in my build. I've also not completely integrated the u-boot ports into the build. There's also an open question about the proper way to install packages on these boxes. One school of thought says that nanobsd should put the packages you want onto the image, and that's all you'll ever get. Another says that nanobsd should keep the database of packages off the ping or pong partitions so that when you upgrade, the packages are refreshed to the old set. There's other in-between positions I've heard articulated. So I can't help you today, but I'll be able to help you soon. Warner