Currently, shm has been used all around for python multiprocessing, and so forth. My system has been working for any program except python bitbake who is using this technology. This is not the only technology, so there should be a "plugin/backend" architecture established where something else can be plugged in. I have been trying to get "shm" right in chroot environments for about a day now, asking many experts, but we have not just got this right, which means unnecessary headache.
Since very sadly, Archlinux is not a supported host distribution, I need to execute this hackery in my /etc/fstab. Yes, the SHM is not writable in /mnt/wheezy/run after the automated mounting. I mean it is not even mounted as such.. I have to mount it separately, but why? Mounting /run should do the trick. This is just one of those serious hassles around it. /dev /mnt/wheezy/dev auto bind 0 0 /proc /mnt/wheezy/proc auto bind 0 0 /run /mnt/wheezy/run auto bind 0 0
Note, this is not a chroot fixing tutorial, but here is what I did: mount --bind /dev/shm /media/wheezy/run/shm
This is a core part of the python multiprocessing that bitbake uses, this would require a re-write of bitbake to not use python multiprocessing which is using shm.
Then document the chroot workflow including how to mount /dev/shm and /run/shm? Note, there is a user story break in here. Something has to be done, no doubt. Please do not close user story issues without a proposed simplification. Fwiw, a few people agreed about that on IRC documentation should or could be done with clear instructions. I personally do not think it is a base rewrite of bitbake since it is a python detail, and the bitbake functionality would almost fully remain.
Laszlo, Thanks for providing information on how to address this issue. I am going to create a FAQ entry for this situation. Here is suggested text based on my understanding, which probably needs some bolstering. I am not sure on the use of the term "chroot jail" to describe this situation. I found it by googling around for chroot concepts. Maybe that term is not valid here or well enough understood. Also, I am guessing on the actual solution a bit. I need some assistance there. Here is the suggested text for review: ------------------------------- 12.25. Can I get shared memory working in a "chroot jail"? Yes - If you have set up a chroot environment and cannot get shared memory to work, you need to bind the memory to your media. For example, assume you have the following commands in your /etc/fstab for mounting: /dev /mnt/wheezy/dev auto bind /proc /mnt/wheezy/proc auto bind 0 /run /mnt/wheezy/run auto bind 0 You must also bind the shared memory as follows: mount --bind /dev/shm /media/wheezy/run/shm
The technical content is inappropriate. Someone has to investigate about the process setup. I could not get it working.
Ok - thanks Laszlo. I will get further help. Scott
In my opinion, this is beyond the scope of the documentation. We state what distributions are supported, but it's implicit that these are correctly installed distributions. If you want to do builds in a chroot or similar, then the precise details of setting this up depend on both the host and the child distribution. We can't be expected to test and document the full matrix for correctly configuring a chroot environment in every combination of host and child distributions.
Yeah, right, but people disagree with you. In fact, if there is a feature which is _very core_ part of your system that it cannot even get an alternative backend (super silly, isn't it?), that has to be documented to work properly. Please do not screw users. If the Yocto project does not care in any way to help the users with chroot, which is again very user-unfriendly as it is quite Yocto specific, it has to state that in the documentation that "We do not support chroot in any way".
I have never ever had a problem with chroot, though been using it for 10+ years now. This is the first time, and that is Yocto making it non-working with "fundamental core part" of the system as they claim. I asked around in several channels like #debian, #archlinux, #yocto, and many other friends. None could have really helped, and never experienced this issue. Jeff, please comment on it as this is another occasion when improving the user experience gets reluctance.
Note also that, I have a very inconvenient workflow due to this. I need to use an unsupported Ubuntu version over ssh as Arch is broken, so is debian chroot with shm. It is tiresome when it comes to using openocd for the u-boot, kernel image, and the root filesystem over ssh, but there are other unpleasure issues as well.
As Ross says, as a bug, this request is outside the normal Yocto Project workflow. Unsupported development environments are, well, unsupported. We can only support so many combinations of things that people want to do, and chroot builds are not on the roadmap currently due to the Python issues mentioned. I'm not happy that it disrupts your workflow. One alternative that occurred to me is to use Ubuntu in a virtual machine on your primary host, though of course there would be a performance hit during the build. If you do persist in using chroot, it would be very helpful to us if you keep track of your process and let us know what you had to do to get it to work. We don't normally document things that we simply don't support, but we do try to provide some help when we can, hence Scott's message. We can also make the issue more clear in the documentation, perhaps with something like this: Using a chroot environment is untested and may have some issues. If you wish to try this process, consult the Quick Start Guide for the list of required packages for the supported Linux distribution you are using in the chroot. Also, check the Wiki and FAQ for any issues reported by the community. Please update the Wiki/FAQ if you discover issues with your chroot setup so others can learn from your experience. Hopefully this paragraph can offer some help without implying that the chroot setup is supported.
Why that message would be unhelpful and then bloated into the documentation is because it is so obvious to contact the chroot documentation (i.e. note, not distro as you wrote), but have you realized that is what I have been doing for weeks now, and it still does not work? Really, I have been trying to get it work for days, nights and week now. If it is a core technology of bitbake/oe-core and it cannot even get an alternative backend soltion, then it should be documented in my opinion. End users struggle for days, nights, and weeks. You do not think there should be a FAQ entry where the solution is presented? Do you think every single end user using chroot should struggle this much because of a "core" technology bitbake/oe-core uses, but pretty much nothing else during my 10+ years experience with chroot? This tickt is about *helping* users, and not leave them with trouble. So, I am with Scott on this one. An official FAQ documentation is the best place in my opinion. So many of your engineers told me on IRC it would be 5 minutes with basic linux skills. Good, we are very unskilled engineers then. Please enlighten us. Surely, your engineers have 5 minutes to help with a "core" technology issue out?
Not fixing this one based on final comments.
Wow, no help for the users, and not even documenting no the unwillingness ...
Please see comment 8 for the rationale on not documenting how to setup a chroot.
Why that does not make any sense is simply the fact the supported distributions are not supported at all because a "core technology" is a huuuuge blocker. Nice core technology, isn't it ... Again, please document at least that you do not care about chroot and the users are screwed if they go that way as Yocto does not provide any support for that. I am very unhappy every improvement suggestion is pretty much turned down, but then at least be sincere, and state clearly that those things are not supported. Try to be fair. :-)
Also, it is funny that I was told by several Yocto people that it should require 2-5 minutes to set up, and you have about ... a few supported distribution? The chroot command should be pretty much the same everywhere, except Debian... so you have got what? Like 10 minutes to document all this in a FAQ? You have been writing a lot more than that. How about changing the strategy in the future? Spending the time with the actual support rather than trying to escape from that with long discussions? If it is really 2-5 minutes for the Yocto people who claimed that, I do not see why we are still discussing it rather than just helping the users with ready made few instructions.
Just to track the record in here: yet another user had pain with shm while chatting about this unofficially on IRC. I believe the person was using Mac if I understood correctly. Either way, the discussion has inspired me enough to highlight that this core technology is broken in several ways. Moreover, my build actually reports _supported_ environment if I try to run bitbake. Surely, that is fake and bogus. It should be clarified by either a relevant warning like with unsupported host distributions or/and proper documentation. Mind to reopen the issue and improve the situation?
So, why wasn't the documentation updated at least based on Jeff's suggestion, Scott? Here goes it again: "Using a chroot environment is untested and may have some issues. If you wish to try this process, consult the Quick Start Guide for the list of required packages for the supported Linux distribution you are using in the chroot. Also, check the Wiki and FAQ for any issues reported by the community. Please update the Wiki/FAQ if you discover issues with your chroot setup so others can learn from your experience."
For people looking for a fix, at least on Linux, this can be a workaround: https://wiki.archlinux.org/index.php/Change_Root#An_Alternative_to_chroot_Using_systemd-nspawn Not sure about Mac, etc, though. This could be a FAQ entry IMHO.