**** BEGIN LOGGING AT Tue Apr 14 02:59:59 2015 Apr 14 07:23:26 hello Apr 14 07:24:13 when building core-image-minimal-initramfs, I have an error : arm-poky-linux-gnueabi not in compatible hosts Apr 14 07:24:34 It seems that initramfs use syslinux, which is not compatible with arm. Apr 14 07:24:50 Is it true ? and how to build an initramfs ? Apr 14 07:25:33 good morning Apr 14 07:27:42 Fazo: FWIW, initramfs is rather untested/unmaintained at the moment, so you might be more on your own thatn usual ther. Apr 14 07:29:03 LetoThe2nd: why that ? (not supported ?) Apr 14 07:29:16 It's pretty useful. Apr 14 07:30:33 Fazo: i never said that it isn't useful, i merely stated that obviously nobody bothered to document/test/provide the results. Apr 14 07:30:52 :/ Apr 14 07:31:05 Fazo: obviously the need hasn't been that great so far. Apr 14 07:31:42 Fazo: and as it comes with some licensing problems AFAIK, people in the industry might also define "useful" a bit different. Apr 14 07:31:50 Yeah, but I haven't found any other solution to boot over network and download all the necessairy. Apr 14 07:32:11 depends. Apr 14 07:32:21 Currently, I use u-boot to donwload the kernel and boot on it. I'd like to download the rootfs as weel. Apr 14 07:32:32 (NFS is out of the question) Apr 14 07:32:41 Fazo: how big is your rootfs? Apr 14 07:32:41 *as well Apr 14 07:32:55 you can also have kernel+initrd on the target and do nearly the same Apr 14 07:33:07 nrossi: it depends. Curretnly, about 200Mo, but it will probably vary (and be a bit less). Apr 14 07:33:23 and initrd comes with a lot less specialities (read: problems) than initramfs Apr 14 07:33:33 LetoThe2nd: yeah, but how generate the initrd ? Apr 14 07:33:47 Fazo: IMAGE_FSTYPES :) Apr 14 07:33:57 Fazo: initrd is just an ordinaly rootfs. Apr 14 07:34:21 with as much in it as you need to do your downloading, and then pivot_root Apr 14 07:35:40 create an .ext3 image for example, and pass it in. done. Apr 14 07:36:58 LetoThe2nd: I have rootfs.ext3 Apr 14 07:37:15 Whats the problem, then? Apr 14 07:37:29 It's too big to put on ram Apr 14 07:38:04 well of course you need two rootfs then. 1) a small one fitting into ram for initrd duties 2) the big one that gets downloaded. Apr 14 07:38:06 nrossi: in local.conf, I put IMAGE_FSTYPES = ? Apr 14 07:38:24 but thats not different from the initramfs way. Apr 14 07:38:36 Oh, ok. Apr 14 07:38:49 So, for example, I build core-image-minimal ? Apr 14 07:39:07 Like that I'll have a small rootfs Apr 14 07:39:50 yes. equip that with your downloading stuff Apr 14 07:39:57 and then just use it as an initrd. Apr 14 07:40:11 Fazo: you already have your initrd image, i was just pointing at the variable to get it generated for you Apr 14 07:40:35 I have my initrd image ? Apr 14 07:41:04 I have IMAGE_FSTYPES = "cpio.gz" Apr 14 07:41:29 you said you have rootfs.ext3? Apr 14 07:42:14 there's a little magic involved in the rootfs handover (which i can't recall ATM, sorry), but once you've gotten your head around the fact that you're basically working with TWO distinct images: 1) loader 2) payload Apr 14 07:43:14 Yup nrossi. But it's the rootfs of the core-image-minimal. I have also the rootfs of my image. Apr 14 07:43:52 When I have the rootfs.ext3 of the core-image-minimal, I can download it on RAM and boot on it using u-boot ? Apr 14 07:44:19 yep Apr 14 07:44:36 Oh, cool. Apr 14 07:44:56 I'll try that right after coffee time. :) Apr 14 07:45:04 oh wait, no you will need to pack it into a .ub file for u-boot to understand it Apr 14 07:45:13 Oh, right. Apr 14 07:45:28 tag on a set your IMAGE_FSTYPE = ".u-boot" Apr 14 07:46:10 IMAGE_FSTYPES* Apr 14 07:46:11 It'll work like that ? Apr 14 07:46:18 It seems pretty simple. Apr 14 07:46:43 oh and add IMAGE_CLASSES += "image_types_uboot" Apr 14 07:46:46 to get that feature Apr 14 07:47:26 nrossi: now that depends a bit on the u-boot in use Apr 14 07:47:29 I have this in my recipe : Apr 14 07:47:32 IMAGE_FSTYPES = "initram.u-boot" IMAGE_CLASSES += "image_types_uboot" Apr 14 07:47:56 LetoThe2nd: true, but at least oe-core has a seperate u-boot-mkimage recipe for the tools Apr 14 07:48:11 IMAGE_FSTYPES = "cpio.gz.u-boot" Apr 14 07:48:16 if you want a initramfs Apr 14 07:48:44 (and by initramfs i mean what the kernel does with the rootfs image) Apr 14 07:48:52 nrossi: i haven't followed those things too closely. i just knew from tinkering a while ago that initramfs sounds *VERY* promising, but comes with a lot of pain. Apr 14 07:49:06 plus the licensing problems, i dropped i idea then. Apr 14 07:50:00 LetoThe2nd: there are a couple of terms called "initramfs", i am just talking about the kernels ability to load a cpio as a rootfs and not have to have a /dev/ram node to do it Apr 14 07:50:26 If you are talking about INITRAMFS_BUNDLE, thats a different topic ;) Apr 14 07:51:20 nrossi: yeah. you obviously are more up to date on the details than i am :) Apr 14 07:51:43 LetoThe2nd: the kernels ramfs/initramfs feature is one of my fav's ;) Apr 14 07:52:40 ;) Apr 14 08:07:14 Soooo Apr 14 08:07:18 <_4urele_> Fazo, I'm using an initramfs, to boot on another one on sdcard. The initramfs is simply a core-minimal-image bitbaked with a distro near from "poky-tiny", then in my real image I have a recipe that downloads the bitbaked initramfs Apr 14 08:07:26 <_4urele_> not sure i'm clear ;) Apr 14 08:07:40 nrossi: I have a rootfs.cpio.gz.u-boot Apr 14 08:07:47 (4.1Mo, cool) Apr 14 08:08:05 So now, I have to make u-boot download it on RAM, right ? Apr 14 08:08:33 _4urele_: seems close of what I am trying to do. ;) Apr 14 08:08:54 If it doesn't work, maybe you'll be able to help. :) Apr 14 08:09:04 Fazo: yep, you should be able to do it the same way you do it with your kernel Apr 14 08:09:12 <_4urele_> Fazo, yes, I think we are doing it the same way! Apr 14 08:10:07 nrossi: but how to download it on RAM, and then say to the kernel that the rootfs is on the RAM ? Apr 14 08:10:42 <_4urele_> Fazo, dhcp ${ramfs_addr} ${serverip}:${ramfs_file} Apr 14 08:12:17 <_4urele_> Fazo, you should have a tftp server with your cpio.gz Apr 14 08:13:35 <_4urele_> Fazo you have to choose a destination address in ram for the file Apr 14 08:13:36 Fazo: i assume you are using bootm to boot the kernel? if so the address of the rootfs is the second arg (bootm 0x0 0x) Apr 14 08:18:36 nrossi: I use bootz, because my kernel is a zImage Apr 14 08:19:12 So I download also a dtb file, and I boot with bootz ${loadaddr} - {fdt_addr} Apr 14 08:19:56 Fazo: replace the - in your bootz command with the address of the rootfs Apr 14 08:20:28 Ok, I'll try that. Apr 14 08:32:35 dhcp ${ramfs_addr} ${serverip}:${ramfs_file} Apr 14 08:34:36 nrossi: what can I put for address ? (${ramfs_addr}) Apr 14 08:34:54 I don't know the addresses in RAM. Apr 14 08:36:15 <_4urele_> faz0, find addresses of loadaddr and fdt_addr Apr 14 08:37:48 <_4urele_> faz0, which board are you using? Apr 14 08:39:48 _4urele_: 0x12000000 for the kernel, 0x18... for fdt Apr 14 08:40:11 I've put 0x19... for the rootfs.cpio.gz.u-boot Apr 14 08:40:27 and root=/dev/ram on the bootargs Apr 14 08:40:32 AND IT WORKS ! :) Apr 14 08:40:45 <_4urele_> fazo, gg Apr 14 08:40:57 Yeah, but it's random ^^" Apr 14 08:41:13 <_4urele_> faz0, what is random? Apr 14 08:41:52 <_4urele_> I think you can reproduce this Apr 14 08:42:08 Yeah Apr 14 08:42:21 But i'm not 100% sure I've booted on ram Apr 14 08:42:25 (only 99%) Apr 14 08:42:44 faz0: check your boot log, it should say something like "loading from initramfs" Apr 14 08:43:15 "Trying to unpack rootfs image as initramfs..." Apr 14 08:45:02 <_4urele_> faz0, touch a file and reboot, or "cat /proc/cmdline", cat /proc/filesystems, proc/mounts ... etc Apr 14 08:47:47 cat /proc/cmdline gives noinitrd console=ttymxc0,115200 Apr 14 08:48:35 <_4urele_> faz0, it seems that your bootargs were not set... Apr 14 08:48:53 seems too... Apr 14 08:49:02 I don't know why. Apr 14 08:49:14 <_4urele_> what gives proc mounts Apr 14 08:49:16 setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi, 1920x1080M@60, if=RGB24' Apr 14 08:49:22 my bootargs Apr 14 08:49:39 and I boot with bootz 0x12 0x19 0x18 Apr 14 08:51:34 _4urele_: http://paste.ubuntu.com/10820814/ Apr 14 08:51:57 n Apr 14 08:52:05 what happened to bluelightning? Apr 14 08:52:08 holiday? Apr 14 08:52:11 /dev/mmcblk2p2 has been mounted manually Apr 14 08:52:54 nrossi: dmesg | grep init gives nothing about ram... Apr 14 08:53:13 Idem for grep ram Apr 14 08:53:35 <_4urele_> faz0, (looks like imx sabre) could you pastebin dmesg? Apr 14 08:53:49 does anyone have a clue why pthread_atfork does not work with daisy? Apr 14 08:53:51 faz0 and 'cat /proc/mounts' is / mounted from ramfs/tmpfs? Apr 14 08:54:00 at least with the application that I am trying to build anyway... Apr 14 08:57:55 what is the easiest way to replace -lpthread with -pthread for the compilation of an application integrated into Yocto? Apr 14 08:57:59 nrossi, _4urele_ : my dmesg : http://paste.ubuntu.com/10820841/ Apr 14 08:58:06 I mean the build is integrated with a recipe, not the whole upstream source code, obviously. Apr 14 08:59:05 I have tried to boot without setting the bootargs Apr 14 08:59:12 It works. Apr 14 08:59:27 I don't have put this line : setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi, 1920x1080M@60, if=RGB24' Apr 14 08:59:37 oops Apr 14 08:59:44 it was /dev/ram Apr 14 08:59:53 how to tell bitbake not to build kernel for machine? i have a machine config file in my layer and there is a PREFERRED_PROVIDER_virtual/kernel -- but what if i do not want to build any kernel? Apr 14 09:00:01 so _4urele_ was right, the bootargs aren't read. Apr 14 09:01:13 faz0 yep thats what it looks like "noinitrd " is your main problem. You don't need to root=/dev/ram for initramfs Apr 14 09:01:43 ericbutters: PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" Apr 14 09:02:15 ericbutters: its a kernel, but its not really a kernel. Just stubs all the tasks/etc Apr 14 09:03:13 nrossi: is it a problem ? Apr 14 09:04:10 faz0: not if you can get your bootargs to be picked up by the kernel Apr 14 09:04:28 <_4urele_> faz0, taccording to your traces I think you boot on the initramfs, (bootargs should be set accordingly but it seems kernel doesn't matter), to be sure you could wipeout the filesystem partition on your sdcard ;) Apr 14 09:04:44 _4urele_: it's what I'm doing ;) Apr 14 09:04:55 So, it seems ok for me. Apr 14 09:05:22 Now I have to dig on u-boot options and scripts to do all that only when I want. Apr 14 09:05:42 (and to boot with my specific bootargs the other times) Apr 14 09:07:45 <_4urele_> faz0, in u-boot sources you should find your board configuration and scripts in include/configs/ (maybe something like "imx6qdl" for sabre board Apr 14 09:08:37 Since today I've used a custom boot.scr (a really simple one) Apr 14 09:10:36 <_4urele_> faz0, bootscript is a good and flexible way to boot, (config for your board seems to be in "mx6sabre_common.h" ;) Apr 14 09:30:54 So, thanks to you nrossi and _4urele_, it works well. I use the rootfs in RAM to download the "real" rootfs and dd it on /dev/mmcblk2p2. Then, after a reboot, it works like a charm. BUT, I think the reboot use the kernel that is in the u-boot partition, not the one I have donwloaded with u-boot and dhcp. How can I change the kernel on which I am booting ? Apr 14 09:32:50 <_4urele_> faz0, I wold say update also the partition wich contains the kernel? Apr 14 09:34:44 <_4urele_> faz0, I tuned meta-fsl-arm/classes/image_types_fsl.bbclass to keep the generated vfat partition, you can also get the kernel image from the same directory you found the rootfs? Apr 14 09:35:36 <_4urele_> the kernel is stored in a vfat partition (I would say : mmcblk2p1) Apr 14 09:37:59 ERROR: QA Issue: File '/usr/lib/gconv/ISO8859-15.so' from eglibc-locale was already stripped, this will prevent future debugging! -- why? Apr 14 09:38:15 how to fix this? Apr 14 09:38:36 do not strip in the buildsystem Apr 14 09:38:46 or accept this insane check as "ok" Apr 14 09:44:33 lpapp: pls see here for full error log: http://paste.ubuntu.com/10821005/ Apr 14 09:49:31 Hi, is there a meta package to build/install gnome/gnome3? I'm searching for something like the packagegroup-xfce-base. Apr 14 09:50:29 ericbutters: so why does the buildsystem strip it? It is unusual. It will not be possible to debug it if one wants. That is also what the QA error is writing, isn't it Apr 14 09:50:55 DatGizmo: meta-gnome Apr 14 09:52:46 lpapp: meta-gnome is only the layer. Or am I missing something? Apr 14 09:54:29 Hi, I am trying to build an image with an embedded ramfs using the initramfs routines provided by poky daisy. I see the cpio.gz image being copied and gunzipped into the kernel workspace (/usr). The resulting kernel image does not contain a ramfs though, as the variable $use_alternate_initrd passed with oe_runmake seems to be empty. Any idea what I might be missing here? Apr 14 09:55:09 DatGizmo: and what is wrong about using it? Apr 14 09:56:26 I can't figure out wich packages to build/install to get a basic installation of gnome. Apr 14 09:57:41 <_4urele_> DatGizmo, maybe meta-gnome provides some images? Apr 14 09:58:29 it does not. Apr 14 09:58:30 bluelightning: Is there any documentation page on usage of variables and functions for bitbake's internal data dictionary? Apr 14 09:58:45 but cannot you use gnome-terminal to bring the dependencies in? Apr 14 09:59:57 bluelightning: what is the simplest way to try -pthread for my build instead of -lpthread? I am still struggling with daisy to get the app build. Apr 14 10:00:22 lpapp: hm I will try it. Apr 14 10:01:34 DatGizmo: ask JaMae Apr 14 10:15:50 hmm, I've been looking a bit at the documentation, but where should I start looking to get my image built with a specific file system setup? (f.ex. instead of one EFI partition having one with the EFI bootloader + kernel, and then another full partition for / as a starting point) Apr 14 10:16:05 I have so far caught up with the IMAGE_FSTYPES variable Apr 14 10:20:55 lpapp: yes.. Apr 14 10:21:19 bluelightning: could you pls take a short look into: http://paste.ubuntu.com/10821005/ -- what do you think? Apr 14 10:21:50 ericbutters: like I said, fix the source by patching it for instance or give it a green light explicitly. Apr 14 10:21:59 at least that is what I would personally do. Apr 14 10:22:09 not sure if these are the best things. Apr 14 10:24:45 lpapp: what does that mean, give it a green light? Apr 14 10:25:38 you can override these. Apr 14 10:25:44 to move along Apr 14 10:26:49 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-insane -> already stripped Apr 14 10:29:53 lpapp: thanks, i try Apr 14 10:38:17 I am digging a bit deeper into the initramfs issue I mentioned earlier. Is it possible that the use_alternate_initrd variable (set at poky daisy kernel.bbclass:134, used at kernel.bbclass:166) is expanded too early? Apr 14 10:41:31 run.do_bundle_initramfs: http://pastebin.com/1JrBxrP0 Apr 14 11:17:02 it seems that the generated static libpthread library is broken in daisy. Apr 14 11:41:38 Good day, how can I run a ROOTFS_POSTPROCESS_COMMAND with root rights? E.g. when trying to create a folder with mkdir? Apr 14 11:44:14 edison__: it just works, have you tried it? Apr 14 11:44:31 we do ROOTFS_POSTPROCESS_COMMAND += "mkdir ${IMAGE_ROOTFS}/opt;" in multiple places and we do not need to specify anything additional. Apr 14 11:45:38 I think it may be the case that you can only specify functions in ROOTFS_POSTPROCESS_COMMAND now Apr 14 11:46:00 but the functions can obviously be shell functions with whatever commands you want in them Apr 14 11:46:31 bluelightning: not sure if you had seen, but I claim that the generated libpthread static library by Yocto is broken. Apr 14 11:46:44 if I repliace the command issued by Yocto, but by adding -shared, it links properly. Apr 14 11:46:57 also nm -a says that the address of the "T" symbol is 0000000 and that is wrong, I think. Apr 14 11:47:15 it also makes sense that this is broken now as static libpthread is not much used, I would think so. Apr 14 11:47:42 lpapp: I couldn't say either way; if it looks like it's broken I can only suggest filing a bug and someone more knowledgeable in that area than me can take a look at it Apr 14 11:48:44 In my case "mkdir /media/RAM-Disk;" fails because of missing rights (I am using a function) Apr 14 11:49:04 bluelightning: ok, would that be khem or someone else? Apr 14 11:49:23 bluelightning: I will write a simple main function in C using that pthread_atfork. That should reproduce the issue. Apr 14 11:49:59 and it is also possibly fixed in latest Yocto since I am referring to daisy. It would be nice to see if there had been updates to this part of Yocto ever since. Apr 14 11:50:56 I cannot verify this against the latest Yocto, though. Apr 14 11:52:58 Please have a look: http://codepad.org/uS0CAqyb Apr 14 11:53:38 edison__: that wouldn't work because that would be making a directory on your local machine, rather than within the image Apr 14 11:53:53 edison__: you need ${IMAGE_ROOTFS} in front of any paths Apr 14 11:54:22 Is there a way to print the complete kernel configuration file? I'm not sure if my conf fragment is really used Apr 14 11:54:33 How embarrssing, I apologize, I am quite new to yocto... thanks Apr 14 11:55:33 :-) Apr 14 11:59:25 edison__: no need to be embarrassed, happy to help Apr 14 12:01:41 CromFr: you can have a look at the .config file that gets generated - you can find it in the directory in which the kernel gets built Apr 14 12:01:50 CromFr: which you can find by running: bitbake -e virtual/kernel | grep ^B= Apr 14 12:02:25 bluelightning: Thank you very much :) Apr 14 12:11:07 _4urele_: are you still there ? Apr 14 12:11:28 <_4urele_> faz0, yes Apr 14 12:11:48 _4urele_: I need some help with u-boot script. Apr 14 12:12:23 I flash the memory card (dd if=/dev/sdd of=u-boo.imx) Apr 14 12:12:43 But this way, I can't put my boot.scr on the sd card. Apr 14 12:13:39 <_4urele_> faz0, do you flash on every boot? Apr 14 12:13:45 Nop. Apr 14 12:14:13 <_4urele_> faz0, could you tell me what you have on the first partition of the sdcard? Apr 14 12:14:25 <_4urele_> (mmcblk2p1) Apr 14 12:14:30 I flash one time to have u-boot, and then I use what we have done this morning to fetch by network the kernel and the minimal rootfs. Apr 14 12:14:34 Nothing. Apr 14 12:15:34 <_4urele_> i'm using freescale sdcard too and I have kernel dtb and bootscript Apr 14 12:16:24 Yes, habitually me too. Apr 14 12:16:51 <_4urele_> faz0, as far as I saw in the u-boot configuration for sabre it takes the boot.scr on the sdcard... Apr 14 12:16:54 But I haven't flashed the card with all the image, only with u-boot.imx Apr 14 12:18:40 <_4urele_> faz0, there is no partitions on the sdcard? Apr 14 12:19:25 Nop Apr 14 12:19:28 <_4urele_> faz0, you would like to have an sdcard empty with just uboot wich will get everything on the network? Apr 14 12:19:35 Yeah ! Apr 14 12:19:38 Exactly Apr 14 12:20:49 <_4urele_> faz0, ok so there is 2 possible way : first the easiest modify ubbot put your script in mx6sabre_common.h Apr 14 12:22:21 <_4urele_> faz0, the second way could be to flash directly on the sdcard the bootscript and modify the uboot to load and launch the script... Apr 14 12:23:53 If you say the first is easiest, I'll try that. Apr 14 12:24:04 <_4urele_> I think the first solution is the easiest one, I never tried the second one :) anyhow you will have to modify the boot command Apr 14 12:24:09 _4urele_: which country are you from ? Apr 14 12:25:17 'cause if you speak french, it'll be easier. ;) Apr 14 12:46:59 Another question: I want to add a module to the driver. Therefore I created the following "append"-file: recipes-kernel/linux/linux-yocto_3.10.bbappend (http://codepad.org/n2hszi5A ). During bitbake I get the error: "opkg_install_cmd: Cannot install package linux-yocto." Apr 14 13:15:32 te Apr 14 13:24:49 how can I make sure that one recipe will be used over another one ? Apr 14 13:24:52 thanks in advance ! Apr 14 13:55:37 Hi all, I have finally found a workaround to the initramfs issue I have been bugging you all about today: http://pastebin.com/pSNqnP2P Apr 14 13:56:35 Essentially, I have copied the relevant part of kernel_do_compile() into do_bundle_initramfs(). I cannot imagine this is the way it is supposed to be done though, so I must be doing something wrong. Any ideas please? Apr 14 14:03:01 Small recap regarding my previous messages: without applying this patch the CONFIG_INITRAMFS_SOURCE variable is not being passed to Make. Possibly there is some kind of issue in the setting and getting of $use_alternate_initrd between do_bundle_initramfs() and kernel_do_compile(). Apr 14 14:17:51 acidfu: depends on the context - if it's just about the version selection, PREFERRED_VERSION_recipename = "version" Apr 14 14:25:20 halstead: around? Is everything ok with the NAS? Did anything change on the autobuilder setup in the last few days? Apr 14 14:25:42 We've seen https://autobuilder.yoctoproject.org/main/builders/nightly-qa-systemd/builds/258/steps/BuildImages/logs/stdio kinds of errors twice in this build (and never before) Apr 14 14:49:38 hello otavio. You've just responded to my e-mails on meta-fsl mailing list Apr 14 14:49:46 concerning the flash of the eMMC. Apr 14 14:50:14 Could you be more specific ? It's been a long time, and I didn't find anything. Apr 14 14:50:51 What do you mean by "So you must to write it to the boot partition otherwise it won't work" ? Apr 14 15:05:35 bluelightning, ah great thank you ! Apr 14 15:24:31 RP: hmm, I'm assuming the impact, performance wise, of adding a new item to OVERRIDES is fairly low unless it's used a great deal due to the cookie monster tracking at setvar time, is that a correct assumption? Apr 14 15:27:40 kergoth: its pretty low, yes Apr 14 15:28:25 kergoth: packaging code for something with a ton of modules is a good speed test of it Apr 14 15:28:36 (we add an overide per package) Apr 14 15:29:14 ah, right. that reminds me, i wonder if we should stop doing that and just explicitly check for the pkg-specific version.. in the past the override has bitten us when a pkg specific var references the non-specific value Apr 14 15:29:24 that's a good point, thanks Apr 14 15:30:42 kergoth: I think I tried that but there was a reason I didn't change it, some kind of subtle issue... Apr 14 15:31:18 wouldn't surprise me, there usually is some kind of subtle issue or corner case to such things Apr 14 15:38:39 do you know guys what recipe handle the file /etc/issue ? Apr 14 15:42:09 acidfu: base-files, iirc. Apr 14 15:42:14 oh great Apr 14 15:42:23 it's the a word that you can google easily "issue" Apr 14 15:42:25 thank you ;) Apr 14 15:42:34 it's not* Apr 14 15:45:23 acidfu: well, i just tried git grep -w issue in oe-core, and it gives results quickly ;-) Apr 14 16:56:03 I created my own layer. Is it possible to include all my recipes in that layer at once to the image which I am building? Apr 14 16:58:18 not automatically, no. you'll have to add them to IMAGE_INSTALL in the image recipe Apr 14 17:03:19 could make packagegroups if that fits your stuff... Apr 14 17:03:59 but is there some possibilty to add one recipe via "IMAGE_INSTALL" that includes all other recipes? Apr 14 17:05:31 if you create such a recipe, and add all the other recipes to it manually, yes Apr 14 17:06:19 RP, It looks like there might be more fragmentation then is healthy. I've deleted several milestone rcs that have been copied to downloads which should help. Apr 14 17:08:35 RP, The last error reported was an nfs soft lock up on March 1st. Apr 14 19:07:51 I am trying to use the "useradd" recipe example. However, "echo user:pw | chpasswd" fails because of missing root rights. Seems that I have to add --root (see https://lists.yoctoproject.org/pipermail/yocto/2014-December/022483.html) but where exactly in that command? Apr 14 19:13:35 what would be the general approach to get root rights in "do_install"? Apr 14 19:28:24 do_install is already running under pseudo, which makes you already seem to be root.. Apr 14 19:30:35 so why do I get the following error: DEBUG: Executing shell function do_install chpasswd: cannot lock /etc/passwd; try again later. Apr 14 19:31:12 i thought root rights might be missing in that echo user:pw | chpasswd command Apr 14 19:31:32 no idea, never used the useradd class, but it seems to be working for everyone else.. Apr 14 19:31:34 * kergoth shrugs Apr 14 19:31:54 no, have a look here: https://lists.yoctoproject.org/pipermail/yocto/2014-December/022483.html Apr 14 19:32:02 same problem Apr 14 19:33:55 looks pretty clear to me Apr 14 19:34:03 it's trying to write to /etc instead of ${D}/etc inside the rootfs Apr 14 19:34:09 add —root ${D} to the useradd commandline Apr 14 19:59:44 warthog9: who would be the best person to ask about bare metal probe support for the minnowmax? Apr 14 20:03:22 DarkKnight: what kind of bare metal probing? Apr 14 20:03:28 DarkKnight: you thinking jtag? Apr 14 20:07:57 warthog9: yep. Apr 14 20:08:46 darknighte: best answer I can give right now is we have an xdp/itp lure for the MAX, but that's not terribly useful to anyone who doesn't have access to Intel's debugging tools Apr 14 20:09:17 darknighte: we have been digging through a path to try and enable a normal jtag interface and we think we've just about got something on that front Apr 14 20:09:18 right. that's what I've found so far. what's the damage for the Intel debugging tools? Apr 14 20:09:41 * darknighte realizes that he should have asked this in #minnow Apr 14 20:09:45 darknighte: no idea, but it involves NDAs and many dollars I think Apr 14 20:09:58 darknighte: I'm just everywhere ;-) Apr 14 20:38:48 sgw_: ping Apr 14 20:40:26 hi ulf` Apr 14 21:54:00 * kergoth notices that changing OVERRIDES even to add a new override that isn't used anywhere causes glibc/nativesdk-glibc to rebiuld, even if that override isn't used anywhere.. thankfully easy to fix **** ENDING LOGGING AT Wed Apr 15 02:59:58 2015