I've recently acquired a clusterboard with some compute modules, along with a baseboard. I've verified the modules are operational via the baseboard, and boot via the clusterboard's serial terminal. I'm using the latest stable version of Armbian. The board is being powered via an external supply coming into the connector beside the coaxial power jack, to which I've soldered screw terminals. I've also tried the "official?" brick supplied from Ameridroid.
I'm having trouble getting the modules to talk to the network. I've assigned the modules static IP addresses within Armbian, and it appears to be correct when I check it. The yellow LEDs are blinking as if there is network traffic, and the green are all blinking in unison save the slot(s) where modules are installed. If I tell a particular module to halt, the green LED stops blinking.
Is there something I'm missing? I've read about some changes to network timing in other threads, but I'm not sure where to go with this.
(03-14-2019, 05:50 PM)BryanS Wrote: I've recently acquired a clusterboard with some compute modules, along with a baseboard. I've verified the modules are operational via the baseboard, and boot via the clusterboard's serial terminal. I'm using the latest stable version of Armbian. The board is being powered via an external supply coming into the connector beside the coaxial power jack, to which I've soldered screw terminals. I've also tried the "official?" brick supplied from Ameridroid.
I'm having trouble getting the modules to talk to the network. I've assigned the modules static IP addresses within Armbian, and it appears to be correct when I check it. The yellow LEDs are blinking as if there is network traffic, and the green are all blinking in unison save the slot(s) where modules are installed. If I tell a particular module to halt, the green LED stops blinking.
Is there something I'm missing? I've read about some changes to network timing in other threads, but I'm not sure where to go with this.
I never had any trouble with timing. It's best to use DHCP to let them pull configuration from the network.
They aren't asking for addresses from the router, so I wonder if there's something wrong with my clusterboard.
(03-15-2019, 05:29 PM)BryanS Wrote: They aren't asking for addresses from the router, so I wonder if there's something wrong with my clusterboard.
They won't pull down DHCP at all?
03-16-2019, 07:04 AM
(This post was last modified: 03-16-2019, 07:05 AM by BryanS.)
(03-15-2019, 11:18 PM)AZClusterboard Wrote: (03-15-2019, 05:29 PM)BryanS Wrote: They aren't asking for addresses from the router, so I wonder if there's something wrong with my clusterboard.
They won't pull down DHCP at all?
They weren't, but they are now. I assumed the most obvious answer here, that of I did something wrong. I went back and re-read your guide carefully, and stopped where you said you HAD to use Xenial. I loaded that on to a test card, and it appeared in the router as a device within a minute.
So, I guess I need to pay attention to the manual. The board currently has 3 modules on it, just doing some generic network tasks for a burn-in. The only thing I have left to do is make sure there's no unnecessary desktops loading with this particular version. I assume there isn't.
Thank you for the replies, sometimes it just takes someone asking you about it to make you go back and look at your process differently.
(03-16-2019, 07:04 AM)BryanS Wrote: (03-15-2019, 11:18 PM)AZClusterboard Wrote: (03-15-2019, 05:29 PM)BryanS Wrote: They aren't asking for addresses from the router, so I wonder if there's something wrong with my clusterboard.
They won't pull down DHCP at all?
They weren't, but they are now. I assumed the most obvious answer here, that of I did something wrong. I went back and re-read your guide carefully, and stopped where you said you HAD to use Xenial. I loaded that on to a test card, and it appeared in the router as a device within a minute.
So, I guess I need to pay attention to the manual. The board currently has 3 modules on it, just doing some generic network tasks for a burn-in. The only thing I have left to do is make sure there's no unnecessary desktops loading with this particular version. I assume there isn't.
Thank you for the replies, sometimes it just takes someone asking you about it to make you go back and look at your process differently.
I'm still waiting on my USB UART and LTS baseboard. I had to way to troubleshoot the problem which is why I used xenial. I have a feeling the newest images might not have all the proper configs to run headless out of the box.
I was able to get the SOPine module to boot (headless) without issue on the baseboard using the latest version of Armbian Stretch, which is why I figured I could just plug it in to the clusterboard and just continue on my way without noticing anything different. At some point this weekend I may search the Armbian forums and post my findings there if no one else has.
I was thinking I should copy the console boot sequences and compare the two for differences at some point, maybe that would reveal why Stretch works on the baseboard and not the clusterboard. I will say that if you do get a baseboard, the coaxial power jack that Pine chose is somewhat fragile with a cable plugged in - that is, the extra leverage provided by the cable can break the jack away from it's mounts easier than you think. I'm powering it via the Euler bus pins right now...
If I have time in the coming week, I will boot a module on both and post my results.
03-17-2019, 08:48 AM
(This post was last modified: 03-17-2019, 08:57 AM by BryanS.
Edit Reason: New information.
)
There appears to be a thread about this issue in the Armbian forums. It talks about some changes that weren't carried through to the newest kernel, that of timing issues with the Realtek devices. I assume that's the same whispers I saw regarding timing elsewhere.
https://forum.armbian.com/topic/9402-eth...ne-module/
I'm out of my league at the moment doing kernel recompiles, but I'll try and provide any information that is needed to get this resolved.
(edit: I tried to post my findings in the Armbian forum, but I've forgotten my password and the email reset appears to be broken...)
03-18-2019, 01:31 PM
(This post was last modified: 03-18-2019, 01:32 PM by PigLover.)
(03-17-2019, 08:48 AM)BryanS Wrote: There appears to be a thread about this issue in the Armbian forums. It talks about some changes that weren't carried through to the newest kernel, that of timing issues with the Realtek devices. I assume that's the same whispers I saw regarding timing elsewhere.
https://forum.armbian.com/topic/9402-eth...ne-module/
I'm out of my league at the moment doing kernel recompiles, but I'll try and provide any information that is needed to get this resolved.
(edit: I tried to post my findings in the Armbian forum, but I've forgotten my password and the email reset appears to be broken...)
That is the exact issue you are fighting against. You can fix it on the newer kernels - one module at a time - by modifying one of the boot files as described in that other thread. But it requires a serial console and is a PITA.
I appreciate all the work that Armbian does, but there really is no excuse for this issue remaining open and untouched by them for this long.
Once you get past that one the next hurdle to get over is the "won't reboot without power cycle, which required power cycling the whole cluster" issue. This one really needs to get fixed if the Clusterboard is ever going to be really useful. At is is mine is back on a storage shelf because its just not worth fighting it.
In fact, if anyone wants a Clusterboard and 8 so-pines at a good discount you could PM me...
|
