On Sun, Mar 11, 2012 at 5:04 AM, Zygmunt Krynicki < zygmunt.krynicki@linaro.org> wrote:
Also look at http://lists.linaro.org/pipermail/linaro-dev/2011-December/009024.html
From the day I wrote that we've managed to change... nothing. Point 1) is somewhat offset by better platform code but since I'm now fixing bug
That's not really true, point 1 was complete fiction and the platform code to make sure that pandas without the ability to keep a unique mac on their own had already been long since done. You made this one up, read the other messages in the thread you point to. :)
https://bugs.launchpad.net/**lava-dispatcher/+bug/934164https://bugs.launchpad.net/lava-dispatcher/+bug/934164I think that something is very fishy there (uuid generation is based on real time stamp and mac address. How are we getting dupes again? Same time and same mac? Really?
Yeah, that sounds really fishy to me - like it's the same bundle! that's the problem we had last time, and we're doing the clean up before and after the runs, so I'm not sure how this would have regressed off the top of my head unless someone removed the extra cleanups we did before to fix it. As for the bug, I'm still waiting to see someone point me at examples of this happening. I haven't seen that yet.
I'd really like to continue this discussion on the possibility of having a lava-specific rootfs. We have a list of packages that we normally install on top of nano to create the rootfs, and it would be really convenient to have an image that integrates everything we need already. We could point at that image for others who want to deploy lava.
In fact, I'd like to really take it a step further. Any chance we could strip it down enough to make it an initramfs image? What I'd like to consider doing here, is have a *SINGLE* recovery image partition, which we'll simply call "boot", and eliminate the need for the rootfs partition. We've talked before about sharing boot and testboot, so that when we deploy a testboot partition, we just extract it into a directory on the first partition (boot) and point uboot at that to boot the new kernel. With the elimination of those 2 extra partitions, that means we could preserver the partition layout of the rest of the image in all cases. That means no special handling for those nasty hardcoded android partitions.
Thoughts?
Thanks, Paul Larson