russ has joined #beagle
rtwfroody has joined #beagle
<rtwfroody> I just got a Beaglebone Black Wireless, but don't have an SD card. What should I get? It looks like a micro SD card, but I can't find people say what size it should be.
<PhotoJim> rtwfroody: depends on what OS you want to put on it, and what you'll be doing with it. but these days, cards are cheap so I tend to get a little bigger than I need to avoid problems and hassle later. I'd suggest 16 or 32 GB.
<PhotoJim> I have a 32 in mine. 30% full.
<zmatt> you have 10G in use? o.O are you storing large media files or something?
<zmatt> rtwfroody: note that an sd card is not required, the beaglebone black and black-wireless have 4GB of internal eMMC
<zmatt> but yeah it's a microSD card, and how much space you need is completely dependent on what you're doing with it
<PhotoJim> fail2ban tends to use up a fair bit of storage. I'd guess it's the biggest culprit.
<zmatt> uhh, how?
<zmatt> I've never used it but it sounds like something that has no reason to require significant storage
<PhotoJim> I have a public IP address on mine.
<zmatt> rtwfroody: generally I'd recommend using eMMC unless you really need more space for your use-case
<PhotoJim> eMMC will be faster. but it's tight.
<zmatt> depends on what you do on it
<PhotoJim> Fair point.
<PhotoJim> If you were careful, you could probably make it work.
<PhotoJim> I've had to upgrade storage on a few systems (an Alix 2D3, some Raspberry Pis) so I tend to go bigger than needed to delay or prevent that.
<zmatt> the only beaglebone here that's ever been at risk of running out of space is our main development beaglebone, and that's mostly because 3 different devs work on it and tend to accumulate cruft, including countless separate installs of the same NPM module :P
<rtwfroody> . eMMC is on-board storage, right?
<zmatt> yes
<rtwfroody> I was just following instructions to update it, because no storage showed up when I plugged it into my Linux box. But maybe it is programmed and I need to figure out why nothing auto-mounted.
<zmatt> I'd generally recommend booting from eMMC unless you absolutely need more space and are willing to sacrifice performance to get it
<rtwfroody> zmatt: You've convinced me. Thanks.
<zmatt> note that the storage that shows up via usb is just a small read-only disk image containing some documentation and such, it's not of any use for updating or whatever
<PhotoJim> rtwfroody: you can always migrate to SD later. and I presume you could have / on eMMC and use an SD card for /home or additional storage if needed.
ketas has quit [Ping timeout: 258 seconds]
<zmatt> if the system on eMMC is in a broken or unknown state and you don't have stuff on it you want to preserve, I recommend just reflashing it
<zmatt> the easiest way to do that is by grabbing a ready-made flasher image, e.g. "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" in the "Flasher Debian images" section of
<zmatt> write that to microSD card (4GB or larger), it's highly recommended to use Balena Etcher for doing so
<zmatt> if you then boot the beaglebone from that sd card, it should automatically proceed to wipe and reflash eMMC
<zmatt> (you can tell it's reflashing from the leds: the flasher shows a back-and-forth sweep (aka "cylon" or "knight rider" pattern) across all four leds)
<rtwfroody> Thanks, so 4GB is the magic number if I need buy an SD card.
<zmatt> in rare cases (specifically, if the existing bootloader on eMMC is really ancient or weird) it may be necessary to use the S2 button to force it to boot from SD card. this is done by holding the S2 button (the one closest to the SD card slot) while connecting power to the beaglebone, you can let go of the button once the power led turns on
<zmatt> (it doesn't hurt to do so just in case, but usually it's unnecessary)
ketas has joined #beagle
<zmatt> yeah, 4GB is the minimum for flashing the "IoT" image, which has a lot of stuff preinstalled
<PhotoJim> what sort of free space does that image leave?
<zmatt> there are also very lean "console" images for people who prefer to start with a lean and clean system and are comfortable with simply installing whatever packages they want
<zmatt> the IoT image has 1.9G in use
<PhotoJim> that's not bad.
<rtwfroody> My problem was that I was using a "charging" USB cable when I first tried.
<zmatt> whenever you discover such a cable, cut it in half and throw it away
<zmatt> such cables are even bad for charging
<zmatt> (charger detection uses the data lines)
<zmatt> PhotoJim: and the console image uses 400M
<PhotoJim> zmatt: that'd be the better way to do it. then one could keep it as lean as possible.
drewfustini has quit [Ping timeout: 252 seconds]
<zmatt> our production beaglebones use 310M excluding our custom stuff, and maybe 100M of custom stuff or so
drewfustini has joined #beagle
<zmatt> but those are very sparse systems used as appliances
<zmatt> (no development tools)
<PhotoJim> what kernel are you running, 4.19.0? I've run into some interesting issues with the 5.11.12 on my Arch install (that also happens with my Debian Bullseye 5.14.0 on a SheevaPlug) where IPv6 causes weird delays in response, but IPv4 doesn't. No idea how to isolate it enough to file a bug report. Clearly not hardware, exactly, though they're both 32-bit ARM. (my Pine A64+ with 64-bit aarch64 doesn't
<PhotoJim> have the issue though.)
<zmatt> we're still on 4.14, I should probably put some time into moving to a newer kernel, but it hasn't been a priority
<PhotoJim> well, a heads-up.
<PhotoJim> maybe it's the kernel. maybe it's something in the networking stack. no idea. so weird.
<zmatt> there's no logical reason for the hardware to be relevant for what you're describing... to the ethernet driver a packet is a packet, it doesn't know or care about the IP layer
<PhotoJim> exactly.
<PhotoJim> but it's super consistent. and repeatable. and before I realized the SheevaPlug was doing it too, I changed Ethernet cables, changed ports, even plugged it into another switch, and added a USB NIC (which had the same issues).
<PhotoJim> so it really doesn't seem to be hardware.
<zmatt> I mean, if it affects two totally different SoCs as well as a USB NIC then you've demonstrated successfully that it's not hardware-dependent (as expected) :P
<PhotoJim> I feel like I have :)
<PhotoJim> Pretty sure it's the same problem.
<PhotoJim> It's slightly annoying on the Sheeva. Makes the BB Black unusable with IPv6 though. It's much worse. But on IPv4... it's fine.
<PhotoJim> if I had another BB Black and knew someone else with IPv6, I'd test one there.
<PhotoJim> That's the ideal next step. Reproduce it somewhere that isn't on my network.
<zmatt> I can test 5.10, or does it have to be 5.11 ?
<PhotoJim> No idea to be honest.
<zmatt> (and the network that beaglebone is on only has link-local ipv6, no global ipv6, if that matters)
<PhotoJim> And no idea, to be honest. :)
<zmatt> what problem are you observing exactly?
<PhotoJim> IPv6 connections act as if there is huge packet loss.
<PhotoJim> Huge delays on ssh connections, e.g.
<PhotoJim> a couple of characters in a command might appear, then nothing, nothing, nothing, then a bunch of characters you typed a few seconds ago, then nothing...
<zmatt> hmm
<PhotoJim> if you had a connection with really bad packet loss... it would be like that.
<PhotoJim> and if it matters, I use systemd-networkd for IP configuration.
<zmatt> I use systemd-networkd too
<zmatt> oh wait not on this beaglebone
<PhotoJim> you could possibly deploy a private IPv6 range too. fc00:/12, I think, is all private. I use an fdde:: subnet locally (plus a public 2605:: one)
<zmatt> I don't see how that would make a difference compared to link-local
<rtwfroody> Hmm... beaglebone connects to USB, and then fails with some USB error (in dmesg output) a few minutes later.
<PhotoJim> less hassle than adding the %nic extensions. but in theory it shouldn't matter.
<PhotoJim> I'm not sure I tested if the problem exists on fe80:: addresses. I'll test.
<PhotoJim> hmm, seems okay.
<PhotoJim> I'll make another session to the 2605:: address.
<PhotoJim> first ssh attempt failed. second succeeded. evidence of the problem.
<PhotoJim> Yup, has the problem.
starblue has quit [Ping timeout: 260 seconds]
<PhotoJim> and another connection to the fdde:: address does too
<PhotoJim> but the fe80:: session is fine.
<PhotoJim> so that's another piece of evidence.
<zmatt> that makes absolutely no sense, wtf is going on on your network
<PhotoJim> and only on 32-bit ARM systems that aren't Raspberry Pis.
starblue has joined #beagle
<zmatt> rtwfroody: nobody can possibly give any useful feedback on a statement that vague btw
<zmatt> rtwfroody: (what error? share using pastebin. have you already reflashed it to the latest image? does the beaglebone seem to boot normally based on led activity?)
<PhotoJim> zmatt: networkctl shows eth0 (and eth1, which is still connected) as "configuring" sometimes, and "configured" at other times. so I wonder if there's some issue where IPv6 stateless autoconfiguration is getting purged or reset somehow, then restored. that would explain the delays. the system may be without that IPv6 address for a moment.
<zmatt> have you checked journal
<zmatt> ?
<PhotoJim> No. Doing that now.
<PhotoJim> Nothing obvious on journalctl -xe
<PhotoJim> looking without the -xe now
<PhotoJim> Nothing obvious.
<zmatt> well, good luck with it! :)
<PhotoJim> if you get any inspiration or ideas... let me know
<PhotoJim> or if you find the same problem and need me to help diagnose or investigate... also willing
<PhotoJim> I wish we had IPv6 at work. I'd take it there for awhile. (No one would care. Our IT guy there trusts me.)
<zmatt> afk
<PhotoJim> I should change systemd-networkd to debug logging.
<PhotoJim> also afk
sts-q has quit [Ping timeout: 264 seconds]
sts-q has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
russ has quit [Ping timeout: 260 seconds]
russ has joined #beagle
ikarso has joined #beagle
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #beagle
vd19 has joined #beagle
vd has quit [Ping timeout: 256 seconds]
giort has joined #beagle
johanhenselmans has joined #beagle
giort has quit [Quit: giort]
giort has joined #beagle
otisolsen70 has joined #beagle
xet7 has quit [Remote host closed the connection]
florian has joined #beagle
xet7 has joined #beagle
rtwfroody has quit [Ping timeout: 256 seconds]
Shadyman has quit [Quit: Leaving.]
giort has quit [Quit: giort]
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #beagle
Daulity has quit [Quit: Lost terminal]
bzyx has quit [Read error: Connection reset by peer]
bzyx has joined #beagle
Guest92 has joined #beagle
Guest92 has quit [Client Quit]
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #beagle
zjason` is now known as zjason
vd19 is now known as vd
buzzmarshall has joined #beagle
florian has quit [Quit: Ex-Chat]
vagrantc has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
lucascastro has joined #beagle
russ has quit [Remote host closed the connection]
russ has joined #beagle
lucascastro has quit [Ping timeout: 260 seconds]
otisolsen70 has quit [Quit: Leaving]
behanw has joined #beagle
Guest74 has joined #beagle
Guest74 has quit [Client Quit]
ikarso has quit [Quit: Connection closed for inactivity]
Shadyman has joined #beagle