Replies: 2 comments 6 replies
-
Hi Ryan, This should be the minimal configuration to get someone up and building with kirkstone-next. The kirkstone-next branch should just be temporary measure for the short-term until we can verify it and merge it in to the kirkstone branch. Thanks for taking up this project, it will be great for new users! Regards,
|
Beta Was this translation helpful? Give feedback.
-
Hi Ryan, By default the poky builds have "debug-tweaks" enabled in conf/local.conf. In this debug mode, the root password is blank. So you can just log in with root and you will not get prompted for a password:
When I tested it just now, I was using it on a build server where I was connected via SSH and didn't have root privileges. Adding slirp and nographic to runqemu allowed me to run it in the console without root privileges for the tap devices. I did find however, that I had to manually specify the cpu type as it had defaulted to compile for the IvyBridge processor and I was getting complaints unsupported CPUID features (from QEMU):
or exceptions at runtime for unimplemented instructions if I chose an earlier CPU variant:
Issue 1: The QEMU -cpu option seems like a possible bug in the Yocto QEMU BSP because the machine is configured to build for the IvyBridge instruction set, but it hasn't seemingly set the variables used by runqemu to match. This perhaps isn't seen when using kvm. I temporarily worked around this with:
I was able to log in and source /usr/bin/ros_setup.sh. However it complained about unknown parameters to "head". This is because poky has busybox by default for constrained devices, however ROS makes some assumptions about bash and coreutils being installed. Issue 2: I tried sourcing the ros_setup.sh to source the environment, but I found that it required "head" from coreutils instead of the minimalistic version found in busybox. The proper thing would be for us to fix the ros-image-core.bb image recipe, (I added a comment to #1068) however as a quick fix we can just add these lines to conf/local.conf and rebuild ros-image-core:
With the new image we can then source ros_setup.sh and run ros2. The ros2 command is a little slow to start and may take 10 to 20 seconds to produce output. (This is something to investigate as well)
Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
Hello! I'm creating a public discussion to get help resolving my questions when writing this tutorial: https://github.com/Ryanf55/poky/wiki/Manual-Setup-Process
I'm currently facing an issue with
bitbake-layers add-layer ../meta-ros/meta-ros2
, where it reports the error:ERROR: Layer ros2-layer is not compatible with the core layer which only supports these series: kirkstone (layer is compatible with ${ROS_OE_RELEASE_SERIES})
It was recommended to switch meta-ros from
kirkstone
tokirkstone-next
. I've done that, and meta-ros is now pointing at hash baf1fa6. Unfortunately, I still get the same problem.Rob also recommended following a gist. I think this is it. Should this line be
kirkstone
orkirkstone-next
? https://gist.github.com/robwoolley/e16f60e6e8483e7ea36f7616197bab11#file-build-ros-image-world-txt-L8Beta Was this translation helpful? Give feedback.
All reactions