Re: [yocto] PXE Boot NFS not working

[Raymond Yeung]

Thanks a lot Alim for the detail step-by-step, for both modes.  I'd like to 
stay with legacy mode with pxelinux.0 for now.  I'm doing pretty much the same 
as what you described below, with exceptions -


  1.  I'm not using vesamenu.c32.  Instead menu.32 is used, though I don't 
think that would be an issue.
  2.  I use "kernel image/bzImage" instead of "linux image/bzImage".  Still 
this shouldn't be an issue.
  3.  With the "append" line, I've a question - what is the significance of the 
options "hard, tcp, intr"?  I currently don't use them.


Since my last email this morning, I'd made some progress -


  1.  I figured out how to reconfigure the kernel with bitbake menuconfig to 
change my Ethernet driver from .ko to part of kernel.
  2.  I now have a confusing situation, due to Avahi-daemon in the mix.  
PXEBoot would request IP address via DHCP.  Then when this NFS boot runs, it 
too uses DHCP, and allocates a different IP address.  I suppose this is fine, 
so long as I've enough IP address to spare.  However, Avahi-daemon also request 
IP address and get the board yet another IP address.  I've yet to figure out 
how to turn off Avahi-daemon.  And NFS boot still doesn't work (I don't see the 
mount point with "df -h").
  3.  Client side uses NFS v4.1 while server side uses v3.  Would this be a 
problem?  I suppose there must be backward compatibility built into NFS.


Also, in the "Append" line of pxelinux.cfg/default, I add nfsrootdebug.  What 
sort of NFS debugs should I see?  I only see two NFS logs, and 4 RPC calls.  Is 
there anyway to turn up the verbosity so I know how NFS client fails?


Until I get some more insights to above, I'd proceed to investigate the other 
issue - why my kernel initialization would need to wait for any "removable 
media" indefinitely, and see if I could fix/change this.


Thanks,

Raymond




From: Hussin, Mohamad Noor Alim 
Sent: Thursday, April 26, 2018 8:30 PM
To: Raymond Yeung; yocto@yoctoproject.org
Subject: RE: PXE Boot NFS not working


You are using PXE with legacy BIOS as you use pxelinux.0 . To configure PXE 
with legacy BIOS follow these instruction

Note: PXE server IP = 192.168.1.2

Target IP = 192.168.1.1



On PXE server

1.   make sure DHCP, NFS & TFTP services are up and running.

2.   change the filename “pxelinux.0”; in /etc/dhcp/dhcpd.conf. Then 
restart your DHCP service.

3.   Put your kernel to /path/to/tftpboot/image/ and extract your rootfs to 
/srv/rootfs/.

4.   Create a file in /path/to/tftpboot/pxelinux.cfg/default. The content 
should like this

include menu.cfg

default vesamenu.c32

prompt 0

timeout 5

label Manual Netboot genericx86-64

menu label Netboot genericx86-64

linux image/bzImage

append root=/dev/nfs rw nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp



if you want to use PXE with GRUB, bootx64.efi, you need to enable UEFI  instead 
of legacy BIOS in BIOS configuration. Follow these instruction.

on PXE server

1.   make sure DHCP, NFS & TFTP services are up and running.

2.   change the filename “bootx64.efi”; in /etc/dhcp/dhcpd.conf. Then 
restart your DHCP service.

3.   Put your kernel to /path/to/tftpboot/image/ and extract your rootfs to 
/srv/rootfs/.

4.   If you want to get into GRUB,

a.   comment the commands from /path/to/tftpboot/grub/grub.cfg to avoid 
grub automatically load the kernel from network.

b.  On GRUB, press “TAB” key to list available command. Or you can try use 
this command

   i.  net_bootp

 ii.  linux 
(tftp,pxeserverip)/image/bzImage root=/dev/nfs rw 
nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp

iii.  boot

5.   if you want boot automatically to NFS, create a file called grub.cfg 
in /path/to/tftpboot/grub.cfg. your grub.cfg should look like this

Set timeout 5

menuentry " genericx86-64" {

linux image/bzImage root=/dev/nfs rw 
nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp

initrd image/initrd

}

6.   When your device boot, it will download bootx64.efi and the message 
something like this
>>Start PXE over IPv4.

Station IP address is 192.168.1.1

Server IP address is 192.168.1.2

NBP filename is bootx64.efi

NBP filesize is 1137016 Bytes

Downloading NBP file...

NBP file downloaded successfully.



Please note that I did not use initramfs or initrd as my kernel already have 
network module build-in. To build your kernel with network module, you need to 
know which module need to build-in into your kernel. Simply boot your device 
using *.hhdimg from USB stick. Then check loaded kernel module from your device.

$ lsmod

