[sudo-access] [sudo-discuss] can't reach door computer

robb sf99er at gmail.com
Mon Apr 5 21:38:36 PDT 2021


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 at 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 at 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 at 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 at 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 at 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 at lists.omnicommons.org
> >>>>>>> https://omnicommons.org/lists/listinfo/discuss
> >>>>>>>
> >>>>>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sudoroom.org/pipermail/access/attachments/20210405/fac3e232/attachment.html>


More information about the access mailing list