I've found various answers to this. The correct answer appears to be in tmp/work-shared/<machine>/kernel-source, but I didn't even have this directory, after doing a working build of core-image-minima

Thanks for the advice. I decided to try wic, since that's actually the x86 default if you don't set IMAGE_FSTYPES. It also looks cleaner than hddimg, since it has a real ext4 partition and no loop mou

Yocto Gatesgarth, using meta-intel to build core-image-minimal Intel D2700MUD mini-ITX mobo with D2700 Atom Ordinary USB 2.0 flash drive I followed the instructions in the meta-intel README, and had n

/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/sys/cdefs.h:453 /opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/features.h:465, /opt/poky/3.2.1/i64/sysroots/core2-64-poky-lin

I've been resurrecting an old Pyro project under Gatesgarth. It's an Intel 32-bit system that needs maximum speed, so I decided to try to build the system and application as 64-bit, for more registers

Using Yocto 3.2.1 on an Intel target, trying to use the x32 model. I'm getting this compile error when I use the SDK to separately compile my application. I get no such errors when I build Linux, or t

I'm upgrading a project from Pyro to Gatesgarth. Building the toolchain, it barfs on a patch which isn't needed. Here's one of the error messages: ERROR: binutils-native-2.35-r0 do_patch: Command Erro

I don't have tune2fs on my embedded system, so I can't check, but that sounds like the probable reason. The nanoseconds that ext4 added are in the upper 128 bytes of a 256 byte inode, for compatibilit

I just noticed that I'm getting one-second resolution on all my timestamps. This is for both ext4 and vfat partitions, and shows up in ls --full-time and the stat command. What could account for this?

A two-letter answer is too cryptic. He's not just asking what the variable name is, he's asking where the file is that contains the variable.

I can vouch for this. I've been using meta-raspi-light for a while on an RPi3, doing music synthesis, and pushing all four cores to about 90% utilization, running the OS "in the cracks", and it's been

I had a feeling I was doing something dumb. Thanks.

mitdiff_plain;h=> 39865a7f420ab4ca4dec6ed27339618a5d5dc366;hp=fe22022617a7122491aa83c893a10a8d861cde73 That didn't change anything. (Pyro is using 2.28, BTW.) The crosssdk recipe is built in x86_64-li

Yocto's Bugzilla isn't recognizing my password, and when it says that it's emailed me a password change message, it doesn't show up. However, the four small patches are in the Sourceware binutils-gdb

I found a bug in the GNU assembler that makes it produce corrupted listings, reported it on sourceware bugzilla, and it has been fixed. Now I'd like to take those small patches and apply them to the a

Apparently, the meta-raspberrypi layer does not employ the Yocto method of modifying the kernel configuration through config fragments. Instead, it uses a kernel_configure_variable function called fro

(Yocto Pyro, using systemd configured with resolved, networkd, timedated, timesyncd) /etc/resolv.conf is supposed to be symlinked to /run/systemd/resolve/resolv.conf, which gets updated with the DNS a

I thought this was a morty->pyro upgrade issue, but trying morty again, on a freshly installed Ubuntu system, didn't change anything. In meta/classes/patch.bbclass, patch_do_patch() is barfing when it

Nuking sstate-cache didn't change anything. I've attached the full console output from my x86 build. My RPi build produces similar errors. This is on a freshly installed Ubuntu 16.04 system. I install

I just upgraded to Pyro, and now I get several Python errors in sstate_sign_package(), complaining there is no module named oe.gpg_sign. I reused the Morty sstate-cache. Is that legal, or do I need to