Not likely to help. The problem is the filename length, which will be the same whether it's a file or a symlink. On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo < alejandro.delcasti...@ni.com> wrote:
> > > 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:*kerg...@gmail.com [mailto:kerg...@gmail.com] *On Behalf Of > > *Christopher Larson > > *Sent:* Tuesday, October 20, 2015 10:20 PM > > *To:* Paul Barker > > *Cc:* Ahsan, Noor; yocto@yoctoproject.org > > *Subject:* Re: [yocto] opkg 0.3.0 or rootfs task > > > > On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson > > <clar...@kergoth.com <mailto:clar...@kergoth.com>> wrote: > > > > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker <p...@paulbarker.me.uk > > <mailto:p...@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_ah...@mentor.com > > <mailto:noor_ah...@mentor.com><mailto:noor_ah...@mentor.com > > <mailto:noor_ah...@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@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 > > > > > > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto