This is a custom OS image for the XO-1 released by the Paraguay Educa technology team:
http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/os140py.img http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/os140py.crc http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/os140py.img.fs.zip
This release candidate was seeded for field testing in Caacupé yesterday. If everything goes well, within a few days we'll start NANDblasting it on all laptops.
Besides the limited language support (we only ship English and Spanish strings), there's nothing in this build that would prevent its use outside of Paraguay.
== Changes relative to the previous release (os115 Paraguay) ==
* Append "py" to the image name to avoid confusion with other OS flavors developed in parallel (me)
* Add activities requested by the education team: Typing Turtle, Ruler, Analyze, Poll Builder, Jigsaw Puzzle, Slider Puzzle, Tux Paint, Social Calc, Clock, Colors, Labyrinth, Physics. (jorge)
* Merge most changes from F11-XO1 changes (smparrish)
* Remove olpc-update and disable the /versions kludge (me, smparrish)
* GSM broadband support: most modems are supported, as long as they don't require USB mode switching. (tch)
* Basic GUI to backup/restore the Journal to the schoolserver. We're working with Plan Ceibal to merge this functionality with their GUI to perform backups to removable media (tch & jorge)
* Sugar updated to 0.84.15 (sugarlabs & olpc)
* Pull latest OS updates from upstream (fedora)
== Bugs fixed ==
* Record does not record sound (alsroot) http://bugs.sugarlabs.org/ticket/1244
* NetworkManager crashes on suspend/resume (dcbw, tch) http://lists.laptop.org/pipermail/devel/2010-February/thread.html#27505
* "Register" menu item doesn't disappear after successful registration (km0r3, me) http://bugs.sugarlabs.org/ticket/1837
* Can't restore a journal that was backed up to the XS with Sugar 0.82 (bernie, jorge)
== Known bugs ==
Remaining bugs are summarized here:
http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo
There are no longer any known regressions relative to the previous stable build from OLPC (OS801 Paraguay).
Social Calc has known quirks on with the new OS, one of which appears to be a simple timing issue.
== How to help testing ==
Feedback from the entire community is very appreciated, although there's not much time left. Bugs belonging to upstream components should be filed in the usual trackers:
* Sugar and activities: http://bugs.sugarlabs.org/ * Fedora 11: http://bugzilla.redhat.com/ * Drivers and OLPC customizations: http://dev.laptop.org/ * Paraguay-specific bugs: http://trac.paraguayeduca.org/
If you're unsure where a bug belongs to, use the Paragauy Educa tracker. Please, always assign these bugs to "Carlos", who will keep our status summary updated.
We're unlikely to dedicate much attention to bugs affecting Gnome and obscure activities with no active maintainer, but it's still good to be informed on what is broken. For everything else, we'll do our best, with the help of OLPC, Fedora, and Sugar Labs.
== How to join development ==
Build system source: http://git.paraguayeduca.org/gitweb/users/bernie/olpc-os-builder.git
Yum Repository containing our custom RPMs (along with sources): http://repo.paraguayeduca.org/f11-xo1-py/i386/os/ http://people.sugarlabs.org/bernie/olpc/pyeduca-repo/f11-xo1-py/
IRC: #olpc-paraguay irc.feenode.net (English also welcome)
--- On Wed, 4/14/10, Bernie Innocenti bernie@codewiz.org wrote:
From: Bernie Innocenti bernie@codewiz.org Subject: ANNOUNCE: F11 for the XO-1 build 140py released To: "OLPC Devel" devel@lists.laptop.org Cc: "IAEP" iaep@lists.sugarlabs.org, "Fedora OLPC List" fedora-olpc-list@redhat.com Date: Wednesday, April 14, 2010, 12:22 PM This is a custom OS image for the XO-1 released by the Paraguay Educa technology team:
http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/os140py.img http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/os140py.crc http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/os140py.img.fs.zip
Downloaded and installed twice but failed to boot. Stopped at "loading olpcrd.img..." every time However, booting with a simple olpc.fth in an SDcard, booted fine and after setting up the os (user/icon/network) subsequent reboots with the NAND olpc.fth worked fine. This is on an XO-1, CL1, with q2e42d.
A very fast run through the activities revealed 2 issues. Record activity spits a "Cannot find cached 0sugar launch implementation" error. I guess something was left out in the build.
Ruler activity, is out of scale (~half of the proper). I guess the XO screen resolution was not considered appropriately?
Was unable to boot XO-1 with build140py installed on jffs2, unless develop.sig was present.
If not present, OFW (q2e42e) gave the message "No signature for our key list"
mikus
On Wed, 2010-04-14 at 17:08 -0500, Mikus Grinbergs wrote:
Was unable to boot XO-1 with build140py installed on jffs2, unless develop.sig was present.
If not present, OFW (q2e42e) gave the message "No signature for our key list"
I think Stephen Parrish is preparing to release an F11-XO1 image signed with OLPC's private key.
If deployments ask for it, I can provide instructions for creating OS images similar to ours, but signed with their private keys.
On 14 April 2010 13:22, Bernie Innocenti bernie@codewiz.org wrote:
* Remove olpc-update and disable the /versions kludge (me, smparrish)
Great work Bernie! This is the only bit that seems a bit surprising to me.
Granted, the /versions system is a little perplexing (but it works, and is being shipped on XO-1.5, so it has good support in the present day). And granted, it doesn't work for large substantial updates, and doesn't update activities.
But it is a nice system for small updates, with fairly good documentation. It has only a 15mb overhead. I also set up all the infrastructure in Paraguay to push these to schools and XOs automatically, and we actually rolled out a tiny update in 1 school to test it (worked perfectly first time). And I documented it.
Being the first deployment to run with this substantial software update, it seems somewhat likely that you'll find a few niggly bugs that would be nice to fix in the coming weeks. olpc-update would provide you with a mechanism to do that with minimal effort.
Daniel
On Wed, 2010-04-14 at 19:35 -0300, Daniel Drake wrote:
On 14 April 2010 13:22, Bernie Innocenti bernie@codewiz.org wrote:
- Remove olpc-update and disable the /versions kludge (me, smparrish)
Great work Bernie! This is the only bit that seems a bit surprising to me.
I noticed that Stephen Parrish had removed olpc-update from F11-XO1, which made /versions also superfluous. Besides the nice saving in space, disabling the versioned fs considerably sped up olpc-os-builder.
Granted, the /versions system is a little perplexing (but it works, and is being shipped on XO-1.5, so it has good support in the present day). And granted, it doesn't work for large substantial updates, and doesn't update activities.
But it is a nice system for small updates, with fairly good documentation. It has only a 15mb overhead. I also set up all the infrastructure in Paraguay to push these to schools and XOs automatically, and we actually rolled out a tiny update in 1 school to test it (worked perfectly first time). And I documented it.
Being the first deployment to run with this substantial software update, it seems somewhat likely that you'll find a few niggly bugs that would be nice to fix in the coming weeks. olpc-update would provide you with a mechanism to do that with minimal effort.
Hmmm... perhaps I should reconsider this decision. We'd first have to do some testing to ensure your original work still works well with F11-XO1.
Last time I looked, the hostname of the update server was hardcoded inside olpc-update. Did you create a custom package to point it at the schoolserver?
For a future release cycle, we may want to re-evaluate yum-updatesd as an alternative to olpc-updates which provides different trade-offs in terms of performance, robustness and distro integration. At the time olpc-update was written, yum was still awfully buggy and unreliable.
On Thu, 2010-04-15 at 14:48 -0400, Bernie Innocenti wrote:
For a future release cycle, we may want to re-evaluate yum-updatesd as an alternative to olpc-updates which provides different trade-offs in terms of performance, robustness and distro integration. At the time olpc-update was written, yum was still awfully buggy and unreliable.
This brings up again an old question: is the installation of additional packages something we support and encourage? In the past, we could get along with a straight answer: "no". (although some exceptions were made for things such as Adobe Flash).
Now that we're shipping Gnome alongside Sugar, both environments obviously need a mechanism for software installation. Even though we provide no package management GUI in Gnome, children of Caacupé have already learned how to use yum from the terminal. Shall we remove it, making things a little harder? I bet they'll quickly figure out a workaround.
The most effective way to prevent local software installation would consist in taking away root privileges from users, thus violating OLPC's first principle.
There's an immense benefit in unleashing the immense software library provided by any Linux distro, enough to counter-balance the concern of some adventurous users breaking their systems in some clever way. There's no damage that couldn't be restored by the quick remedy of reflashing the OS.
On 15 April 2010 15:48, Bernie Innocenti bernie@codewiz.org wrote:
I noticed that Stephen Parrish had removed olpc-update from F11-XO1, which made /versions also superfluous. Besides the nice saving in space, disabling the versioned fs considerably sped up olpc-os-builder.
I'd be surprised if there is any significant saving of space. As for build time, that would also surprise me but I'm not so familiar with the technicalities of mkfs.jffs2 - perhaps it does take a lot longer for lots of links.
Hmmm... perhaps I should reconsider this decision. We'd first have to do some testing to ensure your original work still works well with F11-XO1.
Last time I looked, the hostname of the update server was hardcoded inside olpc-update. Did you create a custom package to point it at the schoolserver?
olpc-update-query is the component in question. You need to point it at the mothership like was done in the 801 image, not the school server. If there is an update available, the mothership will ask olpc-update-query to run olpc-update using rsync from the local school server.
The new olpc-update-query version will look on the school server first, then a server configured in /etc. (make sure you're using olpc-update-2.22 then you can use the oats_cfg module of olpc-os-builder for this configuration). There is also the option to make it bypass the school server and use the other one directly -- thats what I'd suggest for Paraguay.
Regardless of whether you use the updates bit or not, you'll want to reinstate that server configuration so that the laptops can receive lease updates before expiration (Raul told me that they have switched this feature on a while back when school holidays were approaching).
For a future release cycle, we may want to re-evaluate yum-updatesd as an alternative to olpc-updates which provides different trade-offs in terms of performance, robustness and distro integration. At the time olpc-update was written, yum was still awfully buggy and unreliable.
I agree with the idea of using a more standard system, but I'd say that yum is not yet a suitable replacement based on a discussion that I started based on this exact question in the beginning of the XO-1.5 development cycle. It's in the archives.
Daniel
On Thu, 2010-04-15 at 18:55 -0300, Daniel Drake wrote:
I'd be surprised if there is any significant saving of space. As for build time, that would also surprise me but I'm not so familiar with the technicalities of mkfs.jffs2 - perhaps it does take a lot longer for lots of links.
You're right: the saving in space is just 5MB (compressed). The build time overhead is about 2 minutes on a total runtime of 13 minutes; bearable even for the impatient buildmaster :-)
olpc-update-query is the component in question. You need to point it at the mothership like was done in the 801 image, not the school server. If there is an update available, the mothership will ask olpc-update-query to run olpc-update using rsync from the local school server.
The new olpc-update-query version will look on the school server first, then a server configured in /etc. (make sure you're using olpc-update-2.22 then you can use the oats_cfg module of olpc-os-builder for this configuration). There is also the option to make it bypass the school server and use the other one directly -- thats what I'd suggest for Paraguay.
I had to pull your recent additions to olpc-os-builder and rebase my changes on top of it. The new modules open the opportunity for me to cleanup a few kludges, but I'm afraid of changing too many things just 3 days before release.
Regardless of whether you use the updates bit or not, you'll want to reinstate that server configuration so that the laptops can receive lease updates before expiration (Raul told me that they have switched this feature on a while back when school holidays were approaching).
I'd say this is still working fine, because laptops perform activation from wifi just after being flashed with the new OS. Is there anything else I should check for? I have very little understanding of the internals of OATS.
I agree with the idea of using a more standard system, but I'd say that yum is not yet a suitable replacement based on a discussion that I started based on this exact question in the beginning of the XO-1.5 development cycle. It's in the archives.
Interesting. Do you remember the subject?
On 16 April 2010 19:52, Bernie Innocenti bernie@codewiz.org wrote:
Regardless of whether you use the updates bit or not, you'll want to reinstate that server configuration so that the laptops can receive lease updates before expiration (Raul told me that they have switched this feature on a while back when school holidays were approaching).
I'd say this is still working fine, because laptops perform activation from wifi just after being flashed with the new OS. Is there anything else I should check for? I have very little understanding of the internals of OATS.
This is the fetching of leases from the school server once they have expired (or for the cases when there is no activation at all, e.g. right after reflash). Thats the first way that laptops can receive leases. This codepath does not execute at other times. And it only works when you're in-school.
The other way that they receive leases is through the olpc-update-query cronjob which basically ends up with olpc-update-query querying the internet-based paraguayeduca mothership once per day. This server will deliver updated leases to the XO laptops *before* they expire, which has a few advantages. (for example, there was one time when Raul realised that the current round of leases were set to expire in the middle of a long school holiday. this system was used to deliver much-extended leases in the final week of school before the holidays set in).
I agree with the idea of using a more standard system, but I'd say that yum is not yet a suitable replacement based on a discussion that I started based on this exact question in the beginning of the XO-1.5 development cycle. It's in the archives.
Interesting. Do you remember the subject?
update mechanism for new releases
Daniel
Daniel wrote:
It <i.e. /versions> has only a 15mb overhead.
When I type in 'du -x', on os13 it shows me /versions having around 100 MB.
On os140py the same command shows nothing for /versions. [The remaining high-level directories (except for /home) have comparable sizes on those two builds.]
I do not know how much of what is in /versions gets "counted more than once" (because of all those hard links between pristine and the running system) -- but I'm not convinced the overhead of /versions is only 15 MB.
mikus
I usually bring the system up with messages being displayed (NOT in pretty-boot). Several times now, the system has "paused/hung" at about the time it should be running through /etc/rc.d/rc0.d (or suchlike). [Note: the camera LED is on.] After SEVERAL MINUTES nothing more has happened - so I just reboot. [I can not bring up a text console, so I can't take a dump.] The hang is random - so the next boot usually works.
As far as I am concerned, if the machines in the field also encounter this hang -- it is a blocker to the release of build 140py.
mikus
On Wed, 2010-04-14 at 17:54 -0500, Mikus Grinbergs wrote:
I usually bring the system up with messages being displayed (NOT in pretty-boot). Several times now, the system has "paused/hung" at about the time it should be running through /etc/rc.d/rc0.d (or suchlike). [Note: the camera LED is on.] After SEVERAL MINUTES nothing more has happened - so I just reboot. [I can not bring up a text console, so I can't take a dump.] The hang is random - so the next boot usually works.
As far as I am concerned, if the machines in the field also encounter this hang -- it is a blocker to the release of build 140py.
I have observed this problem a couple of times, although only after reflashing the OS. The machine would hang after displaying the frame of the boot animation with just one dot.
In my case, a simple reboot would not cure the problem. Pulling the battery did the job. Therefore, I suspect it may be caused by upgrading the EC code, which wouldn't be a big concern since we have found an easy workaround.
Let me know if you see it again on laptops that are already running the latest open firmware code. Please, take note of how you triggered it and how exactly you managed to solve it.
I have observed this problem a couple of times, although only after reflashing the OS. The machine would hang after displaying the frame of the boot animation with just one dot.
So far, if I've been running a machine, and it has hung -- and if it doesn't want to reboot -- I will do the EC reset thing (unplug the AC, take out the battery for a couple of minutes).
If an EC reset might be required also after reflashing the OS, then the person doing the reflashing ought to be warned somehow (Release notes? Wiki?). My reason for mentioning the hang I saw was that I had not been expecting a reflash to require an EC reset to make the os boot work.
Please, take note of how you triggered it and how exactly you managed to solve it.
I triggered it by doing a 'copy-nand u:\os140py.img', then powering off, pulling the USB stick, and powering on (while pressing the 'check' game button). [I already was using q2e42e from before doing the reflash.]
I never solved it - I repeated the power-up (I think twice) - and finally the boot worked. [Never did any explicit EC reset.]
mikus