On 7 March 2012 16:57, Dave Pigott dave.pigott@linaro.org wrote:

Hi Fathi,

For the most part I've stored them on the NAS, although with recent developments they're in my home directory on control because I haven't updated the NAS yet. My intention is to add this information to the wiki, but I haven't got round to it yet.

Thanks Dave. Table updated on the wiki for that purpose: https://wiki.linaro.org/Platform/Validation/LabHardware#Master_Image

Thanks

Dave

On 7 Mar 2012, at 14:24, Fathi Boudra wrote:

...

Hi,

Which rootfs/hwpacks are used to create master images? Are they document somewhere?

Cheers

Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs

---

linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation

On 8 March 2012 01:59, Alexander Sack asac@linaro.org wrote:

On Wed, Mar 7, 2012 at 3:24 PM, Fathi Boudra fathi.boudra@linaro.org wrote:

...

Hi,

Which rootfs/hwpacks are used to create master images? Are they document somewhere?

Very important question with partly scary answers.

How do we produce those?

It's done manually. Dave is working on a script to automate master image builds.

How are we deciding when and what to upgrade?

Master images are known good images. We update them when really needed, thus using older rootfs/hwpack combination.

What's the roll out process and how do we track what we have were?

Dave is in charge to create those images. We planned to track master information on the wiki: https://wiki.linaro.org/Platform/Validation/LabHardware#Master_Image

It isn't done yet.

Also, how do we systematically select the rootfs/hwpacks used etc...

It seems to be trial by error.

And maybe Ubuntu team help making this reproducible? Would it be worth to have a lava-master rootfs devbuild?

Master images, as they are today, need to be documented, built automatically and reproduced. I'm not sure we have this plan blueprinted or in a bug. I need to check.

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