Date: Mon, 11 Jul 2016 11:20:33 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Karl Denninger <karl@denninger.net> Cc: freebsd-arm@freebsd.org Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld Message-ID: <0979D126-85A1-4AD2-B99D-C0D1272E5A16@gromit.dlib.vt.edu> In-Reply-To: <dc6b08fa-a350-acb8-04cc-afb74e8fceb4@denninger.net> References: <CABMOuVdW9SFFJineYtv6hvYypgRwBP9dEn-OKvb9xL2_XAXhvQ@mail.gmail.com> <CABMOuVeXnKrF52L-Xo1RYjdYhN8eoWOo8nLShxHn-TteAnyObg@mail.gmail.com> <CABMOuVd2z-3Do98C0kbDPXowvvP7-j=XMZ-x3ED=A37w=zPkYA@mail.gmail.com> <CABMOuVc%2BiHL4GLw=4BDE=%2B1ZKfw3wzxQRyJrO5OdNbw4ets-Xw@mail.gmail.com> <4876c9e05d5.30c7197a@mail.schwarzes.net> <CABMOuVfEefQ8BAxtUNrAUwTnwkq-4dN4T=X-aOWutgUec-p7Rw@mail.gmail.com> <20160711050802.4743251.48194.8248@gmail.com> <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> <cf3d7f5f-f9d4-49b5-d1f7-1664b09c5c45@denninger.net> <C3716178-F240-4D92-8480-AAC7FF563CA5@gromit.dlib.vt.edu> <dc6b08fa-a350-acb8-04cc-afb74e8fceb4@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 11, 2016, at 10:00 AM, Karl Denninger <karl@denninger.net> wrote: > On 7/11/2016 08:54, Paul Mather wrote: >> On Jul 11, 2016, at 9:24 AM, Karl Denninger <karl@denninger.net> = wrote: >>=20 >>> On 7/11/2016 07:51, Paul Mather wrote: >>>> On Jul 11, 2016, at 1:08 AM, Russell Haley <russ.haley@gmail.com> = 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 > <port-where-listening>' '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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0979D126-85A1-4AD2-B99D-C0D1272E5A16>