**** BEGIN LOGGING AT Fri Jul 22 02:59:56 2022 Jul 22 15:18:29 hello Jul 22 15:19:56 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 Jul 22 15:22:09 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? Jul 22 15:26:13 yes windows with USB micro port plugged in to PC Jul 22 15:28:24 Does the RNDIS device show up in Device Manager? If you fire up tera-term do you have a new usb-cdc device.. Jul 22 15:36:05 No it not show Jul 22 15:36:30 okay what image are you running on your board? Jul 22 15:37:04 AM3358 Debian 10.3 2020-04-06 4GB SD IoT Jul 22 15:38:30 i'd fully expect to see a rndis device in windows with that image.. Jul 22 15:39:00 just grab the newer iot build: https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280 Jul 22 15:54:22 Thanks lot i check Jul 22 17:52:54 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 Jul 22 17:54:08 (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) Jul 22 17:54:35 in general, reflashing eMMC with the latest image is always highly recommended Jul 22 17:54:41 rather than booting from SD card Jul 22 18:17:35 Hi good evening Jul 22 19:46:48 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 Jul 22 19:46:48 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) Jul 22 19:46:48 https://gist.github.com/StaticRocket/8934f78b3da7838ca265aa0223e62608 Jul 22 19:46:48 let me know if it's useful to anyone or if something like this already exists that i completely overlooked Jul 22 20:52:34 static_rocket: uhh, 2 partitions haven't been the default for many, many years though Jul 22 21:03:37 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 Jul 22 21:04:12 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. Jul 22 21:04:41 the debian images provided on beagleboard.org have only a single image, and it's been like that for a very long time Jul 22 21:04:49 *single partition Jul 22 21:05:37 the bootloader is located in the space between the partition table and the rootfs partition Jul 22 21:07:30 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. Jul 22 21:10:18 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 Jul 22 21:10:44 but it's certainly not ideal, it was a lazy solution. e2image is new to me Jul 22 21:11:53 Sure, but that's entirely dependent on the fragmentation of that partition Jul 22 21:14:43 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. Jul 22 21:15:33 the bbai images use 2 partitions? I'm using a single partition on my bbx15 which uses the same SoC Jul 22 21:15:56 https://debian.beagle.cc/images/bbai64-debian-11.3-xfce-arm64-2022-06-14-10gb.img.xz Jul 22 21:16:08 oh ai64, that's a different matter Jul 22 21:17:05 the ai64 is very different from previous devices Jul 22 21:20:10 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 Jul 22 21:22:18 and that includes a completely different bootrom Jul 22 21:22:55 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... Jul 22 21:23:35 it snowballs quickly Jul 22 21:24:43 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 Jul 22 21:26:03 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 Jul 22 21:26:23 means you have to update the fstab a lot Jul 22 21:26:45 I personally don't put uuids in the fstab but just /dev/mmcblk Jul 22 21:27:59 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... Jul 22 21:28:04 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 Jul 22 21:28:14 no, mmcblk devices are stable, not dependent on detection order Jul 22 21:28:21 they're based on the /aliases in DT Jul 22 21:28:32 at least since kernel 4.19 or something like that Jul 22 21:28:40 .9 I mean Jul 22 21:28:43 4.9 Jul 22 21:29:08 oh, that's fair Jul 22 21:29:13 e.g. on the AM335x-based devices mmcblk0 is SD, mmcblk1 is eMMC, always **** ENDING LOGGING AT Sat Jul 23 02:59:56 2022