Nuts on enviroment and config!

first post…please bare with me
wow…what a mess!
I design scary big HPCs for a living. Prior, I’d spent 25+ years designing robotics, factory automated test and manufacturing systems… I’ve been programming since the 70’s. Have at least 30 various embedded technologies under my belt, so I figured one more 'puter…no big deal.

What a convoluted mess of info there is for this new (to me) TX1 dev board. Two days I’ve spent reading dev docs and other base info…just to find out the revisions of this ‘as supplied’ operating system pretty much voids all the reason I bothered to buy it! (is now 64 bit /64 bit) with most coding examples and libs still 32 bit.

The worst part… seems this board as delivered (LT4 running r24.1) is scrambled… can’t get the as installed ff browser to run (apparently 32 bit FF) and just now hit a wall… GIT can’t be found??

Online info is so convoluted with so much out of date and interspersed versions it’s hard to even figure out WHAT is the right path forward. Updating the op sys needs a second computer?..running a specific version of Linux?? What ever happened to Debians at least?

…sorry…sounds like griping here… just amazed that such a forward tech is so scattered

Ok to the point. … a Q… why can’t an entire opsys with libs be config’ed and imaged to these boards. Did I totally miss something somewhere?? More so …how to know you’ve included the proper libs to use the resources presented?

tia

So… obligatory question…
What is the best path forward, updating to what appears to be v28.x. … docs

I don’t know how much experience you have with Linux itself, but it comes in handy. So forgive me if I mention things you already know.

64-bit/32-bit

There are actually two environments to consider if programming entire operating systems. One is kernel space, the other is user space. Most of the time the two are both the same instruction set, so both are either 64-bit or 32-bit…most of the time.

A desktop x86_64 CPU is x86_64 architecture, and 64-bit. On the desktop there is a compatibility mode for 32-bit, usually called i686 (i386 up to i686 were of course all 32-bit, but the newer i686 supported additional features). When the Intel format CPUs first released 64-bit versions they were concerned with backwards compatibility with 32-bit PCs. Basically old 32-bit compatible hardware was glued on to the 64-bit hardware. When you see software available for a desktop PC from most package management flavors you will typically see 64-bit versions of the package.

The 64-bit architecture is the native architecture for the PC. 32-bit is only valid if you’ve supplied “compatibility” libraries and linkers for user space. If you’ve added 32-bit compatibility, then the package manager has been told about a foreign architecture you are interested in…this is despite the fact that 32-bit is built in to the CPU. The CPU goes into a compatibility mode in order to service 32-bit (it isn’t a software adapter, it is a hardware adapter).

The TX1 is 64-bit ARMv8-a, but has a 32-bit compatibility mode similar to the desktop PC CPU…“ARMv8” without the “-a” is 32-bit, “ARMv8-a” is 64-bit. Kernels and kernel space and drivers always run 64-bit, this is native. To run 32-bit the CPU goes into compatibility mode. This is a foreign architecture directly supported by the ARM Cortex A57 cores.

To use 32-bit you have to be in user space. This in turn implies drivers and kernel space still run 64-bit. The linkers and libraries are 32-bit. ARMv8 32-bit is a super set of the older 32-bit ARMv7. All ARMv7 instructions will run on ARMv8, but not all ARMv8 instructions will run on ARMv7…though they might for the bulk of instructions.

32-bit on the first TX1 was used in user space because it was the moment of transition when most previous packages and applications had been built for 32-bit and were not ported to arm64/aarch64/ARMv8-a packages. Drivers and kernel space were still 64-bit, and the hardware is still 64-bit.

Very soon after arm64/aarch64 appeared on the market packages began arriving which were built for this architecture. NVIDIA released an upgrade in which both user space and kernel space were 64-bit. No 32-bit compatibility mode is added, although you could add 32-bit libraries and linkers in user space and tell your package manager you are interested in seeing that foreign architecture (armhf/arm32). This would probably be a bad choice on an embedded system, especially since storage is limited and since the 32-bit compatibility mode is quite slow.

