How to increase APP size partition on internal eMMC 64 GB


I have one external NVM drive storage on PCIe slot. The mounting goes off, each time I do a reboot and it cannot be seen in the list of devices when we do “df -h”.

I need to explicitly mount it using disk manager each time.
Is there any method where it automatically mount the NVM storage device automatically on the boot up.

We need to figure out the “disappear” part. When it is working, since it is PCIe, what do you see from:

  • lsblk -f
  • lspci -v
  • After it disappears, run “lsblk -fandlspci -v” again.
  • Post all of those with a note of which is for fail or working.

Note that the above can easily be logged like this:

  • For working:
    • lsblk -f 2>&1 | tee log_lslk_works.txt
    • lspci -v 2>&1 | tee log_lspci_works.txt
  • For failing:
    • lsblk -f 2>&1 | tee log_lslk_fails.txt
    • lspci -v 2>&1 | tee log_lspci_fails.txt

There are ways to tell the system to mount on a best efforts basis, such that if it disappears the system doesn’t lock up waiting. But we need to know why it is unreliable first. PCIe is one possible reason.

You say this occurs during reboot. Is it possible for you to have the system up and running with the NVMe showing up, and then start a serial console log, and run a full reboot plus “lspci -v” and “lsblk -f

What I’m looking for is whether it is PCI or the device itself showing an issue. It could also just be a configuration issue.

If there is an entry for this in “/etc/fstab”, then you might include that too.

log_lspci_works.txt (4.1 KB)

log_lslk_works.txt (2.7 KB)

log_lspci_fails.txt (9.9 KB)

log_lsclk_fails.txt (2.7 KB)

serial_boot_log_NVM_mounted.txt (82.7 KB)


I have one more issue which says "You do not have permissions to view the contents of … "
when accessing the pen drive connected to my USB ports on the unit , by clicking using mouse.

Note, we had cloned image using Backup and Restore method. Is this causing this issue?

Please find the snapshot below for details:

But we are able to access the data through terminal commands but not through GUI. Kindly let us know how to fix the issue.

I’m not putting this in order, but noting things as I see them. Some of it is fascinating, and probably ties to the “You do not have permissions”. Note that this is about finding out why sometimes you have to remount the NVMe and it doesn’t load by itself.

lspci examined…

I put the PCIe logs into a diff viewer.
print.pdf (28.3 KB)

The PDF above is just for the NVIDIA PCI bridge. What surprises me is that lspci -v, with a single “-v”, should never say access denied. On the other hand, it is the log for when things work that has the denial. I would have expected perhaps being denied something when the bridge details fail would be the real issue, but it is reverse.

Going through the set of lspci diffs via kdiff3 shows access denial of some details happens in the “works” case for more or less everything. Was this lspci using only one “-v” in the option? I expect failure in a case of fully verbose. If you first drop into a root shell via “sudo -s”, and then repeat all of the logs above, access should not be denied.

It says you have a third party video controller installed. This should not normally be related, but if power consumption is an issue, then it might indirectly have an effect on the NVMe.

For reference, the PCIe slot for the NVMe is device ‘1bcd:0220’. One could limit a lspci reading to just this device via:
lspci -d '1bcd:0220'

It is worth noting that in both works and fails cases the NVMe drive shows up as existing, and the driver shows as being loaded:
Kernel driver in use: nvme

I doubt PCIe is the issue of the drive dropping out. It is still possible that other PCIe devices indirectly interfere.

lsblk examined…

diff_lsblk.pdf (11.8 KB)

The only difference with lsblk between working and failing is that failed does not mount. It appears the drive is otherwise available and functioning. This suggest it is a timing issue whereby the drive is not available in time before it is mounted.

Serial log examined…

There are a lot of i2c errors. It seems there are some USB issues as well. This makes me suspicious of incorrect firmware (the device tree). You have extra PCIe devices as well. Although you got your rootfs/APP partition size listed as the issue of this thread, is this a third party carrier board? If this is a dev kit, then the software NVIDIA supplies is correct. If this is a third party carrier board with an AGX Xavier module, then you have to use their firmware.

Getting back to mounting a drive on a location other than “/”…

