| Summary: | possible DL_DIR cloning race condition | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Alexandre Belloni <alexandre.belloni> |
| Component: | bitbake | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | poky.bs.watcher, poky.watcher, randy.macleod |
| Version: | unspecified | ||
| Target Milestone: | 3.4 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | AB-INT AB-INT-TMPFS | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Alexandre Belloni
2021-06-17 14:01:12 UTC
Audit the nfs locking. It can't be NFS since build-appliance does local fetches and the paths in question are local to the build directory. It will not reference git repos via the file:// urls either. To result in corruption like this I'm wondering if there was a race over creation of the mirror tarballs and a truncated mirror tarball was accessed. The creation of the git mirror tarballs in git.py uses tar directly on the file and could mv the file into position after creation to avoid races. I plan to fix the mirror tarball race and then see if this recurs Fix in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=626e949292a4d21cc828fcc6c8d5f62a93622f61 and we can reopen or file a new bug if the issue recurs. |