11-Alpha to 11-Beta rewrite card or buildworld

[Karl Denninger]

On 7/11/2016 08:54, Paul Mather wrote:
> On Jul 11, 2016, at 9:24 AM, Karl Denninger <karl at denninger.net> wrote:
>
>> On 7/11/2016 07:51, Paul Mather wrote:
>>> On Jul 11, 2016, at 1:08 AM, Russell Haley <russ.haley at gmail.com> wrote:
>>>
>>>> Sorry about the top post. 
>>>>
>>>> If your not trying to learn about the build process and‎ 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?
>>>>
>>>> I would think there is more value in finding anomalies in your favorite applications. From 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.
>>>
>>> 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.)
>>>
>>> Cheers,
>>>
>>> Paul.
>>>
>> 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)
>>
>> 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.
You do need to tell rsync to handle the schg flags -- for example:

rsync -av --force-schange --fileflags -I -e 'ssh -p
<port-where-listening>' 'karl at newfs:/pics/CrossBuild/nfsroot/' /

-p <port-where-listening> is for those who run sshd on a non-standard
port (which I do to reduce the number of crazies trying to connect to my
boxes and thus the noise in the nightly security reports.)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160711/b9c6f1cc/attachment.bin>