Merge lp://staging/~qzhang/lava-dispatcher/inject-kernel into lp://staging/lava-dispatcher

123 + elif filesuffix in ["gz", "tgz"]:
124 + cmd = ('wget -qO- %s |tar --numeric-owner -C /mnt/root -xzf -'
125 + % pkg_url)
Is there a reason why we want this here? What would we use it for?

We should make sure to include an example of how to use this, and also in the documentation.

Have you tested this with a kernel built by the infrastructure team? Which one?

> 123 + elif filesuffix in ["gz", "tgz"]:
> 124 + cmd = ('wget -qO- %s |tar --numeric-owner -C /mnt/root
> -xzf -'
> 125 + % pkg_url)
> Is there a reason why we want this here? What would we use it for?

For tarball packages, now it only extract it to testrootfs simply, it assume the kernel will be extracted to the right place.

158 + board.populate_boot(chroot_dir, rootfs_uuid, boot_partition, boot_disk,
159 + boot_device_or_file, is_live, is_lowmem, consoles)
The function is run on the server but it can't recognize boot and root partition on board.

The logic here is something complicated, especially when recreating the boot partition, I try to finish it, and switch to linaro-hwpack-replace when it's ok.

1. Move recreating testboot partition command to master image.
2. Fix a bug #821385
3. Add an example json file in doc/
4. Tested and get a new kernel with the json file on doc/lava-new-kernel.json, but the deb package is extracted from 20110727 hwpack.

Add support for Android part, it requires the pkg parameter to be a bz2 tarball and it will be extracted to / directly, then recreate uInitrd, so the package should consider its inner structure. Also added an example json file.

The code is not tested for I don't have an available android board.

This seems to use linaro-image-tools on the board too, via a very long in-line python command. However we don't seem to do anything to make sure that it is installed on the boards. Is there a better way we could do this than the big in-line python commandline? Maybe do something to fix it up in the tarballs before downloading them to the board?

One way to make sure the new kernel installed in normal image, is that it will delete all files in bootfs first, if the bootfs recreating fails, the board won't boot up, then we know something wrong.

Another way is using linaro-image-tools linaro-hwpack-replace, I checked the status, seems it can support it if new kernel is in deb package except another new bug I just find: #827914

But for the tarball, it can't use l-h-r to replace the hwpack, and it can't have a chance to extract to testroot before the bootfs is generated, for the testboot/testroot partition is created by a single command l-m-c.

I will try to push another branch by using it, but I can't find a good way to handle tarball, I can only extract it to testroot partition after l-m-c instructions.

The blueprint automatically set the branch to be merged, however it's another branch another-inject-kernel merged, so I set to Work in Progress

On Thu, Sep 15, 2011, Spring Zhang wrote:
> The blueprint automatically set the branch to be merged, however it's
> another branch another-inject-kernel merged, so I set to Work in
> Progress

 Usually this happens when the commits were included in the other branch

--
Loïc Minier

yeah, it would be best to try to keep things distinct unless you really intend to merge them all at once. What's left to be done? It might be less messy to just start a new branch for whatever is left.

The branch is implemented a different way from branch another-inject-kernel, I have merged the latter one, I keep it here to see if there is some help in the future.