Stuck at step Open your browser and access http://<IP_ADDRESS>:7860
I’m able to instantiate the docker container for text-generation-webui and it’s running (as shown with “docker ps -a”) however, the Ports area is blank. Navigating to localhost:7860 via Chromium does nothing. How can I expose ports from docker to the host machine? (Would hope this would happen automatically in the container config file) This is a fresh build, maybe a step in the tutorial is missing? Many thanks in advance, this is the second time flashing and installing but no success yet :-(
It looks like docker container is not launched properly or not configured. You should see the something under PORTS and curl should respond. I tried 2 of the training/demos and neither worked…My board crapped out and had to send it back and we only have one and they are of stock in USA so I cannot do any more testing.
Picking this apart is hard without a board.
The whole purpose of the container is to avoid issues like this, they should install and run without any headaches.
I am out of guesses on this, other than to back peddle and install r35.
You can build the packages yourself, that is how we do it.
Just guessing on this since my board is out, it will explicitly launch with that port
Appreciate your efforts in debugging, I’ll continue to dig through this along with any documentation. I was able to run a simple nginx docker container which exposes a port to the host machine successfully…and launches in the chromium browser
docker run -d -p 8080:80 --name my-web-server nginx
so the issue must be within some configuration of the jetson-containers wrapper…
Didn’t expect such a steep learning curve off the bat!
Their is no learning curve on running a container, at least should not be. I tried to light up 2 of them and neither worked. For one, that board only has 8gb ram. That is not enough for some of the stuff. You can run nvme and set the swap to 60Gb however you will need a heatsink on the nvme. It will not run as fast as ram but it should run. Most of the stuff we have been testing is running a little over 7gb ram and its not anything heavy duty.
Since the nginx container is working its not your fault. Pulling this response out of the air, should be a config script in the docker, might check it and see if it is pointing to localhost or cloud url. Also make sure it completely downloaded.
I seem to have gotten much further through various re-installs and library updates from the base Jetson Orin Nano Developer Kit JetPack 6.1 (rev. 1) image.
Here’s what I did differently from my previous attempt.
After the OS installed from image, I did not upgrade to Ubuntu Pro (not sure if that makes a difference)
Following the mounting of the NVMe SSD for Docker, I mapped the drive as /mnt instead of /ssd
Before installing Jetson Containers, I made sure to install python3-pip and jetson-stats for Jtop.
Did a sudo apt update, dpkg --configure -a and apt --fix-broken install for good measure of anything lingering.
Installed Jetson Containers, then installed the Stable Diffusion package and got worlds further! (The package was able to download third party libs etc, run builds with cmake, all which wasn’t happening before. Compiling took quite some time.)
But alas, no ports are exposed to connect to localhost.
The only key differences from what I can tell were the drive mount name as /mnt instead of /ssd, and not installing Ubuntu Pro, maybe the pro version has additional network lockdowns or more strict permissions?
I finally got an instance of stable diffusion running in docker, and was able to connect to localhost:7860
It seems that not all of the jetson-container examples are quite ready for Jetpack 6.1 with the autotag feature…
For example, “jetson-containers run $(autotag stable-diffusion-webui)” fails miserably with tons of inline errors during compilation, however “jetson-containers run dustynv/stable-diffusion-webui:r36.2.0” will compile and work just fine. A weird side effect though is that running docker ps -a still doesn’t show any ports named, but they are in fact open.
So, this seems to be a simple container issue, and not an underlying issue with either docker, jetpack, or the board.
Now, to find a version of pytorch that works for this setup! (22.04 with JP6.1)
