Flash script creates image with binaries missing extended attributs (xattrs)

The various flash scripts (un)tar the files without support for extended file attributes.
This leads to binaries like arping missing capabilities which are stored in xattrs.

The flash scripts (in my case l4t_initrd_flash.sh) should honor all extended attributes.
Especially when unpacking, tar needs to be run with --xattrs AND --xattrs-include='*'

During flash (assuming you didn’t get a pre-canned SD card image), any generated image inherits from the defaults of the local system’s mkfs.ext4. If you look for “mkfs” in “flash.sh”, then for non-msdos partitions (msdos VFAT is used in UEFI), note this (understand that it is filling in ext4):
mkfs -t ${__rootfs_type} "${loop_dev}" > /dev/null 2>&1;

That command uses defaults on the host PC’s file:

There are a lot of features and options to that command. Should you want to add extended attributes, then see “man mkfs.ext4”, and note this:
-E extended-options

You can edit flash.sh to include those options. I wouldn’t recommend it, but you could also edit the host PC’s “/etc/mke2fs.conf”.

Also, making extended attributes available does not necessarily create them. That’s part of a copy from “Linux_for_Tegra/rootfs/”. It also depends on kernel options.

This is not about extended filesystem attributes, but about extended file attributes…
Let my try to be more explicit:
There are files (binaries) in my rootfs that have extended attributes set, i.e. arping from the iputils-arping package has linux capabilities set via extended file attributes:

getcap rootfs/usr/bin/arping

which returns

rootfs/usr/bin/arping = cap_net_raw+ep

So in the rootfs this is there, but after running the flash script this attribute is missing in the flashed rootfs.
If I mount bootloader/system.img.raw then getcap also already returns nothing…

So somewhere the rootfs is tared/extracted without the --xattrs-include='*' option and this needs to be fixed in the nvidia scripts.

Tarball creation always needs to be done with --xattrs and extraction with --xattrs --xattrs-include='*'.

So to create a correct system.img from the given rootfs without loosing attributes the tar command in flash.sh needs to be fixed:
Instead of

		echo -n -e "\tpopulating rootfs from ${__rootfs_dir} ... ";
		(cd "${__rootfs_dir}"; tar cf - *) | tar xf - ;

it needs to be

		echo -n -e "\tpopulating rootfs from ${__rootfs_dir} ... ";
		(cd "${__rootfs_dir}"; tar --xattrs -cpf - *) | tar --xattrs --xattrs-include='*' -xpf - ;

Flashing via Initrd (l4t_initrd_flash.sh) also needs to be fixed:
In l4t_flash_from_kernel.sh change

		echo "Formatting APP partition ${APP_partition} ..."
		echo "tar --xattrs -xpf ${file_image} " "${COMMON_TAR_OPTIONS[@]}" " -C "\
		if ! tar --xattrs -xpf "${file_image}" "${COMMON_TAR_OPTIONS[@]}" \
			-C "${tmp_dir}"; then


		echo "Formatting APP partition ${APP_partition} ..."
		echo "tar --xattrs --xattrs-include='*' -xpf ${file_image} " "${COMMON_TAR_OPTIONS[@]}" " -C "\
		if ! tar --xattrs --xattrs-include='*' -xpf "${file_image}" "${COMMON_TAR_OPTIONS[@]}" \
			-C "${tmp_dir}"; then

With those fixes, the extended file attributes from the rootfs are preserved and things like capabilities, SELinux, etc. are working again.

Other scripts like the backup/restore ones need to be fixed in the same way.

Hope this finds it’s way into the next L4T release.

That sounds like a good patch. All I can do is suggest to NVIDIA that this is a worthy patch. I think most people don’t care about those attributes, and so it has not been noticed (but it should be noticed).


looks like you are doing some customization on your rootfs.
Do you find other binaries that get affected with extended attributes in our sample rootfs?
If the answer is no, then we may need to evaluate if it has to be patched;
and we do have to fix it if yes.

I’m not using the sample rootfs, but built a new one from scratch with the stuff I need.
So I don’t know if there are binaries in the (unmodified) sample rootfs that use extended attributes.


it’s good you get to fix it yourself, but if there are no other users reporting the same issue on our samplefs, we may just leave it as is.

Why not fix it to spare others from searching for the problem?
And IMHO it is even more likely to happen if someone used the backup/restore scripts after they installed additional packages.


that sounds reasonable.
We’ll report it and discuss with our internal teams.

Nice! Looks like this fix made it into L4T 35.5.0.

1 Like