[yocto] Can't boot to initramfs

Moritz Porst moritz.porst at gmx.de
Fri Jul 12 01:17:57 PDT 2019 

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
Otherwise in your machine config via the variable "APPEND", e.g. APPEND
+= "quiet shell"
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.
>
> Thank you
>
> On 7/12/19, JH <jupiter.hce at gmail.com> wrote:
>> Hi Moritz,
>>
>> I could not find zImage-initramfs:
>>
>> $ grep zImage tempfile
>>
>> ARCH_DEFAULT_KERNELIMAGETYPE="bzImage"
>> KERNEL_IMAGETYPE="bzImage"
>> KERNEL_IMAGETYPES="bzImage"
>> QB_DEFAULT_KERNEL="bzImage"
>>
>> $ grep zImage-initramfs tempfile
>>
>> $ grep INITRAMFS_IMAGE_BUNDLE tempfile
>>
>> # $INITRAMFS_IMAGE_BUNDLE
>> INITRAMFS_IMAGE_BUNDLE="1"
>>
>> $ grep INITRAMFS_FSTYPES tempfile
>> INITRAMFS_FSTYPES="cpio.gz"
>>
>> I added PACKAGE_INSTALL += "initramfs-module-debug" and I added
>> "core-image-minimal-initramfs.bbappend" coppied from yours:
>>
>> $ cat core-image-minimal-initramfs.bbappend
>>
>> PACKAGE_INSTALL += "\
>>                          busybox \
>>                          base-files \
>>                          base-passwd \
>>                          bash \
>>                          util-linux-lsblk \
>>                          vim \
>>                          "
>>
>> 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.
>>
>> $ 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.porst at 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 \
>>>>                          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.porst at 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.porst at 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.porst at 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.porst at 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 at yoctoproject.org
>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto

More information about the yocto mailing list