Testing Bitbake on Yocto 6.0.1 (Wrynose) LTS

Last fall, I tested my first Yocto (5.0) linux builds on a couple machines from the past decade: a 2011 Lenovo ThinkPad Edge 420 with an i3 2350M and 6GB of RAM, and a Ryzen 5 1600 with 16GB of RAM. The latter is quite capable, but I honestly found it more interesting to see the dual core i3 (w/ 4 threads) manage to compile a core-image-minimal. I even wrote an installation log about the process (I recorded video with the Ryzen using Ubuntu's built-in CPU recorder, since it has 12 threads, whereas I only took screenshots on the i3 2350m during load, to limit crashing)

With the release of Yocto 6.0.1 LTS Wrynose, I was curious to test out the Bitbake, on a PC in between the performance of the i3 2350m and the Ryzen 5 1600: My 2015 FX8320E with 8 threads (it's called an 8 core but it's really a quad core with 2 threads each). I built this PC from MicroCenter and Newegg, plus a lot of swapping of GPUs in the past several years, but I had a few new things I wanted to test out. First, I acquired a DVR box that had been in disuse, and since I don't really plan on using it for a cable subscription, assuming it's still offered in that format, I was able to remove the 300GB HDD from it and install it on my Gigabyte 990FX series board. Instead of using it as a storage drive for a faster SSD, I decided to install a copy of Rocky Linux 9.5 (from an ISO I had from 2024) which later upgraded to 9.8). Fortunately, Yocto has supported Rocky Linux 9 since 5.0 scarthgap releases, so the installation process had documentation for it.

The size of the disk space needed for a minimal image is less than 100GB, although it is recommended to have more than 160GB for Sato (This was one reason I was only able to compile the core-minimal-image on my Lenovo E420, which had a 120GB SSD at the time). The Sato image compiled using a Crucial M.2 500GB NVMe drive which I purchased in 2020 for my Ryzen 5 1600. However, I had not tested a spinning platter before, and I was also curious how much of that new 32GB RAM requirement was really needed, mainly due to the introduction of LLVM 22.1.2. 

Results: I completed my first core-minimal-image compile early this morning (well, not super early, but around 3AM) using the 6.18 kernel. I watched a video about LLVM using lld, a faster linker than GNU BFD, and even gold, since LLVM-native was taking one of the longest steps of the compilation. I realized this was normal by now, because it was also what drew me towards reading about LLVM back in December when I started testing Yocto. The Hitachi 5900 RPM (or possibly 7200RPM) drive had little to do with it. However, it's unclear how much of the standard toolchain requires legacy compilations, whereas lld was designed for larger and more frequently compiled software like Chrome, Rust, and Mesa.

By the time the compilation was complete, I had used 11.6GB on my root partition (of 75.1GB- likely little was for Poky), and 76.6GB out of a 226.8 GB on my home partition. Thus the minimal image doesn't require 140GB, but then again, it's not a typical image unless one is working on microcontrollers or very old systems.

Interestingly, the time the RAM usage was highest was around the time a GCC, Yocto-linux, and llvm task, zstd, openssl and/or glibc were all compiling at the same time. It peaked around 20GB of RAM, although only briefly, around 3-4 hours in. Typical usage was around 12GB and it frequently reached 14-15GB. The total compilation time was around 5hrs, and it appeared more CPU bottlenecked since the FX 8320E is technically around 4 modules with 2 logical threads each. That said, had I used a Sato Image, it might take significantly longer (which is why the Ryzen is preferred). I did find some FX-specific potential slow downs for AVX2, although I wasn't sure if it was affected by it. I also found an AMD optimized C compiler, which Ryzen has improved performance for, although I am not sure if it helped the Piledriver.

Some unexpected unpleasantries. Unlike Yocto 5.0, the development image is no longer a playground. Developers on Yocto 6 are expected to use passwords, and since systemd requires a password, the login process after I ran qemux86-64 did not accept a password, since none was generated:

By default, systemd/PAM in Yocto blocks empty passwords for security. To enable them, add EXTRA_IMAGE_FEATURES += "allow-empty-password" and EXTRA_IMAGE_FEATURES += "debug-tweaks" to your local.conf, or create a custom pam_unix config using the nullok flag. [1, 2, 3] 

From last year's ELCE Conference, I read that empty "debug-tweaks" was actually removed in Walnascar 5.2 (p.15-17):

 

I spent an hour trying to edit the "config file", only to realize the correct config file, a .bb file in recipes-core, was in a different folder.

I had been searching the qemuboot.conf file:

 

This was at 3AM, so I had no interest in patching that after a 5 hr compilation. I had at least found the answer, but I saved my notes for the next day (today). I had been using 5.0 in January (scarthgap), so I was most likely not affected by the 5.2 change. Each release has its own quirks- for example, I had to install a prebuilt buildtools tarball, since I wasn't able to use the building it. But in any case, three options are given to fix a bug that affects AlmaLinux 9, CentOS 9, and RockyLinux 9:

"The AlmaLinux 9, CentOS 9 and RockyLinux 9 distributions are affected by a bug described in https://bugzilla.yoctoproject.org/show_bug.cgi?id=16143, which is the reason why a buildtools tarball is required."

"buildtools

Build tools in binary form, providing required versions of development tools (such as Git, GCC, Python and make), to run the OpenEmbedded build system on a development host without such minimum versions."

So, will I need to recompile the image with the debugging image features allowed? Well, before that, I did find similar issues on forums posted as early as 2019 through 2024, but those were using slightly different Yocto versions. I think my password is effectively in a "locked state" as the 2019 post suggests, since I baked an image without having a way to edit the config file, which is now in binary. So I probably will try this some other time. At least I learned something: create more trust in the world, since there is no need to mandate passwords. :) 

I haven't uploaded the 3.2GB file yet of the 6 hr video yet, but I did record an earlier video of me installing Yocto on Rocky:

https://youtu.be/lGz8M_6JwDU (it's not the full installation- there is a break near the end as I figure out how to source the buildtools and poky environment sdk setup- the correct/final instruction for sourcing the path that I downloaded it to can be seen at the top of the terminal in the first image of this post)

I used GPU Screen Recorder and installed the h.265 hardware encoder for my AMD GPU (a non-free plugin). VLC was able to play it.

Here is also a screenshot of the manifest:

 

Knowing I can build an image, it's more about deciding what I don't need:

From the ELCE presentations, it shows how one can remove a lot more:

 

What I'd like to see: 

DISTRO_FEATURES:remove = "acl alsa bluetooth debuginfod ipv6 pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc vfat seccomp systemd usrmerge pulseaudio gobject-introspection-data ldconfig" ;)