| Summary: | wic should mount /boot | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Ross Burton <ross.burton> |
| Component: | Scripts and Tools | Assignee: | Ed Bartosh <eduard.bartosh> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | ross.burton |
| Version: | 2.3 | ||
| Target Milestone: | 2.4 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | |||
| Bug Blocks: | 11291 | ||
|
Description
Ross Burton
2017-06-14 15:19:10 UTC
Should be fixed by this patch: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138228.html looks like my patch uncovered old wic bug: RP 13:05 ed2: Does wic write to /etc when its building an image? 13:05 ed2: https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/1183/steps/BuildImages_1/logs/stdio - "tar: ./etc: file changed as we read it" 13:06 ed2: something changed while do_image_tar was running, the other tasks were do_image_jffs2 and do_image_wic. I was wondering if wic would make changes? ed2: so how are other tasks meant to run in parallel without the files changing? 13:08 ed2: nothing is meant to write to the rootfs during do_image_xxx :( Everything looked good so far because wic didn't update / and /boot partitions and 100% of oe images have only 2 partitions - / and /boot However, for more than 2 partitions or even for anything different from / and /boot the bug would cause conflicts similar to above. To properly fix this we need to copy rootfs to temporary directory, update fstab there and make rootfs image out of that directory. I'm going to do that in the next revision of the patchset. Copying the entire rootfs sounds very painful: best case you hardlink the entire thing at it's just slow. Can we not use e2fsprogs to manipulate the fs directly? yes, that's what I'm going to do. I'll use copyhardlinktree API for that. It's already used in rootfs plugin in the implementation of --exclude option. It works quite fast and doesn't require a lot of code changes. I can use debugfs to modify fstab if harlinking is slow. Will test it on sato image to understand if this is the case. tested hardlinking approach. It's pretty fast from my point of view:
copying sato image takes only 1.3s
$ time PYTHONPATH=../meta/lib/:../bitbake/lib/ python3 -c 'from oe.path import copyhardlinktree; import bb; copyhardlinktree("tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs", "/tmp/rootfs-sato")'
real 0m1.328s
user 0m0.632s
sys 0m0.752s
$ du -sh tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs
235M tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs
$ du -sh /tmp/rootfs-sato/
235M /tmp/rootfs-sato/
I'm going to use this at least for now.
done, please review: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138771.html Hardlinking roofs directory content using copyhardlinktree API makes do_image_tar task to exit with error "file changed as we read it" as making hardlink changes file ctime. In v4 we copy rootfs content instead of hardlinking it: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/140167.html It's slower a bit, but not very slow. For example it takes 1.5 sec for core-image-sato-dev rootfs with size around 500Mb. v5: back to hardlinking: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/140199.html the patchset has been accepted to poky master. commit id: ae4ee4d51158eb43f770debf6e41646ef8ed9817 |