14 Mar
2021
14 Mar
'21
6:51 p.m.
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
14 Mar
14 Mar
7:13 p.m.
New subject: [omni-discuss] can't reach door computer
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(a)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(a)lists.omnicommons.org
https://omnicommons.org/lists/listinfo/discuss
7:36 p.m.
New subject: [sudo-discuss] can't reach door computer
[ 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(a)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(a)lists.omnicommons.org
https://omnicommons.org/lists/listinfo/discuss
8:22 p.m.
New subject: [sudo-discuss] can't reach door computer
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-beagl…
On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
https://omnicommons.org/lists/listinfo/discuss
10:41 p.m.
New subject: [sudo-discuss] can't reach door computer
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(a)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-beagl…
On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
> >> https://omnicommons.org/lists/listinfo/discuss
> >>
> >
11:32 p.m.
New subject: [sudo-discuss] can't reach door computer
as it appears to be a hardware issue with beaglebone blacks, prolly need a
rpi if you want to avoid reboots
On Sun, Mar 14, 2021 at 10:41 PM Yardena Cohen <yardenack(a)gmail.com> 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(a)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-beagl…
On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
> >> https://omnicommons.org/lists/listinfo/discuss
> >>
> >
11:45 p.m.
New subject: [sudo-discuss] can't reach door computer
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(a)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-beagl…
On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
>>> https://omnicommons.org/lists/listinfo/discuss
>>>
>>
11:59 p.m.
New subject: [sudo-discuss] can't reach door computer
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(a)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(a)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-beagl…
>
> On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
>>> https://omnicommons.org/lists/listinfo/discuss
>>>
>>
15 Mar
15 Mar
12:36 p.m.
New subject: [sudo-discuss] can't reach door computer
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(a)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(a)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-beagl…
>
> On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
>>> https://omnicommons.org/lists/listinfo/discuss
>>>
>>
5 Apr
5 Apr
9:38 p.m.
New subject: [sudo-discuss] can't reach door computer
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(a)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(a)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(a)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-beagl…
>>>
>>> On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
>>>> https://omnicommons.org/lists/listinfo/discuss
>>>>
>>>
9:50 p.m.
New subject: [sudo-discuss] can't reach door computer
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(a)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(a)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(a)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-beagl…
>>>
>>> On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
>>>>> https://omnicommons.org/lists/listinfo/discuss
>>>>>
>>>>
>
6 Apr
6 Apr
1:57 a.m.
New subject: [sudo-discuss] can't reach door computer
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(a)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(a)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(a)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(a)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-beagl…
>>>>>
>>>>> On Sun, Mar 14, 2021 at 7:36 PM Jake <jake(a)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(a)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(a)lists.omnicommons.org
>>>>>> https://omnicommons.org/lists/listinfo/discuss
>>>>>>
>>>>>
>>
>
1125
days inactive
1147
days old
11 comments
3 participants
participants (3)
-
Jake -
robb -
Yardena Cohen