[yocto] opkg 0.3.0 or rootfs task
Alejandro del Castillo
alejandro.delcastillo at ni.com
Sat Oct 24 10:53:17 PDT 2015
On 10/21/2015 02:49 AM, Ahsan, Noor wrote:
> 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
If you are in need of a quick workaround, try setting:
option cache_local_files 0
on opkg.conf. This will make a copy of your ipk's instead of creating
symlinks (haven't try it myself, but that's my understanding).
Also, please open a bug report for opkg on
https://bugzilla.yoctoproject.org to track the issue.
> *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
>
>
>
More information about the yocto
mailing list