The router takes much longer to boot up. Even the bios takes a few minutes waiting for shit to time out. It's still that old dell desktop because the proper hardware died last year and nobody has replaced it.

On Mon, Apr 5, 2021, 9:50 PM Jake <jake@spaz.org> wrote:
yes the front door computer is accessible and says it's been up for 28 minutes

which is strange because the router that i connected to it through has only
been up for 19 minutes.  anyway it's working.

your email went out to four lists in addition to a couple of people directly.
I feel weird about messages going out to so many lists.

-jake


On Mon, 5 Apr 2021, robb wrote:

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