Find the module something with network. Yes it is a little bit tricky.



Build your kernel in host machine.

$ bitbake virtual/kernel 

Re: [yocto] PXE Boot NFS not working

[Hussin, Mohamad Noor Alim]

You are using PXE with legacy BIOS as you use pxelinux.0 . To configure PXE 
with legacy BIOS follow these instruction
Note: PXE server IP = 192.168.1.2
Target IP = 192.168.1.1

On PXE server

1.   make sure DHCP, NFS & TFTP services are up and running.

2.   change the filename "pxelinux.0"; in /etc/dhcp/dhcpd.conf. Then 
restart your DHCP service.

3.   Put your kernel to /path/to/tftpboot/image/ and extract your rootfs to 
/srv/rootfs/.

4.   Create a file in /path/to/tftpboot/pxelinux.cfg/default. The content 
should like this

include menu.cfg

default vesamenu.c32

prompt 0

timeout 5

label Manual Netboot genericx86-64

menu label Netboot genericx86-64

linux image/bzImage

append root=/dev/nfs rw nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp

if you want to use PXE with GRUB, bootx64.efi, you need to enable UEFI  instead 
of legacy BIOS in BIOS configuration. Follow these instruction.
on PXE server

1.   make sure DHCP, NFS & TFTP services are up and running.

2.   change the filename "bootx64.efi"; in /etc/dhcp/dhcpd.conf. Then 
restart your DHCP service.

3.   Put your kernel to /path/to/tftpboot/image/ and extract your rootfs to 
/srv/rootfs/.

4.   If you want to get into GRUB,

a.   comment the commands from /path/to/tftpboot/grub/grub.cfg to avoid 
grub automatically load the kernel from network.

b.  On GRUB, press "TAB" key to list available command. Or you can try use 
this command

   i.  net_bootp

 ii.  linux 
(tftp,pxeserverip)/image/bzImage root=/dev/nfs rw 
nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp

iii.  boot

5.   if you want boot automatically to NFS, create a file called grub.cfg 
in /path/to/tftpboot/grub.cfg. your grub.cfg should look like this

Set timeout 5

menuentry " genericx86-64" {

linux image/bzImage root=/dev/nfs rw 
nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp

initrd image/initrd

}

6.   When your device boot, it will download bootx64.efi and the message 
something like this
>>Start PXE over IPv4.

Station IP address is 192.168.1.1

Server IP address is 192.168.1.2

NBP filename is bootx64.efi

NBP filesize is 1137016 Bytes

Downloading NBP file...

NBP file downloaded successfully.

Please note that I did not use initramfs or initrd as my kernel already have 
network module build-in. To build your kernel with network module, you need to 
know which module need to build-in into your kernel. Simply boot your device 
using *.hhdimg from USB stick. Then check loaded kernel module from your device.
$ lsmod
Find the module something with network. Yes it is a little bit tricky.

Build your kernel in host machine.
$ bitbake virtual/kernel -c menuconfig
A menu will popup and search your kernel module using key "/". Make sure symbol 
module [*] indicate build-in.
$ bitbake virtual/kernel

You also can create a kernel bundle with initramfs.  Read this 
https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#building-an-initramfs-image.
Maybe need to ask someone who are expert on kernel development on how to enable 
build-in kernel module.


Regards,
Alim Hussin

From: Raymond Yeung [mailto:rksye...@hotmail.com]
Sent: Friday, April 27, 2018 1:12 AM
To: Hussin, Mohamad Noor Alim ; 
yocto@yoctoproject.org
Subject: Re: PXE Boot NFS not working


