From: Jack Mitchell <ml@communistcode.co.uk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: do_root_fs failing on flock command
Date: Tue, 27 Aug 2013 13:31:45 +0100 [thread overview]
Message-ID: <521C9C31.7010400@communistcode.co.uk> (raw)
In-Reply-To: <1377606070.32502.10.camel@ted>
On 27/08/13 13:21, Richard Purdie wrote:
> On Tue, 2013-08-27 at 13:07 +0100, Jack Mitchell wrote:
>> I'm attempting to build core-image-minimal using oe-core +
>> meta-beagleboard on an NFS mount. I'm running into the following error:
>>
>>> [jack@archAntec beaglebone]$ bitbake core-image-minimal
>>> Loading cache: 100%
>>> |#######################################################################################################|
>>> ETA: 00:00:00
>>> Loaded 1193 entries from dependency cache.
>>>
>>> Build Configuration:
>>> BB_VERSION = "1.19.1"
>>> BUILD_SYS = "x86_64-linux"
>>> NATIVELSBSTRING = "Arch-Linux"
>>> TARGET_SYS = "arm-oe-linux-gnueabi"
>>> MACHINE = "beaglebone"
>>> DISTRO_VERSION = "oe-core.0"
>>> TUNE_FEATURES = "armv7a vfp neon"
>>> TARGET_FPU = "vfp-neon"
>>> meta = "master:2ac7783e04f5e8e6005f967e1a6dd65d2fc6a19a"
>>> common-bsp = "master:f02fabd39cd49bf5932fa5f90e83084d49a8cbe2"
>>>
>>> NOTE: Resolving any missing task queue dependencies
>>> NOTE: Preparing runqueue
>>> NOTE: Executing SetScene Tasks
>>> NOTE: Executing RunQueue Tasks
>>> ERROR: Function failed: do_rootfs (log file is located at
>>> /mnt/mediaserver/Projects/oe-core/beaglebone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.19520)
>>> ERROR: Logfile of failure stored in:
>>> /mnt/mediaserver/Projects/oe-core/beaglebone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.19520
>>> Log data follows:
>>> | DEBUG: Executing python function rootfs_process_ignore
>>> | DEBUG: Python function rootfs_process_ignore finished
>>> | DEBUG: Executing python function rootfs_runtime_mapping
>>> | DEBUG: Python function rootfs_runtime_mapping finished
>>> | DEBUG: Executing shell function do_rootfs
>>> | flock:
>>> /mnt/mediaserver/Projects/oe-core/beaglebone/tmp-eglibc/deploy/ipk/Packages.flock:
>>> Bad file descriptor
>>> | WARNING:
>>> /mnt/mediaserver/Projects/oe-core/beaglebone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/run.do_rootfs.19520:1
>>> exit 65 from
>>> | flock $pkgdir/Packages.flock -c "opkg-make-index -r
>>> $pkgdir/Packages -p $pkgdir/Packages -m $pkgdir/"
>>> | ERROR: Function failed: do_rootfs (log file is located at
>>> /mnt/mediaserver/Projects/oe-core/beaglebone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.19520)
>>> ERROR: Task 7
>>> (/mnt/mediaserver/Projects/oe-core/meta/recipes-core/images/core-image-minimal.bb,
>>> do_rootfs) failed with exit code '1'
>>> NOTE: Tasks Summary: Attempted 1580 tasks of which 1579 didn't need to
>>> be rerun and 1 failed.
>>> No currently running tasks (1579 of 1581)
>>>
>>> Summary: 1 task failed:
>>> /mnt/mediaserver/Projects/oe-core/meta/recipes-core/images/core-image-minimal.bb,
>>> do_rootfs
>>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>>
>> Does anyone have any insight to why this may be failing. It mentions a
>> bad file descriptor, so I assume it is related to building on an NFS mount.
>
> Correct, running builds on NFS isn't really recommended or supported
> (other than the downloads and sstate directories). I looks like the
> locking didn't work on the NFS mount and reading the man page for flock
> suggests that even if you do get NFS locking working, its still not
> recommended.
>
> Cheers,
>
> Richard
>
Indeed, I've just been doing some further research myself and it seems
as though flock on NFS isn't recommended. It states using fnctl is a
better alternative, so I'm looking to see if there is a way to do that
natively in bash which could possibly replace the use of flock. I have
done all the build on NFS and this is the only issue I have run into, so
I feel it's probably worthwhile to see if there is a reasonable work around.
Cheers,
--
Jack Mitchell (jack@embed.me.uk)
Embedded Systems Engineer
Cambrideshire, UK
http://www.embed.me.uk
--
prev parent reply other threads:[~2013-08-27 12:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 12:07 do_root_fs failing on flock command Jack Mitchell
2013-08-27 12:16 ` Phil Blundell
2013-08-27 12:38 ` Jack Mitchell
2013-08-27 12:21 ` Richard Purdie
2013-08-27 12:31 ` Jack Mitchell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=521C9C31.7010400@communistcode.co.uk \
--to=ml@communistcode.co.uk \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox