I have a working Yocto project for Raspberry Pi 3 built on a Ubuntu 16.04.4 PC. This needs to be transferred to a second Ubuntu 16.04.4 PC.
poky, meta-embedded and meta-raspberry were obtained with git clone -b.
Due to a poor internet connection this took several days to build an image with bitbake.
My question is, is it possible to copy all of the downloads generated by bitbake on the first PC to the second PC, so that with the local.conf and bblayers.conf from the first PC bitbake will build the image successfully?
Ideally, on the second PC bitbake will restart from the last successful download copied from the first machine (where?) to the second PC. Bitbake was re-run 10+ times on the first PC, seemingly without significant repetition of execution steps.
Thanks.
Yes, you can copy DL_DIR folder and SSTATE_DIR folder from one PC to another for minimum rebuild time.
You can also use SSTATE_MIRRORS and own-mirrors if you want to use multiple computers with same Yocto environment.
Related
I am trying to build custom linux image using yocto. The set up is;
Ubuntu 20.04 on Oracle Virtual Machine
Yocto release dunfell
It gives this error
NOTE: Exit code 127. Output:
/home/user234/yocto-project/image/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/intercept_scripts-1bf6a9721f164ba99b8a07325a9c3fe0f21a700fea55c8351519b59cf02d0aca/update_desktop_database:
7: update-desktop-database: not found
ERROR: The postinstall intercept hook 'update_desktop_database' failed, details in /home/user234/yocto-project/image/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs
The problem only occures in Virtual Machine Environment, It works fine with native linux environment on my other machine.
I have installed the desktop-file-utils and I can run from my shell manually. Somehow, bitbake is unable to detect it. Does someone know the solution?
You can resolve this issue immediately by patching poky sources to skip execution of "update_desktop_database" in this path:
poky/scripts/postinst-intercepts/update_desktop_database
Just comment the line.
It may happen again for other scripts. Just do the same for the other scripts. Finally, the do_rootfs task will complete successfully.
I had a similar problem (without virtual machine, you will see that this part is unrelated). The issue is with file permissions of the Yocto sources, or part of them. In my particular case the DevOps have set the POSIX file permissions on the entire Yocto source directory to 777, i.e. -rwxrwxrwx. Don't ask me why.
In the OP's case it seems like the Yocto sources may have been copied to the virtual machine with a help of some permission-less file system, like FAT32, which results in the same outcome. A good example is copying the sources with a USB flash drive formatted with FAT32. YMMV, this may probably be relevant for ACLs as well, I haven't tried to fiddle with that.
In my opinion, this should be considered as a bug in bitbake. If the source files permissions can cause such an unpredictable behavior, they have to be verified before or during the build, and the user must be informed by generating an error.
This is clearly irrelevant to the OP by now, hope somebody finds it useful.
>wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-18.04 (Default)
Ubuntu
I made the mistake of setting up everything in the Ubuntu-18.04 version, which is locked to that specific version and doesn't allow dist upgrades (Please prove me wrong). This includes shell customizations, symlinks etc.
I would however like to upgrade Ubuntu every once in a while. What I do not want to do is manually find all the configuration files and copy them to the new distribution.
The Ubuntu distribution is the one from the Windows store; fresh clean with no modifications.
How do I get my data from the old distribution into the fresh Ubuntu store distribution? Or is there a way to upgrade the locked Ubuntu-18.04 distribution (also from the Windows store)?
I know of wsl --export and wsl --import, but as far as I can tell these keep the distribution (with in this case the lack of upgrades) and just place a copy of that distribution into another folder. Which does not solve the dist upgrade problem.
I ended up using the free, legacy version of Aptik (I couldn't get the GTK version to launch). Even though it's no longer maintained, it's still working perfectly well, and only took me a single command to export everything and another single command to import everything again.
I'm compiling an image for raspberry-pi in yocto.How can i develop the same image to run in qemu.?
I included meta-raspberrypi in poky(sumo branch) along with its dependencies(meta-openembedded).I don't want to take the image,flash in SD-card and run in the hardware every time for simple tweaks.
MACHINE ??= "raspberrypi2"
This is what I have included in local.conf.
So how to run my image in qemu to check the changes are applied.What should I include in local.conf to do this.
The answer above was on the right track but chose the wrong machine.
In order to run the image built using the meta-raspberrypi package you need to
comment out the raspberrypi2 machine and set the machine to qemuarm. The reason is
the processor on the raspi2 is a 32bit arm chip either a Broadcom 2836,or 2837 depending on the version of raspi2 you have. If you have a raspi1 B then likely a Broadcom 2835. You can look up the hardware here (raspi-projects) .
In your local.conf file change the lines to match those below .
#MACHINE ??= "raspberrypi2"
MACHINE ??= "qemuarm"
Build the image with
$ bitbake core-image-base
# or
$ bitbake rpi-basic-imag # deprecated
Then you will have a qemu image that can be run with
$ runqemu qemuarm
I have followed there steps myself and created the image I want, and am in the process of developing the system I need for a project. Hope this helps with others to move forward with similar goals.
Try MACHINE = "qemux86-64", then bitbake your image, then use the runqemu script.
setup.py sdist upload -r local --show-response
hangs on
Creating tar archive
removing 'my_lib-0.0.3' (and everything under it)
running upload
The first question is how can I get more debug info on what is the problem with running upload? Until that, I can't ask a more specific question on my problem. The second will be how to solve this problem and what to check.
I use Windows 10. I put .pypirc to {HOME}, {HOME}\pip, {HOME}\AppData\Local\pip, because I am not sure where it should be placed.
[distutils]
index-servers =
pypi
local
[pypi]
username:some_user
password:
[local]
repository: http://my_repo.local:9292
username:some_user
password:
I tried the same on another PC (with the same python environment, config, etc.) with Ubuntu and it works ok.
I also tried to use twine, but the effect is similar- it hangs without output.
I'm using a Python application that accesses a USB device (pipsta printer) and executes a routine. It's running fine outside the container, but when it comes to the container it returns a error like this:
(File "usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", line 386, in _check:
raise USBError(errmsg, ret)
USB.core.USBError: [Errno None] couldn't opendir(): No such a file or directory)
In my dockerfile, I've included all the packages relevant to Python and USB, and I also moved the relevant files to /etc/udev/rules.d and restarted udev.
Make sure you:
followed every step from assembly instruction and https://bitbucket.org/ablesystems/pipsta/wiki/Pipsta%20First-Time%20Setup
printer is connected to the power
printer is connected via usb to raspberry
printer's led doesn't blink (should be green constantly)
proper usb library is installed (or try to install different version of the usb library). What version are you using? python: print(usb.__version__) , it works fine for me with version 1.0.0rc1
is printer visible to the os? command: ls /dev/ap1400
I know this is an old question (I've only just encountered it). The following is a paraphrasing of the FAQ. The following steps should help diagnose the problem.
Download the latest set of Pipsta examples..
Extract the contents of the zip file.
Change directory to where the files were extracted
Change directory to the Examples folder.
Using a terminal run the command python verify_pipsta_install.py. This will try and help diagnose problems.
The following will should fix the python usb library error.
If your Pipsta printer firmware is V9.2.03 please upgrade the firmware to V9.2.08 using the fpu (both can be found in the downloads section of bit bucket.
Install the latest version of the Pipsta examples (download from bitbucket).
Copy the new pipsta/Examples/system_scripts/ to /etc/udev/rules.d/60-ablesystems-pyusb.rules
Restart the Raspberry Pi
If the printer still fails to be discovered then -
The following workaround may work.
1. Unplug the printer from the USB port
1. Enter the command sudo lsusb
1. Reconnect the printer
1. Enter the command sudo lsusb
If the printer has been detected by the Linux environment then either /dev/ap1400 or /dev/pipsta should exist in the filesystem.
NOTE The Pipsta now has Debian packages to help with installation. I have a link limit on my account but search for pipsta-printer-utilities-1.1.1-Linux.deb and pipsta-cups-driver-0.3.0-armhf.deb for more information.