When cloning a TK1, I’ve come across issues whereby the eth0 interface on the new TK1 is now no longer recognized. If I attempt to configure the eth0 device, I get the following errors:
sudo ifconfig eth0 192.168.1.202 netmask 255.255.0.0 up
SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
eth0: ERROR while getting interface flags: No such device
My guess is that when I cloned the rootfs, I included some files that should not have been included.
Is it possible to recover this situation? I’m thinking that wherever the MAC address is stored has been overwritten - if this is the case, I hate to think what else has been overwritten!
Ooops!
If the rootfs is from a version of L4T which is different, then you may need to make other updates (which may or may not be practical). What L4T release is the rootfs clone from? What L4T release was flashed to the new unit prior to writing the clone onto it?
Thanks for your reply. The rootfs is from the same R21.5 release.
I have to wonder if something did not quite clone correctly. Are you able to mount the raw image via loopback on the host which does the flash (perhaps monitor “dmesg --follow” while doing this)?
sudo mount -o loop /where/ever/it/is/system.img.raw /mnt
ls /mnt
sudo umount /mnt
What is the exact byte size of the raw file?
I followed another another post on a different forum suggesting that deleting the
/etc/udev/rules.d/70-persistent-net.rules
would resolve the issue and it has.
There were a couple of other minor discrepancies but on the whole, it seems to work well now.
That file chooses a new interface name based on MAC address…but if it uses the MAC address of the wrong Jetson, then it could indeed cause network failure (or at least odd behavior such as a timeout). This is one to remember…I’m sure other people cloning for a production environment will be interested in this one.
For people curious about such possibilities, explore the files from:
sudo find /etc -name '*persistent*.rules'
EDIT: Normally rules for this are in “/lib/udev/rules.d/”, but customization goes into “/etc/udev/rules.d/”. A rule in the “/lib” version is a candidate for going in “/etc”, but won’t have any hardware-specific values when in “/lib”. Whenever a udev rule appears in “/etc” you can be suspicious that there is something about either the hardware design (such as a rule just for Jetsons) is involved, or in this case, a rule about a specific address of a specific piece of hardware being involved. Rules specific to Jetsons should be cloned, rules specific to a MAC address would need edit. Removing the file is a fallback because there are default rules.