The next release, being fully 64-bit in both user space and kernel space was a big improvement since there were actually 64-bit packages available. This is with a 3.x version kernel. The R28.1 release has not only pure 64-bit, but it has also migrated to the newer generation 4.x kernel.

Note that adding a foreign architecture to a native architecture is a “Linux thing”, and not specific to Jetsons. On a desktop PC this is simple because the compilers have integrated 64-bit and 32-bit support in a single compiler (linkers and libraries still must be a separate addition). There is very little difference between adding i686 support on a PC and adding cross-compile armhf support on a PC…only the desktop PC CPU can’t switch to armhf and execute it. User space support for cross compile of ARMv8-a gets a bit trickier because compatibility mode causes the need to support not just 64-bit tools, but also 32-bit tools…and compilers and tools are not integrated for these architectures the way they are integrated on a PC.

Even if you ignore 32-bit/64-bit compatibility and features I would always recommend flashing before you try to do any real work because the initial releases were never all that great, and the latest 64-bit release is quite good.

Flash Software

So far as flash software goes JetPack is a front end to the flash script. The flash script only requires any x86_64 Linux and is not dependent upon Ubuntu (I use Fedora, I don’t like Ubuntu for development, and Ubuntu cannot be installed on my desktop due to bugs in its installer regarding BIOS style partitions). The Ubuntu 14.04 requirement is just for JetPack. Part of the reason for this is that JetPack can manage packages for cross-platform work on both host and the Jetson. It’s hard to create a general utility for a platform if you don’t know which platform it is…creating packages for simultaneous use of Fedora+SuSE+CentOS+Debian+Ubuntu+WhateverGreatFlavor would not be easy.

Ubuntu 14.04 is supported for use as a host, and though not supported, many people have reported that Ubuntu 16.04 works fine for the most part…most issues are related to packages which won’t work on 16.04 hosts. Unfortunately there are some software packages which at first seem available only via JetPack. I say “seem” because on any x86_64 host you can extract the URLs of those packages and download them with wget…manual install order issues can be a pain though, whereas JetPack handles install order issues for you.

Word of caution on flash software on a VM: Many people use a VM and discover a VM typically does not have well-behaved USB (technical term: “it sucks”). VMs are not supported, but the people who have made this work typically have to fine-tune USB, e.g., specifically mark the Jetson in recovery mode for pass-through, specifically mark to run in USB2 mode, and add additional buffer to the USB port.

Should you choose to flash on command line without JetPack you would need the driver package plus sample rootfs. Both the TX1 and TX2 use the same sample rootfs in this release, but the driver package is different. Be sure on driver package to pay attention to TX1 or TX2 driver package version if you go this route. The R28.1 URL is here (you may need to log in separately, not sure):
https://developer.nvidia.com/embedded/linux-tegra

Flashing

For both JetPack and command line make sure your Linux host uses a native Linux file system type. NTFS/VFAT/others do not work since they cannot preserve Linux permissions. I think Live DVD distributions also would require a separate mounted Linux file system type, e.g., ext4.

For JetPack you just unpack as a regular user and run it as a regular user…you’ll be prompted at some point for a password to use sudo.

If you do flash on command line you’ll see images are indeed used. Typically it would go like something like this:

  1. Make sure you have lots of space.
  2. Unpack the driver package as a regular user.
  3. Make sure you still have about 20GB or more of space.
  4. cd to "Linux_for_Tegra/rootfs/" and use sudo to unpack the sample rootfs as user root.
  5. cd back one directory up to the "Linux_for_Tegra/" directory.
  6. Unpack the sample rootfs with sudo (as user root).
  7. Run "sudo ./apply_binaries.sh"
  8. Put the Jetson in recovery mode, attach the supplied micro-B USB cable.
  9. Make sure the TX1 is visible to the host, run "lsusb -d -0955:7721" and see if something shows up...it should.
  10. Run this command and wait...it takes a long time:
    <b>sudo</b> ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
    