Follow-up to my previous post, after seeing the reply below suggesting me not 
to use initramfs (but initrd is usable, right?).  BTW, I don't use bootx64.efi. 
 Instead, I use pxelinux.0 along with the other lib***.c32 files.



  1.  Is there a way to verify if GRUB (that I'm using) supports networking or 
not?  It seems to have very limited user commands available.
  2.  How do I get into GRUB?  I'd been into GRUB, more like accidentally.  The 
reply below refers to grub.cfg.  Is this cfg file stored on target, or on host 
(like pxelinux.cfg)?
  3.  How do I configure my build (and what yocto tool to use, if any) in order 
to get my network driver part of kernel, instead of being a LKM that isn't 
there when I need it for NFS boot?


From: Hussin, Mohamad Noor Alim 
>
Sent: Thursday, April 26, 2018 12:26 AM
To: Raymond Yeung; yocto@yoctoproject.org
Subject: RE: PXE Boot NFS not working


Refer to my post here 
https://lists.yoctoproject.org/pipermail/yocto/2018-April/040860.html



Don't use initramfs/initrd as it not working.





Regards,

Alim Hussin




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PXE Boot NFS not working

[Raymond Yeung]

Follow-up to my previous post, after seeing the reply below suggesting me not 
to use initramfs (but initrd is usable, right?).  BTW, I don't use bootx64.efi. 
 Instead, I use pxelinux.0 along with the other lib***.c32 files.


  1.  Is there a way to verify if GRUB (that I'm using) supports networking or 
not?  It seems to have very limited user commands available.
  2.  How do I get into GRUB?  I'd been into GRUB, more like accidentally.  The 
reply below refers to grub.cfg.  Is this cfg file stored on target, or on host 
(like pxelinux.cfg)?
  3.  How do I configure my build (and what yocto tool to use, if any) in order 
to get my network driver part of kernel, instead of being a LKM that isn't 
there when I need it for NFS boot?



From: Hussin, Mohamad Noor Alim 
Sent: Thursday, April 26, 2018 12:26 AM
To: Raymond Yeung; yocto@yoctoproject.org
Subject: RE: PXE Boot NFS not working


Refer to my post here 
https://lists.yoctoproject.org/pipermail/yocto/2018-April/040860.html



Don’t use initramfs/initrd as it not working.





Regards,

Alim Hussin



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] New Recipe Integration Issue

[Andre McCurdy]

On Thu, Apr 26, 2018 at 11:36 AM, Shakthi Pradeep (tpradeep)
 wrote:
> Thanks for the info Andre. What you are suggesting it to be done while 
> building an application over these libraries right?

No. The soname needs to be set when the library is linked.

> Any idea why the packaging is failing?

I don't think packaging is failing.

> Regards,
> Shakthi
>
> On 27/04/18, 12:00 AM, "Andre McCurdy"  wrote:
>
> On Thu, Apr 26, 2018 at 11:03 AM, Shakthi Pradeep (tpradeep)
>  wrote:
> > Hello Folks,
> >
> > I am trying to integrate an SDK which is very simple and small. 
> Building the
> > SDK generates an executable and few .so libraries.
> >
> > “bitbake sdk” command goes through fine but when I run “bitbake
> > wrlinux-image-glibc-std” to generate an ISO with SDK packages I am get
> > following error
> >
> > ...
> >
> > install -m 0755 ${S}/lib/libmvudrv.so
> > ${D}/${libdir}/libmvudrv.so.1.0.1
> >
> > ln -sf libmvudrv.so.1.0.1 ${D}/${libdir}/libmvudrv.so
>
> Unfortunately, creating versioned libraries requires more than just
> renaming and creating a symlink.
>
> If the library is going to be renamed during installation, then the
> soname (which is set within the library when the library is linked)
> needs to match a name which will exist in the target rootfs at
> runtime.
>
> In this case, since "libmvudrv.so.1.0.1" is the name which will be
> present at runtime, when the build creates libmvudrv.so, it needs to
> set the soname to "libmvudrv.so.1.0.1". ie add the following to the
> linker commandline:
>
>   -Wl,-soname,libmvudrv.so.1.0.1
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Weston Failure

[Zoran Stojsavljevic]

> A log file (/var/log/weston.log)is mentioned in the western-start script file 
> .

Western or Weston? I never saw anything as western, considering GFX
(you mentioned western twice)?! Probably you meant Weston.

Weston is Wayland backend, actually, Wayland is more of a GFX
communication protocol, and Weston is one of the several compositors
behind Wayland. Other well-known compositor is Mutter, as common
example.

It seems that you have timing synchronisation problem (race effect)
between EGL's (Embedded Graphic Library) loadable modules components,
and the best place to ask about such things is exactly:
http://wayland.freedesktop.org
Bug reports to:
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=1.9.0

Best Regards,
Zoran
___

On Thu, Apr 26, 2018 at 9:15 AM, Nishina A. Pervin
 wrote:
> Hi Sir ,
>
>
>
> We are using weston (1.9.0) for loading our application on IMx6Q sabreauto
> board.
>
> sometimes it fails to start and sometime it works after reboot or after
> restart Weston services.
>
> I found that there is some synchronisation issue occurred in loading western
> service at the boot time.
>
> A log file (/var/log/weston.log)is mentioned in the western-start script
> file .
>
> Form the log file I get the details about error like below
>
>
>
> Date: 2018-02-09 UTC
>
> [09:47:32.751] weston 1.9.0
>
>http://wayland.freedesktop.org
>
>Bug reports to:
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=1.9.0
>
>Build: 1.8.93-2-gb05cdb8 configure.ac: bump to version 1.9.0
> for the official release (2015-09-21 18:11:26 -0700)
>
> [09:47:32.752] OS: Linux, 4.1.15-rt18-2.0.0-avb-1_1_cand20170403+gb63f3f5,
> #9 SMP PREEMPT RT Wed Mar 14 12:37:25 IST 2018, armv7l
>
> [09:47:32.754] Using config file '/home/root/.config/weston.ini'
>
> [09:47:32.757] Loading module '/usr/lib/weston/fbdev-backend.so'
>
> [09:47:32.981] Output repaint window is 7 ms maximum.
>
> [09:47:32.981] initializing fbdev backend
>
> [09:47:33.018] Loading module '/usr/lib/weston/gl-renderer.so'
>
> [09:47:33.026] warning: either no EGL_EXT_platform_base support or specific
> platform support; falling back to eglGetDisplay.
>
> [09:47:33.027] failed to create display
>
> [09:47:33.027] gl_renderer_create failed.
>
> [09:47:33.027] fatal: failed to create compositor backend
>
>
>
>
>
> Could you please help me to resolve this issue.
>
>
>
>
>
> Regards
>
> Nishina
>
>
>
> 
>
> Confidentiality Statement / Disclaimer : This message and any attachments is
> intended for the sole use of the intended recipient. It may contain
> confidential information. Any unauthorized use, dissemination or
> modification is strictly prohibited. If you are not the intended recipient,
> please notify the sender immediately then delete it from all your systems,
> and do not copy, use or print. Internet communications are not secure and it
> is the responsibility of the recipient to make sure that it is
> virus/malicious code exempt.
>
> The company/sender cannot be responsible for any unauthorized alterations or
> modifications made to the contents. If you require any form of confirmation
> of the contents, please contact the company/sender. The company/sender is
> not liable for any errors or omissions in the content of this message.
>
> 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] New Recipe Integration Issue

