Found the answer in another thread started at the end of January 2019 from @Francisco-Suarez
Replace the current obsolete root CA file.
@Lazar-Demin I did a power cycle to the Omega Pro. Now I see:
root@Omega-B668:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 7.8M 7.8M 0 100% /rom
tmpfs 61.0M 216.0K 60.8M 0% /tmp
/dev/mmcblk0p1 7.1G 437.0M 6.3G 6% /overlay
overlayfs:/overlay 7.1G 437.0M 6.3G 6% /
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mmcblk0p1 7.1G 437.0M 6.3G 6% /mnt/mmcblk0p1
/dev/mtdblock6 6.6M 6.1M 504.0K 93% /mnt/mtdblock6
So this seems like what I should have been seeing, correct?
To answer my own question, the button on the Pro Dock does work as a reset button.
I then followed the instructions here:
to use a serial connection to the malfunctioning Omega Pro to flash new firmware from a USB drive.
That worked to resurrect the Pro back to a workable state.
Well, I tried to use the button as a reset button and a reboot did seem to occur.
But I do not get to a stable boot state. The yellow LED flashes for a bit, the blue LED comes on briefly and then the multi-color LED flashes a lot and then the reboot seems to happen all over again.
Seems like this board may be bricked.
Any hints for recovery?
There is a programmable button on the Omega2 Pro PCB.
Does this work as a reset button as well? There is Onion documentation for other expansion boards that identify a button in a similar location.
I have two Pro's that will no longer boot up successfully and am looking for a recovery mechanism.
Thanks for any suggestions.
I discovered this resource:
This seems to have been provided by the onion team but has not been made available via npm.
Has anyone used these: packaging up the html and js files so that they can be installed into node-RED? Apparently you need to create a package.json file for each node and I am a little unclear on what must go in there.
I may try this myself but perhaps someone has done something like this already.
A bit more community searching led me to the command line:
echo 1 >/sys/class/gpio/unexport
that will free a GPIO pin apparently -- in this case pin 1.
Then the python program that was failing works again.
Can we do something like that from python itself?
We are having trouble with python and GPIO status access. A little test program works after the omega Pro boots but after a couple of minutes the same python program fails with a IOError: [Errno 16] Resource busy error.
We did see some community posts from around 2017 referring to this same condition and it seems no final resolution was offered. We are using Omega2 Pros with 0.3.2 b222 firmware.
We are running node-RED on the Pros, but even if I kill the node-Red process, the resource busy error keeps recurring. A reboot will make the error disappear but only for a few minutes.
Is there a simple bit of python logic that will free the GPIO?
We are currently using GPIO pins 1 and 2 for our tests. Eventually we want to invoke python scripts from node-RED flows that deal with sensing and setting GPIO pin conditions.
@James-Solderitsch John Walicki has added some notes to his node-RED github page about installing node-RED on an Omega2+. He also advocates for the need to have a swap partition AND an extended file system to have room to install and run node-RED on an Omega2+.
@James-Solderitsch After I followed the instructions at the link I posted above to provide both a swap partition AND a file-space partition, I was able to complete the install of the IBM Watson-IoT nodes as documented on John Walicki's github page.
So it looks like have a swap partition is mandatory for the Omega2+. Perhaps not needed for the Omega Pro..
@James-Solderitsch I did find this:
Seems to provide for both a partition for swap AND a partition for extending /overlay.
Will try this later today and see how far I get.
Looks like your connection to Community was lost, please wait while we try to reconnect.