During the flash the rootfs folder is used for the basis of creating an image for the root partition (“APP” partition in config files). Depending on other arguments part of the boot environement is adjusted, e.g., some files in “/boot” will change versus the rootfs “/boot” directory, but everything else will be verbatim.

apply_binaries.sh overlays the NVIDIA hardware drivers onto the rootfs folder. Without this the sample rootfs is pure Ubuntu. Once you’ve added the NVIDIA drivers it can be referred to as L4T (Linux for Tegra). Even so, it is still Ubuntu and you can use any Ubuntu admin book/information directly on the Jetson.

The flash.sh script has an option “-r” to reuse the image. In this case it takes less time because you don’t have to generate a huge image. It also allows to restore a system from a clone of the rootfs image if you have previously backed up via cloning.

You will see subdirectory “bootloader/”. Before a flash you will not see any “system.img*” file. After a flash you will see “system.img.raw” and “system.img”. “system.img.raw” is the entire file system bit-for-bit and can be loopback mounted, edited, so on. “system.img” is a “sparse” (basically compressed) version of this. flash.sh option “-r” would imply reusing the existing system.img file. What comes in handy is that if you place an uncompressed system.img.raw there, and name it system.img, then flash works perfectly fine even with the uncompressed version (just make sure the name is system.img). system.img and system.img.raw take up a lot of space on the host, but if you are going to flash without reusing the image, then you can consider these temporary files and delete them when done. If you are reusing those files then you don’t need the content of the “rootfs/” subdirectory anymore…you could delete those files and unpack sample rootfs again at a later date if you want to generate a new rootfs image.

Do note that flash uses only the micro-B USB cable. JetPack is a front end to flash and package management, so during flash stage no ethernet cable is required. After flash, when package management begins, ethernet is required, and it must be wired ethernet, not WiFi.

Miscellaneous

A really big difference between a Jetson and most embedded systems is that you are creating an entire Linux system, not a bare bones system. The sample rootfs is not a cut down customized system, it is an ordinary Ubuntu system. This tends to mean you will need to know how to be an administrator (to some small extent) on Ubuntu.

Probably your questions about missing packages would be best studied by knowing “apt” and “apt-get” are the normal Ubuntu package tools. The file “/etc/apt/sources.list” contains a list of standard Ubuntu repositories used for package search…for many packages you will have to uncomment some of the optional repositories.

After changing sources.list (or perhaps before any update) you should run “sudo apt update”. This creates a snapshot at an instant in time for what is visible.

If you wanted to search for a package, e.g, git, you’d run:

apt search git

If you wanted to install git:

sudo apt-get install git

To be fair, this is the only embedded system which is basically a true and full operating system capable of competing with a desktop in such a broad range of uses…but it is still an embedded system. Space is never free without a trade-off. A desktop system can afford to install every kernel module there is for your acme elephant elevator controller and wyle e. coyote roller blade controller…or for the AMD graphics card and the Intel 10G-base-T driver. It would be a terrible choice if your Jetson arrived with all of that on it the way a desktop does. Very few people develop natively on their embedded product when it is something less powerful. So consider that despite the resemblance to a desktop in function that you won’t get as many pre-installed packages just because it is an embedded product.

If you want to verify the NVIDIA drivers are correctly in place (they don’t use apt or package management):

sha1sum -c /etc/nv_tegra_release

Note that on rare occasions an Ubuntu package could overwrite “/usr/lib/xorg/modules/extensions/libglx.so” (if video breaks after an update this would be the cause). You can restore this by deleting whatever version of libglx.so was put there, and then adding a symbolic link to “/usr/lib/aarch64-linux-gnu/tegra/libglx.so” (this is the hardware accelerated version). Example:

cd /usr/lib/xorg/modules/extensions
sudo ln -sf /usr/lib/aarch64-linux-gnu/tegra/libglx.so <b>.</b>

I would definitely recommend keeping packages up to date, don’t avoid updates. Also, if your Jetson is visible on a network that isn’t yours beware that the passwords are defaults known to the entire world. “ubuntu/ubuntu” and “nvidia/nvidia” name/pass should be changed before touching the outside world.