[Shakthi Pradeep (tpradeep)]

Thanks for the info Andre. What you are suggesting it to be done while building 
an application over these libraries right?

Any idea why the packaging is failing?

Regards,
Shakthi

On 27/04/18, 12:00 AM, "Andre McCurdy"  wrote:

On Thu, Apr 26, 2018 at 11:03 AM, Shakthi Pradeep (tpradeep)
 wrote:
> Hello Folks,
>
> I am trying to integrate an SDK which is very simple and small. Building 
the
> SDK generates an executable and few .so libraries.
>
> “bitbake sdk” command goes through fine but when I run “bitbake
> wrlinux-image-glibc-std” to generate an ISO with SDK packages I am get
> following error
>
> ...
>
> install -m 0755 ${S}/lib/libmvudrv.so
> ${D}/${libdir}/libmvudrv.so.1.0.1
>
> ln -sf libmvudrv.so.1.0.1 ${D}/${libdir}/libmvudrv.so

Unfortunately, creating versioned libraries requires more than just
renaming and creating a symlink.

If the library is going to be renamed during installation, then the
soname (which is set within the library when the library is linked)
needs to match a name which will exist in the target rootfs at
runtime.

In this case, since "libmvudrv.so.1.0.1" is the name which will be
present at runtime, when the build creates libmvudrv.so, it needs to
set the soname to "libmvudrv.so.1.0.1". ie add the following to the
linker commandline:

  -Wl,-soname,libmvudrv.so.1.0.1


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] New Recipe Integration Issue

[Andre McCurdy]

On Thu, Apr 26, 2018 at 11:03 AM, Shakthi Pradeep (tpradeep)
 wrote:
> Hello Folks,
>
> I am trying to integrate an SDK which is very simple and small. Building the
> SDK generates an executable and few .so libraries.
>
> “bitbake sdk” command goes through fine but when I run “bitbake
> wrlinux-image-glibc-std” to generate an ISO with SDK packages I am get
> following error
>
> ...
>
> install -m 0755 ${S}/lib/libmvudrv.so
> ${D}/${libdir}/libmvudrv.so.1.0.1
>
> ln -sf libmvudrv.so.1.0.1 ${D}/${libdir}/libmvudrv.so

Unfortunately, creating versioned libraries requires more than just
renaming and creating a symlink.

If the library is going to be renamed during installation, then the
soname (which is set within the library when the library is linked)
needs to match a name which will exist in the target rootfs at
runtime.

In this case, since "libmvudrv.so.1.0.1" is the name which will be
present at runtime, when the build creates libmvudrv.so, it needs to
set the soname to "libmvudrv.so.1.0.1". ie add the following to the
linker commandline:

  -Wl,-soname,libmvudrv.so.1.0.1
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] New Recipe Integration Issue

[Shakthi Pradeep (tpradeep)]

Hello Folks,

I am trying to integrate an SDK which is very simple and small. Building the 
SDK generates an executable and few .so libraries.

