For those running into lock issues on package installs…
One subtle design issue on many Linux distributions (including both Ubuntu and Fedora) is that often the GUI login will include a check for updates in the little system tray icons in the tool bar (where it displays and with what program depends on your desktop and distribution). If a login to GUI does this, then during the check there will be a lock file generated with the package update tool. Until the process ends the lock file will remain in place and no other process will be allowed to touch package update.
If all goes well, then after a few minutes the lock file goes away and you can try again. If something goes wrong, then a stale lock file will be left in place (often fixed by reboot). One possibility for the file staying around is if networking fails and it gets stuck there (this requires both network and DNS being able to talk to the outside world). I suspect that either something will take a long time to time out, or a previous boot has left a stale lock file.
Does your Jetson have this file?
/var/lib/dpkg/lock
If this file exists, do you see a process listed with:
fuser /var/lib/dpkg/lock
If and only if there is no fuser output (and therefore nothing actually using dpkg) you can simply delete this file. Do not delete this file if anything is listed as using it.
If the lock file exists and something is using I recommend waiting to see if a timeout ends the process using this. This might take quite some time…I’m not sure how much…but perhaps several minutes or even an hour.
If this doesn’t do the trick, and something is using the lock file and you’ve decided waiting won’t work, then you can try telling the accessing process to gracefully shut down. The fuser command would have returned a process ID which “kill” can work with. Doing this wrong is probably not a high risk, but the risk is still not without merit if you kill the process violently as this is related to the database the package manager is working with. As an example, if you have a PID of 3547, then you can see processes like this:
ps aux | grep 3547
…output might be something like this:
root 3547 0.2 0.5 53152 47732 pts/9 S+ 19:00 0:01 apt-get upgrade
root 5154 0.0 0.0 5548 568 pts/8 S+ 19:06 0:00 grep -E --color=auto 3547
Killing this would be something like:
sudo kill -HUP 3547
This form of kill allows the application to try to shut down gracefully. This might take a few seconds (or more for disk operations like this), and it might not work at all. There is no harm in issuing this command a few times and waiting several seconds between tries. Once the process no longer shows up with “fuser /var/lib/dpkg/lock” you can rm the lock file.
If the process is stuck and you are willing to take a risk, then you can use:
sync
sleep 1
sudo kill -9 3547
# verify nothing using the lock:
fuser /var/lib/dpkg/lock
sudo rm /var/lib/dpkg/lock
Do you have this lock file? Avoid logging in to the GUI and check after reboot via ssh or serial console or even CTRL-ALT-F2 to get to a text console.