L4T 34.1.1 -> Hidden files (.) in rootfs


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.

Hey Wayne,

it is pretty simple.

  1. Create a file starting with “.” in the filename in the rootfs folder.
  2. Use the flash script flash.sh or the initrd script to flash the board.
  3. Check if the file exists in the flashed rootfs

Expected: File exists
Actual: The file is not copied by the script


So even flash.sh would hit this issue or only initrd flash?

Hey Wayne,

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 - *”

I hope this helps!

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.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.