aussetg has quit [Remote host closed the connection]
aussetg has joined #beagle
florian has joined #beagle
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Shadyman has quit [Quit: Leaving.]
ikarso has quit [Quit: Connection closed for inactivity]
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #beagle
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 268 seconds]
johanhenselmans_ is now known as johanhenselmans
akaWolf has quit [Ping timeout: 268 seconds]
florian has quit [Quit: Ex-Chat]
azarubkin has joined #beagle
ikarso has joined #beagle
akaWolf has joined #beagle
johanhenselmans has quit [Read error: Connection reset by peer]
johanhenselmans has joined #beagle
johanhenselmans has quit [Remote host closed the connection]
johanhenselmans has joined #beagle
azarubkin has quit [Ping timeout: 252 seconds]
brook has quit [Ping timeout: 244 seconds]
brook has joined #beagle
buzzmarshall has joined #beagle
marcheu has quit [Ping timeout: 244 seconds]
marcheu has joined #beagle
Sivakumar has joined #beagle
<Sivakumar>
hello
<Sivakumar>
I try Beaggle board black wireless kit for my project. It not able connect to http://192.168.7.2/ link. please any one suggest the procedure
<rcn-ee>
Sivakumar: 192.168.7.2 would assume you are running windows or linux, with the usb micro port plugged into the BeagleBone Black Wireless and then connected into your PC.. Is this true?
Sivakumar has quit [Quit: Client closed]
Sivakumar has joined #beagle
<Sivakumar>
yes windows with USB micro port plugged in to PC
<rcn-ee>
Does the RNDIS device show up in Device Manager? If you fire up tera-term do you have a new usb-cdc device..
<Sivakumar>
No it not show
<rcn-ee>
okay what image are you running on your board?
<zmatt>
booting from SD card might fail if the firmware on eMMC is really ancient, though I don't know if any BBB-Wireless is old enough for that to happen or if it's a problem exclusive to the BBB
<zmatt>
(in which case a workaround is holding down the S2 button (the one closest to the SD card slot) while applying power, you can (and should) let go once the power led turns on)
<zmatt>
in general, reflashing eMMC with the latest image is always highly recommended
<zmatt>
rather than booting from SD card
lucascastro has quit [Ping timeout: 268 seconds]
Shadyman has joined #beagle
jfsimon1981 has joined #beagle
<jfsimon1981>
Hi good evening
demirok has joined #beagle
Sivakumar has quit [Quit: Client closed]
randombot has joined #beagle
akaWolf has quit [Ping timeout: 244 seconds]
akaWolf has joined #beagle
<static_rocket>
hey lads, i wrote a little script to wrap e2fs tools to backup sd card images faster than dd by fetching only the used parts of the root partition. it does assume you only have 2 partitions and that the second partition is root with an ext4 fs on it, but its really fast for those few that have unreasonably large sd cards that are only sparsely populated. it also copies all the common partition identification information so the fstab
<static_rocket>
doesn't need to be updated (UUID, PARTUUID, lable). (there's even a method to make a minimal size, dd compatible disk image for portability)
<static_rocket>
let me know if it's useful to anyone or if something like this already exists that i completely overlooked
randombot has quit [Remote host closed the connection]
randombot has joined #beagle
randombot has quit [Remote host closed the connection]
<zmatt>
static_rocket: uhh, 2 partitions haven't been the default for many, many years though
<zmatt>
a strategy I've sometimes used myself is shrinking the filesystem using e2resize -M before making the backup, or using rsync to just backup the contents of the filesystem
<static_rocket>
zmatt: what exactly do you mean? I understand that expecting there to only be 2 partitions on the device is not necessarily reasonable, but it's still the default for the debian images provided on beaglebone.org, archlinuxarm, yocto, etc.
<zmatt>
the debian images provided on beagleboard.org have only a single image, and it's been like that for a very long time
<zmatt>
*single partition
<zmatt>
the bootloader is located in the space between the partition table and the rootfs partition
<static_rocket>
Also, e2resize before dd means that everything outside of the designated minimal fs region has to be read and re-written to the sd card before backup. e2image can rip all the useful chunks off the sd to a faster storage device before the resize.
<zmatt>
I mean, e2resize only has to rewrite whatever has to be moved... if little space is used on the filesystem, there's necessarily little to be moved
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
but it's certainly not ideal, it was a lazy solution. e2image is new to me
<static_rocket>
Sure, but that's entirely dependent on the fragmentation of that partition
<static_rocket>
Ah, I see what you mean now about the 2 partition standard. I was used to the boot flow the beagle ai uses and the dedicated boot partition associated with it. The scripts can be adjusted for that easily enough, however. It can just use dd for the space up to the start sector of the root partition.
<zmatt>
the bbai images use 2 partitions? I'm using a single partition on my bbx15 which uses the same SoC
<zmatt>
the ai64 is very different from previous devices
<zmatt>
the ai64's SoC comes from a completely different lineage, the Keystone family which descends from C6000-series DSPs, while all the previous ones most strongly descend from the OMAP series of mobile processors
<zmatt>
and that includes a completely different bootrom
<static_rocket>
eh, well... the script was more of a template than anything anyway. if i wanted to make it cover everything id have to parse the full output of lsblk -f and adjust the commands for every different filesystem's variation of e2image... and then capture that starting sector space for mbr and other compatibility...
<static_rocket>
it snowballs quickly
<zmatt>
I wonder whether this is faster or slower than using rsync to copy the contents... I'm guessing your approach is probably more efficient, unless you have a previous backup you want to bring in sync with the current filesystem contents but most of it remains the same
<static_rocket>
my first revision actually used rsync, but then you run into metadata issues. changing uuid's and labels that need to be updated. not every fs uses the same label creation flags and such
<static_rocket>
means you have to update the fstab a lot
<zmatt>
I personally don't put uuids in the fstab but just /dev/mmcblk<whatever>
<static_rocket>
heh, some would say that's not the best practice, but it gets the job done. at least until another drive is detected sooner than the boot drive...
<zmatt>
and I prefer to ensure the fsuuid is randomized any time I flash something so I don't end up with multiple filesystems that share the same fsuuid
<zmatt>
no, mmcblk devices are stable, not dependent on detection order
<zmatt>
they're based on the /aliases in DT
<zmatt>
at least since kernel 4.19 or something like that
<zmatt>
.9 I mean
<zmatt>
4.9
<static_rocket>
oh, that's fair
<zmatt>
e.g. on the AM335x-based devices mmcblk0 is SD, mmcblk1 is eMMC, always