Device restarts on plugging in Ethernet (Was: Flash custom image via CLI)

Hi,

I downloaded resinOs image via CLI. I have a file which I can mount but with read only option. I am trying to add new network setup to my image and then somehow to flash edison. How can I do that?

Which Edison version have you downloaded? What do you mean by mount with read only option?

If the latest resinOS 2.x version for Edison, then you need to mount the resin-image-edison.hddimg file, which has the relevant boot partition, and place you network setup in the system-connections folder (that’s where the NetworkManager settings are).

Edison is a tricky one, as that is flashed directly instead of an SD card / USB drive that is used as for the other devices, so would be great to hear more about how exactly you are trying to use the cli for your use case, and would like to improve on the experience of that too!

sure!

So when I download OS files from dashboard panel I can only setup Wifi. I need setup GSM and Ethernet connection to internet. This is why I need the custom image :slight_smile:

When I use CLI
(https://docs.resin.io/tools/cli/#os-download-60-type-62-)
for image downloading and pass -o option like edisonOsDev.img the CLI will create a single file which can be mounted.
If I use standard ubuntu tool to mount it I have few partition mounted in read only mode so it is hard to change/add anything :slight_smile:
But I found this http://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/
And following steps I mounted OS files in read write mode. So I created needed files but I do not not how to save it to this single *.img file I downloaded and how to flash edison with it…

please help:)

hmmm it seems that if I use image downloaded from your dashboard I can simply mount a file you mentioned. Add my stuff and umount it:slight_smile:

so step
mount -o rw /home/pmg/dev/sense_workspace/edison/resinOsDev/resin-image-edison.hddimg /mnt/edisonDevImg/

  1. Add files you want for wifi, eth0 or GSM
  2. umount /mnt/edisonDevImg/

The file resin-image-edison.hddimg is in zip downloaded from dashbaord or you can use CLI to download OS image but pass -o . or omit that

Cool, yeas, whatever you download from the dashboard is the same as with the CLI, except that the one from dashboard has the configuration inserted already as well.

Sounds like you are on the right path :wink:

On a side-note, I’m using kpartx personally to mount filesystems in files, and works very well :slight_smile:
Also, it sounds like an interesting project!

Funny thing – having all that setup in place, and using resinOS-dev I have very strange resinOS behavior here. When I plug in an ethernet cable device close all terminal session (on serial an ssh via wifi) and reboot after a while :slight_smile:

Not sure I totally understand: if you plug in an ethernet cable, the device will reboot after a while? That would be very strange indeed!

What resinOS dev image you have? Downloaded from the dashboard? Does this happen with production image? If dev image, does it happen in local mode or any time? If you have a chance to log in to the host OS on the device, and see the logs, is there anything that looks relevant just before the device reboots? (Hope not too many questions, but it’s a strange thing as you mentioned:)

I tried with Resin OS 2.0.5+rev1 (prod).
It is hard to say what is going on cos no serial console is available on prod os (how to turn it on?). When I connect eth cable the device is going offline.

When I try with dev OS version I can see on serial console strange chars times to times. After a while, the whole thing stops and reboot. Right now I got back to dev OS and I added autoconect-priority to every network configuration file…

On serial console I see

*** Ready to receive application ***
03�03�0`3�~x�~~x�~

My eth0 setup is:
[connection]
id=my-ethernet
type=ethernet
interface-name=eth0
permissions=
secondaries=
autoconnect-priority=20
autoconnect=true

[ethernet]
mac-address-blacklist=

[ipv4]
address1=192.168.0.111/24,192.168.0.1
dns=8.8.8.8;8.8.4.4;
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

and wifi setup is:

[connection]
id=resin-wifi
type=wifi
autoconnect-priority=10
autoconnect=true

[wifi]
hidden=true
mode=infrastructure
ssid=galazka

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=borys2015

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto

and gsm modem setup is:

root@xps:/mnt/edisonDevImg/system-connections# cat gsm
[connection]
id=resin-cellular
type=gsm
autoconnect=true
autoconnect-priority=0

[gsm]
apn=internet
password=internet
username=internet

[serial]
baud=115200

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto

What can I do :frowning:

Hi. On which port do you plug the eth? What kind of adaptor do you use?

One of the last think before our app (in Java) kick in is installing drivers (in Docker container) to handle USB hub and eth adapter

So script runs
echo "Installing drivers for usb hub"
insmod /usr/src/app/hubDrivers/smscusbnet.ko
insmod /usr/src/app/hubDrivers/smsc9500.ko

We use exactly this
http://www.microchip.com/wwwproducts/en/LAN9514

Is this a proper approach to handle this custom hardware with resinOS?
Please help :slight_smile:

Hi,

regarding the way you handle the drivers I assume that the above commands are inside a script that is executed at the end of the Dockerfile.
You can also take a look here: https://github.com/resin-io-playground/kernel-module-build
So, yes this is a proper approach.

If you are referring to the specific custom hardware and if it will function properly, I think we will need a member from the devices team to validate. // cc @floion

Best,
ilias

At some point, we inserted driver as it is in your example but we build it (the *.ko files) on our own using this steps:
http://tektyte.com/docs/docpages/edi-expand/gettingstarted.html

so our dockerfile is adding drivers to image like this:

RUN mkdir -p /usr/src/app/hubDrivers
COPY hubDrivers/smsc9500/smscusbnet.ko /usr/src/app/hubDrivers
COPY hubDrivers/smsc9500/smsc9500.ko /usr/src/app/hubDrivers

COPY start.sh /usr/src/app
RUN chmod +x /usr/src/app/start.sh

ENV INITSYSTEM on

CMD [“/usr/src/app/start.sh”]

With dmesg I can confirm that driver are installed as the should. What do you think?

Since you confirm that the drivers are installed I guess the Dockerfile is correct.

How is your device powered on? Is it plugged directly to the plug?
It’s strange that it reboots when you plug the eth, but this can be sometimes related to power issues.

But when we use standard Yockto from intel the all thinks just works…

Can you try the following?

In your eth0 setup, can you change the [ipv4] section to:

[ipv4]
method=auto

Sure,

I downloaded right now new image from your dashboard and added ethernet conf file to image then flushed.

Conf file

root@63b9a65:/etc/NetworkManager/system-connections# cat ethernet
[connection]
id=my-ethernet
type=ethernet
interface-name=eth0
permissions=
secondaries=
autoconnect=true
autoconnect-priority=10

[ethernet]
mac-address-blacklist=

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

Routing table:

root@63b9a65:/etc/NetworkManager/system-connections# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 600 0 0 wlan0
52.4.252.97 0.0.0.0 255.255.255.255 UH 0 0 0 resin-vpn
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0

sorry I meant,

[ipv4]
address1=192.168.0.111/24,192.168.0.1
dns=8.8.8.8;8.8.4.4;
dns-search=
method=manual

(just replace method=manual with “auto”)

???

so you want static IP and method auto???

No, disregard that, apologies for the confusion.
I wanted to try the auto method as suggested in the docs to see if this was causing any issue that was leading to the reboot when you plug the eth

konsole.log (2.1 KB)
konsole2.log (4.7 KB)
konsole3.log (4.7 KB)

Please take a look at logs. When Ethernet cable is attached then resinOs boots. I can login. And after 10sek I lose console and then see again that it is booting.