thanks very much for that well thought out dissertation. At a minimum, good for the archives as a dense guide for flashing and ref in general.

All is well understood… a few tidbits did add …‘some’ clarity…but still makes my point of a convoluted procedure to flash/update.

So I guess though I’m still dead in the water upgrading. We don’t have a Linux native machine to use to do the upgrade. I flashed a normal Ubuntu 16.x to a thumb drive… then installed the iso in a VM on an x86 machine (under Win10), only to re-read your statement regarding operational instability of the procedure…would hate to get halfway through and die…leaving a scrambled dev board.

What about a kubernettes (or other container)? A couple other SoC embeded boards here as sooo simple by comparison to flash/install from scratch. Since this is a development board, I’m amazed a generic nVidia image could not be iso’ed with all oem libs for dnl, then simply supply apt-gets for libs as desired.

guess this might simply get shelved for now, and use what we know here works easily and reliably for the customer :-(

v/r

ptegler

A thumb drive in and of itself will work, but you would have to reformat it with ext4 file system underneath…most arrive with VFAT.

I’m not familiar with kubernettes, but most VMs will work…after a lot of work getting USB to behave well. The typical symptom is that flash will start correctly, but then halt or error out with USB not responding correctly. I suspect that all VMs and containers add latency or other overhead requiring tweaking of parameters in their pass-through from host to guest O/S.

Should a flash start and then halt, it will likely leave the Jetson unbootable until a new flash occurs. It depends on which stage it stops in.

So far as flash goes understand that a Tegra boot is far more complicated than bringing up a common microcontroller. There is in fact an embedded server system just for bringing things up (I think it is called “3p server” in some errors I’ve seen in the past…but this has probably changed some since the TK1 I first observed it on). Just accessing eMMC for flash would be useful, but flashing to bring up a system where boot environment is also set up is more complicated than what you may be used to from something like a Cortex-M CPU.

One possibility is to get an external USB3 hard drive (for speed). Format it with ext4, and install a native Ubuntu 14.04 O/S (16.04 works if you don’t expect the host side packages to be installed…any x86_64 Linux works if you use command line instead of JetPack…basically just flashing and not additional package installs if you stick to command line). Then you would have a native install system which does not depend on a VM or container (this requires the ability to boot to a USB drive without modifying your boot loader to depend on the USB drive being there…a rescue/install disk can boot to the Linux install even if the boot loader itself has no such entry…avoid letting your boot loader be installed during the Linux install…make a backup of your boot loader before starting).

thanks again for the detailed respons(s)

Morning is obviously a better time for technical thought :-) I realized my QNAP network backup device is native Linux. Plugging a keyboard, mouse and HDMI monitor directly into the box (vs just a network cable) I was able to fire up a full 64 bit Ubuntu 16 environment.

Following the guide at http://docs.nvidia.com/jetpack-l4t/index.html#developertools/mobile/jetpack/l4t/3.0/jetpack_l4t_install.htm everything flew for the most part … until…

Everything DNL’ed and unpacked on the host (QNAP) without issue.
…even found the dev board with lsusb. That’s where the fun ended. I got a sub-dir (or file?) failed write permissions telling me to fix it. close the terminal window and restart jet install.
I looked at the permissions (error in the log file)…didn’t see any issues…so restarted everything.

Everything ran well again… until after ‘making boot image… done’
It copied a couple files…bcffile, tegraboot, wb0boot, dtbfile (couple of ‘reused’ in between as this was a repeat attempt)

but then it errored on ‘Making system img…’ the error in the file reads
/dev/loop0 is not block device. Terminating…

