| Summary: | [fri2-noemgd] core-image-sato fails in bootimg with "Disk full" error from mcopy | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Darren Hart <dvhart> |
| Component: | core | Assignee: | Darren Hart <dvhart> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher |
| Version: | 1.2 | ||
| Target Milestone: | 1.2 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Darren Hart
2011-12-20 16:43:43 UTC
The problem appears to be that we are not account for the size of the directory structure in the dosfs image which gets larger with bigger image sizes. For a sato image (~750M) dosfs structure uses 208K, then the current (smaller) directories need another 52K (16K Dir Structs), which brings us to 260K, df reports 176K available which leaves another 76K to overhead somewhere. For a larger image (2.8G) sato-sdk with a 1024 extra size, the dosfs overhead is 256K and the directories require 148K (64K Dir Structs) leaving 192K (from df) and 428 going to overhead somewhere For an 1.5G image the dosfs structure takes 224K and the directories are 32K dir structs, with around 172 going to other overhead. This was with only the EFI/* files so it had half the number of files. So your bandaid is probably correct, we could drop it to 1024 of EXTRA_SPACE or work on sliding scale based on image size. I tried to build a 4G mkdosfs but that failed. Is it straight forward to calculate a deterministic direntry size in blocks with something like "find ${HDDDIR} | wc -l" ? If so, we could just increase the initial size accordingly prior to the padding being added.
(03:36:15 PM) sgw: dvhart: no, that not determinisc, it's size not direntry (03:36:52 PM) sgw: that dosfs image for sato has the same number of directory entries as sato-sdk, but sato-sdk is 3 times larger in size. In that case, the 512k added for the much larger image could be padded and added to all images. Adding 1MB to the IMAGE size is probably reasonable. There is also the duplication of data due to the EFI boot using EFI/BOOT. I'll test without that duplication and see if things work. If not, we can increase the padding to account for the filesystem overhead. This was apparently due to using stale sstate for the xf86-input packages. Running the following generated a functional image: $ bitbake -c cleanall xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-input-synaptics $ bitbake core-image-sato Saul, this does not appear to be an fri2 issue, but rather a build issue where stale sstate was used for the xf86-input drivers. I've assigned this to you to either close as is, or hand off to someone to investigate further. It's certainly possible that things have changed enough that nobody will hit this again with sstate generated from now on, so I'm not sure how much more time we should spend on this. (In reply to comment #5) > Saul, this does not appear to be an fri2 issue, but rather a build issue where > stale sstate was used for the xf86-input drivers. I've assigned this to you to > either close as is, or hand off to someone to investigate further. It's > certainly possible that things have changed enough that nobody will hit this > again with sstate generated from now on, so I'm not sure how much more time we > should spend on this. Apologies, wrong bug :( |