Date: Tue, 26 Nov 2019 18:42:59 +0500 From: Ruslan Garipov <ruslanngaripov@gmail.com> To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-current@freebsd.org Subject: Re: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL Message-ID: <4d7c7c51-33b9-2345-93fa-0736e2e640c9@gmail.com> In-Reply-To: <41b921c4-568f-5bd1-ae0f-1d85d750a8c7@quip.cz> References: <5596338e-134c-9849-de9e-710d3106687f@gmail.com> <bf490832-9433-f5a4-afe2-2463652f453b@quip.cz> <a03e4c56-1c20-9b68-2a27-b3f6f91da18b@gmail.com> <41b921c4-568f-5bd1-ae0f-1d85d750a8c7@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/26/2019 12:09 AM, Miroslav Lachman wrote: > Ruslan Garipov wrote on 2019/11/25 19:26: > > [...] > >>> I didn't tried this with current but I am using it with stable (11.3 at >>> this time). Building on Xeon E3-1240v3 and installing on many different >>> machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649, >>> some 10 years old Intel Pentium. >>> So at least it worked in the past (11.3 amd64). Did you use this >>> workflow in the past / did it work? >> No, unfortunately I didn't. Always built world/kernel on target host. >> >>> I remember some issue in the past which was (accidentally?) fixed by >>> running "make buildworld && make builkernel && make installkernel && >>> make installworld" on the build host (to some different DESTDIR) and >>> then "make installkernel && make installworld" on the target host (build >>> machine is shared via NFS) >> Therefore, this trick somehow "fixes" /usr/obj shared on the build >> machine? I'll try this later. Thanks! > > Yes, I think so. But I am not a developer nor I know much about how > build process works. I've tried to installkernel/installworld with non-default DESTDIR, it doesn't help for GENERIC kernel. But... After I had failed with that DESTDIR, I decided to update kernel/world on the build machine to the revision I tried to deploy (r355085). I cleaned result of the previous build, restored make.conf and src.conf specifying sandybridge† there as value of CPUTYPE and explicit -march, build and install kernel and world. Then I cleaned result of the build again, run buildworld and buildkernel preparing to investigate the build logs. But before doing that, I decided to run `make installkernel` once again on a target machine, and ... bang! It completed successfully! mergemaster, installworld -- the same! Everything completed smoothly. I updated the source to r355105 on the build machine, buildworld and buildkernel there -- installkernel, mergemaster, installworld on a target machine completed with no errors. To be honest, I don't know what exactly was a reason for my previous failure. Because I've tried to build with sandybridge in the configs. May be r355085 helped me, I don't know. In any case, I should inspect the build log, I believe. Miroslav, thanks for support! † This is the oldest chip we have on our ESXi hosts.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d7c7c51-33b9-2345-93fa-0736e2e640c9>