1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3*******************
4System Requirements
5*******************
6
7Welcome to the Yocto Project Reference Manual. This manual provides
8reference information for the current release of the Yocto Project, and
9is most effectively used after you have an understanding of the basics
10of the Yocto Project. The manual is neither meant to be read as a
11starting point to the Yocto Project, nor read from start to finish.
12Rather, use this manual to find variable definitions, class
13descriptions, and so forth as needed during the course of using the
14Yocto Project.
15
16For introductory information on the Yocto Project, see the
17:yocto_home:`Yocto Project Website <>` and the
18":ref:`overview-manual/development-environment:the yocto project development environment`"
19chapter in the Yocto Project Overview and Concepts Manual.
20
21If you want to use the Yocto Project to quickly build an image without
22having to understand concepts, work through the
23:doc:`/brief-yoctoprojectqs/index` document. You can find "how-to"
24information in the :doc:`/dev-manual/index`. You can find Yocto Project overview
25and conceptual information in the :doc:`/overview-manual/index`.
26
27.. note::
28
29   For more information about the Yocto Project Documentation set, see
30   the :ref:`ref-manual/resources:links and related documentation` section.
31
32Minimum Free Disk Space
33=======================
34
35To build an image such as ``core-image-sato`` for the ``qemux86-64`` machine,
36you need a system with at least &MIN_DISK_SPACE; Gbytes of free disk space.
37However, much more disk space will be necessary to build more complex images,
38to run multiple builds and to cache build artifacts, improving build efficiency.
39
40If you have a shortage of disk space, see the ":doc:`/dev-manual/disk-space`"
41section of the Development Tasks Manual.
42
43.. _system-requirements-minimum-ram:
44
45Minimum System RAM
46==================
47
48You will manage to build an image such as ``core-image-sato`` for the
49``qemux86-64`` machine with as little as &MIN_RAM; Gbytes of RAM on an old
50system with 4 CPU cores, but your builds will be much faster on a system with
51as much RAM and as many CPU cores as possible.
52
53.. _system-requirements-supported-distros:
54
55Supported Linux Distributions
56=============================
57
58Currently, the &DISTRO; release ("&DISTRO_NAME;") of the Yocto Project is
59supported on the following distributions:
60
61-  Ubuntu 20.04 (LTS)
62
63-  Ubuntu 22.04 (LTS)
64
65-  Fedora 38
66
67-  CentOS Stream 8
68
69-  Debian GNU/Linux 11 (Bullseye)
70
71-  Debian GNU/Linux 12 (Bookworm)
72
73-  OpenSUSE Leap 15.4
74
75-  AlmaLinux 8
76
77-  AlmaLinux 9
78
79-  Rocky 9
80
81The following distribution versions are still tested, even though the
82organizations publishing them no longer make updates publicly available:
83
84-  Ubuntu 18.04 (LTS)
85
86-  Ubuntu 23.04
87
88Note that the Yocto Project doesn't have access to private updates
89that some of these versions may have. Therefore, our testing has
90limited value if you have access to such updates.
91
92Finally, here are the distribution versions which were previously
93tested on former revisions of "&DISTRO_NAME;", but no longer are:
94
95*This list is currently empty*
96
97.. note::
98
99   -  While the Yocto Project Team attempts to ensure all Yocto Project
100      releases are one hundred percent compatible with each officially
101      supported Linux distribution, you may still encounter problems
102      that happen only with a specific distribution.
103
104   -  Yocto Project releases are tested against the stable Linux
105      distributions in the above list. The Yocto Project should work
106      on other distributions but validation is not performed against
107      them.
108
109   -  In particular, the Yocto Project does not support and currently
110      has no plans to support rolling-releases or development
111      distributions due to their constantly changing nature. We welcome
112      patches and bug reports, but keep in mind that our priority is on
113      the supported platforms listed above.
114
115   -  If your Linux distribution is not in the above list, we recommend to
116      get the :term:`buildtools` or :term:`buildtools-extended` tarballs
117      containing the host tools required by your Yocto Project release,
118      typically by running ``scripts/install-buildtools`` as explained in
119      the ":ref:`system-requirements-buildtools`" section.
120
121   -  You may use Windows Subsystem For Linux v2 to set up a build host
122      using Windows 10 or later, or Windows Server 2019 or later, but validation
123      is not performed against build hosts using WSL 2.
124
125      See the
126      :ref:`dev-manual/start:setting up to use windows subsystem for linux (wsl 2)`
127      section in the Yocto Project Development Tasks Manual for more information.
128
129   -  If you encounter problems, please go to :yocto_bugs:`Yocto Project
130      Bugzilla <>` and submit a bug. We are
131      interested in hearing about your experience. For information on
132      how to submit a bug, see the Yocto Project
133      :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
134      and the ":doc:`../contributor-guide/report-defect`"
135      section in the Yocto Project and OpenEmbedded Contributor Guide.
136
137Required Packages for the Build Host
138====================================
139
140The list of packages you need on the host development system can be
141large when covering all build scenarios using the Yocto Project. This
142section describes required packages according to Linux distribution and
143function.
144
145.. _ubuntu-packages:
146
147Ubuntu and Debian
148-----------------
149
150Here are the packages needed to build an image on a headless system
151with a supported Ubuntu or Debian Linux distribution::
152
153   $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
154
155.. note::
156
157   -  If your build system has the ``oss4-dev`` package installed, you
158      might experience QEMU build failures due to the package installing
159      its own custom ``/usr/include/linux/soundcard.h`` on the Debian
160      system. If you run into this situation, try either of these solutions::
161
162         $ sudo apt build-dep qemu
163         $ sudo apt remove oss4-dev
164
165Here are the packages needed to build Project documentation manuals::
166
167   $ sudo apt install make python3-pip inkscape texlive-latex-extra
168   &PIP3_HOST_PACKAGES_DOC;
169
170Fedora Packages
171---------------
172
173Here are the packages needed to build an image on a headless system
174with a supported Fedora Linux distribution::
175
176   $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
177
178Here are the packages needed to build Project documentation manuals::
179
180   $ sudo dnf install make python3-pip which inkscape texlive-fncychap
181   &PIP3_HOST_PACKAGES_DOC;
182
183openSUSE Packages
184-----------------
185
186Here are the packages needed to build an image on a headless system
187with a supported openSUSE distribution::
188
189   $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
190
191Here are the packages needed to build Project documentation manuals::
192
193   $ sudo zypper install make python3-pip which inkscape texlive-fncychap
194   &PIP3_HOST_PACKAGES_DOC;
195
196
197AlmaLinux Packages
198------------------
199
200Here are the packages needed to build an image on a headless system
201with a supported AlmaLinux distribution::
202
203   $ sudo dnf install &ALMALINUX_HOST_PACKAGES_ESSENTIAL;
204
205.. note::
206
207   -  Extra Packages for Enterprise Linux (i.e. ``epel-release``) is
208      a collection of packages from Fedora built on RHEL/CentOS for
209      easy installation of packages not included in enterprise Linux
210      by default. You need to install these packages separately.
211
212   -  The ``PowerTools/CRB`` repo provides additional packages such as
213      ``rpcgen`` and ``texinfo``.
214
215   -  The ``makecache`` command consumes additional Metadata from
216      ``epel-release``.
217
218Here are the packages needed to build Project documentation manuals::
219
220   $ sudo dnf install make python3-pip which inkscape texlive-fncychap
221   &PIP3_HOST_PACKAGES_DOC;
222
223.. _system-requirements-buildtools:
224
225Required Git, tar, Python, make and gcc Versions
226================================================
227
228In order to use the build system, your host development system must meet
229the following version requirements for Git, tar, and Python:
230
231-  Git &MIN_GIT_VERSION; or greater
232
233-  tar &MIN_TAR_VERSION; or greater
234
235-  Python &MIN_PYTHON_VERSION; or greater
236
237-  GNU make &MIN_MAKE_VERSION; or greater
238
239If your host development system does not meet all these requirements,
240you can resolve this by installing a :term:`buildtools` tarball that
241contains these tools. You can either download a pre-built tarball or
242use BitBake to build one.
243
244In addition, your host development system must meet the following
245version requirement for gcc:
246
247-  gcc &MIN_GCC_VERSION; or greater
248
249If your host development system does not meet this requirement, you can
250resolve this by installing a :term:`buildtools-extended` tarball that
251contains additional tools, the equivalent of the Debian/Ubuntu ``build-essential``
252package.
253
254For systems with a broken make version (e.g. make 4.2.1 without patches) but
255where the rest of the host tools are usable, you can use the :term:`buildtools-make`
256tarball instead.
257
258In the sections that follow, three different methods will be described for
259installing the :term:`buildtools`, :term:`buildtools-extended` or :term:`buildtools-make`
260toolset.
261
262Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script
263--------------------------------------------------------------------------------
264
265The ``install-buildtools`` script is the easiest of the three methods by
266which you can get these tools. It downloads a pre-built :term:`buildtools`
267installer and automatically installs the tools for you:
268
269#. Execute the ``install-buildtools`` script. Here is an example::
270
271      $ cd poky
272      $ scripts/install-buildtools \
273        --without-extended-buildtools \
274        --base-url &YOCTO_DL_URL;/releases/yocto \
275        --release yocto-&DISTRO; \
276        --installer-version &DISTRO;
277
278   During execution, the :term:`buildtools` tarball will be downloaded, the
279   checksum of the download will be verified, the installer will be run
280   for you, and some basic checks will be run to make sure the
281   installation is functional.
282
283   To avoid the need of ``sudo`` privileges, the ``install-buildtools``
284   script will by default tell the installer to install in::
285
286      /path/to/poky/buildtools
287
288   If your host development system needs the additional tools provided
289   in the :term:`buildtools-extended` tarball, you can instead execute the
290   ``install-buildtools`` script with the default parameters::
291
292      $ cd poky
293      $ scripts/install-buildtools
294
295   Alternatively if your host development system has a broken ``make``
296   version such that you only need a known good version of ``make``,
297   you can use the ``--make-only`` option::
298
299      $ cd poky
300      $ scripts/install-buildtools --make-only
301
302#. Source the tools environment setup script by using a command like the
303   following::
304
305      $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux
306
307   After you have sourced the setup script, the tools are added to
308   ``PATH`` and any other environment variables required to run the
309   tools are initialized. The results are working versions versions of
310   Git, tar, Python and ``chrpath``. And in the case of the
311   :term:`buildtools-extended` tarball, additional working versions of tools
312   including ``gcc``, ``make`` and the other tools included in
313   ``packagegroup-core-buildessential``.
314
315Downloading a Pre-Built ``buildtools`` Tarball
316----------------------------------------------
317
318If you would prefer not to use the ``install-buildtools`` script, you can instead
319download and run a pre-built :term:`buildtools` installer yourself with the following
320steps:
321
322#. Go to :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/`, locate and
323   download the ``.sh`` file corresponding to your host architecture
324   and to :term:`buildtools`, :term:`buildtools-extended` or :term:`buildtools-make`.
325
326#. Execute the installation script. Here is an example for the
327   traditional installer::
328
329      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
330
331   Here is an example for the extended installer::
332
333      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
334
335   An example for the make-only installer::
336
337      $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh
338
339   During execution, a prompt appears that allows you to choose the
340   installation directory. For example, you could choose the following:
341   ``/home/your-username/buildtools``
342
343#. As instructed by the installer script, you will have to source the tools
344   environment setup script::
345
346      $ source /home/your_username/buildtools/environment-setup-x86_64-pokysdk-linux
347
348   After you have sourced the setup script, the tools are added to
349   ``PATH`` and any other environment variables required to run the
350   tools are initialized. The results are working versions versions of
351   Git, tar, Python and ``chrpath``. And in the case of the
352   :term:`buildtools-extended` tarball, additional working versions of tools
353   including ``gcc``, ``make`` and the other tools included in
354   ``packagegroup-core-buildessential``.
355
356Building Your Own ``buildtools`` Tarball
357----------------------------------------
358
359Building and running your own :term:`buildtools` installer applies only when you
360have a build host that can already run BitBake. In this case, you use
361that machine to build the ``.sh`` file and then take steps to transfer
362and run it on a machine that does not meet the minimal Git, tar, and
363Python (or gcc) requirements.
364
365Here are the steps to take to build and run your own :term:`buildtools`
366installer:
367
368#. On the machine that is able to run BitBake, be sure you have set up
369   your build environment with the setup script
370   (:ref:`structure-core-script`).
371
372#. Run the BitBake command to build the tarball::
373
374      $ bitbake buildtools-tarball
375
376   or to build the extended tarball::
377
378      $ bitbake buildtools-extended-tarball
379
380   or to build the make-only tarball::
381
382      $ bitbake buildtools-make-tarball
383
384   .. note::
385
386      The :term:`SDKMACHINE` variable in your ``local.conf`` file determines
387      whether you build tools for a 32-bit or 64-bit system.
388
389   Once the build completes, you can find the ``.sh`` file that installs
390   the tools in the ``tmp/deploy/sdk`` subdirectory of the
391   :term:`Build Directory`. The installer file has the string
392   "buildtools" or "buildtools-extended" in the name.
393
394#. Transfer the ``.sh`` file from the build host to the machine that
395   does not meet the Git, tar, or Python (or gcc) requirements.
396
397#. On this machine, run the ``.sh`` file to install the tools. Here is an
398   example for the traditional installer::
399
400      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
401
402   For the extended installer::
403
404      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
405
406   And for the make-only installer::
407
408      $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh
409
410   During execution, a prompt appears that allows you to choose the
411   installation directory. For example, you could choose the following:
412   ``/home/your_username/buildtools``
413
414#. Source the tools environment setup script by using a command like the
415   following::
416
417      $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux
418
419   After you have sourced the setup script, the tools are added to
420   ``PATH`` and any other environment variables required to run the
421   tools are initialized. The results are working versions versions of
422   Git, tar, Python and ``chrpath``. And in the case of the
423   :term:`buildtools-extended` tarball, additional working versions of tools
424   including ``gcc``, ``make`` and the other tools included in
425   ``packagegroup-core-buildessential``.
426