“bitbake sdk” command goes through fine but when I run “bitbake 
wrlinux-image-glibc-std” to generate an ISO with SDK packages I am get 
following error


/ Build Log /

bgl-ads-4169 # bitbake wrlinux-image-glibc-std
Loading cache: 100% 
||
 Time: 0:00:01
Loaded 5193 entries from dependency cache.
Parsing recipes: 100% 
|##|
 Time: 0:00:01
Parsing of 2223 .bb files complete (2221 cached, 2 parsed). 5195 targets, 2526 
skipped, 16 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal-4.8"
DISTRO= "wrlinux-small"
DISTRO_VERSION= "9.0.0.10"
MACHINE   = "intel-x86-64"
DEFAULTTUNE   = "corei7-64"
TARGET_SYS= "x86_64-wrs-linux"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU= ""
lib32:  DEFAULTTUNE   = "corei7-32"
lib32:  TARGET_SYS= "i686-wrsmllib32-linux"
lib32:  TUNE_FEATURES = "m32 corei7"
wr-base   = "HEAD:18310d224e6c2afa478900cb24457ad7f39dc365"
wr-fixes  = "HEAD:b07a1d75c651fa4c267d18694fcd9d54973b320e"
wrlinux   = "HEAD:4e91be83f02898b9a6186d07e4da451606f2df3b"
intel-x86 = "HEAD:6ef28fd1ecd25b0ec2f574dc61d624012c59d123"
meta  = "HEAD:17450ac189cfdb0df281c63cfaf9fb7622f3861b"
meta-initramfs
meta-python
meta-networking
meta-oe
meta-perl
meta-webserver= "HEAD:3d657a42e37a8fd653d6c76220d85fb0f8c07fd4"
wr-template   = "HEAD:4ca39f39de1a649e0fc9cffa1f048803f609fdb4"
meta-xfce = "HEAD:3d657a42e37a8fd653d6c76220d85fb0f8c07fd4"
wr-kernel = "HEAD:c9d11b7c7e24d97120adcacb0f5c55cede0dc996"
meta-gnome
meta-filesystems  = "HEAD:3d657a42e37a8fd653d6c76220d85fb0f8c07fd4"
meta-realtime = "HEAD:02733b143bdfe02175db723a582913acf3d53ebd"
meta-virtualization = "HEAD:c6c681749238a97c1148625330dbc694629f0525"
wr-base-dl= "HEAD:029c9b02e776787cb1ce84cb61e4957414a4e229"
oe-core-dl-2.2= "HEAD:03ac056beaad1949983e74a34b3cd3c676465720"
meta-initramfs-dl-2.2 = "HEAD:1347989107c2f97644b18d862f850fd4dc0e104e"
meta-python-dl-2.2 = "HEAD:92e1f001d07e66b6b612d26910b72185ce2b5430"
meta-networking-dl-2.2 = "HEAD:724dbc0d839c258e7feb96a506c1aaeae4ed94d0"
meta-oe-dl-2.2= "HEAD:06d007644151f6e099b9b4e9368299e5ac73a5f1"
meta-perl-dl-2.2  = "HEAD:4d65c8cf72a198d849104cd3f213b6f3777f7431"
meta-webserver-dl-2.2 = "HEAD:ec10bc34d57bd4f8f1a8ff4d6fff993d45c754a0"
meta-xfce-dl-2.2  = "HEAD:b5c398839240694a6dc86ae5872f1d5fa39df8a8"
wr-kernel-dl  = "HEAD:a8298e914bbcc0a09feb6287d1e5ed200be49d89"
meta-gnome-dl-2.2 = "HEAD:86e40dcfb44212cfeed26cae972edd24c1c99324"
meta-filesystems-dl-2.2 = "HEAD:ffa26ce28c1a1ddd181aedc6dbc95c2b539f35a4"
meta-realtime-dl-2.2 = "HEAD:edb1581f9a8b3f5e5f0f3b775bf173095ecaa9f3"
meta-virtualization-dl-2.2 = "HEAD:710a214c83b65744a3980d97411a1b421ec28ffa"
local
meta-minimal-docker = "master:caadc243217c9d9859966437c488f3e43662dc2d"

Initialising tasks: 100% 
|###|
 Time: 0:00:11
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: wrlinux-image-glibc-std-1.0-r5 do_rootfs: Unable to install packages. 
Command 
'/nobackup/tpradeep/os-sdk-dev/os-sdk/repos/windriver/wrl9/build/tmp/sysroots/x86_64-linux/usr/bin/smart
 --log-level=warning 
--data-dir=/nobackup/tpradeep/os-sdk-dev/os-sdk/repos/windriver/wrl9/build/tmp/work/intel_x86_64-wrs-linux/wrlinux-image-glibc-std/1.0-r5/rootfs/var/lib/smart
 install -y packagegroup-wr-core-python@corei7_64 rtl8723bs-bt@corei7_64 
