**** BEGIN LOGGING AT Sun Feb 21 02:59:58 2016 Feb 21 03:40:24 zmatt: dont forget you cant stack them also, that a plus also. Feb 21 03:40:34 bonus \o/ Feb 21 04:13:57 hi Feb 21 05:48:58 I see there is talk about increasing the price of the BBB. If there going to do that I wish they would upgrade the Ethernet to Gigabit and the RAM to 1GB. Make it worthwhile. Feb 21 06:06:58 i'm trying to read images from a usb camera using a bbb and opencv. i am able to get images, but they look strange. see ozzloy.lifeafterking.org/~ozzloy/image.png the code is at ozzloy.lifeafterking.org/~ozzloy/opencv-hello-world.cpp and it works fine when i run on my laptop Feb 21 06:07:36 how do i get normal images without that line across? Feb 21 06:13:03 I've seen such issues somehow due to usb autosuspend Feb 21 06:14:19 you can disable it via sysfs, or disable it globally by adding usbcore.autosuspend=-1 to your kernel parameters Feb 21 06:15:52 try doing (as root): echo -1 >/sys/module/usbcore/parameters/autosuspend Feb 21 06:16:00 and then (re)connect the camera Feb 21 06:16:32 kk i'll try that Feb 21 06:16:33 thanks Feb 21 06:16:36 if that helps, you can persist the setting by adding usbcore.autosuspend=-1 to the "cmdline" setting in /boot/uEnv.txt Feb 21 06:16:36 zmatt, thanks Feb 21 06:17:40 I hope this info is still accurate since apparently it might somewhat depend on kernel version Feb 21 06:19:59 yay! Feb 21 06:20:18 so it worked after i did it twice Feb 21 06:20:27 the very first image is weird Feb 21 06:21:13 but this is something that happens on the laptop too. i can consistently make it happen by taking an image with streamer on the cli, then using the opencv program Feb 21 06:21:36 the first image is weird, then all images after are normal. know anything about what's going on there? Feb 21 06:21:49 zmatt, also, SUPER DUPER THANKS because i've spent a lot of time on this Feb 21 06:22:00 :) Feb 21 06:22:32 no idea, probably the cam is doing something wonky when initializing Feb 21 06:26:23 zmatt, so would this line work in /boot/uEnv.txt: "cmdline=usbcore.autosuspend=-1" ? Feb 21 06:26:39 you don't already have any cmdline options? Feb 21 06:26:54 oh, hey, there is one in there Feb 21 06:27:03 i saw the one near the end that was commented out Feb 21 06:27:22 so then, this: "cmdline=coherent_pool=1M quiet cape_universal=enable usbcore.autosuspend=-1" ? Feb 21 06:27:39 yes (ew, cape_universal...) Feb 21 06:28:02 that was there already. i didn't add it. what's it do? why's it bad? Feb 21 06:28:07 or "ew"? Feb 21 06:28:20 hehe, no it's default nowadays but I don't like it personally Feb 21 06:29:36 what's it do? Feb 21 06:30:32 it allows changing pinmux settings at runtime without using device tree overlays (hence the "universal" part), but in doing so it also enables basically all peripherals unconditionally Feb 21 06:31:16 it also means it conflicts with pretty much any device tree overlay Feb 21 06:31:36 oh wow Feb 21 06:31:43 that is good to know Feb 21 06:36:59 it's a relatively recent change and I don't really understand why... same with making RT-kernels standard, I also wouldn't recommend using one unless you explicitly need it Feb 21 06:40:39 yay, works after reboot! Feb 21 06:40:43 wooo Feb 21 06:40:48 (after the first image) Feb 21 06:40:48 \o/ Feb 21 06:40:56 \o/ Feb 21 06:41:53 now to screw everything all up and try a different camera Feb 21 06:42:30 * ozzloy marches confidently off the edge of a cliff Feb 21 06:43:56 oh yeah, here's another thing Feb 21 06:44:14 it takes a really really long time (like 5 whole seconds) for a picture to be taken Feb 21 06:44:21 (5 whole seconds!) Feb 21 06:44:43 check kernel log whether any errors are going on? Feb 21 06:44:45 which on the one hand isn't that much, but on the other is a killer if i'm trying to capture something moving Feb 21 06:45:19 5 seconds is a LOT of time Feb 21 06:45:39 damnit Feb 21 06:45:45 different camera doesn't work Feb 21 06:45:56 but it does work with the laptop Feb 21 06:46:03 it's $25 instead of $100 Feb 21 06:46:18 zmatt, where is kernel log? Feb 21 06:46:29 /var/log/? Feb 21 06:46:44 dmesg Feb 21 06:47:18 kern.log Feb 21 06:47:22 oh or dmesg Feb 21 06:47:24 (dmesg is a command) Feb 21 06:49:04 so dmesg says a lot of stuff which i don't know how to interpret. i see something about disconnecting, i'm guessing that's about the camera i just took off Feb 21 06:49:21 and something about a usb 2.0 camera, which is probably the camera i just plugged in Feb 21 06:49:35 i'll paste it somewhere, just a sec Feb 21 06:50:46 https://www.refheap.com/115022 here's the tail end of dmesg Feb 21 06:52:51 so, lines 9-12 and 21-30 look problematic to me Feb 21 06:53:20 which kernel currently on? (type: uname -r ) Feb 21 06:53:49 4.1.15-ti-rt-r40 Feb 21 06:54:36 what is softirq? Feb 21 06:55:05 so, I would suggest trying a non-RT kernel. the latest one from the 4.1-ti line is 4.1.17-ti-r48 Feb 21 06:55:11 i just unplugged the cheap camera and plugged in the expensive one and tried again. this time it took 2 images. TWO OF THEM! Feb 21 06:55:46 zmatt, sudo apt-get install mumble-mumble-4.1.17-ti-r48 ? Feb 21 06:56:29 yeah, linux-{image,headers}-4.1.17-ti-r48 Feb 21 06:56:30 linux-image-4.1.17-ti-r48 Feb 21 06:56:33 woo Feb 21 06:56:40 oh headers too? Feb 21 06:56:47 headers are optional Feb 21 06:57:21 but apparently some people manage to have dkms in use, and that will complain if headers are missing Feb 21 06:57:29 ooh, what about linux-image-4.1.17-bone19 ? it's got "bone" in the name Feb 21 06:58:24 ah, that makes sense that they would want headers to recompile Feb 21 06:58:32 that's another option, though if you go -bone then you may as well go all the way to 4.4.1-bone-r5 Feb 21 06:58:47 eh Feb 21 06:58:55 4.4.1-bone5 I mean Feb 21 06:59:06 i really don't know what the different kernels do Feb 21 06:59:23 whatever's gonna make this cheap camera work and allow me to return the expensive one Feb 21 06:59:29 lol Feb 21 06:59:31 that'd be the swellest Feb 21 07:00:15 you can try both of them of course. if you don't need specific features of the TI kernel (such as advanced power management) then you can try 4.4.1-bone5 Feb 21 07:00:20 do i have to do more than just sudo apt-get install -y $KERNEL && reboot ? Feb 21 07:00:44 sudo apt-get update first if you haven't done it already in the last 24 hours or so Feb 21 07:00:47 i might want advanced power later, when i'm running this on a battery powered robot Feb 21 07:00:55 yeah, i have updated Feb 21 07:01:12 then try 4.1.17-ti-r48 Feb 21 07:01:22 but what i mean is do i have to mess with configuring ... grub? or something? Feb 21 07:01:53 no, it automatically runs a kernel post-install script which uses sed to patch your /boot/uEnv.txt Feb 21 07:02:05 ah, cool Feb 21 07:02:15 there's a uname_r variable containing the kernel version you want Feb 21 07:02:18 ok so you suggest i try 4.1.17-ti-r48 first ? Feb 21 07:02:45 it's a sensible choice... or well, both choices are sensible but for different reasons Feb 21 07:05:07 apt-cache search linux|grep bone gives a /ton/ of output Feb 21 07:05:09 unfortunately, usb is a frequent source of trouble on the BBB Feb 21 07:05:29 I can imagine yes Feb 21 07:13:43 cool, apparently to make an effective shield against neutrinos you'd need 4 lightyears of lead Feb 21 07:18:16 what are you doing that you need to shield against neutrinos? Feb 21 07:18:38 lol, nothing, just watching a youtube video in which a physicist mentioned it Feb 21 07:19:05 as the number shows, there isn't actually anything practical that shields against neutrinos Feb 21 07:19:57 the universe is pretty big. i bet that much lead exists Feb 21 07:20:43 getting it in one place is a problem though, especially since it'll collapse under its own gravity Feb 21 07:21:05 if it were denser, wouldn't it make a better shield? Feb 21 07:21:47 no idea really, certainly you'd have *less* shield :P Feb 21 07:22:35 by volume... Feb 21 07:23:12 and by surface area. also, you'd probably soon have a shield you don't actually want nearby Feb 21 07:23:41 * vagrantc accepts neutrinos for who they are Feb 21 07:23:54 yeah I don't really have a problem with them either Feb 21 07:24:09 yeah, why you trying to keep out the neutrinos? Feb 21 07:24:17 what've they ever done to you? Feb 21 07:24:21 I already mentioned I'm not :P Feb 21 07:24:28 probably lots of things Feb 21 07:24:58 well, statistically you do interact with a handful of neutrinos during your lifetime Feb 21 07:25:12 eh, bad chocie of words Feb 21 07:25:20 I meant a dozen or so Feb 21 07:25:37 obviously a literal handful of neutrinos would be a rather lot :P Feb 21 07:26:01 heh Feb 21 07:27:27 ok, finally have a fan for the bbx15 and can do fun things like compile tests Feb 21 07:27:45 boy, it sure is annoying how often it powers on and off Feb 21 07:27:56 any suggestions to tell it to just stay on? Feb 21 07:28:21 a fork bomb? Feb 21 07:29:40 nah, just compiling u-boot and the kernel, nothing crazy Feb 21 07:29:47 although i did play a bit with stress-ng Feb 21 07:53:52 ok, 4.1.17-ti-r48 gave me the same weird images from the cheap camera. here's an example: http://ozzloy.lifeafterking.org/~ozzloy/image.png Feb 21 07:54:17 different kind of failure than the expensive camera used to have Feb 21 07:56:05 same code as before: https://www.refheap.com/115021 Feb 21 07:57:45 usb camera? Feb 21 07:58:09 yah Feb 21 07:59:08 the expensive one is logitech c920, the cheap one is http://www.amazon.com/Gear-Head-Webcam-Microphone-WC7500HD/dp/B0086UK786 Feb 21 08:01:18 zmatt, thanks a lot for helping. now i at least have one camera working Feb 21 08:11:37 I'd try that stuff on a desktop first Feb 21 08:11:59 and on the BBB I'd closely watch CPU cycle consumption Feb 21 08:22:14 tbr, oh i'm doing it on my laptop just fine Feb 21 08:22:52 with the gearhead and the logitech c920 Feb 21 08:46:12 is there gpu support on bbb? Feb 21 08:46:16 good, many people go straight for the BBB and then try to solve all the problems at once... Feb 21 08:46:38 the AM335x has a SGX/PVR GPU with a closed source driver Feb 21 08:46:55 you can probably get it to work if you need to Feb 21 08:47:01 :-/ Feb 21 08:47:06 that makes me a sad panda Feb 21 08:47:38 yeah, at this point i've done enough troubleshooting to know i need to break it down to very very small pieces Feb 21 08:47:43 I don't think I've even used the framebuffer output on HDMI Feb 21 08:47:59 which works without any special drivers Feb 21 08:48:40 oh, i'm hoping to get this working on bb green, which i think doesn't have hdmi Feb 21 08:49:48 yeah, you can hook up a hdmi cape if you really need tho' Feb 21 08:50:11 i really doubt i'll need that Feb 21 08:50:49 or a LCD cape or a SPI-LCD Feb 21 08:50:59 lcd i might want Feb 21 08:51:03 lcd+touch Feb 21 09:13:20 say i wanted to pay someone to solve this problem Feb 21 09:13:30 where would i go to find someone to pay? Feb 21 09:15:48 i need sleep Feb 21 09:15:52 gnight Feb 21 13:58:01 i am getting kernel panics when using most recent debian image to create the eMMC installation Feb 21 13:59:01 logile: http://pastebin.com/4rmD3iJ8 Feb 21 14:11:42 i can reproduce those errors every time Feb 21 14:31:10 Does anyone have a working MTP responder for the beagleboard? Feb 21 14:40:24 claudenw: that would depend on the OS, not the HW though, wouldn't it? Feb 21 14:41:12 indeed it would. So I figure a working MTP responder will lead me to the correct OS to use. Feb 21 14:41:55 is there a chat specifically for OS related questions on the BB? Feb 21 14:43:14 what problem are you trying to solve? Feb 21 14:45:53 I have a fuse based file system that I can run on the BB. I want to be able to plug the BB into a windows/linux/android host and have the fuse based file system appear as the content of the BB based device Feb 21 14:46:37 so the BB is an MTP responder to a windows/linux/android initiater. Feb 21 14:47:23 look at buteo-mtp Feb 21 14:47:44 Do you know anyone that has managed to get that to work? Feb 21 14:47:51 It brings a lot of baggage with it. Feb 21 14:47:59 hi all Feb 21 14:48:34 it works on Mer based distributions like Nemomobile and SailfishOS Feb 21 14:48:49 no idea how well it works on others Feb 21 14:49:31 or look at simpler/less feature rich things like ptp-gadget. note it's PTP not MTP Feb 21 14:52:54 https://git.merproject.org/mer-core/buteo-mtp - should be upstream for buteo Feb 21 14:53:46 Yes, I have that. I have been unable to get it to function correctly on my Debian based BBB. It is probably a PBKAS issue. Feb 21 14:54:04 well possible Feb 21 14:54:37 it should be fairly easy to put together a mer-core image for ARMv7, that should run also on the BBB Feb 21 14:55:08 that would most likely get you jumpstarted Feb 21 14:55:53 Yeah, that is probably easier than porting sailfishos to BBB. I'm rather new to building kernels and embedded programming. Lots of years on backend system though. Feb 21 14:56:13 Thx for the advice. I think I'll take a run at that. Feb 21 14:56:13 it's essentially the same, for your use case :) Feb 21 14:56:32 you could ask on #mer for hints on how to get a minimal FS going Feb 21 14:56:42 as you won't need all the UI foo Feb 21 14:56:55 good point. thx. Feb 21 14:57:18 to keep things simple, you can avoid the kernel rebuild and recycle the debian adaptation by manually copying it over Feb 21 14:58:17 or rather the other way around: you take a SD card with debian on it, remove everything on the rootfs except the kernel modules (/lib/modules) and replace things with a mer-core tarball Feb 21 14:58:43 the only step is to get a mer core tarball using mic/mic2 Feb 21 14:59:01 oh, and I hope you like systemd :> Feb 21 15:00:18 just getting the prototype to work will make me happy Feb 21 15:00:39 oh and: if you don't have a usb-uart adapter, get one NOW Feb 21 15:03:00 once you get a bit comfortable, it will just feel like messing with any other linux system Feb 21 15:16:53 i can reproduce the panic while writing the internal memory the whole time. also now tested with an other micro sd card Feb 21 15:18:10 have anyone here any idea? http://pastebin.com/yVVs3YJx Feb 21 15:19:24 4.1.15-ti-rt-r43 → try a vanilla and non-rt kernel Feb 21 15:27:21 tbr: i am using official installer: https://debian.beagleboard.org/images/bone-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img.xz Feb 21 15:28:11 yes, that doesn't prevent you from switching away from one official kernel to another official kernel, does it? Feb 21 15:29:18 tbr: i dont know. i have not changed anything. what file have i to change to use an other kernel? Feb 21 15:32:32 is there any bugtracker i can report this error? Feb 21 15:33:06 you should have a look at /opt/scripts/tools/update_kernel.sh Feb 21 15:33:09 it has options Feb 21 15:34:20 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Kernel_Options Feb 21 15:37:34 i have to add the # in front of the eMMC flash script first and then start the image and run sudo apt-get install linux-image-armmp ? Feb 21 15:41:18 ah, there is a new testing version. maybe this one works: https://rcn-ee.com/rootfs/bb.org/testing/2016-02-15/lxqt-4gb/BBB-eMMC-flasher-debian-8.3-lxqt-4gb-armhf-2016-02-15-4gb.img.xz Feb 21 15:44:38 lets try out. thanks so far. because i cant find any bugtracker i hope that the reported problem with the normal image is now reported propperly Feb 21 18:26:14 tbr: you can just apt-get install a different kernel, no need for scripts or such Feb 21 18:34:05 zmatt: yeah, saw that in the end Feb 21 19:34:07 ozzloy: I'm not really sure whether the usb problems on the bbb are soluble Feb 21 19:34:14 except perhaps in concentrated acids Feb 21 19:35:10 although I haven't yet completely ruled out the possibility it's just a crappy driver Feb 21 19:37:54 at the very least the bbb is not making the situation any better by missing the semi-obligatory large capacitor on the usb vbus output Feb 21 19:38:44 that could in principle be the cause of corrupting the first frame (due to sudden increase in current causing vbus to dip a bit) Feb 21 19:40:05 (unless the BBG fixes that, haven't checked it) Feb 21 19:44:47 (nope, it doesn't) Feb 21 20:28:48 I tried to setup cross compilation tools on my Mint 17 install, and now I get the following errors: Feb 21 20:28:50 http://pastebin.com/KmMdk9fp Feb 21 20:29:10 Can anyone help me straighten things out? :) Feb 21 20:40:01 help? Feb 21 20:44:08 Catfang, simple 404 error ,, check ur paths or switch a mirror Feb 21 20:44:13 Catfang: I don't really know anythig about the ubuntu repositories Feb 21 20:45:56 most people here use debian Feb 21 20:46:19 Mint is mostly Debian, right? :) Feb 21 20:46:31 no its mostly ubunut Feb 21 20:46:35 ubuntu Feb 21 20:46:40 The sources are correct, but I think they are looking for the wrong architecture Feb 21 20:46:59 well armhf is the correct name for the architecture Feb 21 20:47:01 404 means bsicly the path is wrong Feb 21 20:47:44 looking at http://mirrors.mit.edu/ubuntu/dists/trusty/main/ shows only binary-amd64 and binary-i386 are present, no ARM at all Feb 21 20:49:02 ditto at http://security.ubuntu.com/ubuntu/dists/trusty-security/main/ Feb 21 20:49:31 I don't know enough about Mint/Linux to troubleshoot. I'm in the software sources menu but I'm not seeing where this stuff is called. Feb 21 20:49:52 I don't know enough about Mint/Linux to troubleshoot either. Feb 21 20:50:09 :( Feb 21 20:50:12 dont worry who calls it, worry about the paths getting used .. Feb 21 20:50:29 source.list? Feb 21 20:50:46 I don't know where those paths come from Feb 21 20:51:07 which guide do you use ? Feb 21 20:51:12 guide? Feb 21 20:51:29 For the cross comp tools? Feb 21 20:51:38 yes Feb 21 20:51:55 I used Derek Malloy's Feb 21 20:52:15 for cross-compilation it probably expects to be able to add an APT architecture using the same source repositories as normal... that's true on debian, but apparently not for ubuntu or mint Feb 21 20:52:38 *same repositories Feb 21 20:53:25 Ah, that makes sense. Is this something I can fix? Feb 21 20:53:54 http://exploringbeaglebone.com/ Feb 21 20:54:14 That's Mr. Molloy's book/site Feb 21 20:54:35 well maybe see if there are any resources there Feb 21 20:55:50 There are, but they didn't work for me (I guess): http://exploringbeaglebone.com/chapter7/ Feb 21 20:57:53 on debian the cross-compilation toolchains are part of the main repositories, I've never used emdebian.org Feb 21 20:58:50 so I'm not realkly sure what he's doing with those crosstools Feb 21 20:59:49 in any case, he's using debian jessie as host system, not linux mint Feb 21 21:01:23 you might be able to get it to work on mint, but that will make things harder since you need to add separate source repositories for the armhf packages pointing to the debian jessie repositories (to be compatible with a debian jessie system running on the BBB) Feb 21 21:02:35 you can qualify entries in your /etc/apt/sources.list by architecture, e.g.: deb [arch=armhf] http://ftp.debian.org/debian/ jessie main Feb 21 21:02:48 or make a debian chroot? Feb 21 21:03:19 or a systemd-nspawn container (assuming mint uses a not-too-ancient systemd) Feb 21 21:03:45 n+1 roads lead to rome Feb 21 21:04:58 I've actually even managed to get a debian stretch armhf system running using systemd-nspawn and qemu-user, although that required a lot of creativity ;) Feb 21 21:07:34 I did make a debian chroot, or at least tried Feb 21 21:09:21 I'm not sure how to test it, to be honest. Ideally I'd like to develop in Eclipse or something similar and have it run using QEMU to test with Feb 21 21:11:08 zmatt: I'm going to look over the sources and see which ones I could use that qualifier with Feb 21 21:12:18 Catfang: well if you're doing this in your host linux/mint system then you'd need to add the source repositories (e.g. the one I listed), and qualify the ubuntu/mint repositories with your host architecture(s) (i363 and/or amd64) Feb 21 21:12:59 assuming you're targeting a BBB running jessie you'd want to use the jessie armhf repositories Feb 21 21:13:32 whether this is going to work at all on a mint host system, I have no idea Feb 21 21:14:10 Okay, just changed /sources.list.d/crosstools.list to have "deb [arch=armhf] http://emdebian.org/tools/debian jessie main" Feb 21 21:14:19 that's likely wrong Feb 21 21:14:48 Crap, I thought that's where you were directing me. Feb 21 21:15:17 since cross tools run on your host system, hence will use your host architecture Feb 21 21:15:55 the problem is that armhf has apparently been added as architecture to APT, so you'll need to add host-architecture qualifiers to every repository that doesn't support armhf Feb 21 21:16:41 Should I remove it as an apt architecture? I think I can figure that out. Feb 21 21:17:28 you can, but you won't be able to use any libraries other than the standard C/C++ libraries Feb 21 21:18:20 For armhf or for *86? Feb 21 21:18:24 armhf Feb 21 21:18:49 unless you manually (cross-)compile them that is Feb 21 21:19:17 but the reason for adding the armhf architecture to APT was to be able to use armhf libraries directly Feb 21 21:19:46 but that really only works out-of-the-box if your host runs more-or-less the same distro as the BBB Feb 21 21:20:43 Okay, I think I get that. What do you recommend I try then? Can I use the chroot for this? Feb 21 21:20:45 (all this multiarch stuff is also still a bit new and doesn't work quite as smooth as one would like) Feb 21 21:20:53 I understand. :) Feb 21 21:21:33 a debian jessie system running in a chroot (or systemd-nspawn, which is slightly nicer) should work yes Feb 21 21:22:05 I suppose the "right" answer would be to rebuild this machine using Debian instead of Mint, but I'd prefer not to go down that route if I can avoid it. Feb 21 21:22:58 Okay, I *think* I have a BBB/Debian chroot. How can tell if it's working/correct? Feb 21 21:24:31 I suspect you're now referring to your rootfs for the BBB Feb 21 21:25:16 that's not the same as a chroot environment for your cross compilation tools... the rootfs for your BBB is designed to run on armhf, not on amd64 Feb 21 21:25:57 Ah yes! So I *think* it's set up for armhf, but I have no idea if I did it correctly. Feb 21 21:26:27 you can actually enter it if you have qemu-user-static installed by using e.g. systemd-nspawn --bind-ro=/usr/bin/qemu-arm-static -M beaglebone -D path/to/rootfs Feb 21 21:26:38 but executables will run emulated, i.e. pretty slow Feb 21 21:28:11 (you can't actually boot it up using the "-b" option since qemu-user has some limitations which prevents running e.g. systemd) Feb 21 21:30:16 Okay, I just entered the chroot and did uname -a Feb 21 21:30:28 Linux MintyCat 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015 armv7l GNU/Linux Feb 21 21:31:06 yeah, it shows the host kernel yet "armv7l" as architecture :) Feb 21 21:31:15 Shouldn't that be debian instead of Ubuntu though? Feb 21 21:31:29 I thought I installed debian in that chroot Feb 21 21:31:42 it's showing the kernel version Feb 21 21:31:53 Is there a way to get the OS? Feb 21 21:32:29 cat /etc/debian_version Feb 21 21:33:17 root@MintyCat:/# cat /etc/debian_version Feb 21 21:33:18 8.3 Feb 21 21:33:29 that's jessie Feb 21 21:33:39 That's good, right? :) Feb 21 21:34:19 So I have a Jesse/armhf chroot. Got it. Feb 21 21:34:25 yes, but if you compile stuff in this environment you're not actually cross-compiling, you're native-compiling inside an emulator Feb 21 21:34:40 Which will be slow, as you said Feb 21 21:34:48 which is very nice for compatibility (i.e. configure scripts work), but not so much for performance Feb 21 21:35:46 So that environment is probably good for testing, but I should come up with something better for actual development. Correct? Feb 21 21:36:45 well if it's fast enough for your needs then go ahead Feb 21 21:38:18 SHould I make another chroot/systemd-nspawn for an actual development environment? Feb 21 21:39:04 it's worth considering... see the systemd-nspawn manpage for examples Feb 21 21:39:25 if you have a debian jessie for amd64 then you can nspawn a container running at native speed Feb 21 21:39:44 I'm reading this: https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/ Feb 21 21:40:26 beware of the date on that article Feb 21 21:41:19 I'm just trying to get a handle on what it is Feb 21 21:41:26 ok Feb 21 21:41:43 it's a tool to easily spawn containers :) Feb 21 21:41:57 lol, thanks. :D Feb 21 21:42:32 Okay, well back to fixing my Mint install. Do I just remove the armhf arch from apt? Feb 21 21:42:45 Will that fix my update errors? Feb 21 21:43:16 BTW, thank you a TON for helping me! I really appreciate it!! Feb 21 21:43:24 I've forgotten where exactly you add/remove an architecture from APT, but yeah once you've removed it you should be able to apt-get update without errors again Feb 21 21:43:47 you're welcome :) Feb 21 21:43:58 dpkg --remove-architecture Feb 21 21:46:01 Okay, that looks like it made Mint happy again. :) Feb 21 21:46:59 \o/ Feb 21 21:47:01 I'll look into building a debian systemd-nspawn or chroot then for my dev needs. I think I've got a better idea of what I'm doing now. :) Feb 21 21:47:18 woot :) Feb 21 21:47:30 Thank you again for your time! :) Feb 21 21:47:46 good luck :) Feb 21 21:47:53 Thanks! Feb 21 21:50:53 btw in case you're wondering how/why exactly qemu-arm-static gets automatically invoked for arm executables inside the container: magic. Feb 21 21:51:43 This is ALL magic for me at the moment. Black magic!!! Feb 21 21:54:02 specifically, qemu-arm-static registers the ELF header of an arm executable as filemagic to match on using the "binfmt_misc" facility of the kernel. This makes the kernel invoke /usr/bin/qemu-arm-static inside the chroot, which is aliased to the same executable of your host system using the --bind-ro option of systemd-nspawn Feb 21 21:57:17 Is there a way to convert my current chroot to an -nspawn containter? Feb 21 21:57:25 container? Feb 21 21:58:12 nspawn doesn't really impose any special requirements, as seen by the fact you have already successfully spawned a container using that rootfs Feb 21 21:58:41 you can similarly use it to enter a BBB that's in usb mass storage mode, e.g. to perform recovery if you screw up its rootfs Feb 21 21:59:18 (instead of the -D option with a directory you can also use the -i option and point it to the whole block device) Feb 21 22:00:22 so instead of "chroot BBBchroot" I just need to "systemd-nspawn BBBchroot"? Feb 21 22:01:12 no, you need the command you used earlier Feb 21 22:01:41 Which one was that? I'm confused. Feb 21 22:02:01 systemd-nspawn --bind-ro=/usr/bin/qemu-arm-static -M beaglebone -D path/to/rootfs Feb 21 22:02:41 path/to/rootfs would be /BBBchroot in this case? Feb 21 22:02:47 if that's where you put it Feb 21 22:03:03 That's where the Jessie/BBB chroot is Feb 21 22:04:23 what does the bind command do? I've already copied qemu-arm-static into the chroot Feb 21 22:04:35 then it's unnecessary Feb 21 22:04:55 conversely, the bind command makes copying the qemu-arm-static unnecessary Feb 21 22:05:11 Okay, got it Feb 21 22:07:03 afk Feb 21 22:08:51 Hmmm... "systemd-nspawn: command not found" Feb 21 22:09:00 Another Mint hangup? Feb 22 01:14:38 zmatt, that sucks (usb problems unsolvable) Feb 22 01:14:44 on the bbb Feb 22 01:14:49 what about the bbg? Feb 22 02:39:31 the bbg is the bbb with hdmi ripped out and some weird random changes **** ENDING LOGGING AT Mon Feb 22 02:59:58 2016