so now I haven’t a clue what’s going on. Should I try booting the dev board?
One thing the procedure (linked above was a mention of paying attention to target device screen prompt…which of course is not there as the dev board is in flash mode…no video out (at least on this device

Any ideas how to proceed? what to check? I’m sitting hre i nthe middle of three machines… Win10 for interent and email (this message reply) the QNAP Linux host, and the dev board…afraid to turn anything off…

ptegler

wow…answering my own Q’s here… realized the block issue was a port.
Back on a win10 network machine I can see two Ubuntu machines and their IP’s (network scanner) and going into my router, can see them as well.
Problem now is the JetPack L4T 3.1 window asking me to enter the Jetson TX1 network IP address, un and pw will not accept any of those ips. Is there a default pw and username? It also seems like it only wants to open port 22 for any address I enter. I tried the username and password I ‘was’ using on the jetson, as well as the defaults for ubuntu to no avail

ideas? suggestions?

tia

ptegler

It isn’t clear if the flash portion completed and the Jetson can be rebooted or not. Does the Jetson boot up? I suspect not if system.img failed, so here are some things to check.

First, does your host use a native Linux file system type, e.g., ext4? If you are on your host and run “df -H -T” it will show available capacity and also file system type.

Next is a bit of information regarding loop0, the loopback device which gave the error…

During flash a bit-for-bit exact file system is generated. That file system is the exact content of the root partition in binary form. The content will be whatever is in the rootfs directory, modified somewhat with various boot configuration edits (nothing but boot configuration and boot environment will differ from the rootfs subdirectory). In order to accomplish this a blank file the size of the file system is generated, and then it is covered with loopback to make it look like a block device. There is a bug in how the flash.sh script does this, and so it will fail except when things start out as expected (things won’t be as expected if the host is not configured to support loopback, or if that loopback device is in use).

Normally the command “losetup -f” will find the first unused loop device…for most people this will be “/dev/loop0”. Should it be a different device, then you will have to edit flash.sh to get around the bug. Should losetup not work, then it probably means your kernel is not configured to support loopback. Some otherwise “ordinary” Linux appliances have this cut out, but Ubuntu 14.04 and 16.04 both have this enabled in a regular desktop distribution.

Note that if a non-root user runs “losetup -f”, then the first unused loopback device is mentioned, but if that device does not yet exist, it won’t be created (check “ls /dev/loop*” before and after “losetup -f”). When root runs “losetup -f” the story is different: Not only does this mention the first unused loopback device, it will also create the device if needed (provided the kernel has loopback support).

You’ll need to verify if root can run “losetup -f”, and if the named loopback device exists. You’ll also have to verify it is loop0. If it is not loop0, then you can make an edit in flash.sh to work around the loopback bug. If the kernel can’t create loop devices, then you’d need to add support for that.

Once loopback works subdirectory “bootloader/” will create files “system.img.raw” and “system.img”. These might exist even if parts of loopback fail…but the content will be wrong if this is the case. If you give the exact size of “bootloader/system.img.raw” we can tell if this was the full size or if it was truncated. Example: “ls -l bootloader/system.img.raw”.

If the system.img.raw is the wrong size, then login may fail due to a truncated file system. If “df -H -T” shows the partition file system type on the host is not a native Linux type, then permissions will not have been preserved and you will get many commands failing (especially the sudo command)…the system would basically work, but very little would work right. “df -H -T” will tell you if you had enough disk space, and also name the file system type.

Note that if you run command line flash, then you must run it sudo in order for losetup to work. For JetPack you run as a regular user, but it will prompt for a password and use sudo where needed.

Once flash succeeds the device should be rebooted…the USB cable is no longer needed after reboot. Login should be for user “ubuntu”, pass “ubuntu”, or user “nvidia”, pass “nvidia”. If these fail, then it is a significant chance that something went wrong in the generation of the system.img.raw file; if this was all correct, and if the Jetson is connected to a public network, then there is a significant chance someone port scanned you, saw the Ubuntu install, and got in and did something malicious (this can occur surprisingly fast).

ok…two more days… another attempt at a flash.

The system dies saying there are no more loop devices avail! Yet rerunning…it dumped a bunch of files to the dev board…and says in the end it completed.
But along the way I had to open another terminal to rednl and unpack files before the process would continue

/dev/ dir doesn’t show any loops… doesn’t show any ttyusb either just LOTS of ttys

I know I read somewhere you can force/create a loop device…wondering how that might conflict with other system parts…

elinx.og post states something about network cabling direct, to transfer the sys to the TX1
??? need to re-read that…but many posts there specific to the TX1 dev platform seem so much more straight forward then the jetpack directions… many of which did not run like the guide says as it walks you through the install

now reading all the issues with the 64/64 environment… will probably settle and go back to (try to install) an earlier 64/32 env (where most libs still are)

If that fails… this board is headed for EBay!

ptegler

The flash.sh script shouldn’t be hard wired to “/dev/loop0”, but it is…that’s a bug (the script attempts to use losetup correctly, but the logic is incorrect…losetup needs to run prior to the exit statement…I haven’t looked closely at R28.1 but it seems to have that flaw). What should happen is that as root (sudo) it runs the command “losetup --find”, and then marks the returned loop device as the one to use (it doesn’t work to exit if loop0 is invalid and only run losetup after exit…and in fact loop0 might be a valid loop device, but not the one available…again, losetup needs to run before testing if loop_dev is valid, not after testing). You can get around this manually, as there may be reasons why loop0 is used elsewhere (it might be part of a loopback mount for something else).

Prior to flash, run “sudo losetup --find”. Normally the answer will be “/dev/loop0”. If this is the case, and if you have file “/dev/loop0”, then all should work. If a different loop device is named, e.g., loop1, then edit flash.sh and where it says “/dev/loop0”, change it to “/dev/loop1”. No matter which version of driver you use, if loopback is wrong, flash will not work as expected. If you have a lot of “/dev/loop#” files, then perhaps you have a program running wild and using all of the possible loopback devices…but this is unlikely. Having a few loop devices would be common for some crypto functions (or if you ran a second flash.sh before the first exited this would also happen).

The image being generated starts out as a very large, empty file full of NULL bytes. It is then covered by loop0 to make it look like a block device. After that it can be formatted and sample rootfs copied over to it. If loop0 fails, then so will formatting, and so will copy of any content (copy might occur, but it won’t be to where it is expected). Flash will happily continue and use the blank very large file (about 15GB) to flash a lot of NULL bytes to the Jetson. Flash is actually separate from creation of the content being flashed, so loopback can fail and flash can still succeed…it just won’t be a useful flash.

ok makes sense as far as the flash continuing even though I get a loop failure…

on the TX1 dev I’m left with a bootable device (lots of stuff scrolls by) then the Ubuntu desktop comes up… USB3 port goes live (during scrolling) then dies as the desktop comes up (usb3 hub has idiot lights about each active port…comes on then goes out) … so cannot access anything as no mouse or keyboard is live with the desktop. so will have to try a re-flash to get …anywhere.

Q though… the /dev dir shows NO loop devices, nor TTYUSB devices, only a few TTYSx devices.
ideas? what to run to create/assure a loop device is avail for the xfr.

tia

ptegler

There must be a “/dev/loop0” during the flash if the default script is used. “sudo losetup --find” guarantees creation of the device (to emphasize, it must be with sudo…a regular user cannot create a loop device…one of the reasons why root must be used to run flash.sh). If the Jetson boots as far as you said after a flash, then I would conclude there was a loop device during flash. There are some pre-made images other than rootfs which would flash correctly even without loopback, and would have some activity because U-Boot would run fine until it is time to load the o/s kernel…then the next stage of boot (loading the kernel) would fail if loopback had not existed. Check “sudo losetup --find” prior to flash, check “ls /dev/loop*” after “sudo losetup --find”, and also during flash.

The ttyS and ttyUSB devices are serial devices…different from loopback (loopback is a block device, and is virtual without real hardware behind it).

EDIT: Check available disk space on host as well with “df -H -T”. Make sure your image isn’t truncating due to insufficient disk space.

thanks for the quick reply… just finished dinner… now headed off to abuse my Linux box

ptegler

sudo losetup --find
simply responds with
losetup: cannot find unused loop device: no such file or directory

df -H -T…
/dev/mapper/cachedev1 ext4 size 3.0T used 510G avail 2.5T
/devtmpfs 4.2G avail

…plus lots of other stuff listed

ptegler

losetup was run as default login admin@ubuntu_16-4
then re-run just to test after a sudo su as root@ubuntu@ubuntu_1604

ptegler

The “ubuntu” login will report the first available loop device…but it won’t tell you if the loop device actually exists. The sudo version will create any missing loop device.

4GB is not enough if this is the partition flash is run from. cachedev1 is plenty if this is your partition with the flash program.

If losetup cannot create or find an unused loop device, then it tends to imply your kernel was built without loopback support…which is unusual unless it is a live DVD or something other than a regular PC install.

my linux box as such is a QNAP 251+
it’s a network connected dual drive backup server.

Plugging in an hdmi cable keyboard and mouse directly, even when it’s already up and running… give you a direct access Ubuntu 16.04 64 bit desktop.

No that I’m in a browser on that desktop I can cut and paste here,

admin@ubuntu_1604:/dev$ df -H -T
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/cachedev1 ext4 3.0T 510G 2.5T 18% /
none tmpfs 504k 0 504k 0% /dev
devtmpfs devtmpfs 4.2G 8.2k 4.2G 1% /dev/input
tmpfs tmpfs 68M 844k 67M 2% /var/nas-tmp
/dev/md9 ext3 535M 134M 402M 25% /etc/config/group
none tmpfs 210M 185M 26M 88% /etc/platform.conf
tmpfs tmpfs 17M 4.1k 17M 1% /.share
none tmpfs 4.2G 0 4.2G 0% /.share/CACHEDEV1_DATA/.qpkg/CodexPack/sys/fs/cgroup
tmpfs tmpfs 4.2G 0 4.2G 0% /.share/CACHEDEV1_DATA/.qpkg/CodexPack/run
none tmpfs 4.2G 0 4.2G 0% /.share/CACHEDEV1_DATA/.qpkg/CodexPack/run/shm
none tmpfs 4.2G 0 4.2G 0% /.share/CACHEDEV1_DATA/.qpkg/CodexPack/run/lock
none tmpfs 4.2G 0 4.2G 0% /.share/CACHEDEV1_DATA/.qpkg/CodexPack/run/user
tmpfs tmpfs 4.2G 201k 4.2G 1% /dev/shm
tmpfs tmpfs 4.2G 9.5M 4.2G 1% /run
tmpfs tmpfs 5.3M 4.1k 5.3M 1% /run/lock
tmpfs tmpfs 4.2G 0 4.2G 0% /sys/fs/cgroup
bindfs fuse.bindfs 17M 4.1k 17M 1% /share2
tmpfs tmpfs 827M 70k 827M 1% /run/user/1000
admin@ubuntu_1604:/dev$

admin@ubuntu_1604:/dev$ ls
char dsp1 fuse mqueue snd tty1 tty15 tty20 tty26 tty31 tty37 tty42 tty48 tty53 tty59 tty7 ttyS3 video3
console dsp2 hugepages null stderr tty10 tty16 tty21 tty27 tty32 tty38 tty43 tty49 tty54 tty6 tty8 urandom video4
core dsp3 initctl ptmx stdin tty11 tty17 tty22 tty28 tty33 tty39 tty44 tty5 tty55 tty60 tty9 video zero
dri dsp4 input pts stdout tty12 tty18 tty23 tty29 tty34 tty4 tty45 tty50 tty56 tty61 ttyS0 video0
dsp fd log random tty tty13 tty19 tty24 tty3 tty35 tty40 tty46 tty51 tty57 tty62 ttyS1 video1
dsp0 full lxc shm tty0 tty14 tty2 tty25 tty30 tty36 tty41 tty47 tty52 tty58 tty63 ttyS2 video2
admin@ubuntu_1604:/dev$

from the ubuntu file cabinet… doing a right click properties… on HOME…
says there is 2.4T free space. 18,000 some files at 9gig+
I’ve installed absolutely nothing except downloading LTS4 jetpack and built the files having run the (attempted to) the install to the jetson TX1

ptegler

damn thing will not seem to force a ‘loop’ creation…re-ran manually at the command line…see following
log error is still loop does not exit

admin@ubuntu_1604:~/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1$ lsusb
Bus 002 Device 002: ID 1c05:3074
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1005:b155 Apacer Technology, Inc.
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 007: ID 1d57:0008 Xenta
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 010: ID 0955:7721 NVidia Corp.
Bus 001 Device 002: ID 1c05:2074
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
admin@ubuntu_1604:~/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1$ sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
copying bctfile(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/t210ref/BCT/P2180_A00_LP4_DSC_204Mhz.cfg)… done.
copying bootloader(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/t210ref/cboot.bin)… done.
populating kernel to rootfs… done.
populating initrd to rootfs… done.
populating extlinux.conf.emmc to rootfs… done.
populating /home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/kernel/dtb/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb to rootfs… done.
done.
Making Boot image… done.
copying bcffile(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/t210ref/cfg/board_config_p2597-devkit.xml)… done.
Existing sosfile(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/nvtboot_recovery.bin) reused.
copying tegraboot(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/t210ref/nvtboot.bin)… done.
Existing bpffile(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/bpmp.bin) reused.
copying wb0boot(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/t210ref/warmboot.bin)… done.
Existing tosfile(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/tos.img) reused.
Existing eksfile(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/bootloader/eks.img) reused.
copying dtbfile(/home/admin/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1/kernel/dtb/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb)… done.
Making system.img…
/dev/loop0 is not block device. Terminating…
admin@ubuntu_1604:~/Jetpackinstall/64_TX1/Linux_for_Tegra_64_tx1$

This means your host kernel does not have loop device support. The kernel option is “CONFIG_BLK_DEV_LOOP”.

I’m not sure if this can be added as a module…if it can, match your existing kernel config and just build it as a module after adding that option. If not, then you will need to configure to match your existing kernel and add the option as an integrated feature…then replace the kernel itself. Be sure to match your “uname -r” suffix in CONFIG_LOCALVERSION.

I’m not actually surprised to see a dedicated storage appliance not have loopback support…this tends to be something used on a desktop PC and dedicated appliances generally do not include unused features.

…an update (don’t leave the masses hanging…)

went out on a limb… took my big Win10 machine …shrunk a partition and config’ed a dual boot of 16.04 and win10

Started all over dnl’ing everything, built and flashed as expected.

Couple of issues… so rinsed and repeated. fixed a couple problems but not all

updates on the TX1 don’t run… (none of the variations of software updater apps want to run. Window frames come up without any content

ran a couple tests of some of the cuda samples…all is well. Just not sure now… ended up with both a nvidia and an ubuntu user…thinking it’s remnants of the re-install(s) cycle.

ptegler

You will normally get both nvidia and ubuntu users on newer releases. I don’t know the motivation for this, but it does seem intentional.

So far as things sort of working, but not quite…two things might get in the way. One is if permissions were not preserved, the other is if the flashed rootfs was truncated. On the Jetson, what are the permissions of “/usr/bin/sudo”?

ls -l /usr/bin/sudo

…this should show “-rwsr-xr-x”…note the “s” for sticky bit.

On the system used for flash see how much space is available after the flash was complete for the partition JetPack is on:

df -H -T

Within the “Linux_for_Tegra/bootloader/” what is the exact size of “system.img.raw”? It should be an exact multiple of 1024. If you used “-S 14580MiB”, then it would be “1458010241024” bytes (15288238080 bytes); if you used “-S 14GiB”, then it would be “1410241024*1024” bytes (15032385536 bytes). If you did not specify rootfs size, then the default would still be divisible by 1024 either twice or three times. Any other value implies a truncated image. I think the default size would result in a filled file system with hardly any additional space use.

Finally, also check that driers are in place:

sha1sum -c /etc/nv_tegra_release