Firmware update

C. Scott Ananian olpc at cscott.net
Wed Nov 24 17:56:55 EST 2010


On Wed, Nov 24, 2010 at 5:49 PM, Daniel Drake <dsd at laptop.org> wrote:
> On 24 November 2010 22:40, Kevin Gordon <kgordon420 at gmail.com> wrote:
>> Is this recommendation against yum and rpm for all software, or just the
>> oplc repo packages, the kernel and the firmware?  I'm certainly happy doing
>> just safe builds for the core.
>
> To avoid all corner cases it the recommendation really needs to be "everything"
> In reality, you'll probably get away with it, especially because
> you're only really working with added packages in your deployment (not
> upgrading ones that are already installed).
>
> Some of the resultant problems will also not affect small deployments
> like yours. For example, one side effect is that olpc-update pristine
> (efficient) updates stop working as soon as you make any filesystem
> modifications like this. Another side effect is that your
> custom-installed packages will magically disappear after an
> olpc-update upgrade (which in a real deployment would happen without
> you even knowing).
>
> But in a small deployment like yours, touching each laptop for updates
> is probably more sensible than the knowledge and infrastructure
> investment needed for hands-off olpc-update, so you aren't affected.
>
>> However, as part of our 'refresh' stick when we wipe and install a new
>> signed build, we generally also include the necessary rpm's for cheese and a
>> couple of other utilities that are locally installed from the USB stick
>> using a bash script; or, for the Vernier software dependencies, the
>> dependent rpm's are installed by means of a python script.  However, they
>> are rpm's and they are downloaded onto the stick (the first time) using yum,
>> and they are then installed from the stick using --localinstall from the
>> stick.
>
> You probably won't see any problem with this collection of changes.
> Nevertheless, at the SF summit I started showing Adam the "correct"
> way to do this: building a custom OS image with those customizations
> already included. We didn't have time to completely finish it, but he
> picked it up quickly and could probably finish it with a little effort
> (and perhaps a couple of mails to this list).

At one point Michael and I also had a side-loading mechanism
implemented -- if you put your target RPMs in some directory in
/home/olpc -- I think it was ~/.rpms -- then they'd automatically get
re-installed after olpc-update.  That was (at the time) the preferred
mechanism for "adding a few packages" persistently to a build.

Assuming this mechanism hasn't code-rotted, this is a nice
intermediate step: less work than rolling an entire new build, and
relatively easy to accomodate new "upstream" builds without
disruption.
  --scott

-- 
                         ( http://cscott.net/ )



More information about the Devel mailing list