<div dir="ltr">fwiw, the building lost all mains power a day or two ago which may have caused it to reboot w/o eth. regardless, Jake's solution seems like the easiest solution<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 14, 2021 at 11:45 PM Jake <<a href="mailto:jake@spaz.org">jake@spaz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So I looked at the bash script Robb found, and it turns out it's specific to an<br>
issue of the Beaglebone booting up without ethernet working in the first place.<br>
<br>
It does not refer to ethernet stopping working while running!  So that implies<br>
that either our beaglebone is already rebooting but the ethernet doesn't come up<br>
(in which case this script would be wise) OR we're experiencing something else<br>
entirely, and that script wouldn't help us.<br>
<br>
I just checked and saw we're running / off of the built-in eMMC chip (4gb) and<br>
I uncommented the line of /etc/fstab that causes the (8gb) microSD card to be<br>
mounted automatically to /mnt/sd_card/  (after fixing the parameters)<br>
<br>
So we can do logging to /mnt/sd_card/ and use it for backup purposes and<br>
logging, because it's a removable microSD card and we don't have to worry about<br>
ruining it.  And we should log there, so that if the ethernet port goes down we<br>
will have a record of why that happened - assuming someone knows how to<br>
configure it so that cached disk writes are flushed to the disk every few<br>
minutes so that when we have to power cycle it, the logs are actually written<br>
to disk by then.<br>
<br>
-jake<br>
<br>
On Sun, 14 Mar 2021, Yardena Cohen wrote:<br>
<br>
> I'd prefer a solution that doesn't reboot. We lose the swipe log that<br>
> way and I have to tell new people to go back and apply again for their<br>
> cards<br>
><br>
> On Sun, Mar 14, 2021 at 8:22 PM robb <<a href="mailto:sf99er@gmail.com" target="_blank">sf99er@gmail.com</a>> wrote:<br>
>><br>
>> looks like a bash script to ping & reboot when necessary may fix it <a href="https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/" rel="noreferrer" target="_blank">https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/</a><br>
>><br>
>> On Sun, Mar 14, 2021 at 7:36 PM Jake <<a href="mailto:jake@spaz.org" target="_blank">jake@spaz.org</a>> wrote:<br>
>>><br>
>>> [ removing omni-discuss and adding access control list in addition to two other<br>
>>> "admin" lists i didn't know about ]<br>
>>><br>
>>> this is something that has happened before.  Something about the beaglebone<br>
>>> periodically randomly disables the ethernet port until it gets restarted.  We<br>
>>> have never logged into the beaglebone (through its TTL serial port console for<br>
>>> example) in order to diagnose why, we just power cycle it and it comes back up.<br>
>>><br>
>>> would be interesting to save logs to a microSD card (we keep the built-in eMMC<br>
>>> in read-only mode most of the time to prevent wear) so that we could get a clue<br>
>>> as to what's happeneing.  Or perhaps make a process to watch for the ethernet<br>
>>> port being powered down and restart it if that happens for whatever reason.<br>
>>><br>
>>> -jake<br>
>>><br>
>>> On Sun, 14 Mar 2021, robb wrote:<br>
>>><br>
>>>> the beaglebone (BB) & switch to BB were sending (green lights on eth ports)<br>
>>>> but the BB wasn't receiving (orange light...) so i rebooted the BB & it's<br>
>>>> pinging now<br>
>>>><br>
>>>> On Sun, Mar 14, 2021 at 6:51 PM Yardena Cohen <<a href="mailto:yardenack@gmail.com" target="_blank">yardenack@gmail.com</a>> wrote:<br>
>>>><br>
>>>>> Did something happen to the omni door computer? I can't reach it over<br>
>>>>> the network, even from within the building. It appears to be working,<br>
>>>>> letting people in. I tried looking at the box, but couldn't make sense<br>
>>>>> of the mess of cables. Maybe an ethernet got disconnected somewhere?<br>
>>>>><br>
>>>>> The rest of the network is fine. Other devices on that subnet and that<br>
>>>>> interface are reachable, but:<br>
>>>>><br>
>>>>> $ ip neigh | grep 100.64.64.11<br>
>>>>> 100.64.64.11 dev enp3s2  FAILED<br>
>>>>> _______________________________________________<br>
>>>>> discuss mailing list<br>
>>>>> <a href="mailto:discuss@lists.omnicommons.org" target="_blank">discuss@lists.omnicommons.org</a><br>
>>>>> <a href="https://omnicommons.org/lists/listinfo/discuss" rel="noreferrer" target="_blank">https://omnicommons.org/lists/listinfo/discuss</a><br>
>>>>><br>
>>>><br>
><br>
</blockquote></div>