ERROR: Nothing PROVIDES ‘u-boot-fslc’
u-boot-fslc was skipped: PREFERRED_PROVIDER_virtual/bootloader set to u-boot-imx, not u-boot-fslc
ERROR: Nothing PROVIDES ‘u-boot-fw-utils-mender-auto-provided’
No eligible PROVIDERs exist for ‘u-boot-fw-utils-mender-auto-provided’
ERROR: Nothing RPROVIDES ‘u-boot-fw-utils-mender-auto-provided’ (but /home/triamp/imx-yocto/sources/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb RDEPENDS on or otherwise requires it)
No eligible RPROVIDERs exist for ‘u-boot-fw-utils-mender-auto-provided’
NOTE: Runtime target ‘u-boot-fw-utils-mender-auto-provided’ is unbuildable, removing…
Missing or unbuildable dependency chain was: [‘u-boot-fw-utils-mender-auto-provided’]
ERROR: Nothing RPROVIDES ‘u-boot-fw-utils-mender-auto-provided-dev’ (but /home/triamp/imx-yocto/sources/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb RDEPENDS on or otherwise requires it)
No eligible RPROVIDERs exist for ‘u-boot-fw-utils-mender-auto-provided-dev’
NOTE: Runtime target ‘u-boot-fw-utils-mender-auto-provided-dev’ is unbuildable, removing…
Missing or unbuildable dependency chain was: [‘u-boot-fw-utils-mender-auto-provided-dev’]
Your mender config URL for your server doesn’t look correct, it should contain the domain name that is embedded in your Https certificate so domain verification can happen.
As this looks like a local server, You will need an entry added either to your DNS server to resolve domain, or if testing only, added to your hosts file on your device
a. local.conf : add “MENDER_SERVER_URL = “https://192.168.0.119"”
b. remove layer: “meta-mender-demo”
c. set up mender-server-production, 1. ```
API_GATEWAY_DOMAIN_NAME=“mender.example.com”
STORAGE_PROXY_DOMAIN_NAME=”$API_GATEWAY_DOMAIN_NAME"
2. CERT_API_CN=$API_GATEWAY_DOMAIN_NAME CERT_STORAGE_CN=$STORAGE_PROXY_DOMAIN_NAME …/keygen
if “mender.example.com” is the domain you are using and its embedded in your https certificate then the MENDER_SERVER_URL should be “https://mender.example.com” and then perform either of the DNS actions i mentioned previously to ensure that dns resolution of that domain resolves to 192.168.0.119.
Most http clients (browser , curl, sdks) are normally by default set to check that the host of the opened connection to the server matches the one embedded in the certificate.
ok great. so what is the https://61.x.x.x entries in your previous screenshots, as that’s not a local private ipv4 address. In your previous screenshot, i would expect it to log https://mender.example.com
ok that looks a little better. So the next question what have you configured to do the domain name resolution? You either need to add an entry to your DNS server that your device is using, or easier for testing only add the following entry to your /etc/hosts file on your device
192.168.0.119 mender.example.com
the above assumes that your mender-server is on ipv4 192.168.0.119. however it looks like from your logs that you device is using ipv6, and trying to do DNS lookup against a dns server with ipv6 address 2001:4860:4860::8888 (this is a google DNS server). This is not going to resolve your local DNS entries for your testing of mender-server.
if you are using ipv6 then /etc/hosts example above will need the ipv6 address of your mender-server instead of the ipv4 address.
“if you are using ipv6 then /etc/hosts example above will need the ipv6 address of your mender-server instead of the ipv4 address.” , How to solve it is correct?
Thanks!
wired or wireless doesn’t matter as long as the networking is configured correctly.
The mender logs are looking better, now you have “no route to host” error. This implies that your mender-server is down, or the network config on your device is not correct.
First check 192.168.0.126 is the ip address of your mender-server. Then check the machine is on and connected to the network correctly.
On your device use ‘ping’ command line tool to try and contact 192.168.0.126.
ping 192.168.0.126
you should see a similar result below if the mender-server can be contacted from the device. in my example I use 192.168.0.1, but you would use 192.168.0.126
dell@dells-Apollo:tyba $ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=4.09 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=3.60 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=3.78 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=5.01 ms
