This content might not be owned by a package, and so this might not show anything, but what is the result of these commands (the file might be a symbolic link, and if it is, then the file actually pointed at by the link is of interest, and either/or of the original/sym link might not be owned by a package, but if it is the package name is of interest):
ls -l /etc/udev/rules.d/70-snap.snapd.rules
# If this is a symbolic link, substitute the full path for the link, otherwise:
dpkg -S /etc/udev/rules.d/70-snap.snapd.rules
Looks like that file is generated (rather than being provided directly), and I’d like to find out where the configuration comes from (on the unit which works). Also, on the unit which works, did you install any kind of driver or other file on the unit? Was that same software not installed on the non-working unit? Was there any kind of configuration command or setup involved in the working unit which might not have been applied yet to the failing unit?
In the case of a configuration or other command I’m thinking that what is generated might differ if the installation and/or other software was installed while the unit was connected via USB, versus if not. I am trying to find any clue as to what was supposed to be installed, and whether or not the USB might have been connected (or not connected) at the time of the software install on the working unit. Anything which might suggest a difference between how that file was generated on one Jetson versus the other is of interest.
Incidentally, there might be USB events which regenerate this file. That means that we might be able to test by temporarily copying the 70-snap.snapd.rules
from the working unit as a test (first back up the original), but if something causes generation of a replacement file, then it might go away.
I don’t know all of what snapd
does, but it is generally started by systemd
during boot (which in turn is PID 1, the only process the kernel starts, and known as “init
”). There are a lot of systemd
configurations possible, sometimes based on only enabling or disabling something; at other times you have to install software to make enable/disable possible. Yours is obviously related to ModemManager
, and so it gets worse: I don’t know what makes the particular device visible to snapd
, and once snapd
is running, I don’t know which snapd
service or file works with that particular USB device. It’s going to be a bit of a detective story to figure that out.
On the working unit this becomes more useful (I’m just poking around until seeing something which might say where the command comes from):
find /etc/systemd -iname '*snap*'
- `egrep -R -i ‘ModemManager’ *
- systemctl list-units | egrep -i ‘(modemmanager|uart|cdc|acm)’
- Is there any file on the working Jetson in “
/etc
” which is named after the product?
snap list
Note that udev
content will work just by plugging in a USB device (or unplug/replug), but other content might require a systemd
startup (which might also rewrite a configuration file).
Incidentally, for the “/etc/udev/rules.d/70-snap.snapd.rules
” file, if it is a regular file (on the failing unit) and not a symbolic link, then you temporarily disable it via “sudo gzip /etc/udev/rules.d/70-snap.snapd.rules
”, copying that file from the working unit. Then to get rid of that copied version and put the original back, just “sudo gunzip /etc/udev/rules.d/70-snap.snapd.rules
” (compress, replace original, then put back by uncompressing original). If the file is a symbolic link, then you have to use link commands. You can try replacing that file on a running Jetson and see what happens. Probably you’d plug the USB item in after those rules are in place; if it works, then reboot and see if the file is still present and if things still work (but beware something might trigger removing your edited file at any moment).
PS: I might not be around much for a week, so I might be slow to reply, but explore how any “/etc
” configuration might differ between the working and non-working unit.