Add support for directories in bundles #1625
Conversation
6727cc6 to
6cce4d0
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1625 +/- ##
==========================================
- Coverage 84.50% 84.49% -0.02%
==========================================
Files 76 76
Lines 22381 22397 +16
==========================================
+ Hits 18913 18924 +11
- Misses 3468 3473 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
One reason for this check was also to reserve directory names for use internally by RAUC. For example, it creates a Would you be fine with only allowing non-hidden directories (i.e. ones that don't begin with |
|
Excellent idea! Yes, that would work for us. We don't use anything hidden in our bundles. |
|
I added an additional check that throws an error if a directory starting with . is found. Let me know what you think. |
09df1a9 to
b9de93b
Compare
|
I've force pushed to rebase on master and change the check to only reject top-level hidden subdirs. Would this work for you? |
b9de93b to
cb7251f
Compare
|
Sure, that works. Thanks you! |
In some cases, it's useful to store additional files in the bundle which are not used directly by RAUC. To keep things organized, it can be useful to place them in subdirectories. As RAUC may need to store it's own data in subdirectories (e.g. '.rauc-cfs-store' for composefs objects), hidden directories stay reserved for internal use. Signed-off-by: Jens Kehne <jens.kehne@agilent.com> Co-developed-by: Jan Luebbe <jlu@pengutronix.de> Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
cb7251f to
447be62
Compare
|
I've squashed our commits and updated the commit message: Could you try this version and confirm if it that it works for you? |
|
I just tried the latest version, and everything looks good to me:
|
The FAQ says to contact you if someone uses subdirectories or symlinks. Unfortunately, we do: We have put some additional files into the bundle which are read by the target device before applying the update. We put those in the bundle because we wanted them to be signed along with the update, and we put them in a directory because it made deployment simpler on our side. At the time we did this, we were using Yocto Langdale/rauc 1.9 because our hardware vendor's BSP was not compatible with anything newer, so we did not know this was going to be problematic. Now, we have already shipped devices which expect the subdirectory to be present and will not accept bundles without a subdirectory.
I ran into the problem when I updated our build to Yocto Scarthgap/rauc 1.12. To fix this for the time being, I created the proposed patch which re-adds directory support. The patch recursively mirrors any directories found in the content directory to the work directory -- including permissions, but not including owner/group information as these are set to root:root anyway by mksquashfs -- and hardlinks any files found in those directories to the appropriate subdirectory in the workdir.
We have been using this patch in our internal development version (rauc 1.12 on real hardware) for a few weeks now, without problems. I have also built this branch for our target, and it worked fine; both 1.12 and the build from this branch accept the bundles created by the patched version. I have also tested a few additional cases like deeper directory structures and no subdirectories, all of which worked as well.
We do not use symlinks or special files, so the patch does not touch the code handling those.