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: 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