Do you have a line in “/etc/fstab” already for mounting this drive? You can refer to this via either:

  • nvme0n1
  • cb277d1c-7a23-4c1f-bdbe-afbfe7bb9b25. I am surprised though to not see a separate partition, this is the device as a whole (see lsblk -f).

One more detail to add, can you attach your “/etc/mtab” once the drive is mounted?


Please provide solution for this issue of accessing pen drive or SSD drive contents using mouse.

Command line can be used, but I don’t know how to do this with a mouse.

Does this work?

sudo mount /dev/nvme0n1 -t ext4 /mnt
sudo umount /mnt

Also, does this work?

sudo mount -U 'cb277d1c-7a23-4c1f-bdbe-afbfe7bb9b25' -t ext4 /mnt
sudo umount /mnt

What I meant was when I click on the 8.1 GB pen drive with mouse as shown in the snapshot picture, it throws me the error.

How can we fix this?
I had done cloning for this unit but I had done fresh flashing for all other 3 units. If I am not wrong. Is this any where causing permission issue

Sorry.I was referring to the pen drive inserted to the USB port which is mounted as /media/cabs5-willet/A08-xxxx/. Why this is not accessible, when I click on it using mouse.

Regarding NVM I will try out the above and see they after tmrw and see if it works. know how to fix this issue with accessing pen drive contents connected to USB… through GUI when I click on it using mouse

I am interested in first finding out if various mount methods work. Simply clicking would not mount this where you want, it would instead be somewhere under “/media”, “/run” or “/var/run” (in combination with your user ID).

I don’t know yet about the permission issue. I am hoping to see the mount results to see if those behave correctly. I also refer to the pen drive, but it needs to not be mounted in “/media`”.

However, that final directory might differ in name at different mount times, and I will assume that directory is constant (“/media/cabs5-willet/A08-xxxx/”), but adjust if not. What do you see from this when run as your regular user:

ls -ld /media/
ls -ld /media/cabs5-willet/
ls -ld /media/cabs5-willet/A08-xxxx/
ls -ld /media/cabs5-willet/A08-xxxx/*

Regarding permission issue for the pen drive, I came to know that, it was caused because I did not delete the
" /media/cabs5-willet/A0B3-EE03" mount point before taking backup from other thread.

This is causing the issue. please provide example commands of deleting the “/media/cabs5-willet/A0B3-EE03”.
Should we delete directly? or we should unmount them first and then delete?

Also should we do the same for all the auto mount points for external media like SSD drives, SD card attached to M2, PCIe etc…


From where did we get this UUID “cb277d1c-7a23-4c1f-bdbe-afbfe7bb9b25”

Is it fixed always? Pls explain.

Keep in mind that “/media” is for auto mount. If your storage device is not plugged in, and if any removal of the storage device was performed cleanly (with proper umount and not just removal), then that subdirectory is not part of the disk on the Jetson. This would be the name of a temporary mount point based on the partition or device ID. You shouldn’t have to delete that if the device is not auto mounted.

The UID was from your earlier “lsblk -f”. I see some screenshots which have a different ID. Both device and partition have an ID, and I was want to know if you can mount using the “cb277d1c-7a23-4c1f-bdbe-afbfe7bb9b25” ID. It would also be a valid test to see if you can mount (and umount) ID A0B3-EE03. Did you try the commands from my last post?

Do keep in mind that if a device is mounted, then you have to umount that device before you can mount it again. Automount can get in the way. You can name umount of a device or a mount point. For example, if you see the device mounted on /mnt via lsblk -f or df -H -T, then you could “sudo umount /mnt” to remove that device. The same is true if you see it in a “/media” subdirectory. You would always umount before you delete the mount point (e.g., before you “rmdir /media/cabs5-willet/A0B3-EE0C/”).

If a temporary mount point is left over after a device is no longer used, then I suspect it was removed without cleanly umounting the device first.

I don’t know about “fixed” or not. I’m only looking at trying to get a proper mount.

Thanks for all the support and information.

could not try out these troubling shooting steps, as we were support to do a fresh flash for our unit due to some reasons, anyhow in future, will try out these steps, if we come across these issues.


Hi could you please help me/provide guidance on this “Secure Erase” feature implementation as raised in the below thread:

I have no experience with secure erase, so I am unable to comment on that topic.


ok. Thanks