Closed squeeb closed 3 years ago
Hi first off, I definitely need to update the documentation, as what I'm about to suggest should definitely be front and center and people are getting burned on this when it could be avoided. Second - thanks for taking the time to provide a bunch of context with the bug report. Now looking at this, a couple of things come to mind: Try building off the 2021.08br branch - the version of KVM there will build in a Debian 9 Dedicated User Environment container. If you're looking for the latest KVM build with Secure boot and the emulation tools ( see the git commit history for some useful information on that) you'll want a Debian 10 Dedicated User Environment container - that definitely works. The DUE link has information about creating the containers. They should be the same as the ones I use for development and releases. ( this is not entirely flawless, as people have had issues with firewalls, or building on filesystems that the host remote mounts, but we can burn that bridge when we come to it...) I'd also suggest a 'make distclean' to remove any partially built targets. ONIE is pretty clean about recognizing partially built code, but not every component it builds does.
Also see This bug which may be related/helpful Let me know if any of the above helps...
Interesting, I wasn't aware of DUE. I was being lazy and just used the build environment in contrib/build-env
to build the container and build inside.
I ended up building 2021.05 and limiting make to a single job using -j1
.
It took eons to complete but eventually spat out an image for KVM.
Thanks for the info. I'll go and figure out DUE and have a go at the bleeding edge KVM build.
Cool - glad you got it to work. -j4 should work with the 2021.05 build, but I understand the importance of getting a build to work with no competing build targets to establish a functional baseline. Getting the documentation updated is definitely the next priority, If everything is OK, I can close this out, or leave it open for a bit in case there are additonal issues. Thoughts?
Happy to close. Thanks for your help! :)
Also, check out this FIX https://github.com/opencomputeproject/onie/issues/1012 if you encounter the same problem
When building the
all
target forMACHINE=kvm_x86_64
within the dockerised Debian build environment, the build eventually fails with the following errors:The command used to build was:
The container is running in Docker Desktop for macOS and the Docker VM has 24 CPU threads, 16GB of memory and 32GB of storage assigned to it.
The container has an APFS case-sensitive dedicated hard drive bind mounted to
/home/build/src
as I found that trying to build with a case-insensitive filesystem resulted in errors.This appears to be localised to crosstool-NG, or maybe the
xtools
build although it is unclear why.Running the make target for
xtools
completes successfully:Running the
all
build a second time fails for a new reason:Any help on this would be great. Not sure if my build environment isn't correct, but seeing how it's containerized and the container is from the supplied Dockerfile, this leads me to believe that there may be something wrong with the build itself.