rcn-ee has quit [Read error: Connection reset by peer]
rcn-ee has joined #beagle
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 265 seconds]
johanhenselmans_ is now known as johanhenselmans
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 272 seconds]
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #beagle
starblue has joined #beagle
starblue3 has quit [Ping timeout: 246 seconds]
mattb0ne has quit [Ping timeout: 272 seconds]
dr_bot has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
mattb0ne has joined #beagle
llim has joined #beagle
<llim>
Is this a good place to ask a beginner question?
<zmatt>
I doubt there's a better place
<llim>
Ok, thanks I just got a bbb wireless and am having issues getting it to stay connected to the laptop over usb out of box
<zmatt>
like, does it disappear as usb device entirely? does the beaglebone also reboot?
<llim>
Yes, on both windows and ubuntu 20, I see the same thing. On windows, I get the failed to recognize usb device message
<zmatt>
do you have a kernel log of what happens on ubuntu?
<llim>
Funny thing is that Windows does recognize it for a bit, for about 5 minutes
<llim>
How do I go about getting the kernel log?
<zmatt>
"journalctl -k" gives your entire kernel log since boot, you can add more options like --since=-5min to get only the last 5 minutes, or you can add the "-f" option to monitor the log in real time (use control-C to abort)
<zmatt>
what about the leds on the beaglebone? a kernel panic would explain a disappearing device, but it would also cause all led activity to stop
<zmatt>
(apart from the ethernet leds, those are hardware-controlled by the ethernet phy)
<llim>
Ok, thank you for all the leads, dumb question, but I'm assuming the kernel log is for ubuntu, not the bb?
<zmatt>
yeah
<llim>
For the leds I'm not seeing the expected heartbeat response on USR0
<llim>
Sometimes I end up with USR0 and USR3 leds just being constantly lit
<llim>
Sometimes all the LEDs shut down
<zmatt>
okay so that's pretty convincingly a kernel panic... so never mind about your ubuntu kernel logs
<zmatt>
is the beaglebone running the latest firmware image?
<llim>
That's nice as I'm currently booted on Windows
<zmatt>
if not, reflashing to the latest IoT image is probably a good first step
<llim>
I've followed the instructions on the getting started page and have installed this on my microSD card: AM3358 Debian 10.3 2020-04-06 4GB SD IoT
<llim>
Then I followed the instructions to boot from microSD by holding on the boot button before applying power
<llim>
But I currently don't know a way to tell if I'm actually booting from micro-sd
<zmatt>
yeah I wish the getting-started just told people to download the flasher
<llim>
So you recommend the flasher version next?
<zmatt>
like, you can convert a non-flasher into a flasher but that might be more effort than downloading the flasher image
mattb0ne has quit [Ping timeout: 268 seconds]
<llim>
For sure, I didn't go with the flasher as I understand that's for flashing to on-board eMMC
<zmatt>
oh lol I only just now I realized I mentioned ethernet leds earlier completely forgetting that you have a bbb-wireless which has no ethernet
<zmatt>
also, if you log into the beaglebone and type "findmnt /" you can see if you've booted from SD card or eMMC
<zmatt>
the SOURCE for / will be mmcblk0p1 for SD card versus mmcblk1p1 for eMMC
<llim>
Thanks so much, I'm really stumped at the moment and I just am getting started
<llim>
To log in, would you recommend me logging in through USB-serial? Given that I keep getting disconnected
<llim>
This happens both on Windows and ubuntu, after which I lose all connection to the bb
<llim>
I'll also try reflashing with the flasher image to see if that works
<zmatt>
and yes the flasher is for flashing to the on-board eMMC, which is highly recommended. in fact, having an old system on eMMC can cause problems when booting a new system from SD card (and vice versa), so I very strongly recommend either reflashing eMMC or if you really intend to keep booting from SD card (e.g. some people want the extra space, even though it's slower) I recommend wiping eMMC
<zmatt>
since the beaglebone is crashing it doesn't matter how you log in
<zmatt>
maybe first check if you've booted successfully from SD card
<zmatt>
by powering on with the S2 button held down as you said (you can let go of the button once any leds turn on)
<zmatt>
since, if you've booted from SD card and it still crashes, then reflashing is not going to help either
<zmatt>
(though in that case I'm kinda stumped what could be causing this)
<zmatt>
did you perform any configuration on the system, e.g. connect to a wifi network?
<llim>
ok another dumb question, but would you know how to log in through windows? putty? I'm booted on Windows
<llim>
no configs whatsoever
<llim>
though I did notice that the bb did cause my time on the laptop to go haywire
<zmatt>
it what?
<llim>
ok maybe that's just a coincidence
<zmatt>
there are various ssh clients for windows... Windows 10 also has a built-in ssh client (you can install under "Manage optional features" in Apps & features)
<llim>
ok so it's ssh, thanks. I have not set that up yet. Another dumb question, as it's getting late for me and I'll like to get all the help you are willing to give while you are online now, does this ssh login work regardless of kernel panic?
<zmatt>
another thing you could try is a different SD card... consumer-grade SD cards aren't exactly the most reliable of storage devices, and problems with the root filesystem storage would definitely also result in a kernel panic
<zmatt>
no, you'd need to do it before the kernel panic
<llim>
Dang, it's pretty tight then, I think it's actually less than 5 mins..but I think it's possible
<zmatt>
the main thing is to confirm (using "findmnt /") that you've actually booted from sd card
<zmatt>
and ssh access is possible fairly early on, you don't need to wait until boot has completed
<llim>
I'll try it now, if you could please wait!
<zmatt>
i'll be here.... I'm also doing other stuff so I may not always respond right away
<llim>
Thanks anyway really, really appreciate this
<llim>
I entered 192.168.7.2 but don't see anything printing on the terminal
<llim>
Can't seem to type anything in there and got a network timeout error
<zmatt>
that'll happen if you're either too early during boot, or it already crashed... if the timing window is problematically tight then it may not be worthwhile to try this for too long, when I suggested it I was under the impression you had already been able to log in
<llim>
hmm ok, it's still connected over usb, but completely freezed over, clicking anything in there takes forever to load
<zmatt>
you mean the mass storage device that shows up? that sounds really strange, I'd expect it to either work normally or not at all
<zmatt>
unless the SD card is having serious problems
<zmatt>
.. which is honestly the prime suspect right now
<llim>
The whole directory of bb that shows up once it's mounted, where you can access Drivers, the start.html links etc
<llim>
That's frozen
<zmatt>
yeah that's just a small disk image that's on the beaglebone
<zmatt>
but your choice of words was "takes forever to load" .. that would imply that it was still loading, just very slowly
<llim>
Oh, sorry about that, it's hung would be a better description
<zmatt>
anyway, I'm not sure what to try except for a different SD card... it's the only idea I have right now. I've not heard of anyone else having a problem similar to yours
<llim>
Ok, that's really unfortunate, I've been googling around and yes didn't see others having the same issue as mine
<llim>
Ok, so try a different sd card, wiping eMMC and using the flasher image
<llim>
I don't think it's possible I've bricked the board? (esd) or something, but it's just out of the box
<zmatt>
the wiping the eMMC thing isn't really relevant here, it was regarding if you really want to keep booting from SD card (rather than reflashing eMMC) without weird problems (by which I don't mean system crashes)
<zmatt>
I mean, anything is possible with ESD, but it doesn't sound very likely
<llim>
Ok, I'll try another sd card, thanks again for all your help!
rob_w has joined #beagle
markand has joined #beagle
<llim>
I've tried another sd card and think I've flashed it to eMMC, although I didn't change the settings in uEnv, cause I saw the LEDs toggling in succession, then turn off after a couple of mins. I needed to cycle power to the board, but I'm still seeing the same issue as I saw previously
<markand>
hey there
<markand>
at work we're using a opticon reader plugged into serial port 4 (ttyO4) so we've enabled it in uEnv.txt with those settings: https://paste.centos.org/view/0f19a73b
<llim>
USR2 led stays on without flashing, I assume it hangs
<markand>
however, with that, the screen is no longer visible (no output at all)
<zmatt>
markand: first off, cape_enable=bone_capemgr.enable_partno is obsolete and no longer does anything
Guest3778 has joined #beagle
<zmatt>
and I'm pretty sure at least one of the uarts conflicts with video output
<zmatt>
yeah, uart
Guest3778 has quit [Client Quit]
<zmatt>
uart5
<markand>
zmatt, it still enable it though because without that the barcode reader does not output anything to ttyO4
<zmatt>
then you're either running a really ancient system, or you're booting from SD card and have an ancient bootloader installed on eMMC
<markand>
it's the last official iot image
<zmatt>
flashed to eMMC ?
<markand>
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux
<markand>
yep
<zmatt>
then cape_enable does nothing
<markand>
there is no SD card in it right now
<zmatt>
the uboot_overlay_addr* lines are what's configuring the pins for you, though you don't need those either, you can alternatively configure the pins at runtime using the config-pin utility
<zmatt>
the cape_enable line is for 3.8 kernels
<markand>
okay
<zmatt>
or bootloaders that predate u-boot overlays
<markand>
so uboot_overlay_addr0=/lib/firmware/BB-UART4-00A0.dtbo should be sufficent to enable it?
<zmatt>
yeah, though preferably use uboot_overlay_addr4..7 for custom overlays
<markand>
oh okay, let me try
<zmatt>
0..3 are intended for overriding the automatic overlay selection for actual physical capes
LetoThe2nd has joined #beagle
<zmatt>
though apart from that, any of the variables work equivalently
<markand>
I'm just trying without default uEnv.txt to see if the screen lights up again before :P
<zmatt>
or like I said, you can just not enable any of these overlays at all and use config-pin instead
<markand>
I mean *with* default uEnv
<markand>
ah yes the screen comes back
<zmatt>
that also has the benefit that config-pin won't let you reconfigure pins that are in use for things like video (when enabled)
<markand>
I see
<zmatt>
configuring the uart4 pins with config-pin would be something like "config-pin P9.11 uart && config-pin P9.13 uart"
<zmatt>
or maybe it needs to be _ instead of . (e.g. P9_11), I don't remember if config-pin is fussy about that
<zmatt>
it might be
llim has quit [Quit: Client closed]
<markand>
works <3
<markand>
saved my day again #beagle!
samael has joined #beagle
rob_w has quit [Remote host closed the connection]
argonautx has joined #beagle
djinni has quit [Quit: Leaving]
djinni has joined #beagle
florian has joined #beagle
Shadyman has quit [Quit: Leaving.]
rob_w has joined #beagle
samael has quit [Ping timeout: 268 seconds]
samael has joined #beagle
bgm has joined #beagle
otisolsen70 has joined #beagle
rob_w has quit [Remote host closed the connection]
set_ has quit [Ping timeout: 258 seconds]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
bgm has quit [Quit: Client closed]
samael has quit [Ping timeout: 255 seconds]
samael has joined #beagle
bgm has joined #beagle
<bgm>
installed minicom on beaglebone green - but getting error - minicom: cannot open /dev/modem: No such file or directory -
<zmatt>
bgm: that sounds like you've installed it successfully but you're not using it correctly?
<bgm>
got it zmatt .. thank you for quick response.. Got it configured using "-s" option, by default it is referring to /dev/modem
<zmatt>
from what I remember minicom is also an old and awkward program to use
<bgm>
agreed... do you have any suggestions to test neo6m module.. I have connected it to UART4 and trying to test it..
<zmatt>
so this is some gps module? I'm pretty sure there are plenty of tools for gps
rcn-ee_ has joined #beagle
<bgm>
yes.. it is GPS module.. there are tools in python.. but I need to do it in C language :-(
crazymax- has joined #beagle
<zmatt>
why not use something like gpsd ? it has client libraries for C and various other languages
<bgm>
sure..Thank you for quick help.. I was trying using /dev/tty03 - using open() and then doing R/W operations..
<bgm>
will try with gpsd.
<zmatt>
(of course you first need to install the gpsd and libgps-dev packages and configure gpsd to use /dev/ttyS4 )
<tbr>
no need to reinvent that wheel
<bgm>
got.. it.. Thank you.
<zmatt>
you mean ttyO4 ? although the /dev/ttyO* devices are officially replaced by /dev/ttyS* (but /dev/ttyO* still work too since there are backwards compatibility symlinks to /dev/ttyS*)
pi____ has joined #beagle
xet7 has quit [*.net *.split]
rcn-ee has quit [*.net *.split]
noahm has quit [*.net *.split]
Daulity has quit [*.net *.split]
crazymax has quit [*.net *.split]
<bgm>
yes..have updated uEnv and was using /dev/ttyO..
<zmatt>
either /dev/ttyO4 or /dev/ttyS4 will work (though the latter is the proper one to use)
samael has quit [Ping timeout: 258 seconds]
samael has joined #beagle
xet7 has joined #beagle
<bgm>
ok..
<bgm>
any idea on power supply requirement.. I have connected neo6m to 5V of Beaglebone and Beaglebone is connected to Laptop via USB
<bgm>
from past 2 hours, the GPS module neo6m is not showing any sign of waking up..
<zmatt>
the neo6m actually runs on 3.3V, but I'm guessing you're using some kind of breakout module of the neon6m with an on-board LDO ?
<bgm>
my bad.. connected to 3.3V now- neo6m module
<zmatt>
? what exactly are you using?
<bgm>
neo6m brakout module connected to 3.3v
<zmatt>
if you're using a breakout module that has an integrated 3.3V LDO then supplying it with 3.3V is probably a bad idea and may not work correctly (while if you're not using a breakout that has an integrated 3.3V LDO then you've already destroyed it)
<zmatt>
be more specific, do you have a link to what you're using?
<zmatt>
well gpsd failed to install because the gpsd.socket unit could not start because its addresses are already in use, and your "ss" output is showing a process called "gpsd" is the one that's keeping them in use, so it very much does seem like a gpsd is already running on your system (and not the one you tried to install)
<bgm>
I had kill the process where gpsd is running.. but still : systemclt status gpsd.socket shows - https://pastebin.com/U6fCLsb6
<bgm>
now "ss" output is not showing anything.
samael has quit [Ping timeout: 268 seconds]
<zmatt>
instead of killing it it would have been much more useful to identify where it's coming from
<zmatt>
since otherwise you'll have the problem again after reboot
<bgm>
ok.. how to identify its source?
<zmatt>
you could probably have identified its origin using "systemd-cgls" .. if you hadn't killed it
samael has joined #beagle
<zmatt>
(that would at least show what from what unit it is being started)
<zmatt>
maybe reboot and see if it's back
<bgm>
ok
<zmatt>
once it's been identified and gotten rid of in a permanent way you should be able to retry the install with "apt-get -f install"
<zmatt>
btw, "gpsd-clients" includes graphical clients which are kinda useless on a beaglebone, which normally doesn't have a gui. it seems like commandline clients (cgps, gpsmon) are in the package "gpsd-tools"
noahm_ has quit [Changing host]
noahm_ has joined #beagle
noahm_ is now known as noahm
<zmatt>
ah never mind
<zmatt>
that's not in debian buster
<zmatt>
it seems buster still has the commandline clients and graphical clients in a single package... how annoying
<bgm>
ohh..ok..
<bgm>
is there any way to assign static IP to beaglebone.. everytime i restart, it gets new IP, and i cant SSH to old IP
bgm has quit [Quit: Ping timeout (120 seconds)]
bgm has joined #beagle
<zmatt>
why not ssh to it by hostname?
<bgm>
ohh, you mean "uname -a" output.
<zmatt>
you can of course use connmanctl to configure a manual ip, though I personally prefer to do so in the router (so that dhcp always hands it the same IP) in the very rare case I have a need for a static ip
<zmatt>
generally either "ssh debian@beaglebone" and/or "ssh debian@beaglebone.local" will work
<bgm>
ok.. will try out
<zmatt>
(or if you changed the hostname, whatever you changed the hostname to)
<zmatt>
it's also kinda weird that it's getting a different IP every reboot, every router I've ever used tends to hand devices the same IP every time
<bgm>
great.. i am in - "ssh debian@beaglebone"
<zmatt>
isn't that much nicer than using IP addresses? :)
<bgm>
yes..that's big relief..thanks a ton
<zmatt>
if you use multiple beaglebones, be sure to give them individual hostnames with "sudo hostnamectl set-hostname HOSTNAME" (replace HOSTNAME by the desired name for the beaglebone)
<bgm>
sure
<zmatt>
anyway, if you've rebooted, is the gpsd back? if so, check the output of systemd-cgls to see what unit it belongs to (its immediate parent in the tree)
<bgm>
yes.. rebooted and gpsd is back.
<zmatt>
or another way to find the unit is: systemctl status $(pidof gpsd)
<zmatt>
oh lol, the gpsd you (mostly) installed probably won the race during startup
<zmatt>
see if the installation will finish with "sudo apt-get -f install"
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<zmatt>
(btw I see you're habitally logged in as root instead of using sudo on the rare command that needs it... probably not the best habit)
<bgm>
ok.. but few commands are not working in debian user..
<zmatt>
so the other gpsd is probably still trying to start during boot, but now *it* is failing rather than the gpsd you installed with apt.
<zmatt>
yes sudo is occasionally needed, e.g. for apt-get
<zmatt>
or editing system config files
<zmatt>
but not much else
<bgm>
ok.
<zmatt>
the question is still what is this other gpsd and where did it come from.... it hasn't appeared on your system by magic, someone (either you or someone else who has worked on your beaglebone) installed it
<bgm>
i tried it using apt-get multiple times.. even i did purge once and installed again..
<zmatt>
right, but I'm pretty sure the one that was running has nothing to do with what you're doing with apt
<zmatt>
since it presumably failed every time for the same reason?
<bgm>
now, gpsd is working.. coming back to first question.. of neo6m module.. it is sill not responding :-(
<zmatt>
did "apt-get -f install" succeed?
<bgm>
yes
<bgm>
gpsd is already the newest version.
<zmatt>
if your module is powered and the led isn't blinking then it hasn't managed to acquire a fix
<zmatt>
afaik no software action is required for this
<bgm>
led is not blinking yet :-(
<bgm>
it was working module, I had tested same module with Pi board.
<zmatt>
also, to use gpsd with it you need to configure /dev/ttyS4 into the DEVICES variable in /etc/default/gpsd
<bgm>
i had configured using "sudo gpsd /dev/ttyS3 -F /var/run/gpsd.sock"
florian has quit [Quit: Ex-Chat]
<zmatt>
don't do that
<zmatt>
also why are you using the wrong uart?
<bgm>
how to configure using /etc/default/gpsd
<zmatt>
and this explains your earlier problems
<zmatt>
the rogue gpsd process was that one
<bgm>
cat /dev/ttyS4 is not showing anyting..
<zmatt>
you can't just cat a tty device like that, cat doesn't configure the serial port settings for you
<bgm>
ok.. how to configure using /etc/default/gpsd
<zmatt>
it's a text file, use your favorite text editor
<zmatt>
(with "sudo" prefixed, or otherwise as root)
mattb0ne has joined #beagle
<bgm>
i am following up steps from my Pi board :-( cat: /dev/ttyS4: Input/output error
<bgm>
ok.
<zmatt>
I'm not sure what you're saying
<zmatt>
serial port numbers on a Pi are no doubt different
<bgm>
i mean configure like "sudo gpsd /dev/ttyS3 -F /var/run/gpsd.sock"
<zmatt>
that's not a way to "configure" it, you're manually starting gpsd
<zmatt>
instead of letting it be started normally as a system service
<zmatt>
and as a result, starting it normally as a system service was failing
<bgm>
i am into /etc/default/gpsd - what shall i update here?
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
<zmatt>
I told you 5 minutes ago, do I really need to repeat it?
lucascastro has quit [Remote host closed the connection]
<zmatt>
(the amount of hand-holding you seem to require is rapidly depleting my patience)
<bgm>
(sorry about that), i have missed it.. I am still getting hold of beaglebone.
<zmatt>
for the most part this isn't beaglebone-specific stuff though
<zmatt>
the only beaglebone-specific part is which exact tty device to use, and how to ensure its pins are setup right, the rest is all generic debian stuff
<zmatt>
(show-pins doesn't actually require "sudo" on current images I noticed (except for the installation), I still need to update the README to reflect that)
Guest11 has joined #beagle
<bgm>
good.. have downloaded show-pins.. P9.11 28 fast rx up 7 gpio 0.30
<bgm>
P9.13 29 fast rx up
<zmatt>
pins are not configured. can you share the contents of your /boot/uEnv.txt ?
<zmatt>
worse yet, pins are neither configured by an overlay nor is cape-universal functioning
<zmatt>
ah wait I'm confusing you with the person before you who was also doing stuff with an uart
<zmatt>
this is like... a really really ancient system
<zmatt>
is there a particular reason you're using a system that's *this* ancient andobsolete?
<bgm>
no perticular reson zmatt, its just i am unable to update to latest system :-(
<zmatt>
the stuff at the bottom of your uEnv.txt ... did you add that yourself? because those comments look like they're coming from a modern system
<bgm>
yes.. I have updated uEnv.txt for UART4
<bgm>
I had referred few online tutorial
<zmatt>
if this stuff (especially "enable_uboot_overlays=1
<zmatt>
") wasn't already in your /boot/uEnv.txt to begin with, almost certainly your bootloader doesn't support it
behanw has joined #beagle
<bgm>
ok.. it wasn't already in that file, i have added it..
<zmatt>
that won't work
<zmatt>
your system predates u-boot overlays
<zmatt>
the old way of configuring overlays (via cape_enable) presumably works, though I don't really remember what goes there, it's been many many years
<zmatt>
probably something like cape_enable=bone_capemgr.enable_partno=BB-UART4-00A0
<zmatt>
why is upgrading not an option?
<bgm>
will try to upgrade again.. It did not worked last time..
<zmatt>
like, make a backup of your custom stuff (it's good to have a backup of that anyway), reflash, install the packages you need, put custom stuff on it again
<zmatt>
btw, are you using a beaglebone black wireless or beaglebone green wireless?
<zmatt>
easiest way to reflash to the latest system is by downloading the latest flasher image ("AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher") from the "Flasher Debian images" section of https://beagleboard.org/latest-images
<zmatt>
write it to sd card using Etcher (etcher.io)
<zmatt>
if you boot the beaglebone from that, it will automatially proceed to erase and reflash the eMMC
<zmatt>
*automatically
<bgm>
its beaglebone green wireless
<zmatt>
since your current system is very old, to get it to boot from the sd card it *may* be required to power on with the S2 button held down (the one closest to the sd card) during power-on, you can let go of the button once any leds turn on
<bgm>
sure.. I have noted down the steps.. will try it tomorrow..
<bgm>
Thanks a lot.
<zmatt>
ah, that sucks. my show-pins utility has a separate version for the green-wireless, which marks pins that are occupied for wifi on the green-wireless
<zmatt>
you'll want to use that version instead of the default one, it'll help you stay clear of the many expansion header pins you can't use on the beaglebone green wireless (as a result of bad design decisions)
<zmatt>
(specifically the ones marked "wifi", "bluetooth", or "wilink8")
<bgm>
P9.11 28 fast rx up 7 gpio 0.30
<bgm>
P9.13 29 fast rx up 7 gpio 0.31
<zmatt>
no need to keep copy-pasting that, if it's saying "gpio" instead of "uart" then the pins are not configured right yet
<bgm>
got it.. thank you..
<bgm>
will update to latest image and try again.
<zmatt>
yeah that's a good idea
samael has quit [Ping timeout: 255 seconds]
bgm has quit [Quit: Client closed]
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 252 seconds]
vagrantc has quit [Quit: leaving]
lucascastro has joined #beagle
akaWolf has quit [Ping timeout: 265 seconds]
akaWolf has joined #beagle
lucas_ has joined #beagle
lucas_ has quit [Client Quit]
lucas_ has joined #beagle
lucas_ has quit [Read error: Connection reset by peer]
lucascastro has quit [Ping timeout: 268 seconds]
lucas_ has joined #beagle
lucas__ has joined #beagle
lucas_ has quit [Read error: Connection reset by peer]
pi____ is now known as Daulity
lucas__ has quit [Client Quit]
otisolsen70_ has quit [Read error: Connection reset by peer]
otisolsen70_ has joined #beagle
CrazyEddy has quit [Ping timeout: 255 seconds]
lucascastro has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
lucas_ has joined #beagle
Guest11 has quit [Quit: Client closed]
mattb0ne has quit [Ping timeout: 268 seconds]
CrazyEddy has joined #beagle
mattb0ne has joined #beagle
LetoThe2nd has joined #beagle
lucas__ has joined #beagle
otisolsen70_ has quit [Quit: Leaving]
lucas_ has quit [Ping timeout: 265 seconds]
lucas_ has joined #beagle
lucas__ has quit [Ping timeout: 265 seconds]
lucas_ has quit [Remote host closed the connection]
lucas_ has joined #beagle
lucas_ has quit [Remote host closed the connection]
ft has quit [Remote host closed the connection]
ft has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
buzzmarshall has joined #beagle
set_ has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]