[yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

We are hitting this issue on another BSP

file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk

need its solution quickly

Noor

From: kergoth at gmail.com [mailto:kergoth at gmail.com] On Behalf Of Christopher Larson
Sent: Tuesday, October 20, 2015 10:20 PM
To: Paul Barker
Cc: Ahsan, Noor; yocto at yoctoproject.org
Subject: Re: [yocto] opkg 0.3.0 or rootfs task


On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson <clarson at kergoth.com<mailto:clarson at kergoth.com>> wrote:

On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker <paul at paulbarker.me.uk<mailto:paul at paulbarker.me.uk>> wrote:
On Fri, Oct 16, 2015 at 07:38:19PM +0000, Ahsan, Noor wrote:
> On Oct 16, 2015, at 5:47 AM, Ahsan, Noor <Noor_Ahsan at mentor.com<mailto:Noor_Ahsan at mentor.com><mailto:Noor_Ahsan at mentor.com<mailto:Noor_Ahsan at mentor.com>>> wrote:
>
> Hello,
>
> I noticed that at the time of rootfs creation symbolic links of the ipk files present in deploy/ipk. The problem what have it while creation of symbolic link it take the full path till that ipk and remove slashes and convert them into underscores. Use that as the name of the symbolic link. This make a very long file names. If we have very long path then name of the symlink exceed from max filename limits. And we get following error
>
> Collected errors:
> * file_link: unable to stat `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': File name too long.
>
> Can anyone tell me why the addition of full path was added to the symlink name and can we remove it cause it is cause issues?
>
> what does
>
> getconf PATH_MAX /
>
> show ?
>
> jenkins at amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
> PATH_MAX                           4096
> _POSIX_PATH_MAX                    4096
>
>
> I think the issue is with file name not the path.
>
> Secondly the googling which I did reveals that symlink creation can't be stopped. I just wanna confirm that is my findings correct?
>

This looks like something we overlooked in opkg. When we added the caching code
we didn't think about how long the paths and filenames might get during the
rootfs step. It's not currently possible to reduce the length of the symlink
filenames, but it is possible to change the directory in which the symlinks are
created.

Currently the opkg cache dir can only be set in the opkg.conf file. I think we
should add a '--cache-dir' argument to opkg. If this is added you'll be able to
set the following in your local.conf file to change the cache location. Eg. to
use '/tmp/opkg' on the host during rootfs creation.

    OPKG_ARGS = "--cache-dir=/tmp/opkg"

I'll submit a patch to opkg to add this option.

This will only shorten the full path, not the filename length, so I doubt this'll solve it. That said, I can't actually successfully test this today, because cache_dir is made relative to offline_root, so setting such a path as you suggest doesn't shorten the full path either.

Also, did a touch of just the cache filename and it gives the same filename length error, so where the cache dir is really isn't going to matter, it's the filename including the full path to a deep BUILDDIR, and therefore DEPLOY_DIR_IPK, which is the problem.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20151021/de075175/attachment.html>