I have created a Bug Ticket for this but it was closed even though I filled out everything as requested. Thought that was the right way, but it seems I should spam this forum.
When you have hidden files starting with a dot in the rootfs they will not be copied to the system when using the initrd flash tool. That’s probably due to the used copy operation.
Could you share the detail steps to reproduce this issue? We are not using the bug ticket from here to check issue.
Thus, please share your detail steps here.
I can’t access the Bug Ticket anymore but I am pretty sure that the Ticket I created 1.5 weeks ago was when using initrd flash. I just used flash.sh to flash to check it again.
So I would say both are affected.
I just checked the code of the flash.sh and the culprit seems to be from line 585:
echo -n -e "\tpopulating rootfs from ${__rootfs_dir} ... ";
(cd "${__rootfs_dir}"; tar cf - *) | tar xf - ;
When you tar with * you will not copy and hidden files or directories.
The command needs to be changed to “tar cf - .” instead of “tar cf - *”
One other weakness of that command is that perhaps “tar” should have options to preserve numeric owner and group via “--numeric-owner” (the files being copied should be in an archive mode, and the two computers this might copy across do not necessarily have the same users and groups). “rsync” would be a better choice (and it would use option “--numeric-ids”) since it handles all file types correctly (e.g., there are cases where “cp” won’t copy “/dev/random” as a device special file and might try to copy its contents, whereas “rsync -a --numeric-ids” always handles this correctly).
Another useful property of rsync is that it can use options to either check if the file is already there, or to just blindly always copy the way cp does. If one is flashing multiple times using this image, and if rsync were instead used such that it only copies changes, then it would run faster on the second pass.