[Linaro-validation] Deployment report/fallout
michael.hudson at linaro.org
Thu Apr 5 04:47:18 UTC 2012
On Mon, 2 Apr 2012 09:39:26 -0500, Paul Larson <paul.larson at linaro.org> wrote:
> On Mon, Apr 2, 2012 at 12:41 AM, Michael Hudson-Doyle <
> michael.hudson at linaro.org> wrote:
> > Back to the public list...
> > On Sun, 1 Apr 2012 21:28:06 -0500, Paul Larson <paul.larson at linaro.org>
> > wrote:
> > > On Thu, Mar 29, 2012 at 8:55 PM, Zygmunt Krynicki <
> > > zygmunt.krynicki at linaro.org> wrote:
> > >
> > > > W dniu 30.03.2012 03:40, Le.chi Thu pisze:
> > > >
> > > > > This worry me because the hold ideal with automation is you should
> > > > > able to recycle the device (when it stop responding).
> > > >
> > > > Yes but to do that you need reliable recovery boot method, typically
> > > > that is external to the device. We may be able to do this once PXE
> > > > booting and UEFI are commonplace.
> > > >
> > > Or, a piece of hardware that allows you to write/read directly to the sd
> > > from an external system. :) That's the long-term goal, but not so far
> > off
> > > as you might think.
> > >
> > > Short term, I still think a tiny initramfs is the way to go.
> > So how would this work? Please excuse the train of consciousness style
> > below...
> > I guess the idea is that you have two uImage & uInitrd files on /boot,
> > and choose between them using uboot commands and so select booting into
> > test mode or master mode?
> Correct. It's not that different from how we operate now, just that the
> location would be moved up so that the test partition would be on the first
> partition with the regular boot. As a side note, this would also eliminate
> the need for understanding partition offsets, and also make it much easier
> to re-use the boot.scr from the image itself!
Yeah, that might be nice.
> > One extreme approach would be to have the master mode just dd an image
> > file completely over the mmc -- if you did this with the output of l-m-c
> > we'd have no way of recovering, but maybe we could run l-m-c on the
> > server, mush the boot partition of the image around a bit so that it
> > used a known good bootloader and booted to the master mode kernel &
> > initrd by default, then blat that over the mmc.
> No, I think it's best just to push the bits we need rather than blast the
> whole thing across and hope that we don't hit an error part-way through.
> > We could be more gentle in the master image, but that feels to me like
> > although we'd be able to use the expected partition layout, the
> > dispatcher/master image agent would have to know what it _was_ and
> > that's still pretty tedious -- although I guess you could just clone the
> > layout from the image file produced by l-m-c.... This feels like it
> > would be more reliable (e.g. losing power while the image is being
> > blatted over the mmc would presuambly require manual recovery).
> exactly, and the dispatcher already keeps track of which mode it's in, as
> it has to force the boot for the test image, and not for the recovery image.
The part that bothers me about this would be the need to repartition the
rest of the image to match the generated image... it wouldn't be hard,
but it would be tedious I expect.
> > I guess we'd have to be careful about resource consumption in our
> > initramfs -- presumably one has to fit rootfs and all RAM usage within
> > the RAM of the boards? I think Beagle xM's are our least capable boards
> > with half a gig of RAM, but all the others have a gig? That's
> > reasonably generous I guess, and we can customize our rootfs pretty
> > significantly, but I don't know if we'd want to write the master agent
> > in Python in this environment...
> Yes, this is the concern. It should obviously be stripped down as much as
Yeah. I wonder if it's worth doing this work or waiting for the sd card
More information about the linaro-validation