Hi Moritz, On 7/12/19, Moritz Porst <moritz.po...@gmx.de> wrote: > Hey > > On 12.07.19 10:05, JH wrote: >>> BOOT_IMAGE=/bzImage root=PARTUUID=71d1d94a-83e8-4895-98eb-35309f58119f >> break=premount quiet rootwait rootwait rootfstype=ext4 >> console=ttyS0,115200 console=tty0 >> >> Which file did you add kernel boot command for bootargs, bootcmd, etc? >> >> I use meta-freescale, but I could not find BOOT_IMAGE is defined. > Ways I know to add boot arguments: > If you use .wic image via --append in the .wks file
Right, I use .wic image. > Otherwise in your machine config via the variable "APPEND", e.g. APPEND > += "quiet shell" OK, I added APPEND += "quiet shell" to my machine config file solar.conf. > the "BOOT_IMAGE" is not a yocto variable, it is the bootloader syntax. > Thus this depends on which bootloader you use, but yocto abstracts this. > However for all bootloaders I know before boot you can hit "e" to edit > the boot line manually. I use u-boot, I am currently running zImage-initramfs built from OpenWrt defined kernel boot arguement bootargs, bootcmd, console, etc. Although I can edit the u-boot kernel arguments during bootload running on imx6 ram, I really want to configure those arguments in Yocto to build a Yoctor zImage-initramfs. I guess there must be some ways to configure it for zImage-initramfs, but the meta-freescale/wic/imx-uboot-bootpart.wks and other wks files are all used for creating SD card image which I guess that cannot be used to build an initramfs image for running on RAM, but correct me I could be wrong. Here are kernel arguments when I run zImage-initramfs on imx6 ram: .... printenv baudrate=115200 board_name=ULZ-EVK board_rev=14X14 bootargs=console=ttymxc0,115200 earlycon init=/init ...... >>> But I still have troubles to add INITRAMFS_IMAGE = >>> "core-image-minimal-initramfs" or to run core-image-minimal-initramfs, >>> both had errors: >>> >>> $ MACHINE="solar" DISTRO="solar" bitbake core-image-minimal-initramfs >>> >>> ERROR: Nothing PROVIDES 'core-image-minimal-initramfs' >>> core-image-minimal-initramfs was skipped: incompatible with host >>> arm-oe-linux-gnueabi (not in COMPATIBLE_HOST) > in meta/recipes-core/images/core-image-minimal-initramfs.bb there is the > following line: > COMPATIBLE_HOST = "(i.86|x86_64).*-linux" > You could try to overwrite it in your .bbappend to the value "*-linux" > but I guess there is a reason for this line. Is the following core-image-minimal-initramfs.bbappend correct? I still got errors to build core-image-minimal-initramfs, I must misplace things here: $ cat core-image-minimal-initramfs.bbappend PACKAGE_INSTALL += "\ busybox \ base-files \ base-passwd \ bash \ util-linux-lsblk \ vim \ " COMPATIBLE_HOST = "(arm|arm-oe-linux-gnueabi).*-linux" $ MACHINE="solar" DISTRO="solar" bitbake core-image-minimal-initramfs ERROR: Nothing RPROVIDES 'initramfs-module-install' initramfs-module-install was skipped: incompatible with host arm-oe-linux-gnueabi (not in COMPATIBLE_HOST) Thank you very much. - jupiter >>> >>> $ MACHINE="solar" DISTRO="solar" bitbake solar-image >>> >>> ERROR: Nothing PROVIDES 'core-image-minimal-initramfs' >>> core-image-minimal-initramfs was skipped: incompatible with host >>> arm-oe-linux-gnueabi (not in COMPATIBLE_HOST) >>> ERROR: Required build target 'solar-image' has no buildable providers. >>> Missing or unbuildable dependency chain was: ['solar-image', >>> 'virtual/kernel', 'core-image-minimal-initramfs'] >>> >>> Sorry, still learning Yocto, what I could be missing? >>> >>>> BOOT_IMAGE=/bzImage root=PARTUUID=71d1d94a-83e8-4895-98eb-35309f58119f >>> break=premount quiet rootwait rootwait rootfstype=ext4 >>> console=ttyS0,115200 console=tty0 >>> >>> Which did you add kernel boot command for bootargs, bootcmd, etc as >>> above? I could not find BOOT_IMAGE (I use meta-freescale) >>> >>> Thank you very much. >>> >>> - jupiter >>> >>> On 7/12/19, Moritz Porst <moritz.po...@gmx.de> wrote: >>>> Forgot to CC Jupiter and the most important thing: >>>> >>>> PACKAGE_INSTALL += "initramfs-module-debug" (To my understanding this >>>> enables the rescue shell) >>>> >>>> On 12.07.19 08:22, Moritz Porst wrote: >>>>> Hey, >>>>> >>>>> The only thing I can add to what I already said is my >>>>> "core-image-minimal-initramfs.bbappend": >>>>> PACKAGE_INSTALL += "\ >>>>> busybox \ >>>>printenv baudrate=115200 board_name=ULZ-EVK board_rev=14X14> base-files \ >>>>> base-passwd \ >>>>> bash \ >>>>> util-linux-lsblk \ >>>>> vim \ >>>>> " >>>>> Jupiter, are you able to produce your zImage-initramfs now ? If not >>>>> further do the following: >>>>> >>>>> bitbake <your-image> -e > tempfile >>>>> [wait until done, then search] >>>>> grep <appropriate search word> tempfile >>>>> >>>>> where <appropriate search word> may be e.g.: zImage, zImage-initramfs, >>>>> INITRAMFS_IMAGE, INITRAMFS_IMAGE_BUNDLE >>>>> Especially check that all variables you set are not overwritten >>>>> somewhere else >>>>> >>>>> Best regards >>>>> Moritz >>>>> >>>>> On 12.07.19 06:36, Zoran Stojsavljevic wrote: >>>>>> Moritz, >>>>>> >>>>>> Thank you very much for this reply. It makes it very clear... What is >>>>>> the current State of Affairs for the topic. >>>>>> >>>>>> Let us see if there will be the improvement to this topic. I'll >>>>>> document this on one of my private GitHubs. And archive this email. >>>>>> >>>>>> Zoran >>>>>> _______ >>>>>> >>>>>> On Thu, Jul 11, 2019 at 12:39 PM Moritz Porst <moritz.po...@gmx.de> >>>>>> wrote: >>>>>>> Hello Zoran, Jupiter and list >>>>>>> >>>>>>> The configuration you sent seems to be correct. >>>>>>> >>>>>>> As I already said initramfs seems overly complicated in yocto. the >>>>>>> most >>>>>>> important thing to note is that 2 kernel images are created, one is >>>>>>> called bzImage (in my case) an the other bzImage-initramfs. However >>>>>>> only >>>>>>> the bzImage is written into the rootfs so you have to exchange them >>>>>>> manually. (in /boot/bzImage). I did not find a way of including the >>>>>>> bundled kernel right away. >>>>>>> >>>>>>> What you can do is to build core-image-minimal-initramfs and delete >>>>>>> the >>>>>>> symbolic link "bzImage", then recreate it and let it point to >>>>>>> bzImage-initramfs. However this is rather a hack than a solution. >>>>>>> >>>>>>> An other mistake I made was to use IMAGE_INSTALL_append which is >>>>>>> ignored. Use PACKAGE_INSTALL_append. >>>>>>> >>>>>>> Also I found that "break" does not work as a kernel parameter. Use >>>>>>> "shell" oder "debug-shell" instead. If you want to try to boot into >>>>>>> initramfs you can remove all parameters to the booting line so you >>>>>>> either end up in a kernel panic (initramfs doesn't work) or in the >>>>>>> rescue shell (initramfs works). >>>>>>> >>>>>>> In the end I actually managed to get a working shell, but I often >>>>>>> ended >>>>>>> up in initramfs telling me "dropping to shell..." but then freezing. >>>>>>> >>>>>>> I don't have access to my files right now but I can tell you more on >>>>>>> my >>>>>>> setup tomorrow. In case the solution is not included above. >>>>>>> >>>>>>> Best regards >>>>>>> Moritz >>>>>>> >>>>>>> On 11/07/2019 09:24, Zoran Stojsavljevic wrote: >>>>>>>> Hello Moritz, >>>>>>>> >>>>>>>> I need here some help from you. I'll try to reconstruct the parts >>>>>>>> of >>>>>>>> the local.conf you are using, so I (and Jupiter) can understand >>>>>>>> what >>>>>>>> should we do to also bundle kernel image with initramfs, to end up >>>>>>>> in >>>>>>>> Dracut/rescue shell. >>>>>>>> >>>>>>>> Here is what I anticipate after reading several YOCTO @ threads: >>>>>>>> >>>>>>>> IMAGE_FSTYPES_append = " cpio.gz" >>>>>>>> INITRAMFS_IMAGE = "core-image-minimal-initramfs" >>>>>>>> INITRAMFS_IMAGE_BUNDLE = "1" >>>>>>>> # debug: adds debug boot parameters like 'shell' and 'debug', see >>>>>>>> # meta/recipes-core/initrdscripts/initramfs-framework/debug for >>>>>>>> details >>>>>>>> # Could be removed in more minimal product image >>>>>>>> PACKAGE_INSTALL += "initramfs-module-debug" >>>>>>>> >>>>>>>> Could you, please, review these lines and fix, if something is not >>>>>>>> correct? >>>>>>>> >>>>>>>> I what I understood, this does the magic, but you could not stop in >>>>>>>> initramfs shell? Still, this problem is not solved? >>>>>>>> >>>>>>>>> I was following this site: https://wiki.debian.org/InitramfsDebug >>>>>>>>> Rescue shell (also known as initramfs shell) >>>>>>>>> Read man initramfs-tools to learn about the break=something kernel >>>>>>>>> parameter (where valid arguments for something are: top, modules, >>>>>>>>> premount, mount, mountroot, bottom, init), which starts a debug >>>>>>>>> shell. >>>>>>>>> You can try, for example, break=premount. You can edit >>>>>>>>> /boot/grub/grub.cfg >>>>>>>>> to add this to the end of the kernel line, or you can do it >>>>>>>>> interactively >>>>>>>>> from the grub boot menu: "e" to edit, and "b" to boot once you've >>>>>>>>> edited >>>>>>>>> the kernel line. >>>>>>>> Now, as my understanding is, you solved this problem actually >>>>>>>> adding >>>>>>>> to grub.cfg in command kernel line break=premount, and was able to >>>>>>>> stop in rescue shell?! Am I correct here? >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Zoran >>>>>>>> _______ >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 1, 2019 at 4:33 PM Moritz Porst <moritz.po...@gmx.de> >>>>>>>> wrote: >>>>>>>>> Hello, >>>>>>>>> I think I found the issue. ( see below ) >>>>>>>>> >>>>>>>>> On 01.07.19 15:57, Zoran Stojsavljevic wrote: >>>>>>>>> >>>>>>>>> Hello Moritz, >>>>>>>>> >>>>>>>>> Too hot here, in Belgrade... Where I am resting for the Time being >>>>>>>>> (actually, this message given to my invisible spying security >>>>>>>>> "angels" >>>>>>>>> on this list)... :-) Projected +38C degrees today. Too hot for >>>>>>>>> this >>>>>>>>> too old Siberian untouchable bobcat! >>>>>>>>> >>>>>>>>> Luckily it's a rather cold day in germany, thanks that you still >>>>>>>>> take the time to answer ! >>>>>>>>> >>>>>>>>> I started from the core-image-minimal to have a small image and >>>>>>>>> extended it with the features I need, which is e.g. a graphical >>>>>>>>> system. >>>>>>>>> The console=[...] part in the kernel command line is probably a >>>>>>>>> remnant but my image boots into the GUI. Is this a problem ? >>>>>>>>> >>>>>>>>> Nope, it is not. If you need to do it correctly, you should use >>>>>>>>> bitbake -k core-image-sato build command (my best educated guess). >>>>>>>>> Then, I do not feel comfortable seeing in your kernel command line >>>>>>>>> serial interface, do you agree? >>>>>>>>> >>>>>>>>> Yes that is true. >>>>>>>>> >>>>>>>>> YOCTO maintainers, any additional >>>>>>>>> advices? >>>>>>>>> >>>>>>>>> My bootloader is currently grub, the EFI is AM. >>>>>>>>> >>>>>>>>> Nope. Eeeeeeeeek. Wrong. Currently, your boot-loader is UEFI AMI. >>>>>>>>> Your >>>>>>>>> OS (Linux probably, U name it) boot-loader is GRUB2. Let us keep >>>>>>>>> it >>>>>>>>> contained, sane and sober. >>>>>>>>> >>>>>>>>> Sorry but I can't find this info in the EFI. >>>>>>>>> >>>>>>>>> Could you, please try the following command being root: dmesg | >>>>>>>>> grep >>>>>>>>> MCU. or grep mcu, or grep CPUID or grep cpuid?? Please, post >>>>>>>>> results >>>>>>>>> to this list (to me). >>>>>>>>> >>>>>>>>> No luck unfortunately (used grep -i) >>>>>>>>> >>>>>>>>> Could you, also, send to YOCTO list/me attached file: >>>>>>>>> /boot/microcode.cpio so I can somehow (?) inspect it? ;-) >>>>>>>>> >>>>>>>>> I send it to you directly, so I don't spam the list with a large >>>>>>>>> attachment. >>>>>>>>> >>>>>>>>> 2GB, single channel. >>>>>>>>> >>>>>>>>> All Cool. E3825 by HW/silicon design could/does NOT support >>>>>>>>> multiple >>>>>>>>> memory channels. ONLY single... But even YOCTO primes (INTEL ones >>>>>>>>> from >>>>>>>>> this list) are not gonna tell this to you. Not 'cause they are >>>>>>>>> nasty. >>>>>>>>> They are NOT aware/they are ignorant (with the purpose)! ;-)) >>>>>>>>> >>>>>>>>> No, the boot does not stop. Even if I do issue "break=premount" I >>>>>>>>> end up in my graphical interface with the rootfs mounted. This is >>>>>>>>> the >>>>>>>>> last message in the log: EXT4-fs (sdb2): re-mounted. Opts: (null) >>>>>>>>> The rootfs partition is always 2, so either /dev/sda2 or /dev/sdb2 >>>>>>>>> (when booting from stick) >>>>>>>>> >>>>>>>>> Yes, from https://pastebin.com/ya7iCtq7, so it is remounted rw, >>>>>>>>> not >>>>>>>>> read only. So, it seems that you have passed dracut phase. and >>>>>>>>> mounted >>>>>>>>> SD or flash rootfs. So, initramfs is NOT your true problem, is >>>>>>>>> it??? >>>>>>>>> >>>>>>>>> The thing is that the boot works but I want an initramfs that can >>>>>>>>> be used for updating (in case the rootfs is broken). However I >>>>>>>>> need to be able to intercept the boot process there because >>>>>>>>> otherwise I can't deploy an update mechanism, that's what I was >>>>>>>>> trying. >>>>>>>>> >>>>>>>>> Zoran >>>>>>>>> _______ >>>>>>>>> >>>>>>>>> >>>>>>>>> No, the boot does not stop. Even if I do issue "break=premount" I >>>>>>>>> end up >>>>>>>>> in my graphical interface with the rootfs mounted. This is the >>>>>>>>> last message >>>>>>>>> in the log: EXT4-fs (sdb2): re-mounted. Opts: (null) The rootfs >>>>>>>>> partition is >>>>>>>>> always 2, so either /dev/sda2 or /dev/sdb2 (when booting from >>>>>>>>> stick) >>>>>>>>> >>>>>>>>> >>>>>>>>> So for the issue... >>>>>>>>> I expected yocto to put the bundled bzImage onto my rootfs. This >>>>>>>>> was not the case. My image directory contains 2x bzImage, one >>>>>>>>> bundled and one unbundled. Apparently yocto puts the >un<bundled >>>>>>>>> image onto my /boot partition and uses it for boot. So of course I >>>>>>>>> couldn't access initramfs in this case. Now I get to the initramfs >>>>>>>>> statement "dropping to shell" if I intentionally boot with wrong >>>>>>>>> rootfs. >>>>>>>>> Still I don't get the interactive shell. >>>>>>>>> On the github ostroproject site I found this: >>>>>>>>> >>>>>>>>> # debug: adds debug boot parameters like 'shell' and 'debug', see >>>>>>>>> # meta/recipes-core/initrdscripts/initramfs-framework/debug for >>>>>>>>> details >>>>>>>>> # Could be removed in more minimal product image. >>>>>>>>> PACKAGE_INSTALL += "initramfs-module-debug" >>>>>>>>> >>>>>>>>> including the module-debug still does not enable me to get an >>>>>>>>> interactive shell. >>>>>>>>> I was following this site: https://wiki.debian.org/InitramfsDebug >>>>>>>>> I am aware that yocto is no debian but I expected that kernel >>>>>>>>> parameters (like 'break') would be independent of the >>>>>>>>> distribution. >>>>>>>>> >>>>>>>>> Lastly I do not really need the interactive shell, it is enough if >>>>>>>>> I can deploy a custom init script in the initramfs. Still I think >>>>>>>>> that getting an initramfs shell should be as simple as stating the >>>>>>>>> name of the initramfs image and setting the "INITRAMFS_DO_BUNDLE" >>>>>>>>> variable. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Moritz >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jul 1, 2019 at 11:20 AM Moritz Porst <moritz.po...@gmx.de> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello Zoran, >>>>>>>>> thanks for your answer >>>>>>>>> >>>>>>>>> On 28.06.19 14:26, Zoran Stojsavljevic wrote: >>>>>>>>> >>>>>>>>> INITRAMFS_IMAGE = "core-image-minimal-initramfs" >>>>>>>>> INITRAMFS_IMAGE_BUNDLE = "1" >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> You can find the /var/log/dmesg here: >>>>>>>>> https://pastebin.com/ya7iCtq7I >>>>>>>>> >>>>>>>>> Some hints... >>>>>>>>> >>>>>>>>> [1] Kernel command line: BOOT_IMAGE=/bzImage >>>>>>>>> root=PARTUUID=71d1d94a-83e8-4895-98eb-35309f58119f >>>>>>>>> break=premount quiet rootwait rootwait rootfstype=ext4 >>>>>>>>> console=ttyS0,115200 console=tty0 >>>>>>>>> >>>>>>>>> input: Video Bus as >>>>>>>>> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7 >>>>>>>>> fbcon: inteldrmfb (fb0) is primary device >>>>>>>>> Console: switching to colour frame buffer device 128x48 >>>>>>>>> i915 0000:00:02.0: fb0: inteldrmfb frame buffer device >>>>>>>>> snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops >>>>>>>>> i915_audio_component_bind_ops [i915]) >>>>>>>>> >>>>>>>>> Hmmmmm... You are using console and serial, but full i915 GFX >>>>>>>>> kernel driver is still included in the build??? >>>>>>>>> >>>>>>>>> I started from the core-image-minimal to have a small image and >>>>>>>>> extended it with the features I need, which is e.g. a graphical >>>>>>>>> system. The console=[...] part in the kernel command line is >>>>>>>>> probably a remnant but my image boots into the GUI. Is this a >>>>>>>>> problem ? >>>>>>>>> >>>>>>>>> >>>>>>>>> [2] efi: EFI v2.31 by American Megatrends >>>>>>>>> >>>>>>>>> Using AMI BIOS as boot loader FW... OK?! Am I correct? >>>>>>>>> >>>>>>>>> My bootloader is currently grub, the EFI is AM. >>>>>>>>> >>>>>>>>> >>>>>>>>> [3] smpboot: CPU0: Intel(R) Atom(TM) CPU E3825 @ 1.33GHz >>>>>>>>> (family: 0x6, model: 0x37, stepping: 0x9) >>>>>>>>> >>>>>>>>> This is CPUID ID 0x30679, which uses MCU... Which MicroCodeUnit? >>>>>>>>> M0130679xxx (info from AMI BIOS)? >>>>>>>>> >>>>>>>>> Sorry but I can't find this info in the EFI >>>>>>>>> >>>>>>>>> >>>>>>>>> [4] Using INTEL ATOM BYT E3825 dual core (sans Hyper-threading), >>>>>>>>> implies that you are using >>>>>>>>> 4GB (e820 messages) as single channel (one memory module DDR3 as >>>>>>>>> 4GB)! Am I correct (important)? >>>>>>>>> >>>>>>>>> 2GB, single channel. >>>>>>>>> >>>>>>>>> >>>>>>>>> [5] Dracut phase?! >>>>>>>>> >>>>>>>>> To my understanding the initramfs should be embedded in >>>>>>>>> /boot/bzImage. >>>>>>>>> However since I use an intel platform I also have a >>>>>>>>> /boot/microcode.cpio >>>>>>>>> which gets loaded via "initrd /microcode.cpio". Removing this line >>>>>>>>> in >>>>>>>>> grub does not enable me to get an initramfs prompt either (again, >>>>>>>>> using >>>>>>>>> break as option). >>>>>>>>> >>>>>>>>> You are obviously stopping in boot phase called dracut. Please, >>>>>>>>> try to mount by hand >>>>>>>>> /dev/sda(whatever)... You should use fdisk -l command, or do ls >>>>>>>>> -al /dev | grep sda to >>>>>>>>> dig out which partition you need to mount to /tmp dir to see >>>>>>>>> rootfstype=ext4 (HDD/SSD) >>>>>>>>> >>>>>>>>> No, the boot does not stop. Even if I do issue "break=premount" I >>>>>>>>> end up in my graphical interface with the rootfs mounted. This is >>>>>>>>> the last message in the log: >>>>>>>>> EXT4-fs (sdb2): re-mounted. Opts: (null) >>>>>>>>> The rootfs partition is always 2, so either /dev/sda2 or /dev/sdb2 >>>>>>>>> (when booting from stick) >>>>>>>>> >>>>>>>>> _______ >>>>>>>>> >>>>>>>>> Just thinking loud... .. . >>>>>>>>> >>>>>>>>> Hope this helps (has very little to do with YOCTO build system, >>>>>>>>> BTW) . ;-) >>>>>>>>> >>>>>>>>> Zoran >>>>>>>>> _______ >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jun 28, 2019 at 11:22 AM Moritz Porst >>>>>>>>> <moritz.po...@gmx.de> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> I currently try to deploy a single rootfs update mechanism for my >>>>>>>>> embedded device. I can't boot to initramfs using either "break" or >>>>>>>>> "break=premount" (without quotes...). I tried this in systemd-boot >>>>>>>>> and >>>>>>>>> grub-efi (always efi boot) but the boot process just continues >>>>>>>>> normally. >>>>>>>>> If I insert at the same point e.g. "quiet" this argument is >>>>>>>>> recognised. >>>>>>>>> I boot the .wic image with a separate boot partition from a USB >>>>>>>>> stick. >>>>>>>>> in local.conf I have set: >>>>>>>>> INITRAMFS_IMAGE = "core-image-minimal-initramfs" >>>>>>>>> INITRAMFS_IMAGE_BUNDLE = "1" >>>>>>>>> >>>>>>>>> In order to reduce complexity I now use the standard >>>>>>>>> core-image-minimal-initramfs without .bbappend. I can confirm >>>>>>>>> (from >>>>>>>>> seeing the task) that bitbake bundled the kernel with the >>>>>>>>> initramfs. >>>>>>>>> >>>>>>>>> You can find the /var/log/dmesg here: >>>>>>>>> https://pastebin.com/ya7iCtq7 >>>>>>>>> >>>>>>>>> To my understanding the initramfs should be embedded in >>>>>>>>> /boot/bzImage. >>>>>>>>> However since I use an intel platform I also have a >>>>>>>>> /boot/microcode.cpio >>>>>>>>> which gets loaded via "initrd /microcode.cpio". Removing this line >>>>>>>>> in >>>>>>>>> grub does not enable me to get an initramfs prompt either (again, >>>>>>>>> using >>>>>>>>> break as option). >>>>>>>>> >>>>>>>>> Did I forget some configuration or do I have to put the break >>>>>>>>> statement >>>>>>>>> at a very specific position within the "linux ..." boot command ? >>>>>>>>> Do you >>>>>>>>> know which bitbake variables to check ? (both set in local.conf do >>>>>>>>> not >>>>>>>>> get overwritten, already checked this). I got the thud branch >>>>>>>>> checked >>>>>>>>> out in all my meta-layers except for meta-qt which is currently on >>>>>>>>> master branch. >>>>>>>>> >>>>>>>>> Help is much appreciated ! >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Moritz >>>>>>>>> >>>>>>>>> -- >>>>>>>>> _______________________________________________ >>>>>>>>> yocto mailing list >>>>>>>>> yocto@yoctoproject.org >>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto