Date: Tue, 8 Dec 2015 08:55:12 -0700 From: Warner Losh <imp@bsdimp.com> To: Karl Denninger <karl@denninger.net> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Updating / keeping current strategies? Message-ID: <CANCZdfoweb-f-2e2k=Q8zoB_G9x1VJVvHZoGUao-zRu4zvC=Lg@mail.gmail.com> In-Reply-To: <5666F37C.4060908@denninger.net> References: <5666F37C.4060908@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 8, 2015 at 8:13 AM, Karl Denninger <karl@denninger.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoweb-f-2e2k=Q8zoB_G9x1VJVvHZoGUao-zRu4zvC=Lg>