Re: [yocto] One second timestamp resolution?
> From: Jussi Kukkonen [mailto:j...@goto.fi] > > I think file timestamp resolution on ext4 is one of the things that > depend on inode size (ext4 does not enforce reasonable values because > of compatibility with earlier versions I guess). So maybe check inode > size (should be 256 bytes I think?). 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 compatibility reasons, so somehow I must have ext4 configured to use 128 byte inodes. Where would this be configured in a Yocto build? I'm still on Pyro. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] One second timestamp resolution?
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? My uname -a output is "Linux CHROMA1 4.10.17-yocto-preempt-rt #1 SMP PREEMPT Wed Oct 11 12:33:54 PDT 2017 i686 i686 i386 GNU/Linux" if that's any help. Also, my ext4 mount options are "rw,noatime,nodiratime,data=ordered". -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Confusion about U-Boot setup
> From: Belisko Marek > > BR, 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. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran > > <sherifomran2...@gmail.com> wrote: > > > > any body tried the real time kernel? I get an error, it > > is snot in the compatibility list. > > From: Andreas Müller > > Good news: I use RT kernel only together with VC4 graphics > and have lots of fun on PI2/3. > > Bad news: As far as I know it is not in meta-raspberrypi but > in my fork [1]. There were attempts to land the RT-patches in > meta-raspberrypi but that was denied for huge patch size :( 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 solid. Thanks, Andreas. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch binutils for the SDK
> From: John Ernberg > > Looks like you're overriding SRC_URI instead of appending it. I had a feeling I was doing something dumb. Thanks. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch binutils for the SDK
> From: Khem Raj [mailto:raj.k...@gmail.com] > > you can just make 1 patch download > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=com mitdiff_plain;h=> 39865a7f420ab4ca4dec6ed27339618a5d5dc366;hp=fe22022617a7122491aa83c893a10a8d861cde73 > > and delete the hunk which contains changeslog entry and rest > should apply > cleanly. And add it to SRC_URI in binutils-2.29.inc That didn't change anything. (Pyro is using 2.28, BTW.) The crosssdk recipe is built in x86_64-linux/binutils-crosssdk-x86_64-pokysdk-linux/2.28-r0/git. All I see in there are a couple of quilt directories containing my patch files, no source files. So I decided to run a devshell. Since that doesn't happen until after the patches are supplied, that failed, too. So I removed the .bbappend and ran the devshell. There they were, a half-bazillion nice source files, including the gas directory. So I put the .bbappend back and ran the devshell again, and the first thing it did was clean that directory, after which the patches failed again. I have no clue how this build system works. Is the source directory supposed to be where the files are patched? What cleans the source directory? I notice that after any build, there never seem to be any source files hanging around. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch binutils for the SDK
> From: Khem Raj [mailto:raj.k...@gmail.com]
>
> You can apply the patch to all binutils variants, its fine.
> Send a patch or if you
> want, file a ticket in bugzilla and we will take care.
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 GIT repo, at the
link I mentioned:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
a4dec6ed27339618a5d5dc366
Just to verify, my binutils-crosssdk_%.bbappend file contains:
FILESEXTRAPATHS_prepend := "${THISDIR}/binutils:"
SRC_URI = " \
file://gas_as.h.patch \
file://gas_ChangeLog.patch \
file://gas_input-scrub.c.patch \
file://gas_listing.c.patch \
"
and the patches from that Bugzilla page are in a binutils directory. The
errors I get indicate that the patches are being attempted, but aren't
matching up with any source files.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How do I patch binutils for the SDK
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 assembler that winds up in the SDK. The patches are shown here: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c a4dec6ed27339618a5d5dc366 The only recipe I found in Pyro that seemed appropriate was meta/recipes-devtools/binutils/binutils-crosssdk_2.28.bb, so I created a binutils-crosssdk_%.bbappend in my layer with a FILESEXTRAPATHS_prepend and a SRC_URI listing the patches, which I put into a binutils subdirectory. When I ran the populate_sdk task, the patches failed because they didn't find the source files, which are supposed to be in a subdirectory called gas. So I'm wondering, is this the wrong recipe? Does something else build gas? Or am I just doing this wrong? The workings of the build system are pretty opaque and mysterious. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Setting kernel CONFIG variables in the RPi
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 from within a do_configure_prepend function in recipes-kernel/linux/linux-rpi.inc. The question is this: if the defconfig that comes with the kernel includes one value, but linux-rpi.inc overrides it to another value in do_configure_prepend, but I want the original value, how can I override it again in a .bbappend in my own layer? I can't use do_configure_prepend, because it would be defining a function already defined in the .bb file, right? Or if I could do that, wouldn't I be prepending it before what's prepended in the .bb file, so my change would play first, and then be undone by the .bb file? What's the solution? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Missing /etc/resolv.conf
(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 address received from DHCP, but it's not. Looking through systemd_232.bb, I see that do_install() uses sed to edit /usr/lib/tmpfiles.d/etc.conf to set up this link. When I run the system, I see that etc.conf does indeed have this edited line, but there is no /etc/resolv.conf. systemd-tmpfiles-setup.service runs successfully. Isn't that what's supposed to execute all the junk in /usr/lib/tmpfiles.d? All the abovementioned servers are running. Am I missing something? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can't find Python oe package
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 tries to import oe.patch. I carefully reinstalled poky, meta-intel, and meta-openembedded from git, and I get this error, and a bunch more related to the oe package. The package is there, in poky/meta/lib/oe, so why isn't it being found? Am I supposed to have a non-empty PYTHONPATH somehow? What kind of misconfiguration could cause this? This worked on morty before I had to do a fresh Ubuntu install, so I doubt it's anything in my own simple layers. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Morty to Pyro upgrade
> From: Khem Raj [mailto:raj.k...@gmail.com]
>
> On Thu, Sep 14, 2017 at 11:15 PM, Paul D. DeRocco
> <pdero...@ix.netcom.com> wrote:
> > 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 nuke it and start over?
>
> its too optimistic to use sstate across releases and I dont
> think abi is guaranteed
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 installed Pyro from git,
added meta-intel pyro branch from git, and added meta-openembedded pyro branch
from their git. So everything should be current.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
pauld@BUILD:~/yocto-pyro/buildchr32$ bitbake -k core-image-chroma
NOTE: Started PRServer with DBfile:
/home/pauld/yocto-pyro/buildchr32/cache/prserv.sqlite3, IP: 127.0.0.1, PORT:
35827, PID: 30575
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry runqemu: file not
found except in DL_DIR
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry
runqemu-addptable2image: file not found except in DL_DIR
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry runqemu-gen-tapdevs:
file not found except in DL_DIR
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry runqemu-ifup: file not
found except in DL_DIR
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry runqemu-ifdown: file
not found except in DL_DIR
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry
oe-find-native-sysroot: file not found except in DL_DIR
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry runqemu-extract-sdk:
file not found except in DL_DIR
WARNING: ../poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb:
Getting checksum for nativesdk-qemu-helper SRC_URI entry runqemu-export-rootfs:
file not found except in DL_DIR
Parsing recipes: 100% |##| Time: 0:00:49
Parsing of 1893 .bb files complete (0 cached, 1893 parsed). 2645 targets, 141
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-16.04"
TARGET_SYS= "i686-poky-linux"
MACHINE = "chroma32-bsp"
DISTRO= "poky"
DISTRO_VERSION= "2.3.2"
TUNE_FEATURES = "m32 core2"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= "pyro:072430b9b3a78b318b66371c36e2986d2ed5cba4"
meta-intel= "pyro:16aea09d224f3ed2021623d17c3e807f4b8ff18d"
meta-networking
meta-oe
meta-python = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
meta-chroma32-bsp
meta-chroma = "pyro:072430b9b3a78b318b66371c36e2986d2ed5cba4"
Initialising tasks: 100% |###| Time: 0:00:05
NOTE: Executing SetScene Tasks
ERROR: packagegroup-core-ssh-openssh-1.0-r1 do_populate_lic_setscene: Error
executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
*** 0002:uninative_changeinterp(d)
0003:
File: '/home/pauld/yocto-pyro/poky/meta/classes/uninative.bbclass', lineno:
109, function: uninative_changeinterp
0105:
0106:python uninative_changeinterp () {
0107:import subprocess
0108:import stat
*** 0109:import oe.qa
0110:
0111:if not (bb.data.inherits_class('native', d) or
bb.data.inherits_class('crosssdk', d) or bb.data.inherits_class('cross', d)):
0112:return
0113:
Exception: ImportError: No module named 'oe.qa'
WARNING: Logfile for failed setscene task is
/home/pauld/yocto-pyro/buildchr32/tmp/work/all-poky-linux/packagegroup-core-ssh-openssh/1.0-r1/temp/log.do_populate_lic_setscene.30703
WARNING: Setscene task
(../poky/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb:do_populate_lic_setscene)
failed with exit code '1' - real task wil
[yocto] Morty to Pyro upgrade
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 nuke it and start over? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best practices when for script recipes.
> From: Einar Vading > > If I have one or a few shell scripts with their own recipe. Do I make > a git and use the git from the recipe or do I just add the scripts to > a files directory and install from there? A recipe should fetch from something other than a files directory accompanying the recipe if it's large, and you don't want every user of the layer containing that recipe to have it unless they specifically include that package. Even then, it only needs to be a git repo if you want it under version control--FTP is also a valid source. But in your case, what the recipe needs is tiny, so there's no reason not to include it with the recipe in a files directory. That's a completely routine thing to do. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Keeping same IP address under DHCP
Whenever I build a new version of my target system, the DHCP server in my router thinks it's a new machine, and assigns it a new IP address. This means that I have to edit the connection settings in Eclipse remote debugging. What is changing in my system that makes that happen, and is there any way, short of assigning a static IP address, to make the router continue to recognize it as the same machine? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Eclipse Target Communication Framework prevents shutdown
I'm using TCF on a Raspberry Pi and on an Intel Atom, for remote target debugging with Eclipse Mars. It works fine, except for one thing: if I have to reboot the target, it puts up a message that says that "A stop job is running for Target Communication Framework", and it takes a minute and a half to time out. How do I get TCF to respond to the usual kill signal on shutdown, or have a more reasonable timeout like five seconds? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build RPi without wireless?
How do I build a Raspberry Pi image without WiFi or Bluetooth, or any of the related utilities? There seem to be lots of packages involved in this, and I can't figure out what's pulling them in in the first place. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto plug-in not running cmake
Yocto 2.2.1, standard SDK for RPi, Yocto plug-in for Eclipse Mars I do File -> New -> C Project, give it a name, select Project Type -> Yocto Project SDK CMake Project -> Hello World C CMake Project, click Finish, and it creates a project. I click the build button, and it runs "make all" and complains "make: *** No rule to make target 'all'. Stop." Why is it running make and not cmake? It's hard to imagine that I made a mistake somewhere in those two steps. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remote Eclipse debug setup
> From: Paul D. DeRocco > > I'm trying to get remote Eclipse debugging working, between > Yocto Morty and Eclipse Mars. This is for an RPi3 using > systemd. I'm only trying to debug an application separately > compiled with the Yocto SDK toolchain, not to debug anything > in the Linux build. > > In my local.conf, I first set EXTRA_IMAGE_FEATURES to > "debug-tweaks eclipse-debug", but it didn't give me the > necessary SSH daemon, so I added "ssh-server-openssh" as > well, but nothing is starting it. The only related systemd > unit is sshd.socket. > > What is supposed to start sshd, so that Eclipse debugging can > work? And is there any other daemon I have to get running in > the target? The Yocto mega-manual didn't really spell it all out. I'm getting nowhere on this. Is there some documentation that explains how remote debugging from the Yocto plugin works, so that I can maybe figure out what's going wrong? I'm not getting an SSH connection, and there's no sshd running in the target. All the tutorials, including the Yocto docs and various other vendors' explanations, tell you what to do and assume that it will all work, but don't provide any clue as to what to do when it doesn't work. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Remote Eclipse debug setup
I'm trying to get remote Eclipse debugging working, between Yocto Morty and Eclipse Mars. This is for an RPi3 using systemd. I'm only trying to debug an application separately compiled with the Yocto SDK toolchain, not to debug anything in the Linux build. In my local.conf, I first set EXTRA_IMAGE_FEATURES to "debug-tweaks eclipse-debug", but it didn't give me the necessary SSH daemon, so I added "ssh-server-openssh" as well, but nothing is starting it. The only related systemd unit is sshd.socket. What is supposed to start sshd, so that Eclipse debugging can work? And is there any other daemon I have to get running in the target? The Yocto mega-manual didn't really spell it all out. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPi app built with SDK won't load
I incorporated all the relevant symbols from
environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi. I defined the
compilation command as ${CC} ${CFLAGS} and the linker command as ${LD}
${LDFLAGS}. Other Eclipse settings added -O3 -Wall -c to the compile, and -s to
the link.
When I did the build, the compile succeeded, but the link complained about
"-Wl,-O1" as an unrecognized option. I first tried eliminating the "-Wl,"
prefixes, but that gave me a "cannot find entry symbol _start" error. I put the
"-Wl," prefixes back, but changed the link command from
arm-poky-linux-gnueabi-ld to arm-poky-linux-gnueabi-gcc, and it linked okay,
but gave me the same runtime error I've been struggling with.
However, Lukasz put his finger on the problem when he wrote
> From: Lukasz Tekieli [mailto:tekieli.luk...@gmail.com]
>
> it seems that if linker is called without -mfloat-abi=hard
> then the ld is set to /lib/ld-linux.so.3 instead of
> /lib/ld-linux-armhf.so.3 which is the correct one.
It turns out the correct way to run the linker is $CC $CFLAGS $LDFLAGS, not $LD
$LDFLAGS.
The reason this escaped me for all this time is that I was using
arm-poky-linux-gnueabi-objdump -x on the executable, and grepping for NEEDED to
find out what shared libraries were needed. The actual loader isn't listed in
this way. Using the -s option showed that the .interp section contained the
string /lib/ld-linux.so.3. Now it correctly shows /lib/ld-linux-armhf.so.3.
Thanks to all who looked into this for me.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPi app built with SDK won't load
> From: Andrea Galbusera [mailto:giz...@gmail.com]
>
> Could you please post the exact source code of your test
> program and the steps you take to (a) build the SDK and (b)
> build your test executable? Is your running image a pretty
> standard one (core-image-minimal, rpi-test-image or so) or do
> your own with custom features?
It did have some custom features, so I did a plain build of core-image-minimal
using raspberrypi3 as the MACHINE. I also did a populate_sdk for it, and
installed the SDK in /opt/poky/2.2.1-a32 by running the install script.
The test program test.c is just "int main(void) { return 0; }". I normally use
Eclipse CDT to compile native programs, so I set up a cross project using the
SDK, which involves a few manual settings, including telling it the tools are
in /opt/poky/2.2.1-a32/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux,
and adding a --sysroot to the command lines. The compiler command line came out
as:
arm-poky-linux-gcc
--sysroot=/opt/poky/2.2.1-a32/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi
-O3 -Wall -c -mfloat-abi=hard -MMD -MP -MF"test.d" -MT"test.o" -o "test.o"
"../test.c"
(without the line breaks). I had to add "-mfloat-abi-hard" to get it to link.
The link command line was:
arm-poky-linux-gcc
--sysroot=/opt/poky/2.2.1-a32/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi
-s -o "test" ./test.o
(again, without the line breaks). After dd-ing the image to my SD card, I
mounted it and manually copied the "test" program into its rootfs. When I stuck
it in the RPi3 and ran it, I got
-sh: ./test: not found
The shell in this case is busybox, so the error message is slightly different
from bash.
I rechecked everything I had described before, analyzing the executable and
comparing it to some working executable from the rootfs. There must be
SOMETHING in my executable that the loader is barfing on, after it's
successfully opened the file but before it starts looking for libraries. But
it's an awfully small executable, so it's hard to imaging where that something
is hiding.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] RPi app built with SDK won't load
I posted about this a week or so ago, but have narrowed things down further. I built a 32-bit non-GUI RPi image which works, built the corresponding SDK, and used the SDK's toolchain to build an empty C program (just "return 0;" inside main). When I run it on the target, the shell complains: -sh: ./test: No such file or directory If I run "ldd test", it dies with the same error, without even getting far enough to trace the search for libc, the only referenced library. (Yes, the x attribute is set.) On my host system, I ran arm-poky-linux-objdump -x on the test program, and then ran it on the version of chmod.coreutils from the rootfs of the build (because it was the smallest executable in /bin). The only differences were that chmod referenced a couple more libraries, the section addresses and sizes were of course different, test had a small .comment section listing the compiler used, and chmod had a .gnu_debuglink section. All attributes were the same, even the contents of the .ARM.attributes section. Yet despite this, chmod runs fine, but test doesn't. What else could possibly return an ENOENT error code to the shell so early in the load process? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do you remove an IMAGEFS?
> From: Patrick Ohly [mailto:patrick.o...@intel.com] > > On Fri, 2017-06-23 at 16:21 -0700, Paul D. DeRocco wrote: > > x86-base.inc adds "live" to IMAGE_FSTYPES. I have no need for a live > > image, or an iso, so I thought adding IMAGE_FSTYPES_remove > > = "live iso" to > > my image recipe might work, but it complained in do_bootimg > > that my recipe > > "depends upon non-existent task do_image_ext4". On a hunch, > > I movved the > > IMAGE_FSTYPES_remove to before inheriting core-image, > > That's the only feasible approach at the moment. IMAGE_FSTYPES gets > checked while inheriting the class and then triggers inheriting > image-live.bbclass even when the "live" type gets removed later one. > > There's a patch for x86-base.inc which removes this unconditional > extension of IMAGE_FSTYPES, see "[OE-core] [PATCH] x86-base.inc: Don't > add live to IMAGE_FSTYPES, default instead". > > > and then it didn't > > complain, but it didn't build ANY images. > > You still need to set some kind of IMAGE_FSTYPES, for example "wic". Yes, that's what I ended up doing, so it's nice to know I'm on the right track. However, when I explicitly added "hddimg", I found that Syslinux was still configured for live image, with "boot" and "install" menu options. I found some code in image.bbclass that looks like it forces "image-live" if either "iso" or "hddimg" is included. I can of course hide that by setting various Syslinux options, but how do I get a plain hddimg that just boots up and runs, without any support for an "install" option in the kernel? Is that normally done with "wic" and a minimal .wks script? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Current state of linux-raspberrypi-rt?
> From: Trevor Woerner [mailto:twoer...@gmail.com] > > > Google turns up a lot of stuff about this, but the latest I > > found was a > > thread from 1/5/17 that started with Trevor Woerner posting > > a 1MB patch, > > and that ended with him posting a message saying that it > > didn't actually work. > > I posted a v1, which worked great, and continues to work great. > > After posting the v1, lots of feedback was given. One of those pieces > of feedback was that I shouldn't include the entire defconfig, but > rather I should use some sort of "savedconfig" setting to generate the > full config. I had never heard of this before. I asked for more > clarification but received none. I went ahead with the v2 using this > "savedconfig" technique. It *appeared* to work (which is why I > submitted the update to the mailing list), but, after a lot of > testing, I discovered that this "savedconfig" thing didn't work. The > defconfig that was generated using this technique was useless and > nobody could provide any reason why or advice how to fix it. > > So v2 didn't work, but v1 did and still does (we're using it > internally). > > But everyone considered v1 to not be acceptable for inclusion for a > number of reasons, so it never got merged. Besides, that work was for > a 4.4 kernel, which is now considered "old". > > > Is there anything new on this? I'm trying to do some > > compute-intensive > > audio on an RPi3, and it really needs a real-time kernel. > > Andreas Müller has a meta-raspberrypi fork in which he has an -rt > recipe for a 4.9 kernel: > https://github.com/schnitzeltony/meta-raspi-light Thanks to you and Andreas for doing this. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Current state of linux-raspberrypi-rt?
Google turns up a lot of stuff about this, but the latest I found was a thread from 1/5/17 that started with Trevor Woerner posting a 1MB patch, and that ended with him posting a message saying that it didn't actually work. Is there anything new on this? I'm trying to do some compute-intensive audio on an RPi3, and it really needs a real-time kernel. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How do you remove an IMAGEFS?
x86-base.inc adds "live" to IMAGE_FSTYPES. I have no need for a live image, or an iso, so I thought adding IMAGE_FSTYPES_remove = "live iso" to my image recipe might work, but it complained in do_bootimg that my recipe "depends upon non-existent task do_image_ext4". On a hunch, I movved the IMAGE_FSTYPES_remove to before inheriting core-image, and then it didn't complain, but it didn't build ANY images. So what's the right way to suppress live image and iso image generation, where those things are included in some stock config file somewhere? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Any ideas why my RPi app won't load?
I've built a custom 32-bit non-GUI Raspberry Pi image, built the corresponding SDK, and used the SDK's toolchain to build an app. When I run the app on the RPi, from a command prompt as root, the shell complains: -sh: /path/to/app: No such file or directory (with the real app name, obviously). sh is linked to bash. Here's what I've checked: 1) The app exists, and is the correct executable. 2) Its execute permission bit is set. 3) Its ELF file format is the same as the ELF file format of every other command in the system. 4) The shared libraries it uses all exist, recursively, in /lib or /usr/lib. They are all listed by ldconfig -p. 5) There is no LD_LIBRARY_PATH variable. 6) If I run the app with LL_DEBUG=all, I get the same error, so it isn't even getting as far as loading libraries. (Or perhaps LL_DEBUG isn't supported on this build.) Googling didn't turn up any other possibilities. Has anyone seen any other reasons for this error? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Raspberry Pi: how do I change cmdline.txt?
I found cmdline.txt in a folder called bcm2835-bootfiles, so I thought this was related to the bcm2835-bootfiles.bb recipe. I created my own cmdline.txt and a .bbappend saying where I put it, but it didn't work. Looking at the recipe, it doesn't mention cmdline.txt. What recipe deals with that file? I'm just trying to specify tty1 as the console. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is linux-yocto-rt kernel compatible with x32 tune?
> From: Andre McCurdy [mailto:armccu...@gmail.com]
>
> Isn't the point of x32 that the kernel should be full 64bit (and so
> able to directly address all memory) and only user space should be
> restricted to 32bit pointers?
>
> If so, then the kernel ELF architecture x86-64 seems correct. If that
> kernel can't run x32 user space binaries then maybe the kernel config
> option to enable support for x32 user space is somehow missing?
You're probably right, although I never saw any docs that spelled that out.
That would explain why there are libx32 directories. I was hoping that x32 just
meant that everything was compiled with a single architecture, just like a
32-bit processor, just using 64-bit mode for the larger register set, and
32-bit pointers everywhere. No need for any multi-arch logic. That would seem
to be desirable for a modest sized embedded system. But if it still produces a
64-bit kernel, I can live with that, as long as I can get it to work.
> From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
>
> I can't think of a reason off the top of my head that would
> prevent this from working at the kernel level.
>
> But can you confirm that a non-rt build for the same board works with
> x32 ? It could just be a kernel configuration issue if it
> does work with
> non-rt, since the -rt variant may not have a BSP entry point defined.
I did more thorough testing, doing six core-image-minimal builds: 32, 32rt, 64,
64rt, 64x32, and 64x32rt. All the non-rt ones and the 64rt one work. The 32rt
and 64x32rt both panic loading init.
I'm not sure if I'm specifying the rt kernel properly. My 32-bit local.conf
includes
MACHINE = "genericx86"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
PREFERRED_VERSION_linux-yocto-rt ?= "4.8%"
and my 64-bit x32 local.conf includes
MACHINE = "genericx86-64"
DEFAULTTUNE = "core2-64-x32"
baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
or 'INVALID'), True) or 'lib'}"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
PREFERRED_VERSION_linux-yocto-rt ?= "4.8%"
I have a tiny layer that just includes a linux-yocto-rt_4.8.bbappend:
COMPATIBLE_MACHINE = "genericx86|genericx86-64"
KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", \
"mx32", " cfg/x32.scc", "" ,d)}"
and a non-rt one just specifying COMPATIBLE_MACHINE. I copied that last line
from the linux-yocto_4.8.bb file, because it's not in the rt recipe. The .scc
file pulls in a .cfg file which turns on CONFIG_X86_X32 and CONFIG_COMPAT.
Yet the problem isn't with x32, it's that it can't run 32-bit binaries, even in
a plain 32-bit kernel. So what am I leaving out, in my effort to specify the rt
kernel?
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Is linux-yocto-rt kernel compatible with x32 tune?
I've been fighting with this off and on for a week. If I build core-image-minimal for a generic86-64 machine, I can get it to use the x32 ABI, or I can switch to the linux-yocto-rt 4.8 kernel, but I can't do both. If I do both, it builds with no complaint other than a lot of bit size errors in grub-efi do_package_qa (which don't seem to matter with the standard kernel). Most binaries, including loadable kernel modules, are properly built as ELF architecture i386:x64-32, but the kernel itself is built as i386:x86-64. The result is an immediate kernel panic trying to run init, because the kernel doesn't know how to load it. I understand that not all packages have been updated to work with x32, but the RT kernel? Is this a combination that is known not to work? If it is expected to work, am I the first person to try to boot it on actual hardware? I'd like to know either that this simply won't work, so I can stop wasting time on it, or get some help diagnosing the problem and fixing it. I'm stumped. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image lacks libraries needed by SDK
> From: Maxin B. John [mailto:maxin.j...@intel.com] > > Had a similar experience with respect to the availability of > static libraries in the SDK. > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=5347 > > One way to fix this will be to include required static > libraries in the image > before building SDK - eg: for glibc static development libraries: > > IMAGE_INSTALL_append = " glibc-staticdev" Does that include the .a files in the image or the SDK or both? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image lacks libraries needed by SDK
> From: Andre McCurdy [mailto:armccu...@gmail.com] > > > I noticed that when I built an SDK under > > core-image-minimal, it didn't include libasound, but that > > was included > > when I built it under my own image which includes ALSA. So > > it's obviously > > paying attention to what's in the image. So is there some > > package I need > > to include in my image to complete the set of libraries to > > match what's in > > the SDK? > > Not directly. You could add packagegroup-core-standalone-sdk-target to > the image, but then you'd get the corresponding -dev packages too > (header files, etc). Your best bet may be to add libstdc++ plus any > other individual packages to the image as you find you need them. That was pretty painless. It turned out that was the only missing library. Thanks. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Image lacks libraries needed by SDK
I have a working system image for my 32-bit Atom-based hardware, based on Morty. My application is a C++ program that runs as a systemd service. I've always built the application outside Yocto, using the Eclipse CDT and whatever GCC was on my Ubuntu system. It gets installed into my hardware on a separate partition, but runs fine because my build host and target are both x86 machines. In order to try out the much more recent compiler in the Yocto SDK (and to prepare for converting to a different architecture in the future), I built a standard SDK by using do_populate_sdk on my image. I managed to modify my project to use the toolchain and libraries in the sysroot in the SDK, and it successfully produces an executable. But when I copy this into my system, it barfs because there is no libstdc++.o (and perhaps other libraries) on my system. And there is no libstdc++.a in the SDK. Why would the SDK, built against a particular image, not include the same shared libraries as that image? I noticed that when I built an SDK under core-image-minimal, it didn't include libasound, but that was included when I built it under my own image which includes ALSA. So it's obviously paying attention to what's in the image. So is there some package I need to include in my image to complete the set of libraries to match what's in the SDK? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] First attempt at x32 system: kernel panic
I'm still struggling with getting a system running with the x32 tune. I won't bother quoting my previous message, which didn't prompt any suggestions anyway, since I have a clearer scenario to describe. I built four systems (all with Morty): 1) I built core-image-minimal on a genericx86-64 machine, and it booted fine. 2) I built a core-image-minimal with an x32 tune, and it spewed out a ton of nonfatal bit size errors in grub-efi do_package_qa, but it booted fine. 3) I built a core-image-minimal with a realtime kernel (4.8), and got a bunch of warning messages about inapplicable kernel config items that were left out (all related to other architectures). When I booted it, the boot process hung fairly early on, following "clocksource: Switched to clocksource tsc", although I rather doubt there's anything wrong with the TSC. There's also a "Waiting for removable media..." message a bit earlier, which could be a clue. 4) I built a core-image-minimal with an x32 tune and a realtime kernel, and got the grub errors plus the config warnings. When I booted it, I got an immedate kernel panic, because it was unable to run init. The problem is that the kernel compilation ignored the x32 tune, and builds a regular 64-bit rt kernel, while everything else (executables, shared libraries, and loadable kernel modules) are 64-x32. So the big question is this: is the x32 tune not supported on yocto-kernel-rt 4.8? Or is this just some bug in the recipe, and I'm just the first person to try running this combination? The second smaller question is: am I selecting the rt kernel properly? I put the following in my local.conf: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt" PREFERRED_VERSION_linux-yocto-rt ?= "4.8%" Then, I created a layer (included in bblayers.conf) that contained nothing but a linux-yocto-rt_4.8.bbappend file containing COMPATIBLE_MACHINE = "genericx86-64" Is this the right way to select an rt kernel for a machine that isn't listed in the actual recipe (it only lists qemu* machines), or is there a way to do this entirely from local.conf? The third possibly unimportant question is: what can I do to get rid of the grub errors and the config warnings? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] First attempt at x32 system: kernel panic
I took a functioning 32-bit x86 system built with Morty and successfully converted it to 64-bit. Builds and runs fine. Next, I tried applying the x32 tune, as described in the Yocto manual. I created another BSP layer, changed all the names accordingly, set CONFIG_64BIT=y and CONFIG_X86_X32=y in one of my .cfg files, set DEFAULTTUNE to "core2-64-x32", and set baselib to the expression documented in the Yocto manual (which boils down to "libx32"). It builds without complaint, but when I run it, I get a kernel panic almost immediately. The problem is that the kernel is being compiled as regular 64-bit code while everything else is using the x32 tune as it should. The init program is symlinked to systemd, which objdump shows as having an architecture of i386:x64-32, while various object modules used to build the kernel show i386:x86-64. Everything in /lib seems to be x64-32 except for the .ko files in /lib/modules. I thought perhaps the problem was that one of my .scc files specifies KARCH as x86_64, which I used because "yocto-bsp list karch" only lists that and i386 for this CPU. I guessed that there might be an x64_32 choice, and tried that, but it went ahead and built an x86_64 kernel again without complaint. I also tried removing CONFIG_64BIT=y, with the same result. So why am I getting a 64-bit kernel without the x32 tune? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config fragments ignored
> From: Paul D. DeRocco > > I ported a working build from Fido to Morty, made a few > tweaks in response > to error messages (mostly updating version numbers), but it's > not finding > my kernel configuration fragments. This is supposed to be an i386 arch > system, but it insists upon building an x86_64 kernel. The > .config file it > generates does not include my configuration fragments, which contain > things like CONFIG_64BIT=n and CONFIG_X86_32=y. I'm still stumped by this, but I've debugged it further. My top level chroma32-bsp-preempt-rt.scc file contains (among other things) the line include ktypes/preempt-rt/preempt-rt.scc nopatch Building the kernel copies the following files into tmp/work/chroma32_bsp-poky-linux/linux-yocto-rt/4.8.12+blahblah chroma32-bsp-user-config.cfg chroma32-bsp-user-features.scc (empty) but it doesn't copy the following files anywhere chroma32-bsp-preempt-rt.scc chroma32-bsp.scc chroma32-bsp.cfg so none of the values from either .cfg file appear in the resulting .config file. If I change the above line to include ktypes/standard/standard.scc nopatch then tmp/work/chroma32_bsp-poky-linux/linux-yocto-rt/4.8.12+blahblah contains chroma32-bsp-preempt-rt.scc chroma32-bsp-user-config.cfg chroma32-bsp-user-features.scc (empty) and tmp/work-shared/chroma32-bsp/kernel-source/.kernel-meta/configs/standard contains chroma32-bsp.cfg chroma32-bsp-user-config.cfg and everything in them is included in the .config file. Both the preempt-rt.scc and standard.scc files pull in a lot of stuff, and they are quite different from each other. What difference between the two could account for my config fragments being ignored when I use the first one? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel config fragments ignored
I ported a working build from Fido to Morty, made a few tweaks in response to error messages (mostly updating version numbers), but it's not finding my kernel configuration fragments. This is supposed to be an i386 arch system, but it insists upon building an x86_64 kernel. The .config file it generates does not include my configuration fragments, which contain things like CONFIG_X86_64=n and CONFIG_X86_32=y. My linux-yocto-rt_4.8.bbappend file lists my .cfg and .scc files in SRC_URI, and they are indeed being copied into the build directory (at tmp/work/chroma_bsp-poky-linux/linux-yocto-rt/4.8.12+blahblah). The docs seem to imply that that's all I have to do: that they will automatically be found and included, without my having to name them anywhere else. If I intentionally put a syntax error into any of them, that erroneous file is indeed copied, but nothing ever complains about the error, so it isn't being read when I force a kernel_configme. Even cleaning the kernel and repeating the kernel_configme doesn't change anything. There is one .scc that includes the others, so that suggests that there must be some mechanism for specifying that one and relying on the explicit includes to pull in the rest. Its name is chroma-bsp.scc, which matches my custom machine name specified in local.conf. It was previously called chroma-bsp-preempt-rt.scc under Fido, but when that didn't work under Morty, I tried changing the name, to no avail. Also, I'm puzzled that the work directory name contains "chroma_bsp" instead of "chroma-bsp". What am I missing? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to replace an arch*.inc file?
> > On Sat, May 27, 2017 at 2:34 AM, Paul D. DeRocco > > <pdero...@ix.netcom.com> wrote: > > > > I'd like to try the Linaro version of arch-armv8.inc in > > an RPi3 project, > > because it has an ilp32 tune option. What's the correct > > way to incorporate this? > From: Andrei Gherzan [mailto:and...@gherzan.ro] > > Probably the easiest way would be to create a new machine > configuration. Where is this linaro version of arch-armv8? It's here: <http://git.linaro.org/openembedded/meta-linaro.git/tree/meta-ilp32/conf/machine/include/arm64/arch-armv8.inc> I'm not clear about how the system finds these include files. Is there a way to store this file, or the same file under a different name, somewhere in my own layer? I normally treat the rest of the metadata as read-only. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to replace an arch*.inc file?
I'd like to try the Linaro version of arch-armv8.inc in an RPi3 project, because it has an ilp32 tune option. What's the correct way to incorporate this? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] What can I share between projects?
If I'm doing multiple unrelated Yocto based projects, and they use the same version of Yocto, and the same metadata (except for my own layers), am I right in assuming that I can share everything in poky, downloads, and sstate-cache, and I only need separate build directories? (I normally put downloads and sstate-cache next to my build directory, rather than inside it.) -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trying to understand my boot configuration
I have a simple x86_64 system based on Morty, and I'm trying to understand the way the system boots. The disk image file is a FAT16 parition which I use as the second partition on my SSD, with the boot flag set. (The first partition is a FAT16 partition that contains a bunch of data files and my application.) The boot partition contains a file called rootfs.img, which obviously is my rootfs. GRUB is the boot manager on this 64-bit system, and it puts up a menu of four items that allows me to specify graphics or serial as the console, and either booting or installing. After booting, I see that rootfs.img is loop mounted as the root. My questions are: 1) Is this a "live image" boot? As I understand it, a live image is a system that boots from removable media, and gives the user a choice between copying its rootfs to a RAM disk and running a volatile session from there, or installing the rootfs somewhere. Since I see "install" menu items in GRUB, that suggests that this is a live image. But at runtime the rootfs appears to be on the actual drive, not in RAM, because my command history persists across reboots. 2) Why do I have a FAT partition with a loop mounted root file system, in the first place? Is it possible to boot directly into a plain ext3 partition? I tried using the ext3 partition image as-is, but it hung on boot if I used an MBR, and complained there wasn't a bootable partition if I used a GPT. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Patch failures
I'm trying to migrate an Atom-based build from Fido to Morty, and also switch from 32-bit mode to x32. On a clean build, it gets about half way through, and then suddenly coughs up a patch error. I've put blank lines between the log lines so that the email word wrap won't be as confusing: -- DEBUG: Executing shell function do_patch (1/660) ARM-LPAE-Invalidate-the-TLB-for-module-addresses-dur.patch [INFO]: check of .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod ule-addresses-dur.patch with "git am" did not pass, trying reduced context. [INFO]: Context reduced git-am of .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod ule-addresses-dur.patch with "git am" did not work, trying "apply". error: patch failed: arch/arm/mm/fault.c:448 error: arch/arm/mm/fault.c: patch does not apply [ERROR]: Application of .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate- the-TLB-for-module-addresses-dur.patch failed. Patch needs to be refreshed. Sample resolution script: .git/rebase-apply/resolve_rejects WARNING: /home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux- yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/run.do_patch.3069 0:1 exit 1 from 'kgit-s2q --gen -v --patches .kernel-meta/' ERROR: Function failed: do_patch (log file is located at /home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux- yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/log.do_patch.3069 0) -- If I start bitbake again, it detects a "fence", and proceeds a little further. I can do it over and over again, and it keeps building more and more, but this can't be right, can it? The strange thing is that the patches are all about ARM, PowerPC, etc., which have nothing to do with my system. Could this be some fundamental misconfiguration having to do with my MACHINE? At the beginning of my local.conf, I have: MACHINE ?= "chroma-bsp" DEFAULTTUNE = "core2-64-x32" baselib = "libx32" where chroma-bsp is defined in my own layer. My chroma-bsp.conf file contains (among other things): PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt" PREFERRED_VERSION_linux-yocto-rt ?= "4.8%" require conf/machine/include/tune-atom.inc require conf/machine/include/x86-base.inc I'm not really good at this. Does anyone see anything wrong? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] x86-64 with -mx32 option?
Has anyone successfully used Yocto to build a Linux system for a 64-bit Intel processor using the -mx32 compiler option, forcing all long and pointer types to 32 bits? I've got an embedded system with a gig of RAM and I'd like to have access to the larger register set (especially SSE) of 64-bit mode, but suspect that using 32-bit pointers might speed things up a bit, by saving cache space. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to deal with patch failures due to new source?
All of a sudden, I'm getting massive patch failures in OE's Samba 4 package. (Last night it was fine.) Looking at the main log, the samba-4.1.12-r0 recipe did a do_fetch, do_unpack and do_patch. This is a huge patch, a megabyte in size, applying to 525 files, and it now has 31 failures, because the patch is from last September and wasn't updated. I would think the only way to deal with this, until OE provides a fixed patch, is to go back to the previous source version. The recipe itself didn't change, so how do I do this? Also, is this a normal occurrence in the bitbake world? Is it always possible, any time one does a bitbake, that some new source will appear that breaks something? Is there a way of avoiding this by preventing new source from being fetched, and finding out about its existence perhaps through warning messages? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What's mounting this partition?
> From: Khem Raj [mailto:raj.k...@gmail.com] > > are you installing udev-extraconf into image? IIRC that was > doing it in my cases some time ago. That adds some rules to /etc/udev/rules.d, including automounting. I had that in there for a day or so, because I also need to access an external flash drive sometimes, but it had some insoluble issues, so I took it out again. So none of those rules are present now, nor is the mount.sh script. There are a bunch more rules in /lib/udev/rules.d, but none have anything to do with mounting, as far as I can see. I wish there was a way I could see this mysterious mounting happen. Nothing shows up in dmesg or in journalctl. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] What's mounting this partition?
My x86 system, built with Yocto Fido, boots from /dev/sda2 on a USB flash drive. There's another partition on /dev/sda1 which I wish to mount with a systemd mount unit, or with a line in /etc/fstab. But either way is failing because /dev/sda1 is already mounted on /media/sda1. Lennart over at the systemd list suggested it might be udisks doing this, but I don't see any files matching *udisks* anywhere in my file system, or even in my build tree. An older version of this system, built two years ago with Dylan, doesn't have this problem. Nothing relevant changed in my meta-data, so somewhere else in this gigantic universe something has changed. Does anyone know what bit of software would be responsible for automounting my /dev/sda1 partition, which is not my root file system, and doing so before fstab or systemd mounts are processed? Also, when /dev/sda2 (my root file system) is mounted, it gets certain default options. Is there a way to modify these options? I'd like to include noatime, to avoid needless writes to my flash drive. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Overriding bootimg.bbclass behavior
I've been trying to build an image that boots from a USB flash drive that has no persistence, and I've found that the .iso image serves this purpose reasonably well, if processed by isohybrid (part of the syslinux package). It appears that bootimg.bbclass runs isohybrid on the .iso anyway, but in my case the result doesn't work because it is intended to be written to the entire device, not to a partition. My system uses a second partition to store a small amount of persistent data which is only occasionally updated, so it needs a partition table. isohybrid has a --partok option which produces an .iso image that can be booted from a flash drive partition. My bitbake skills are pretty poor, so I'm not clear on the best way to accomplish this. bootimg.bbclass calls isohybrid near the end of the build_iso function. It seems I have two choices: 1) Modify the build_iso function. Is there a safe way to modify an existing .bbclass, or otherwise override its behavior in a way unforseen by its author? It's incorporated through a long chain of inherits. 2) Do something in my own image recipe after the .iso is built to run isohybrid a second time, with the --partok option, to override what build_iso did. Any advice on this would be appreciated. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [systemd-devel] How to automount
> From: Daniel. [mailto:danielhi...@gmail.com] > > I think that sync just flushes data to disk and umount clears > the dirty bit. There is no sync.vfat that I know. That would seem to make auto-unmount (triggered by removal) an intrinsically unworkable concept. Or is that only the case for FAT file systems? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [systemd-devel] How to automount
> From: Mike Looijmans > > This only serves to remove a mounted directory after > "yanking" the device. It > doesn't really do anything useful though, you'll still get corrupted > filesystems, because Linux is way too lazy in writing out dirty data. > > Proper solution would be to have the system mount a removable > device as > read-only, and promote it to r/w once someone tries to write > to it. And then > after a timeout, it should go back to readonly. > > Supposedly, "autofs" can accomplish this, but I've never met > anyone who got > that to actually work. In my system, the removable drive is used only for backing up or restoring various data files in response to user commands. If I do a sync after each such command, shouldn't that be enough to guarantee the file system doesn't get corrupted when the drive is removed? Will it also ensure the dirty flag is clear, or does that get set anyway? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] X86 live image without persistence?
Under Yocto Fido, is it possible to build a live image that boots from a USB flash drive, but runs entirely out of a ramdisk, and has no persistent storage at all, booting the same clean image each time? I have a separate small partition for the limited amount of persistent storage that I need, and way more RAM than my system needs to run, and it would be nice if nothing were accessing the flash drive at all after bootup, except when my application explicitly does so. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [systemd-devel] How to automount
> From: Mantas Mikulenas [mailto:graw...@gmail.com] > > > I don't think there's any way to have something auto-unmount > > There certainly is - udev has been unmounting unplugged > drives for many years. It's done by default. If creating a udev mount rule automatically does the unmount, then the simplest thing for me would probably be to do that, and have my application do a sync after each user-initiated operation. That way, the drive would remain mounted after the operation, so I could still poke around on it while debugging, yet there would be no corruption when it's removed. Thanks for the tip. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [systemd-devel] How to automount
> From: Daniel. [mailto:danielhi...@gmail.com]
>
> If there is any process using the mount point the umount may
> fail. If you have a bash running in a folder from the mounted
> filesystem is the sufficient to umount fail.
>
> You can use the fuser -m MOUTPOINT to check this. Adding -k
> would kill all process using that mount point.
Now I'm totally confused. Renaming /bin/umount to something else, and then
plugging in the drive, is no longer leaving the successful mount intact. I
saw it do this twice, but it's not doing it any more. I even tried
replacing /bin/umount with a script that ran fuser with the results going
to a file, and it's never being invoked. But the missing /bin/umount does
indeed screw things up, giving me a slew of FAT-fs read errors. It also
leaves /run/media/sdb1 as an empty directory that can't be deleted
("Device or resource busy") even though fuser doesn't show any processes
using it.
This makes no sense. How can this auto-mounting not work? Is it known to
be brittle, or is it believed to be reliable? All I did was include
udev-extraconf in my build.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [systemd-devel] How to automount
> From: Fred Ollinger [mailto:fred.ollin...@seescan.com]
>
> This is in the package: udev-extraconf
>
> On your system look here:
>
> /etc/udev/rules.d/automount.rules
>
> In this file, you'll find the following rules.
>
> The second one auto unmounts.
>
> SUBSYSTEM=="block", ACTION=="add"RUN+="/etc/udev/scripts/mount.sh"
>
> SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
>
> SUBSYSTEM=="block", ACTION=="change",
> ENV{DISK_MEDIA_CHANGE}=="1" RUN+="/etc/udev/scripts/mount.sh"
Well, that started me down a long path. First of all, none of these things
existed because my Yocto build didn't include udev-extraconf. The version
I did two years ago did (although I didn't see it mentioned in my own
metadata), which is why it worked. So I added it back, rebuilt it, and
then tried plugging in a USB flash drive.
The drive appeared as /dev/sdb and /dev/sdb1 (it has a partition table),
The syslog showed the mount.sh script message "Auto-mount of
[/run/media/sdb1] successful", /run/media/sdb1 exists as a directory, but
nothing is mounted there. The next syslog message from FAT-fs said "Volume
was not properly unmounted. Some data may be corrupt. Please run fsck."
When I did that, all I found was that the dirty bit was set, so I
speculated that that caused the mount to somehow be undone.
So I cleaned the dirty bit, synced the file system, unplugged the drive
and plugged it in again. This time the syslog showed the successful mount
message, but no complaint about the drive. Yet it still wasn't mounted.
I can manually mount it, and see its contents. If I then yank the drive,
the mount.sh script doesn't unmount it. I even tweaked the script to log
any attempt to unmount, and it didn't even try.
Whenever I fix the dirty bit, disconnecting and reconnecting logs the
successful mount message, doesn't complain about the dirty bit, but
doesn't mount. Disconnecting again gives me a FAT-fs error "unable to read
boot sector to mark fs as dirty". Connecting again gives me the successful
mount message, and complains about the dirty bit.
Something must be missing here.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [systemd-devel] How to automount
> From: Fred Ollinger [mailto:fred.ollin...@seescan.com] > > You can see what udev thinks it will do for a given drive by using: > > $ udevadm test /sys/block/sdb1 > > Given that your drive is in /sys/block/sdb1 (could be sda1, etc). It's definitely running mount.sh, and the mount succeeds. Yet something is subsequently unmounting it, and it's not the "remove" code at the end of mount.sh. If I rename /bin/umount to something else, then the mount remains intact. Do you or anyone have any ideas on how I might figure out what is invoking "umount" right after the drive is mounted? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Pushbutton poweroff
I'm using Fido to create an Atom-based embedded system using systemd. The last version of this system (based on Dylan) worked fine, but in this one the power button doesn't initiate a poweroff. In the systemd area, I only see two differences: 1) The new poweroff.target includes JobTimeoutSec=30min and JobTimeoutAction=poweroff-force in the [Unit] section. That looks reasonable. 2) The new system has a poweroff.target.wants containing a systemd-update-utmp-runlevel.service. Not sure what this is, but it doesn't smell like the problem. The systemd-poweroff.service is the same in both systems. Starting that service does indeed power the system off. I thought systemd was supposed to replace the ACPI daemon, but acpid is running. Could this be a kernel config issue? The old system used 3.8 and the new one uses 3.14, so their .config files have hundreds of differences. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> From: Khem Raj [mailto:raj.k...@gmail.com] > > Generally when you have systemd which copy images to RAM and then run > from RAM would not want that extra 50 odd Megs gone > for storing extra tools in some case. Do you mean systemd or syslinux? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> From: Bob Cochran > > Do you know offhand how much bigger the rootfs would be if you build > core-image-base without busybox and instead use the real applications? > > Also, how many more packages have to be built / managed? I just added packagegroup-core-full-cmdline to my image, and it increased the size by about 36MB. That's on a 32-bit Intel system. I don't know how many packages are in that group, but all I had to do was add that one word to my IMAGE_INSTALL, so I don't really care. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Hanging during kernel boot
I've been redoing an old Danny project with Fido, running on an Atom mobo. I created a fresh BSP with yocto-bsp, using a RT kernel, and haven't begun to fiddle with the kernel configuration yet. It gets part way through the boot process and hangs at "Switching to clocksource tsc". I've googled this error, which lots of people have had on lots of systems (Ubuntu, etc.), and have solved in lots of different ways, none of which seem to relate to my system. I don't believe it has anything to do with the tsc. The system doesn't crash. I can bang on the keyboard, and the keys are echoed. After seven or so presses, I get a "random: nonblocking pool is initialized" message (something to do with entropy collection, I guess). So the kernel is running, but it's like systemd (which I've substituted for sysvinit) has just hung. Since I haven't gotten to a prompt, I can't do anything. Does anyone have any ideas how I might diagnose this? Are there any kernel parameters I might fiddle with on the flash memory? And where does one do such fiddling, with a syslinux-based live image? Or should I be selectively removing things from my BSP that were put there by yocto-bsp? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > > core-image-full-cmdline (and the packagegroup it uses, > packagegroup-core-full- > cmdline) should give you the former, and the full tools will > in almost all > cases take precedence simply by being installed by virtue of > the alternatives > system. In order to actually remove busybox though you'd need > to break apart > packagegroup-core-boot (i.e. include its constituent parts > separately into > your image instead of the packagegroup itself). That was pretty painless, since I don't actually need to remove busybox. Thanks. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I hate busybox!
> From: Khem Raj [mailto:raj.k...@gmail.com] > > I agree on busybox differences but sometimes its not about > the utilities they are needed for some sundry work. > What would be interesting to know is how much size increase > is caused by replacing all busybox functionality > with other utilities and also RAM consumption. That can give > valuable information for someone who is assembling embedded > system stack and help him/her the decision making. embedded > systems of today might have more memory and what not, but > they are also running more > complex applications than in past, so software bloat has > caught up with more memory, in the end you still need to be > cautious about the footprint and equation remains almost same. As I said in another message, my 32-bit Intel system image increased by 36MB when I added the full utilities. The busybox executable is half a meg, while individual full-featured commands are generally a few tens of kilobytes. I don't know if running busybox loads the whole thing into physical RAM, or if it only allocates the pages that are actually touched; that would determine the relative RAM use, I suppose. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] I hate busybox!
My embedded system has enough room in it for full-featured command line tools, instead of the wretched busybox. Does the Yocto meta-data include a layer that provides such tools? Or does OE? And how would I disable busybox in order to use the better tools? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Warning about auto generated BSP description
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] > > The tool may have created these files, but the question is .. > What release are you using ? If you check something in the kernel meta > directory, I can tell you if the warning is wrong, or something is > really being missed. I'm using Fido. > The reason I asked about the release, is that the location of > the kernel > meta directory will be in a different place between the various > releases. But it is always in the kernel source directory, > whether it is > in work-shared, or in work. So if you head to that directory and look > for either .meta or .kernel-meta, you should see a file > "top_tgt" in that > directory. > > Look at the contents of that file. It should point to those generated > files you referenced above. If it doesn't .. they weren't used, and we > need to figure out why. The file "/home/pauld/yocto-fido/build/tmp/work-shared/chroma-bsp/kernel-source/.me ta/top_tgt" contains "/home/pauld/yocto-fido/build/tmp/work-shared/chroma-bsp/kernel-source/.me ta/cfg/scratch/obj/home/pauld/yocto-fido/meta-chroma-bsp/recipes-kernel/li nux/files/chroma-bsp-preempt-rt.scc". That referenced folder includes a copy of all the .scc and .cfg files I mentioned before. I guess that means that they are in fact being used. Does that mean that this warning message is spurious, and can be ignored? My kernel is hanging during the boot at this point, but I suspect my real problem is elsewhere. Thanks so much for your time helping me to figure this out. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Warning about auto generated BSP description
> From: Robert Calhoun [mailto:rcalh...@shotspotter.com] > > Your kernel recipe needs to have an entry for the machine, > e.g. a kernel recipe called linux-mainline.bb contains > COMPATIBLE_MACHINE_mymachine = "mymachine" > > Also, your machine config file mymachine.conf needs to have a > preferred kernel version, e.g: > PREFERRED_PROVIDER_virtual/kernel ?= "linux-mainline" > PREFERRED_VERSION_linux-yocto ?= "3.19%" > PREFERRED_VERSION_linux-mainline ?= "4.2%" > > > (I am not certain these will fix your error but you should > have them defined.) The linux-yocto-rt_3.14.bbappend file created by the yocto-bsp script includes: COMPATIBLE_MACHINE_chroma_bsp = "chroma_bsp" My bblayers.conf file contains: PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt" The chroma-bsp.conf file created by the script (in meta-chroma-bsp/conf/machine/) includes: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt" PREFERRED_VERSION_linux-yocto-rt ?= "3.14%" I'm not sure if or how the last file is getting read. Since I'm definitely using the RT kernel, I would assume I'd only need references to linux-yocto-rt. See anything wrong? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Warning about auto generated BSP description
I'm getting the following warning: [kernel]: An auto generated BSP description was used, this normally indicates a misconfiguration. Check that your machine (chroma-bsp) has an associated kernel description. Googling turns up the information that this is sometimes a spurious error and nothing to worry about, because a full BSP description isn't strictly required. However, as far as I can see I do indeed have a BSP description. I built the BSP using the yocto-bsp tool. It created a linux-yocto-rt_3.14.bbappend (since I'm using the RT kernel), and the following files: chroma-bsp.cfg chroma-bsp.scc chroma-bsp-preempt-rt.scc chroma-bsp-standard.scc chroma-bsp-tiny.scc chroma-bsp-user-config.cfg chroma-bsp-user-features.scc chroma-bsp-user-patches.scc The bbappend refers to chroma-bsp-preempt-rt.scc and the last three (empty) files. chroma-bsp-preempt-rt.scc contains the requisite KMACHINE, KTYPE and KARCH, and includes chroma-bsp.scc, which refers to chroma-bsp.cfg. This seems to fit the definition of a "BSP description" in 3.4.5 of the Kernel Development Manual. The whole BSP tree is called "meta-chroma-bsp" and that is indeed listed in my bblayers.conf. So why is it complaining? Also, I don't know that "Check that your machine has an associated kernel description" means. The term "kernel description" doesn't appear anywhere in the docs. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error in openssl during first stage do_rootfs
Never mind. Installing openssl 1.0.2d on my system cleared up the problem. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Error in openssl during first stage do_rootfs
After two years away from Yocto-land, I've decided to go back into an old project and upgrade it. I installed Fido (I formerly used Danny), made a few changes to my old metadata (bumped up some package version numbers), and created a new stripped down Atom-tuned i386 BSP using yocto-kernel-rt_3.14. I've ploughed my way through a lot of errors, but now I'm getting a fatal error I don't understand. It's still in the first phase of the build, I believe. I've put the error log here: http://pderocco.dynip.com/junk/errors.txt It's complaining about some version mismatch in openssl. The recipe is for openssl 1.0.2d, but the error messages refer to libssl.so.1.0.0 and libcrypto.so.1.0.0. It's complaining about a lack of a "link time reference", and while I can imagine what that might mean, I don't know what it actually is, why such a reference would or wouldn't exist, or what to do about it. A half hour of Googling turned up bupkis. Is this an issue with the recipe, with the upstream openssl package, or with something in my system? Could it be because I have openssl 1.0.0 installed on my system? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find the source of a variable value?
From: Burton, Ross
The default DISTRO_FEATURES includes x11, so that's where
it's coming
from. If you're using oe-core/poky from git master, you can do
DISTRO_FEATURES_remove=x11 in your configuration, or else you'll
need to set DISTRO_FEATURES to the current value, minus x11.
Thanks, but that doesn't work. I still get the same error
messages. In the
bitbake -e output I can see my entry:
# DISTRO_FEATURES_remove=x11
DISTRO_FEATURES_remove=x11
and I can see the same old DISTRO_FEATURES further down:
# DISTRO_FEATURES=alsa argp bluetooth ext2 irda largefile
pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g
x11 ${DISTRO_FEATURES_LIBC} largefile
opengl${@oe.utils.features_backfill(DISTRO_FEATURES,d)}
DISTRO_FEATURES=alsa argp bluetooth ext2 irda largefile
pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g
x11 ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd
libc-cxx-tests libc-catgets libc-charsets libc-crypt
libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt
libc-fmtmsg libc-fstab libc-ftraverse
libc-getlogin libc-idn libc-inet-anl libc-libm
libc-libm-big libc-locales libc-locale-code
libc-memusage libc-nis libc-nsswitch libc-rcmd
libc-rtld-debug libc-spawn libc-streams libc-sunrpc
libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar
libc-posix-regexp libc-posix-regexp-glibc
libc-posix-wchar-io largefile opengl pulseaudio
Any other ideas?
Is this _remove something new? I'm using the Gumstix-provided metadata and
tools, which are from the Dylan branch. If that's the issue, must I
explicitly set DISTRO_FEATURES to the big long list in local.conf?
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find the source of a variable value?
On Mon, Sep 16, 2013 at 10:02 AM, Paul D. DeRocco pdero...@ix.netcom.com wrote: This image recipe has some Python that complains because x11 is in DISTRO_FEATURES. How do I find out where that x11 is coming from? This is a Gumstix build, so I suspect it's indirectly related to my selecting overo as the MACHINE, because otherwise building this image would never have worked with the plain Yocto meta-data. So how do I track this down? From: Chris Larson Assuming you're using recent metadata, bitbake -e somerecipe will show you this. This isn't working for me. The image I'm trying to build is core-image-gtk-directfb. The recipe is in meta/recipes-graphics/images. If I just type bitbake -k core-image-gtk-directfb, I get two errors: ERROR: Nothing PROVIDES 'core-image-gtk-directfb' ERROR: core-image-gtk-directfb was skipped: FEATURE x11 is in DISTRO_FEATURES, Please remove x11 from DISTRO_FEATURES, use gtk-directfb instead of it I don't understand the Nothing PROVIDES error. Doesn't a recipe called x.bb PROVIDE x by default? The second error comes from the bit of Python in that recipe, which at least proves that it's reading that recipe. If I type bitbake -e core-image-gtk-directfb, I just get the first error. This happens almost instantly, before it's done any real work, so I'm not getting any further output. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can anything be done about do_rootfs speed?
From: Samuel Stirtzel
If you change:
COMPRESS_CMD_gz = gzip -f -9 -c ${IMAGE_NAME}.rootfs.${type}
${IMAGE_NAME}.rootfs.${type}.gz
COMPRESS_CMD_bz2 = bzip2 -f -k ${IMAGE_NAME}.rootfs.${type}
in [...]/meta/classes/image_types.bbclass, then can try
pbzip2 / pigz.
This raises a question that has come up for me before: is there a way to
override something in a .bbclass, without just editing the file and
therefore losing it whenever new metadata is released? I really have
little sense of the order in which things are read or obeyed in the whole
bitbake process. Those variables look like they're read by the
get_imagecmds() script; is there an opportunity for a recipe to change the
value of COMPRESS_CMD_gz or _bz2 after it's defined, but before that
script gets called?
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can anything be done about do_rootfs speed?
From: Martin Jansa Are you sure that you're not building some unnecessary IMAGE_FSTYPES? No, I'm not sure. Last time someone asked my why it takes so long I've added some debug output to do_rootfs and found out that only half of the time was opkg installing packages and the rest was various IMAGE_FSTYPES. e.g. tar.bz2 takes very long without pbzip2 or lbzip2 Is there a standard way to use those in a build? Do I replace bzip2 with a link to one of those? Or does Yocto build its own bzip2? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] confusion about DEPENDS vs RDEPENDS
From: Nicolas Dechesne if the source code changes, the version of the recipe needs to change too. if you change the source code without bumping the version, the package might not be rebuilt properly indeed. and that can explain the behavior you are seeing. if 'someapp' does not change, it would be rebuilt only if one of its dependencies was rebuilt. If you're making lots of changes in the course of debugging, isn't it reasonable just to do a cleansstate on the recipe to force it to be rebuilt? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can anything be done about do_rootfs speed?
I got really tired of waiting for builds on my lowly dual-core Atom machine, so I went out and bought a nice fast machine with an i7-4770K and a Samsung SSD. Full builds are now screechingly fast, over 10x compared to the Atom. But when making a tiny change, I still have to wait for do_rootfs. Since this is a single task, it runs on a single core, so it only runs maybe three times as fast. For my Gumstix stuff, it takes five minutes instead of something like 15. That's a meaningful improvement, but it still seems long when the task implementing the minor change took, oh, five seconds. Since it's the one task that _always_ gets executed, it seems like a bottleneck that should be addressed. Is there any way, in the future, of breaking do_rootfs into multiple threads, so they can take advantage of multiple cores? Or has something like this been tried already, and found not to produce much of a speedup? Or is the process intriniscally sequential? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can anything be done about do_rootfs speed?
From: Gary Thomas
As far as I understand, the 'do_rootfs' step in building an
image is basically
equivalent to running ${PKG_MGR} install
all_required_packages, where PKG_MGR
is your package management method of choice - ipk or rpm.
This seems to me to
be a very single-threaded process.
If there's a way to command the package manager to install a package
without enforcing dependencies (Is that what opkg --nodeps does?), then
couldn't the package manager be invoked on one package at a time in n
threads, just like the other tasks are now run? I don't really have any
sense of how long it takes to install the packages, as opposed to building
the final tarball or hddimage and applying the permissions from the pseudo
database, which would certainly be single-threaded.
Perhaps you should think more about how you are using this.
If you don't need
to rebuild the whole image every time, maybe you can use the
package management
tools instead? For example, I routinely build images as well
but I also try to
use 'opkg' as much as possible to manage package updates,
etc. This is a huge
time saver, especially when making small or incremental
changes. I only rely
on the full image builds when I want to checkpoint the
state of the system.
I'd like to try that, but I'm not sure how. If I've tweaked one recipe,
how do I get it to build it and package it, and then stop? Do I use
bitbake -c package? And then do I use opkg -d to manually install it
directly onto my SD card? If my rootfs is a loop mounted hddimage in a
FAT16 file (as it is on my Atom project), do I loop mount it on my build
system and install into that?
Installing directly to the card would be nice because copying the whole
damn rootfs to the card takes an annoying amount of time, too.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building one package needs header from another
On Tuesday 20 August 2013 16:06:54 Paul D. DeRocco wrote:
I've been trying to figure out how the setup.py/setup.cfg
(and distutils)
stuff works. The setup.cfg file lists only one possible
option for adding
directories, which is basedirlist, but setting that to foo adds
foo/include to the include directories and foo/lib to the library
directories, so that's not appropriate.
From: Paul Eggleton
Could you just send it ${STAGING_DIR_HOST}/${prefix} ? We do
do that elsewhere with similar-behaving configure scripts.
I think I've figured out what's going on. The whole distutils.bbclass
interface to the Python distutils package involves the writing of a
setup.py script to perform all the packaging and unpackaging processes.
The setup.py script for matplotlib has to deal with the fact that
matplotlib depends upon a varying set of libraries depending upon how you
configure it. In this case, because I want to build the GTK rendering
backend, it depends upon the pygtk library. It cleverly uses the
pkg-config command to interrogate each dependent library to find out what
compiler options are needed to compile modules that refer to the library,
but unfortunately, pygtk-2.0 is not a library that can be searched by
pkg-config, so the do_compile script coughs up the following nonfatal
error message:
pkg-config: looking for pygtk-2.0 gtk+-2.0
* Package pygtk-2.0 was not found in the pkg-config
* search path. Perhaps you should add the directory
* containing `pygtk-2.0.pc' to the PKG_CONFIG_PATH
* environment variable No package 'pygtk-2.0' found
I think I'm just going to have to patch the setup.py file (actually a
subsidiary setupext.py file) to hack the additional pygtk-2.0 include
subdirectory into it. However, setupext.py and setup.py both already have
small patches in the original matplotlib recipe. If I add another patch in
my bbappend, will it always be applied after the one in the original
recipe? Or should I just replace the patch file with one containing its
fixes and my fix?
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] What symbol contains the current sysroot?
In a do_compile script within a recipe, what symbol can I use to refer to the sysroot in effect during the execution? And whatever it is, is it a real environment variable, or some symbol that is substituted by bitbake before executing the script? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappend on top of bbappend
From: Paul Eggleton
On Friday 16 August 2013 16:22:00 Paul D. DeRocco wrote:
In meta-oe/recipes-graphics/xinput-calibrator (Danny
branch, currently
used by Gumstix), there's a recipe called
xinput-calibrator-git.bb, which
installs a script for running a touchscreen calibration app
if not already calibrated.
In
meta-openembedded/meta-systemd/meta-oe/recipes-graphics/xinput
-calibrator,
there's a bbappend for this recipe, which declares a local
file called
xinput-calibrator.service, which is supposed to run the
above script on
startup. It inherits the systemd bbclass, which I assume
knows how to
install this service file automagically, since there's no explicit
do_install copying the file anywhere.
The systemd.bbclass we now have in OE-Core (as of dylan) does
not handle this
automatically. The old one in meta-systemd does appear to though.
The trouble is, on my Gumstix, the service fails because it needs a
DISPLAY environment variable to tell it what display to calibrate. I
figured the simplest thing to do would be to add an
Environment=DISPLAY=:0
line to the service unit file.
FWIW, when xinput-calibrator was moved over to OE-Core it was
determined that
this shouldn't even be started as a service by systemd, but
instead launched
using Xsession.d. You may have better results if you bring in
the recipe from
OE-Core master and use that instead.
Since I'm not running I GUI, but needed an X session, I created a systemd
unit to start a dummy X session, using sleep as the dummy client. Then,
I can scribble on the screen from my python scripts run from the root
command line. So I solved it by having the xinput-calibrator service run
after my X session starts. I'll look at putting it in Xsession.d instead,
and see if that is cleaner.
But I'd rather just provide my own
version of the file, and use another .bbappend to prepend its file
location to FILESEXTRAPATHS, overriding the one in the
systemd .bbappend file.
So I tried that, just putting the following two lines into my own
.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
PRINC := ${@int(PRINC) + 1}
and of course putting the tweaked service file into my
files subdirectory.
snip
I read somewhere that stacked bbappends are handled in the
order of layer
priority. Mine is 5, the meta-systemd layer is 7. I don't
know which is
higher, or if one wants a higher or lower priority in
order to be the last one to prepend to the path.
They will be applied in ascending order, so anything in the
bbappend from a
layer with a higher layer priority number takes precedence.
After I did a clean and a clean_sstate, the dual bbappends worked as
expected.
I'm learning from experience to clean things manually, to avoid problems,
but sometimes I'm just waving a dead chicken over it. I don't really know
what these things do, or in what situations they should or shouldn't be
necessary. For instance, I've never found an explanation of what shared
state really is, with sufficient specificity that I can predict, Oh, for
that I need to clean the sstate, not just the build tree. Second, it
seems like clean_sstate does a clean, but I'm not sure clean doesn't do
something else that clean_sstate doesn't do.
One more thing puzzles me. The original bbappend, which creates a service
unit, contained these six lines:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
PRINC := ${@int(PRINC) + 2}
inherit systemd
SRC_URI += file://xinput-calibrator.service
SYSTEMD_PACKAGES = ${PN}-systemd
SYSTEMD_SERVICE = ${PN}.service
Since I only wanted to replace the file, I thought it should be sufficient
to put the following in my bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
PRINC := ${@int(PRINC) + 1}
It didn't work, though. I blindly copied all six lines into my bbappend,
and it worked. I suspect the systemd lines were necessary, though. I'm
wondering why adding another copy of the string
file://xinput-calibrator.service to SRC_URI is necessary. Or am I
imagining things? I do that sometimes.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to tweak a build with a setup.cfg file
Well, I hate to say it, but this didn't work. The setup.cfg file ended up
in the same place, even though I did a clean and a cleansstate on the
python-matplotlib recipe.
The log shows it searching for setup.cfg, so it is definitely separating
the subdir= option from the name. And it's not complaining about not
finding it. So it's acting like it's ignoring the option.
Google didn't turn up any official documentation on this option, but
showed a modest amount of discussion of it, along with a 2009 patch to
base.bbclass which implements the creation and switching to of the new
directory:
http://lists.openembedded.org/pipermail/openembedded-commits/2009-January
/097189.html
Yet this doesn't look remotely like my base.bbclass, which is much shorter
than 725 lines, and doesn't contain any code like this. In the intervening
years, this may well have been moved into some other module, but it's
acting like there is a generic routine that parses name=value options into
a list, but doesn't give you an error if nothing uses the option, and
nothing is using it.
This is a Gumstix build based on the Danny branch, by the way, which isn't
the latest and greatest, but it's not four years old either.
So I decided to try what I mentioned in the last message, which is simply
to mimic the fragment of the directory tree in my metadata, creating a
file called python-matplotlib/matplotlib-1.1.0/setup.cfg, and putting this
in the recipe:
SRC_URI += file://matplotlib-${PV}/setup.cfg
It worked.
I suspect what happened is that support for the subdir= option on local
files was added in 2009, then someone thought, why have this obscure
syntax? Simpler to impose the directory structure on the local files in
the metadata, allow file:// to refer to any pathname, not just a filename,
and have the file copy routine create any necessary subdirectories in the
build tree. So they took that option out. Just a guess.
That said, although the setup.cfg file did cause the necessary module to
be compiled, the compile failed for unrelated reasons. If it's not one
thing, it's another. And I rather doubt anyone around here has ever used
Yocto to build the GDK backend for matplotlib, so I don't know who to ask
about this.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Larson
Sent: Monday, August 19, 2013 4:37 PM
To: Paul D. DeRocco
Cc: yocto
Subject: Re: [yocto] Trying to tweak a build with a setup.cfg file
On Mon, Aug 19, 2013 at 3:52 PM, Paul D. DeRocco
pdero...@ix.netcom.com wrote:
I'm trying to build python-matplotlib from the Danny branch of
meta-openembedded/meta-oe/recipes-devtools/python. I
need to add a
setup.cfg file to tweak the build, but I don't know how
to get it into the
right place.
I put the setup.cfg into a python-matplotlib
subdirectory in my recipes
directory, and added a python-matplotlib_1.1.0.bbappend
file which
contains the following lines:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
PRINC := ${@int(PRINC) + 2}
SRC_URI += file://setup.cfg
The file is being copied into
.../work/armv7a-vfp-neon-poky-linux-gnueabi/python-matplotlib-1.1.0-r3
rather than
.../work/armv7a-vfp-neon-poky-linux-gnueabi/python-matplotlib-
1.1.0-r3/mat
plotlib-1.1.0 where it needs to be. How do I push it
down a level?
By default, anything in SRC_URI goes into ${WORKDIR}, not
${S}. You should be able to change this like so:
SRC_URI += file://setup.cfg;subdir=matplotlib-${PV}
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building one package needs header from another
I'm trying to build python-matplotlib, which is a plotting package for PyGTK, and I need to compile the GDK rendering backend so that I can put plots onto the screen. (This is for a Gumstix, and I'm using their Danny branch metadata.) The backend source file needs to include pygtk/pygtk.h, which is all over the place in the fragments of the target rootfs since I've built that for the target system, but isn't anywhere to be found in the cross-compilation environment, so the compilation fails. The whole topic of cross-compilation makes me dizzy. How is this situation dealt with? The source tarball for matplotlib (1.1.0) just assumes that this header file already exists on the user's system. Is this a normal thing for which there's a routine solution in Yocto? Or do I have to hack it by copying one of those files from the target rootfs and including it in my own metadata, forcibly putting it somewhere that the compiler can find it? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building one package needs header from another
From: Burton, Ross [mailto:ross.bur...@intel.com]
If you've built pygtk then the target sysroot should have the headers
in, and for me it does:
ross@melchett /data/poky-master/tmp/sysroots/genericx86
$ find . -name pygtk.h
./usr/include/pygtk-2.0/pygtk/pygtk.h
This is probably a problem with python-matplotlib, can you share the
configure and build logs? It's probably looking in the wrong place.
Yes, the include files are there. I'm only beginning to grasp a little
about how builds work, and that sysroots/overo is the context in which the
Gumstix cross tools run. But the appropriate directory,
/home/pauld/yocto/build/tmp/sysroots/overo/usr/include/pygtk-2.0, is not
on the compiler command line, and that causes the error.
I've been trying to figure out how the setup.py/setup.cfg (and distutils)
stuff works. The setup.cfg file lists only one possible option for adding
directories, which is basedirlist, but setting that to foo adds
foo/include to the include directories and foo/lib to the library
directories, so that's not appropriate. I tried just setting include_dirs
to the proper directory in the [directories] section, but it had no
effect.
The configure log shows nothing, but the compile log (which shows the
compile error at the end), shows this DEBUG note right at the beginning:
/home/pauld/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/python
-matplotlib-1.1.0-r3/temp/run.do_compile.14201: line 82:
/home/pauld/yocto/build/tmp/sysroots/i686-linux/usr/bin/python: No such
file or directory
basedirlist is: ['/home/pauld/yocto/build/tmp/sysroots/overo/usr/lib']
The message refers to this script in run.do_compile (slightly
reformatted):
do_compile() {
BUILD_SYS=i686-linux HOST_SYS=arm-poky-linux-gnueabi \
/home/pauld/yocto/build/tmp/sysroots/i686-linux/usr/bin/python \
setup.py build || true
distutils_do_compile
}
This would suggest that setup.py isn't even being run. Yet when I
accidentally put a syntax error into setup.cfg, it barfed. Is setup.cfg
read before setup.py is run, by something else?
So there are two questions: why is there no python in that directory?
(There is a python-native subdirectory containing python.) And once that's
dealt with, how does one add a specific include subdirectory to the
command line via setup.cfg?
Or maybe those aren't the questions. I understand about 0.1% of what's
going on here.
I'm also curious if distutils is something that is used throughout the
bitbake process, or is it something specific to building Python-related
stuff? Can the setup.py/setup.cfg mechanism be used in any recipes?
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] My stuff is missing from rootfs
From: Paul Eggleton You didn't mention in your reply to Saul whether the foo package was mentioned in log.do_rootfs or installed_pkgs.txt files in your old tmpdir; was it? It's in both places. Yet NONE of the various files that were supposed to be part of that recipe ended up in the rootfs, after several tries, even though the logs showed that recipe being built. I think the problem may have been caused by once hitting Ctrl-C at the beginning of do_rootfs, because I remembered that I had to tweak one of the files, and I didn't want to wait the fifteen minutes for that to complete. (I'm running on an Atom.) As it happens, Ctrl-C just sets a flag that interrupts the process after the task completes, so it didn't really help, but I think that's when the problem started. Maybe that's a clue. That said, rebuilding tmp (preserving downloads and sstate-cache) did indeed fix that problem, but it was replaced with another. Now, do_rootfs is failing, complaining that it cannot satisfy the following dependencies for samba: libpam (= 1.1.6). Yet there's libpam, version 1.1.6, right where it's always been in the metadata. Doing a clean and a cleansstate on libpam didn't help. Does samba.inc used by the samba recipe you are building have a PACKAGECONFIG line referring to pam? I think that was added recently in meta-oe master (and shortly to be merged into the meta-oe dylan branch). Without it there will be a floating dependency on pam, which may account for this latter issue. No, it's not mentioned in samba.inc, samba-basic.inc or in the recipe itself. And cleaning samba and rebuilding fixed the problem. So I suspect what's been done in the Dylan branch has dealt with that problem, and for now everything in the Danny branch works fine as long as things get done in the normal order. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bbappend on top of bbappend
In meta-oe/recipes-graphics/xinput-calibrator (Danny branch, currently
used by Gumstix), there's a recipe called xinput-calibrator-git.bb, which
installs a script for running a touchscreen calibration app if not already
calibrated.
In
meta-openembedded/meta-systemd/meta-oe/recipes-graphics/xinput-calibrator,
there's a bbappend for this recipe, which declares a local file called
xinput-calibrator.service, which is supposed to run the above script on
startup. It inherits the systemd bbclass, which I assume knows how to
install this service file automagically, since there's no explicit
do_install copying the file anywhere.
The trouble is, on my Gumstix, the service fails because it needs a
DISPLAY environment variable to tell it what display to calibrate. I
figured the simplest thing to do would be to add an Environment=DISPLAY=:0
line to the service unit file.
My shameless hack was to add a ROOTFS_POSTPROCESS_COMMAND that runs sed on
the final copy of this service file in the rootfs, to insert the
Environment= line, and that works. But I'd rather just provide my own
version of the file, and use another .bbappend to prepend its file
location to FILESEXTRAPATHS, overriding the one in the systemd .bbappend
file.
So I tried that, just putting the following two lines into my own
.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
PRINC := ${@int(PRINC) + 1}
and of course putting the tweaked service file into my files subdirectory.
On starting the build, it almost immediately spat this out:
NOTE:
['/home/pauld/yocto/meta-foo/recipes/xinput-calibrator_git.bbappend',
'/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gra
phics/xinput-calibrator/xinput-calibrator_git.bbappend'] to
['/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gr
aphics/xinput-calibrator/xinput-calibrator_git.bbappend']
(That was all on one line, of course.)
The do_rootfs failed, and its log says that xinput-calibrator is an
unknown package, and that it can't satisfy the dependency from
packagegroup-core-x11-base.
I read somewhere that stacked bbappends are handled in the order of layer
priority. Mine is 5, the meta-systemd layer is 7. I don't know which is
higher, or if one wants a higher or lower priority in order to be the
last one to prepend to the path. But somehow, I think my problem is a
little more fundamental.
Can anyone give me a little guidance here?
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] My stuff is missing from rootfs
I've done exactly this in a different Yocto-based project, and it worked. Now I'm trying to do the same thing in a Gumstix build, and it's not working. I have a dumb little recipe that merely copies some files into particlar places in the rootfs. It adds a systemd service unit, as well as .bashrc and .inputrc to /home/root. The build logs show the recipe being processed, including the do_install task which copies the files. No errors are produced. If I rummage through build/tmp/work, I can find the fragment of the rootfs containing the /home/root and /etc/systemd/system directories with my files in them. Yet no matter what I try, these things never wind up in the final rootfs. I've tried clean and cleansstate on the recipe, as well as on my top-level recipe. I've bumped PR from r0 to r1. It dutifully reprocesses my recipe, with no errors, and I end up with a perfectly functioning rootfs without these particular files. This is a slightly modified version of gumstix-console-image. I believe it's based on Danny, as the gumstix Dylan stuff is still a work in progress. What could conceivably be wrong? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] My stuff is missing from rootfs
From: Saul Wold On 08/15/2013 11:37 AM, Paul D. DeRocco wrote: I've done exactly this in a different Yocto-based project, and it worked. Now I'm trying to do the same thing in a Gumstix build, and it's not working. I have a dumb little recipe that merely copies some files into particlar places in the rootfs. It adds a systemd service unit, as well as .bashrc and .inputrc to /home/root. The build logs show the recipe being processed, including the do_install task which copies the files. No errors are produced. If I rummage through build/tmp/work, I can find the fragment of the rootfs containing the /home/root and /etc/systemd/system directories with my files in them. Yet no matter what I try, these things never wind up in the final rootfs. I've tried clean and cleansstate on the recipe, as well as on my top-level recipe. I've bumped PR from r0 to r1. It dutifully reprocesses my recipe, with no errors, and I end up with a perfectly functioning rootfs without these particular files. This is a slightly modified version of gumstix-console-image. I believe it's based on Danny, as the gumstix Dylan stuff is still a work in progress. What could conceivably be wrong? Where do you add your recipe's generated packages to the image, this could be in your custom image with an RDEPENDS or via something in local.conf like CORE_IMAGE_EXTRA_INSTALL_append = packagename. Do you have other recipes that DEPEND or RDEPEND on your recipe? That might point you in the right direction. My top level recipe uses IMAGE_INSTALL to add a bunch of packages, including one whose name matches the name of the recipe that's being processed but whose output is being ignored. This is exactly what I did in a different Yocto project, to get a similar recipe to install some similar files, and it all worked fine. I've attached the top level recipe and the problematic one, only changing the project name to foo for proprietary reasons. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com gumstix-foo-pygtk-image.bb Description: Binary data foo_1.0.bb Description: Binary data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] My stuff is missing from rootfs
From: Saul Wold My top level recipe uses IMAGE_INSTALL to add a bunch of packages, including one whose name matches the name of the recipe that's being processed but whose output is being ignored. This is exactly what I did in a different Yocto project, to get a similar recipe to install some similar files, and it all worked fine. I've attached the top level recipe and the problematic one, only changing the project name to foo for proprietary reasons. Interesting, did you verify that the files are in the tmp/work/.../foo/packages-split/foo directory. You can also look in the tmp/work/.../gumstix-foo-pyygtk-image/1.0-r0/installed_pkgs.tx t file to ensure your foo package is there. You can also look in the image temp dir for the log.do_rootfs and see if there are any issues in it or it's missing your package. The files are in tmp/work/.../foo_1.0-r1/packages-split/foo, and also in tmp/work/.../foo_1.0-r1/image, and the package is listed in that text file. And the logs show no errors. This smells like one of those situations where nuking tmp and rebuilding will fix it, and we'll never know what was wrong. I'll let you know if that fixes it. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] My stuff is missing from rootfs
From: Paul Eggleton On Thursday 15 August 2013 13:01:54 Paul D. DeRocco wrote: This smells like one of those situations where nuking tmp and rebuilding will fix it, and we'll never know what was wrong. I'll let you know if that fixes it. If you keep on doing this we'll never figure out what the problem is. Wiping out tmp just removes any way we might have to diagnose the issue. I didn't wipe it out, I renamed it to something else, so I can switch back to it if I need to. I certainly don't have the faintest idea about how to diagnose it, beyond the naive steps I've already taken. And I need to get back to my real job, which is writing apps for this system, instead of building the distro. If there's anything you can think of that I should try, I'd be happy to do so. That said, rebuilding tmp (preserving downloads and sstate-cache) did indeed fix that problem, but it was replaced with another. Now, do_rootfs is failing, complaining that it cannot satisfy the following dependencies for samba: libpam (= 1.1.6). Yet there's libpam, version 1.1.6, right where it's always been in the metadata. Doing a clean and a cleansstate on libpam didn't help. Now I'm trying rebuilding samba, but that's a huge package so it will take a while. The only way I can get any real work done at the moment is to make manual changes to the last good build I had. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] My stuff is missing from rootfs
From: Mark Hatle A simple way to diagnose if your package is even in the install list is to do bitbake -e image, then scan the output for PACKAGE_INSTALL. If your package is not listed there, then something has either cleared your configuration or you have a typo. IMAGE_INSTALL_append = my_package should work, and generally won't be cleared by a recipe. It's there, and it's all working now. I've had things break in odd ways before, and recover when I rebuilt. This time it took a couple of tries. What makes it frustrating is that I'm building on a wimpy Atom system. I've been on the verge of buying a killer system just to do builds, but I keep thinking, maybe I'll only need to do this another dozen or so times and then I'll be done, in which case it wouldn't be a good investment. (Note you should modify IMAGE_INSTALL, which is transformed by the system into PACKAGE_INSTALL... modifying PACKAGE_INSTALL can lead to problems.) I don't think that all the various ways to append stuff will ever make sense to me. Currently, I'm using IMAGE_INSTALL += ... in my top level recipe, and it works. I don't know what IMAGE_INSTALL_append does differently. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] My stuff is missing from rootfs
From: yocto-boun...@yoctoproject.org That said, rebuilding tmp (preserving downloads and sstate-cache) did indeed fix that problem, but it was replaced with another. Now, do_rootfs is failing, complaining that it cannot satisfy the following dependencies for samba: libpam (= 1.1.6). Yet there's libpam, version 1.1.6, right where it's always been in the metadata. Doing a clean and a cleansstate on libpam didn't help. Now I'm trying rebuilding samba, but that's a huge package so it will take a while. Not surprisingly, rebuilding Samba cleared out that spurious issue. So I'm back to normal. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to enable UDHCP?
From: Paul D. DeRocco My build is an Intel Cedartrail system based on Dylan, using systemd. It appears to have udhcp available from busybox, but it's not running. systemd reports that it is masked, because /etc/systemd/system/busybox-udhcpc.service is linked to /dev/null. What creates this link, and how do I get the DHCP client enabled in my build? Is there something else I need to include? It appears this is masked by a post-install script in meta/recipes-core/systemd/system-compat-units.bb. The comment says Units to make systemd work better with existing sysvinit scripts. Doesn't seem like it's doing that in this case. However, if I tweak the recipe so that the systemd service unit for busybox-udhcpc isn't masked, it doesn't reveal a valid service unit, I wind up with nothing. That suggests that there should be a sysvinit script somewhere else for starting udhcpc, but I can't find anything under /etc that contains the string udhcpc other than the script that udhcpc calls when an interface changes state. I also find that I can manually run udhcpc with the appropriate interface parameter, and it works fine; my Samba server from OE becomes accessible from a Windows machine, and everything seems happy. So how is udhcpc normally supposed to be launched? I could hack it in any number of ways, but I'd like to know the right way, because I'd like it to be able to assign an address if someone plugs in a USB WiFi dongle, too, and that's beyond my ability. Or is this just something that works with sysvinit, but no one's gotten around to figuring out how to integrate it into systemd, and I'm on my own? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to enable UDHCP?
My build is an Intel Cedartrail system based on Dylan, using systemd. It appears to have udhcp available from busybox, but it's not running. systemd reports that it is masked, because /etc/systemd/system/busybox-udhcpc.service is linked to /dev/null. What creates this link, and how do I get the DHCP client enabled in my build? Is there something else I need to include? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Mount options for removable drives
Can someone point me to the configuration for how removable drives are mounted? When I plug in a flash drive, it mounts /dev/sdb1 as /media/sdb1, but it uses relatime and I'd like to use noatime. I'd also like it to mount in sync mode, which I would think would be the default for such a drive, but I've gotten a corrupted FAT when I've yanked the drive. This is basically a core-image-base build, modified to use systemd, but I don't see any systemd mount unit that handles it, so it must be some other part of the system. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mount options for removable drives
On 12 July 2013 09:30, Paul D. DeRocco pdero...@ix.netcom.com wrote: Can someone point me to the configuration for how removable drives are mounted? When I plug in a flash drive, it mounts /dev/sdb1 as /media/sdb1, but it uses relatime and I'd like to use noatime. I'd also like it to mount in sync mode, which I would think would be the default for such a drive, but I've gotten a corrupted FAT when I've yanked the drive. This is basically a core-image-base build, modified to use systemd, but I don't see any systemd mount unit that handles it, so it must be some other part of the system. From: Paul Barker Look in /etc/udev on the image, this is handled by udev. Thanks. Changing /etc/fstab does bupkis, so I provided my own slightly modified version of the mount.sh script in udev-extraconf, and that seems to work fine. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Changing syslinux configuration
From: Tomas Frydrych On 06/07/13 02:23, Paul D. DeRocco wrote: Does anyone know what recipe actually sets LABELS? The relevant image classes do. Thanks. It turned out to be image-live.bbclass, which sets a bunch of SYSLINUX_xxx symbols unless they've already been set, and which are then obeyed by syslinux.bbclass. So I'm setting these in my layer.conf, and it seems to work. Is that the right place to do it, or should it be in my main layer recipe? I really have no sense about the order in which anything is read or obeyed. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Another in a seemingly infinite chain of errors
From: Zhenhua-B19537
FILES_${PN}_append = xxx should useful, xxx is the file
which is listed in the were installed but not shipped message.
More info of FILES can be found in
https://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.ht
ml#var-FILES
Thanks for the quick response.
The problem is that every directory that I create in this one recipe is in
that list, not just the files. This includes things like
/lib/systemd/system.
I have another recipe, which is basically the same as the hello.c example,
except that it is a real program. It works fine without a FILES_${PN}
variable. So what is it about my failing recipe that makes it need a
FILES_${PN} variable? It has no do_compile, just a do_install script with a
bunch of install and ln commands.
By the way, I also notice it says to use things like ${bindir} for standard
directories. Is there a comprehensive list of these anywhere? I don't find
them in the Yocto Dev Manual or Ref Manual.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Another in a seemingly infinite chain of errors
From: Luo Zhenhua-B19537
[Luo Zhenhua-B19537] Seems like the similar issue as
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4309
Just adding everything to FILES_${PN} solves the problem, although it's
still a mystery to me why the helloworld.c example doesn't need to do that.
By the way, I also notice it says to use things like ${bindir} for
standard directories. Is there a comprehensive list of
these anywhere? I
don't find them in the Yocto Dev Manual or Ref Manual.
[Luo Zhenhua-B19537] I am not sure whether such variables are
documented in a unified doc, I always check it in
meta/conf/bitbake.conf or bitbake -e | grep xxx.
Thanks. I think I'll create my own little text file listing them all, along
with the default values they expand into.
If anyone involved in upgrading the docs is reading this, that really should
go into the Ref Manual, in a single table.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Changing syslinux configuration
For my system (something similar to core-image-base running on a Cedartrail Atom mobo), the syslinux.cfg file needs to be tweaked. It is built by a script in syslinux.bbclass, which is controlled by various variables. First of all, it's important that it not try to use a serial port as a console, so that means I'm supposed to set SYSLINUX_SERIAL to . Second, it's providing two choices called boot and install, and I'd like to eliminate the latter, which involves setting the LABELS variable to boot. I see that syslinux.bbclass has default value of 0 115200, but it has no default value for LABELS, which would cause a failure if something else wasn't setting it to boot install. I see that it is inherited by boot-directdisk.bbclass, but it doesn't provide a default value for LABELS, either. Does anyone know what recipe actually sets LABELS? And then, do I override these variables by creating a .bbappend file for that recipe? Or are these two symbols global symbols that I can somehow supply values for in my layer file? I really have no understanding of the scope of all the multiplicity of variables in the Bitbake system. Does each recipe have its own namespace for variables, or is everything global? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Another in a seemingly infinite chain of errors
The latest is two things: a warning that the files and directories I created in my do_install were installed but not shipped, followed by an error saying that my layer is not found in the base feeds. Googling those two phrases turned up lots of patches intended to fix those errors in specific obscure cases, but nothing that explains what they mean, or what I should do when it happens to my layer. I don't think I've forgotten anything that the Dev Manual says that I need in order to add a simple layer. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Creating a volatile image
When an .hddimg image is used on a hard disk or flash drive, the target root directory is implemented as a loop device referring to the rootfs.img file contained in that drive. This means it is a true non-volatile file system. Is there a way to make the entire file system volatile? I'm trying to ensure that my flash drive is written to as rarely as possible. To this end, I'm putting my app's volatile data on a separate partition, and I'd like to run the OS out of a big ramdisk, loading it on startup and then discarding it on shutdown. In other words, I want a Groundhog Day system, which always boots up as though it is a brand new clean install. I've spent a couple hours trying to decipher various .bbclass files, Googling about the various file systems, and so on, and I haven't seen anything that looks like this capability is already provided somehow in the Yocto system. Is there an easy way to do this? Or is there only a hard way to do it, involving way more expertise in the build system than I've got? Alternatively, is it practical to make the existing file system readonly? My system is based on core-image-base, with no graphics. What will break if it can't write to anything outside of /tmp or /run or /media/ram or /var/volatile? And is there a built-in way to do that? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating a volatile image
From: Burton, Ross You can set the read-only-rootfs image feature (never tried it myself, so YMMV), That would certainly be the simplest thing to try. but if you turn off atime writes to / you won't be making that many writes to / anyway. How does one turn off atime? By modifying /etc/fstab? How is that done? By supplying a different source file to get copied into the image, or by overwriting the built-in one in my own recipe? I need to do that anyway, since I have a second partition to mount. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] systemd configuration
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
That's entirely up to what you put into your image. busybox
should provide a very basic version of vi out of the box.
Ah, vi. I guess it's time to learn vi.
Sure, you can find in the rootfs subdirectory of the
image's WORKDIR (which you can find out using:
bitbake -e imagename | grep ^WORKDIR=
One way to look at this is to launch a devshell for the image:
bitbake -c devshell imagename
In 1.4+ using a devshell has the advantage of showing you the correct
permission/ownership of files within the root filesystem.
For my purpose, the first choice turned out to be sufficient.
Or perhaps someone can just tell me what target gets
activated on bootup,
where its .wants directory is, and what directory I should
put my daemon's unit file into.
I'm sure someone more knowledgeable about systemd will pipe
up with further
information, but I would suggest looking at other recipes for
examples. AFAICT
systemd units for daemons should be installed into
${systemd_unitdir}/system.
Turns out I was confused by the fact that there is no multi-user.target
file, since it's just an empty unit. But there is a multi-user.target.wants
directory, so I'm all set.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
