Restricted USB and SD card permissions - Write access denied to these devices with automatic mount

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

Hi There,

I’ve just encountered an issue with a TX1 I am working with. When I insert an SD card or USB storage device on this particular TX1 it mounts the devices without write permissions such that I can’t create/delete/modify files on the devices. None of the other TX1’s I have access to exhibit this behavior, they all grant appropriate privileges when the same card is automatically mounted.

I am able to unmount the drive at the command line, then remount with permissions, and then I can write to the directories contained therein, however, I have to do this each time I reboot or re-insert the media.

I’ve attempted to fix this by reflashing to other/older versions of Jetpack, (both 32-bit and 64-bit), however, although I assumed that flashing would completely erase the eMMC drive, this doesn’t appear to be the case as the behavior persists.

Has anyone else encountered/solved this issue previously?

Thanks for your help!

-Mark

2

Apologies, I didn’t realize I was under the TK1 forum. I’ll repost under the TX1 topics.

-Mark

3

This is a standard part of Linux auto mounting, so anything you find on Ubuntu administration applies. If you wanted to manually change an existing mount the “mount -o remount,rw…” can do the umount and mount in one command. Otherwise, you probably want to modify “/etc/fstab”. If you have an exact ID (e.g., UUID from lsblk) or an exact device (e.g., “/dev/mmcblk1p1”), then it shouldn’t be too difficult. Other more automatic setup may require changing a udev rule.

Beware any disk not mounted read-only has to be correctly umount’ed before removing.

In the following the UUID of a specific SD card is interchangeable with “/dev/mmcblk1p1” for SD card first partition…UUID will apply if it is a specifically formatted SD (per-specific-SD-card instructions), mmcblk1p1 will apply to any SD in the slot. The choice is whether you want all SD cards or a specific SD card to have this behavior. For example, if blkid shows this:

/dev/mmcblk1p1: UUID="4488e569-8a44-40f3-abf2-62f4f7d83250" TYPE="ext4"

…then the following “/etc/fstab” entry will force mount point to be “/custom” and allow even some insecure behavior (such as allowing suid root) if found during boot and to not complain if the SD card is not present (note “nouser” is restrictive and used because this will always be mounted without every user needing control; “async” increases performance but is one reason proper umount is needed when writable; nofail stops the mount from being mandatory; the “0 2” is for file system maintenance reasons):

UUID=4488e569-8a44-40f3-abf2-62f4f7d83250 /custom ext4 rw,suid,dev,exec,nouser,async,nofail 0 2

See: “man mount” and “man fstab” for more option info.

This is completely automatic only during boot. Note that you would not need to name any options to mount this card, the fstab entry would take care of that if you name the device or mount point covered in fstab. Once you “umount” you could just “mount /custom” and the next SD card would be mounted.

To get more automation you need to mess with udev. An entry in fstab with more automation would look something like this, where I think gvfs does something with udev:

/dev/mmcblk1p1 /custom auto comment=x-gvfs-show,noauto,rw,user 0 1

Important note if experimenting with fstab: If you have an invalid entry or an entry which is considered “mandatory mount”, then a failure could hang the system during boot. This shows up on serial console, but you probably won’t see it on regular console. Serial console does not respond to the instruction to skip the mount, you’ll need to blindly hit the ‘s’ key to skip that mount from the directly attached keyboard to continue boot. The “noauto” option is to tell init in bootup to not automatically mount this; the gvfs comment is to give nautilus control (nautilus does not run until after basic boot).

4

Hi Linuxdev,

Thank you so much for your detailed reply.

Aside from the specific details about how this device is being mounted, really my biggest concern (to raise specifically to NVIDIA about JetPack), is, how is it possible to re-flash this device and not get the same behavior from identical devices that have been flashed using the same version of JetPack?

Why is this automatic mount setting remaining after successive re-flashes?

Why is the eMMC not being cleared and re-populated appropriately and in the same manner for all devices?

I think more than the annoyance of having to remount a device with permissions is the fact that multiple TX1s flashed using the same process can exhibit different behaviors…

This is puzzling to me. I know I have read in one of your other posts that flashing using JetPack erases and re-writes the eMMC memory… but apparently something is capable of surviving the process…

Any thoughts?

Thanks again!

-Mark

5

The automatic mount settings are from Ubuntu, nVidia has not modified this (most all desktop Linux distributions do this same thing for automount). To change the behavior you’d have to change the sample rootfs prior to flash…this propagates to eMMC. If you were to save the system.img.raw, mount it on loopback on the host, update your Jetson, and then rsync from Jetson to the system.img.raw, then you would have an image suitable for the “-r” flash option to re-use an old image (you’d get rid of the sparse system.img, and copy system.img.raw to system.img prior to flash with “-r”). Behavior should then be the same across flashes of the re-used image.

Much of the behavior differences I’ve seen are from different steps of creating the flash image where for example one person used sudo, and the other person did not (permissions won’t preserve without sudo, new device special files can’t be copied or created without sudo). This wouldn’t explain what you are seeing since this is more of a failure cause than minor behavior difference. But consider that each sample rootfs differs, and that depending on arguments, some of the boot files are edited versus stock sample rootfs. Really the forensics to figure this out depend on comparing sample rootfs to the root file system of the Jetson you’ve modified, or to the system.img.raw.

6

Thanks Linuxdev,

So, I remain perplexed, how did this crop up initially, how do I eliminate it, and how do I get a clean installation so that if you were to flash a TX1 it would be the same as if I were to flash a TX1?

(I really do appreciate your patience, I owe you a beer the next time I am in the same town as you… probably dinner too!)

-Mark

(P.S. This is with the assumption that I am using JetPack with standard settings to install.)

(P.P.S. I am hoping to specifically address this to NVIDIA, TX1 computers should be capable of reproducing behaviors with exquisite detail, I only hope to reproduce one unit’s behavior with a second and obtain identical results given the NVIDIA JETPACK tools at hand, this is my issue.)

7

Unfortunately, since JetPack can only run on Ubuntu (it needs that package manager), I can’t use JetPack. The driver package and sample rootfs though are the same regardless of whether JetPack runs them or not. How the sample rootfs is unpacked and how it is updated by apply_binaries.sh, and finally how it is edited for boot files, is what determines what goes onto the Jetson. JetPack wouldn’t change that, other than perhaps by finding a more recent version of something (indeed, finding the right package in the right order is the biggest benefit of JetPack). To get an identical copy of a given Jetson, what you really need is a clone of the rootfs and then each flash with the “-r” to reuse the cloned rootfs image. Cloning information on a JTK1 is mostly the same as a JTX1, here’s the URL on that:
[url]http://elinux.org/Jetson/Cloning[/url]

The specific clone command for a JTX1 is here:
[url]https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149[/url]

If you have a cloned partition, you can do all standard backup to this on a remote system (or even mounted locally on a hard drive), and be ready to very quickly install an exact clone to as many Jetsons as you want. I use rsync for this, but any backup method works…restore is via flash.sh with “-r”.

One of the problems in all of this is that until now most embedded systems used a cut down version of an o/s. We’re now dealing instead with an entire desktop Linux distribution, and along with that the need to basically be a system administrator. Even among those software engineers who can do sysadmin, there are large differences in procedure for administration of those different distributions…I for one prefer Fedora, which is what my host uses. If I build a server, most likely it’ll be CentOS. I am not a sysadmin, but I’ve been working on Linux since kernel 1.0.9, so I have an advantage in the chaos.

So far as the 64-bit part of L4T goes, until recently there was no ARMv8-a architecture. Nobody had ever ported to this because it didn’t exist. Now that it does exist, there is a very rapid evolution of the compilers as well which can make a huge difference. On a desktop system it is common to have a compiler support both x86_64 and something like i686 for 32-bit compatibility…this will probably occur in the future with Linaro, but for now you even have to use separate 64-bit and 32-bit compilers for dealing with both normal 64-bit mode and 32-bit compatibility modes. People got used to 32-bit/64-bit being in one compiler for desktop machines, it takes a moment to realize there is a lot of effort needed to integrate two compilers of a new architecture, so this makes it even worse for the mental noise index.

Just for humor, my own copyrighted saying: “Understanding is the first sign of insanity.” Enjoy your sanity in the new architecture mix while you can :P Or, be glad you’re surrounded by insanity so you don’t have to go insane getting the job done!

8

:) Hahaha! Thanks!

(P.S. Indeed, there is a great deal of understanding I have yet to acquire!.. at least this is one trick I’ve learned in the past few months: [url]https://www.virtualbox.org/[/url])

9

Update: I traded the TX1 SOM on the Development Kit Carrier Board with another working SOM, and the problem showed up on the new TX1 SOM… so the issue isn’t with the installation, it appears to be with this Development Kit Carrier Board.

If anyone else encounters this issue, it might be with your carrier board.

I have no idea how to go about debugging the Development Kit Carrier Board, so I am going to use a different carrier board and consider this issue resolved.

-Mark

10

Interesting…so the module itself has behaved differently on a different carrier board? That’s one I haven’t seen before, but I can see signal quality of various connectors being more marginal on one board than on another (especially if there has been any cycle of heating and cooling).