Re: Definition of Yocto tasks
Bob Feretich <bob.feretich@...>
On 5/7/2014 5:58 AM, Paul Eggleton wrote:
On Tuesday 06 May 2014 15:23:45 Bob Feretich wrote:I was looking for more detailed information because I was trying to trouble shoot failures that occurred during the "do_fetch" of some source.On 5/6/2014 2:38 AM, Paul Eggleton wrote:They should be identical. The mega manual is simply the other manuals combinedOn Tuesday 06 May 2014 06:47:08 Rifenbark, Scott M wrote:This section seems to be a more polished version of the mega manualFYI, you may already have seen it but we have a bit of coverage for the-----Original Message-----An appendix for a reference of these tasks seems like a good idea.
The most common failure was the inability to access any of the servers that contained the source. This was probably due to those servers being temporarily down for maintenance. Simply restarting the bitbake fixed those problems.
(A common failure that users should be told not to be concerned about. I did read that somewhere, but I don't remember where.)
The next problem was a recipe error effecting "do_install" of some recipe. I troubleshot this and got a fix from the Angstrom people. while troubleshooting (doing lots of double Control-Cs), I believe that I hung the "do_fetch" mechanism. (some "do_fetch" tasks were being executed in parallel with the broken "do_install"). After the "do_install" problem was fixed, "do_fetch" seemed to run, but didn't transfer any data (no network traffic), and it would eventually time out.
That raised the question regarding the use of lock files. (Did my Control-Cs leave a Yocto lock file intact that needed to be cleaned up? Did "do_fetch" use any locking mechanism? How could I do a partial "clean" that would fix the problem without setting my progress back further than necessary?)
During my search for info, I found e-mail discussions of clean, cleanstate, and cleanall. My "do_fetch" failure was occurring at about step 6900 of 8100 build steps. With my internet connection, restarting would have set me back 48 hrs, with no guarantee that the restart would result in a fix. I was looking for ways to "clean" the condition without having to completely start over. Eventually, I gave up and did the cleanall... it did not fix the problem.
Even though none of cleanxxx tasks worked for me in fixing the "do_fetch" hang, info about them should have been easier to find.
I fixed the problem with a shotgun approach.
I erased the entire Yocto build directory, rebooted my host build system, and power cycled my network router and DSL modem. This worked, but was probably more than I needed to do. (I now think that my "do_fetch" hang was do to not properly reinitializing a firewall port.)
My searches also led me to the "do_fetchall" task, as I has just visited with a friend whose network connection was 10x better than mine. Had I know about fetchall, I would have used it during the visit.
In general, the appendix should contain a description of the program logic of the task, the task's intended use, and a discussion of common errors (and fixes) that can occur during execution of the task.
The most probable readers of the appendix would be:
* someone trying to troubleshoot a problem that is occuring during the task.
* someone who saw an e-mail reference for a use for the task and wants to understand it better.
do_setscene itself isn't a task that we have. Setscene equivalents exist forIf we wanted to add an appendix to list them all (and it might be worth usThis file at least provides one sentence on most tasks. (do_setscene is