irqbalance@corei7_64 smartpm@corei7_64 dhcp-server@corei7_64 
dosfstools@corei7_64 kernel-modules@intel_x86_64 eee-acpi-scripts@corei7_64 
packagegroup-wr-core-db@corei7_64 lmsensors@corei7_64 sdk@corei7_64 
packagegroup-wr-boot@intel_x86_64 rtl8723bs@corei7_64 hostapd@corei7_64 
pm-utils@corei7_64 packagegroup-wr-base-discrete-tools@corei7_64 
packagegroup-wr-core-sys-util@corei7_64 packagegroup-wr-core-net@corei7_64 
dhcp-server-config@corei7_64 wpa-supplicant@corei7_64 alsa-utils@corei7_64 
packagegroup-base-extended@intel_x86_64 grub-efi@corei7_64 
lmsensors-sensors@corei7_64 powertop@corei7_64 
packagegroup-wr-core-mail@corei7_64 wireless-tools@corei7_64 
packagegroup-wr-core-interactive@corei7_64 microcode-ctl@corei7_64 
docker@corei7_64 hostap-utils@corei7_64 packagegroup-wr-base-net@corei7_64 
rpm@corei7_64 nfs-utils-client@corei7_64 packagegroup-wr-core-perl@corei7_64 
packagegroup-wr-base@corei7_64 i2c-tools@corei7_64 
packagegroup-wr-core-util@corei7_64' returned 1:
Loading cache...
Updating cache...   

Re: [yocto] yocto jethro failed on gettext-native

[Zoran Stojsavljevic]

> I deleted all the build-imx6ulevk folder and build everything from
> scratch with only one thread, waited a few hours for compilation and now
> its working ;)

Still, I am struggling to understand why??? What is the requirement
behind this ask?

As we see, it is much longer (one thread only) than on 14.04!?

Could you, please, do it on Ubuntu 17.04, or 17.10 (i bet, you
can't)??? And why, after all???

Zoran
___

On Thu, Apr 26, 2018 at 5:53 PM, Oliver Graute  wrote:
> On 25/04/18, Andre McCurdy wrote:
>> On Wed, Apr 25, 2018 at 8:03 AM, Oliver Graute  
>> wrote:
>> > Hello list,
>> >
>> > I try to compile yocto jethro environment which is working
>> > on a Ubuntu 14.04 installation. But not on a Kubuntu 16.04.
>> >
>> > The compilations stops on gettext-native.
>> >
>> > bitbake -k fsl-image-mfgtool-initramfs
>> >
>> > | x86_64-linux-libtool:   error: 'libgettextsrc_la-message.lo' is not a 
>> > valid libtool object
>>
>> libgettextsrc_la-message.lo should be a short text file. Could you
>> find it in your build tree and post a copy?
>>
>
> the file was a zero byte file. All other *.lo files in that directory
> was zero byte too. I assume because of a system crash I had before.
>
> Just a bitbake -c cleansstate and rebuild of gettext-native didn't fixed that.
>
> I deleted all the build-imx6ulevk folder and build everything from
> scratch with only one thread, waited a few hours for compilation and now
> its working ;)
>
>> > Some ideas whats the cause for this error?
>>
>> At a guess, something a little unusual with the setup of your Kubuntu
>> system. Combining Ubuntu 16.04 with OE 2.0 isn't so out of the
>> ordinary and others would certainly have hit the problem before now if
>> it was always seen.
>>
>> Did you install all the standard host dependencies?
>>
>>   
>> https://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html#packages
>>
>
> yes but thanks for the link as reference.
>
> Best regards,
>
> Oliver
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto jethro failed on gettext-native

[Oliver Graute]

On 25/04/18, Andre McCurdy wrote:
> On Wed, Apr 25, 2018 at 8:03 AM, Oliver Graute  
> wrote:
> > Hello list,
> >
> > I try to compile yocto jethro environment which is working
> > on a Ubuntu 14.04 installation. But not on a Kubuntu 16.04.
> >
> > The compilations stops on gettext-native.
> >
> > bitbake -k fsl-image-mfgtool-initramfs
> >
> > | x86_64-linux-libtool:   error: 'libgettextsrc_la-message.lo' is not a 
> > valid libtool object
> 
> libgettextsrc_la-message.lo should be a short text file. Could you
> find it in your build tree and post a copy?
> 

the file was a zero byte file. All other *.lo files in that directory
was zero byte too. I assume because of a system crash I had before.

Just a bitbake -c cleansstate and rebuild of gettext-native didn't fixed that.

I deleted all the build-imx6ulevk folder and build everything from
scratch with only one thread, waited a few hours for compilation and now
its working ;)

> > Some ideas whats the cause for this error?
> 
> At a guess, something a little unusual with the setup of your Kubuntu
> system. Combining Ubuntu 16.04 with OE 2.0 isn't so out of the
> ordinary and others would certainly have hit the problem before now if
> it was always seen.
> 
> Did you install all the standard host dependencies?
> 
>   
> https://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html#packages
> 

yes but thanks for the link as reference.

Best regards,

Oliver 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Generation of images when using repository of signed rpm packages

[Iván Castell]

Hello forum.

I have two questions related with the generation of images when the distro
is configured to use a repository of rpm packages signed with gpg.

First question: after running the "bitbake my-image.bb" command, the build
process stops with this message of error:

ERROR: myimage-1.0-r0 do_rootfs: [log_check] myimage: found 1 error message
in the logfile:
[log_check] Failed to synchronize cache for repo 'yocto-rpm', disabling.

Surprisingly, this error is only raised when the http server (that serving
the rpm packages, i.e. nginx) is stopped (not listening). If the http
server is started (listening), then the error message doesn't appear and
the generation of the image works fine. I don't understand why the build
process needs syncronizing with the rpm repository to build the image.

Second question: I am using dnf client to manage rpm packages. My layer
creates a dnf_%.bbappend file to include this configuration file in the
image built:

$ cat yocto-rpm.repo
[yocto-rpm]
name=Rocko Yocto Repo
baseurl=http:///rpm
enabled=1
gpgcheck=1

If the variable gpgcheck=0, then the image is build fine even if the http
server is stopped. How is that possible? Is yocto analyzing content of a
file installed on the final image to define how the build process is
managed?

Thank you in advance for your time! :)



-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: i...@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains is confidential information
exclusively intended for the recipients. Any divulgation, copy or
distribution to third parties is prohibited without written permission of
NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
the sender immediately. In accordance with Law 15/1999 of 13 December on
the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
has adopted the necessary measures to ensure the confidential treatment of
personal information. We also inform you that you can exercise your access,
rectification, cancellation and opposition rights by send us a mail to:
i...@nayarsystems.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] loopback interface not brought up on 'ifup -a' automatically

[Daniel Ceusan]

Hi,

I am building an image using rocko branch and installing ifupdown package:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/ifupdown/ifupdown_0.8.16.bb?h=rocko 



If there is no loopback definition in /etc/network/interfaces file, then 
"ifup -a" brings lo interface up automatically.


If I define the lo interface:
"auto lo
iface lo inet loopback"
then lo interface is not brought up automatically by "ifup -a", even 
though from ifupdown's changelog/documentation it says both approaches 
should work.


Anyone else seen this behavior?

Thanks and regards,
Daniel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Weston Failure

[Nishina A. Pervin]

Hi Sir ,

We are using weston (1.9.0) for loading our application on IMx6Q sabreauto 
board.
sometimes it fails to start and sometime it works after reboot or after restart 
Weston services.
I found that there is some synchronisation issue occurred in loading western 
service at the boot time.
A log file (/var/log/weston.log)is mentioned in the western-start script file .
Form the log file I get the details about error like below

Date: 2018-02-09 UTC
[09:47:32.751] weston 1.9.0
   http://wayland.freedesktop.org
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=1.9.0
   Build: 1.8.93-2-gb05cdb8 configure.ac: bump to version 1.9.0 for 
the official release (2015-09-21 18:11:26 -0700)
[09:47:32.752] OS: Linux, 4.1.15-rt18-2.0.0-avb-1_1_cand20170403+gb63f3f5, #9 
SMP PREEMPT RT Wed Mar 14 12:37:25 IST 2018, armv7l
[09:47:32.754] Using config file '/home/root/.config/weston.ini'
[09:47:32.757] Loading module '/usr/lib/weston/fbdev-backend.so'
[09:47:32.981] Output repaint window is 7 ms maximum.
[09:47:32.981] initializing fbdev backend
[09:47:33.018] Loading module '/usr/lib/weston/gl-renderer.so'
[09:47:33.026] warning: either no EGL_EXT_platform_base support or specific 
platform support; falling back to eglGetDisplay.
[09:47:33.027] failed to create display
[09:47:33.027] gl_renderer_create failed.
[09:47:33.027] fatal: failed to create compositor backend


Could you please help me to resolve this issue.


Regards
Nishina



Confidentiality Statement / Disclaimer : This message and any attachments is 
intended for the sole use of the intended recipient. It may contain 
confidential information. Any unauthorized use, dissemination or modification 
is strictly prohibited. If you are not the intended recipient, please notify 
the sender immediately then delete it from all your systems, and do not copy, 
use or print. Internet communications are not secure and it is the 
responsibility of the recipient to make sure that it is virus/malicious code 
exempt.

The company/sender cannot be responsible for any unauthorized alterations or 
modifications made to the contents. If you require any form of confirmation of 
the contents, please contact the company/sender. The company/sender is not 
liable for any errors or omissions in the content of this message.


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Configuring speed of SD card read

[Prakash Ks]

Can you elaborate little more.

On Thu, Apr 26, 2018 at 12:24 PM, Nishina A. Pervin <
nishina.per...@nestgroup.net> wrote:

> Hi
>
>
>
>
>
> I am using yocto  Krogoth  build  for imx6q Sabreauto board.
>
>
>
> What is the rate at which data is read from SD card? Can we configure it
> for higher speed from Uboot or Kernel
>
>
>
> Awaiting your favorable reply
>
>
>
> Regards,
>
> Nishina
> --
>
> *Confidentiality Statement / Disclaimer* : This message and any
> attachments is intended for the sole use of the intended recipient. It may
> contain confidential information. Any unauthorized use, dissemination or
> modification is strictly prohibited. If you are not the intended recipient,
> please notify the sender immediately then delete it from all your systems,
> and do not copy, use or print. Internet communications are not secure and
> it is the responsibility of the recipient to make sure that it is
> virus/malicious code exempt.
>
> The company/sender cannot be responsible for any unauthorized alterations
> or modifications made to the contents. If you require any form of
> confirmation of the contents, please contact the company/sender. The
> company/sender is not liable for any errors or omissions in the content of
> this message.
> --
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
Thanks and Regards,
Prakash K S
+91 9620140303
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PXE Boot NFS not working

[Hussin, Mohamad Noor Alim]

Refer to my post here 
https://lists.yoctoproject.org/pipermail/yocto/2018-April/040860.html

Don't use initramfs/initrd as it not working.


Regards,
Alim Hussin

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Raymond Yeung
Sent: Thursday, April 26, 2018 12:46 PM
To: yocto@yoctoproject.org
Subject: [yocto] PXE Boot NFS not working


I've an Intel Xeon-D board.  I could boot up the board with PXE booting.  
However, this seems to be always looking for "removable media"; if there is 
none, it would hang (in a .sh file).  I want to explore NFS approach.  So far, 
I've read up, experimented on NFS setup via pxelinux.cfg/default file.  I'm 
able to manually perform nfs mount from client side, but doing it via 
configuration file doesn't seem to work.



Now, I'm wondering if my bzImage and initrd files are built correct.  According 
to this article here:



https://wiki.yoctoproject.org/wiki/Poky_NFS_Root



Two requirements must be met.  First one is that the network driver must be 
built into the kernel rather than being a module.  Second one is to disable 
network init script.



Does anyone know how to do the above two items?  What recipe file(s) should I 
modify?



Thanks,

Raymond
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] PXE Boot NFS not working

[Raymond Yeung]

I've an Intel Xeon-D board.  I could boot up the board with PXE booting.  
However, this seems to be always looking for "removable media"; if there is 
none, it would hang (in a .sh file).  I want to explore NFS approach.  So far, 
I've read up, experimented on NFS setup via pxelinux.cfg/default file.  I'm 
able to manually perform nfs mount from client side, but doing it via 
configuration file doesn't seem to work.


Now, I'm wondering if my bzImage and initrd files are built correct.  According 
to this article here:


https://wiki.yoctoproject.org/wiki/Poky_NFS_Root


Two requirements must be met.  First one is that the network driver must be 
built into the kernel rather than being a module.  Second one is to disable 
network init script.


Does anyone know how to do the above two items?  What recipe file(s) should I 
modify?


Thanks,

Raymond
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Configuring speed of SD card read

[Nishina A. Pervin]

Hi


I am using yocto  Krogoth  build  for imx6q Sabreauto board.

What is the rate at which data is read from SD card? Can we configure it for 
higher speed from Uboot or Kernel

Awaiting your favorable reply

Regards,
Nishina


Confidentiality Statement / Disclaimer : This message and any attachments is 
intended for the sole use of the intended recipient. It may contain 
confidential information. Any unauthorized use, dissemination or modification 
is strictly prohibited. If you are not the intended recipient, please notify 
the sender immediately then delete it from all your systems, and do not copy, 
use or print. Internet communications are not secure and it is the 
responsibility of the recipient to make sure that it is virus/malicious code 
exempt.

The company/sender cannot be responsible for any unauthorized alterations or 
modifications made to the contents. If you require any form of confirmation of 
the contents, please contact the company/sender. The company/sender is not 
liable for any errors or omissions in the content of this message.


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto