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

Tue Apr 6 01:57:45 PDT 2021

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 at 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 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/20210406/65ae5556/attachment-0001.html>