June 2009 - olpc - Fedora mailing-lists

Show Must Go On - SoaS for the XO-1
by Sebastian Dziallas 29 Jul '09

29 Jul '09

Hi everybody, I'm very pleased to announce the first early preview of a new generation of SoaS XO-1 images. Those consist not only of the latest and greatest Sugar bits, but also a F11 base system and a special OLPC kernel based on 2.6.30. This means now that even power management actually works out of the box. There are some other points, for example the mostly working keyboard keys. But this is really just a preview! You'll notice only very few activities in your home view, which is due to a mistake in our config files. You'd be able to symlink the folders from /usr/share/sugar/honey to ~/Activities, though. This is a known issue, but if you come across others, please let us know! Finally, I'd like to take the chance to thank all the people for their tremendous work, especially Martin Dengler and all the folks at OLPC! Now how can you get that? Just download the following two files: http://download.sugarlabs.org/soas/xoimages/devxo-1.crc http://download.sugarlabs.org/soas/xoimages/devxo-1.img Put them on a USB key or a SD card, plug them into your XO and execute: copy-nand u:\devxo-1.img or copy-nand sd:\devxo-1.img Note that you'll need to have an unlocked XO and the latest firmware! So. Happy hacking and let us know what you think! :) --Sebastian

7 14

olpc-switch-desktop issues
by Alexander Boström 09 Jul '09

09 Jul '09

Hello, I'm working on submitting olpc-switch-desktop for inclusion in Fedora. I (or rather rpmlint) found these issues: The .spec from the repo, the GNOME .desktop and the Sugar control panel references a couple of SVG files, but those aren't in the repo. Are there any suitable icons to use or do someone need to create them? The .spec creates /etc/skel/Desktop (for the GNOME .desktop file). I think that breaks the feature that a name from the user's locale is used when creating the desktop directory (xdg-user-dirs), so that needs to be done some other way. Is there a way to place an icon on every user's desktop without poking around in their ~/Desktop? If not, perhaps the Sugar part can install the GNOME .desktop file for the user when the user first switches from Sugar to GNOME? Then it is only done for GNOME users who actually ran Sugar in the first place (call that a feature or a bug) and by then the locale is hopefully set correctly so that the desktop directory can be created the proper way. Also, the GNOME app should probably have a license declaration at the top of the source file, or the license should be stated explicitly in the README. /abo

3 7

Tkinter support in sugar builds
by Shawn Willden 29 Jun '09

29 Jun '09

Is there any plan for it? A friend of mine is interested in porting some math ed apps to the OLPC, but they're written with pytkinter. He's trying to decide if he needs to port to pygtk. Assuming it's reasonable to install tkinter on the XO in order to support his apps, any idea how difficult it would be to "sugarize" a tkinter app, so that it can run as an activity? I have basically zero knowledge of what's involved in sugarization, so please excuse me if this is a dumb question. All comments/suggestions/flames appreciated, Shawn.

2 1

stalled Fedora reviews
by Peter Robinson 28 Jun '09

28 Jun '09

Hi All Just going through the package reviews in Fedora related to olpc/sugar. The following are either stalled or closed due to lack of response from the reporter. Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 I'm not really sure of the exact reasons for the stall. I know I was watching the first 3 and haven't seen a response for a while. Is someone able to take them over (I can assist or review if necessary) or if they're no longer wanted let me know and I'll close them. Cheers, Peter

3 6

Broken browse activity for strawberry.
by Luya Tshimbalanga 28 Jun '09

28 Jun '09

Hello, With a lot of help of OLPC team, my XO-1 got repaired and I am able to test strawberry from Sugarlabs. While the power management is not quite optimized, the wireless connection has definitively improved. I have a problem running browse active in XO-1 because it traceback somewhat? Has any with XO-1 got the same issue? Luya

2 1

Re: Broken browse activity for strawberry
by Mikus Grinbergs 27 Jun '09

27 Jun '09

> I have a problem running browse active in XO-1 because it traceback > somewhat? Has any with XO-1 got the same issue? I'm booting strawberry on my XO-1 from an USB stick. I'm not really an user of Browse (I prefer Firefox or Opera, both of which launch ok on strawberry on my XO-1), but *all* the instances in which I've used Browse (108) on strawberry on XO-1 have worked ok for me. [Yes, there are some tracebacks in Browse's output log (e.g., for xpcom using xulrunner), but those did not appear to affect Browse showing/downloading the things I told it to do.] I would not say "broken" for Browse Activity on strawberry. mikus

1 0

Fedora packages for XO-1.5 distro
by Daniel Drake 26 Jun '09

26 Jun '09

Hi, Just wanted to point out the slowly-growing list of custom packages that we're including in the XO-1.5 F11 build: http://wiki.laptop.org/go/F11_for_1.5#Modifications_to_Fedora I'm hoping to spearhead some efforts to get these included in the Fedora package tree (specifically dracut, dracut-modules-olpc, olpc-bootanim, olpc-library, olpc-switch-desktop and olpc-utils) but I have not found the time yet. If anyone wants to contribute and has some time on their hands, getting a head start on a couple of these would be a huge help. cheers Daniel

2 3

strawberry on XO-1
by Mikus Grinbergs 24 Jun '09

24 Jun '09

[ FYI. I am _not_ asking for help; I'm sharing my experiences. ] Booted my XO-1 from an USB stick with build soas strawberry on it. [Because I do not have any system on which mounting of a squashfs filesystem works, I have to use the rawhide version of the livecd-iso-to-disk script; neither does livecd-iso-to-xo work, so I am unable to install builds distributed as .iso onto my XO's nand.] Strawberry (F11-based) works; but it is reproducibly stalling when doing a huge 'rsync'. [Since the system then is unresponsive, I can't examine it. My suspicion is that the system ran out of memory, despite having a swap partition active.] The interesting thing is that on my XO-1, Soas2-20090622 (on which strawberry is supposedly based) runs the same 'rsync' without trouble. mikus

3 2

rpm vs xo & activity updates
by Daniel Drake 24 Jun '09

24 Jun '09

Just a quick summary of a discussion and a decision that we reached on IRC, which will hold at least for now with our XO-1.5 software builds. Further input is welcome, although this is at risk of starting another huge discussion... Question: In the early XO-1.5 OS builds right now, we have a mix of RPM-based sugar activity packages, and .xo files unzipped in /home/olpc/Activities. Do we want to change? - It would be a little unfortunate to ignore the hard work of those who have been actively packaging the activities within Fedora. - rpm-based packages cannot be updated with Sugar's updater utility, which is the primary way for updating activities right now. There is no upgrade path for activities installed by rpms (without updating the whole OS, which is another open question) - We could somehow hack the updater to work with rpms, i.e. if it found a newer .xo bundle it could unzip it over the top of the rpm-installed files in /usr/share/sugar/activities, but this is nasty and would raise many issues - One flaw in the existing OLPC OS releases for XO-1 is that there's no way for deployments to push automatic activity updates, because olpc-update doesn't touch /home and the activity updater always has to be invoked by the user. - This flaw would go away with rpm-based updates, because whatever "global" OS updater we choose would include these updates. - Which leads onto the possibility that *all* activities could be shipped as RPMs, the sugar control panel activity updater could be deleted, and then this problem is solved -- but that's quite a change - The easy option is to do what we've done before: ship activities entirely as .xo bundles in /home/olpc/Activities - We're going to go with this option for now, because it's quick and easy and it's what we're already doing. - There is certainly room for improvement in future, but finding development time in the short term may be a bit tricky... or perhaps we will be able to raise community interest in making or implementing a plan for improvement... :) Daniel

5 6

update mechanism for new releases
by Daniel Drake 24 Jun '09

24 Jun '09

Hi, We have a bug open here which is a difficult question, in my opinion: http://dev.laptop.org/ticket/9349 For the upcoming XO-1.5 software build (which will hopefully make it onto XO-1 in the near future), do we want to ship olpc-update or use standard Fedora technologies? My unconclusive thoughts and questions: olpc-update has some features which aren't available elsewhere, such as the ability to switch between 2 OS builds installed on the same disk. However, I've never seen or heard of this being used in the field. olpc-update is a "deployment quality" system in that it has covered everything - not only from being an updater, it has olpc-update-query which implements logic to figure out when to ask for updates and where to ask for them. It's accompanied by the theft deterrence protocol and 3 different server-side implementations of that. It's been implemented in OLPC deployments. olpc-update creates a huge mass of hardlinks on disk, one for every file on the main OS. It then rsyncs in the updated files on a copy-on-write basis. Therefore you end up with a hell of a lot of hardlinks, and 2 complete copies of every file that has changed. (this means it is not great for situations when a lot of files have changed, e.g. changing between major Fedora releases) olpc-update presents challenges for deployments that customise their images. Namely, to produce a build that it is possible to olpc-update to involves quite a bit of hassle (inserting security keys into the firmware of each XO, setting up an OATS server, etc). We did manage to figure this out in Paraguay (thanks to the internet connection, since it wouldn't be safe to put the OATS server in the schools) and I improved some tools accordingly. We've switched to dracut for our initramfs, meaning that the initramfs-level stuff for the olpc-update system needs to be reimplemented. Basically we have to wrangle with the strange /versions filesystem layout and "frob" the /versions/current symlink if the user is switching between versions. I have reimplemented this logic in a dracut module but it is completely untested. The option for using "Standard Fedora technologies" as far as I am aware is to basically use "yum update" in a fashion somehow suited for deployments. Before F11, this would have meant a lot of downloading as each RPM update was downloaded in full even if only a little bit changed. As of F11, Fedora is now joining the "only download the bits that change" movement with yum-presto and deltarpms: http://lwn.net/Articles/329484/ The deltarpm description on that lwn article leaves a little to be desired -- it wouldn't work with big packages (is the quoted 200mb the compressed or uncompressed size?), the reconstruction from deltas is a CPU intensive task and we have a slow CPU, and it's all done in memory and we don't have a huge amount of memory especially on XO-1. olpc-update has an overhead of about 5 minutes of checksumming files. Even though olpc-update isn't great for doing big distro updates (because of storing 2 copies of changed files, in this case almost all of them), it worked in those situations. I've never attempted an RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that work out for regular Fedora users? "yum update" always seems to use a surprising amount of bandwidth, redownloading entire package databases just to see if anything new is available. olpc-update was much more efficient in this respect, sending only a 128-byte hash of the filesystem contents file to the OATS server. For rpms, is there a more efficient alternative for updates-checking in situations where there is only going to be e.g. 1 update per month? "yum update" has historically not worked very well on the XO. It hits OOM, it fills up yum's cache and then aborts, it gets confused between i586 and i686, etc. We would have to tweak yum's behaviour quite heavily.. I don't think we want an rpm cache, or for it to keep the .rpm files at all. It introduces new questions of security, signing, etc. Deployments will want to sign their rpm updates that they push out, so we now need a mechanism for getting that specific RPM signing public key onto all the laptops in a deployment so that they can trust the updates server. We had this nailed down for olpc-update: deployments can insert "local" public keys into the manufacturing through keyjector firmwares for existing laptops, and Quanta can now manufacture laptops with these keys already in place for future orders. olpc-update and the bitfrost code used these keys to verify updates. For the XO-1 possibility it raises the question of how existing laptops could be migrated to this new system, without losing their user data. Using "yum update" would be a large benefit of sharing technologies with other communities and not having to maintain our own systems and tools. However olpc-update would be easier in the short term because all the components have been implemented and deployed, and there aren't really any open questions. Any other thoughts/opinions one way or the other? Daniel

5 9

Fwd: update mechanism for new releases
by Mathieu Bridon 24 Jun '09

24 Jun '09

Oops... My reply went only to Daniel, not to the lists :-/ ---------- Forwarded message ---------- From: Mathieu Bridon (bochecha) <bochecha(a)fedoraproject.org> Date: Tue, Jun 23, 2009 at 20:33 Subject: Re: update mechanism for new releases To: Daniel Drake <dsd(a)laptop.org> > Even though olpc-update isn't great for doing big distro updates > (because of storing 2 copies of changed files, in this case almost all > of them), it worked in those situations. I've never attempted an > RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that > work out for regular Fedora users? Lot's of people will tell you that it works fine. However, this is not a supported path for upgrade. Users should use Pre-Upgrade instead. See: => http://fedoraproject.org/wiki/Category:PreUpgrade => http://fedoraproject.org/wiki/Interviews/PreUpgrade > "yum update" always seems to use a surprising amount of bandwidth, > redownloading entire package databases just to see if anything new is > available. olpc-update was much more efficient in this respect, sending > only a 128-byte hash of the filesystem contents file to the OATS server. > For rpms, is there a more efficient alternative for updates-checking in > situations where there is only going to be e.g. 1 update per month? You can configure yum to not update its cache that often with the « metadata_expire » directive in /etc/yum.conf > "yum update" has historically not worked very well on the XO. It hits > OOM, it fills up yum's cache and then aborts, it gets confused between > i586 and i686, etc. RPM has seen a lot of improvements in speed and memory consumption lately. My XO (a build from the latest G1G1 in Europe that I never updated yet) has RPM 4.4.2. Panu Matilain has just posted about that, comparing the performances of RPM from 4.4.2 (Fedora 9) to 4.7 (Fedora 11). Perfect timing :) => http://laiskiainen.org/blog/?p=19 Yum has also been improved. Not sure those improvements would be enough, but I bet the situation in Fedora 11 is already much better than it was in the previous OLPC builds from Fedora 9. > We would have to tweak yum's behaviour quite heavily.. I don't think we > want an rpm cache, or for it to keep the .rpm files at all. You can use the « keepcache » directive in /etc/yum.conf which AFAIU aims exactly at that. From « man yum.conf » : keepcache Either ‘1’ or ‘0’. Determines whether or not yum keeps the cache of headers and packages after successful installation. Default is ’1’ (keep files) What other customizations are you expecting ? > It introduces new questions of security, signing, etc. Deployments will > want to sign their rpm updates that they push out, so we now need a > mechanism for getting that specific RPM signing public key onto all the > laptops in a deployment so that they can trust the updates server. > We had this nailed down for olpc-update: deployments can insert "local" > public keys into the manufacturing through keyjector firmwares for > existing laptops, and Quanta can now manufacture laptops with these keys > already in place for future orders. olpc-update and the bitfrost code > used these keys to verify updates. Yum will ask the user if he wants to import the key and trust it on first use. Wouldn't that be enough for signing keys ? Couldn't Quanta manufacture the laptops with those GPG keys bundled too ? > For the XO-1 possibility it raises the question of how existing laptops > could be migrated to this new system, without losing their user data. Backup with a School Server ? Best regards, ---------- Mathieu Bridon (bochecha)

5 4

Re: update mechanism for new releases
by Martin Langhoff 23 Jun '09

23 Jun '09

On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidal<skvidal(a)fedoraproject.org> wrote: > they're not insolvable - they are just very very very hard. :-) At the end of the day, if the OS doesn't give you atomic multi-file transactions, and your %pre/%post scripts aren't also written perfectly atomically, I would say that it _is_ impossible. In any case, are there reasons to believe that behaviour in rpm has improved (in F11) in the face of a powerloss in the middle of a transaction? If we start doing OS upgrades and removing power at random points, what chance does rpm of recover/resume? It is an admittedly hard question. cheers, m -- martin.langhoff(a)gmail.com martin(a)laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff

1 0

breakthrough - got sound on XO-1 with F11
by Mikus Grinbergs 22 Jun '09

22 Jun '09

FYI - Had an XO-1 with build rawhide-xo 20090528 (and F12? kernel). Ran a giant 'yum upgrade' to bring it up to current system level. When I checked it out, I was able to hear sound from an application that used the fluendo mp3 driver. [Speak also produced sound - but other applications I have did not. Am currently tied up elsewhere - don't have time to look into why some have sound and others don't.] I do *not* know how come sound started working. I checked, and now I have sound (with those two applications, but not with others) on an XO-1 with build soas devxo-1 (it also has been upgraded to current F11 system level). I'm positive that several days ago sound was not working for me. It might have been the system upgrades I did -- or it might have been my own customizations (which I'm continuously tinkering with). I also checked against the Soas2 builds (including 20090621) - they are up-to-current-F11 level (and have my current customization), but they don't produce sound for me. Thank you, developers for F11 on XO. mikus

1 0

Re: Show Must Go On - SoaS for the XO-1
by Mikus Grinbergs 18 Jun '09

18 Jun '09

Thank you very much, Sebastian and everyone. Because my Ubuntu kernel is not "new" enough, the 'livecd-iso-to-xo' script fails on me - so I had to run previous Soas2 builds from an USB stick. Now I can run a current SoaS build from the XO-1 nand itself. Thanks. - It is nice to have olpc-kbdshim and olpc-powerd in this build. Both my ethernet and my SD card were accessed correctly after I allowed the XO-1 to suspend (my testing was limited). And the screen went dark after I let the XO sit -- now I don't have to "shut the lid" when I leave the XO powered on overnight (and I don't want the XO to be lighting up the otherwise dark room). [By the way, I need olpc-kbdshim to let me to scroll the screen (e.g., in Terminal) incrementally. All too often, if I click within the scrollbar, the effect is "multiplied" - instead of scrolling one page, the screen happens to scroll *many* pages.] - The default fonts used by this build are really *tiny*. I knew how to change to a bigger font in Terminal - but I did not know how to change to a bigger font for the Sugar labels, etc. - The "list of installed rpms" that comes with this build lists a couple of packages as having a back level (e.g., libabiword). The result is that when I ran 'yum upgrade', yum fetched those packages for updating, then told me those updated versions were already installed. Now a request -- would someone please look at the system problems that affect multimedia -- I can launch 'Speak' but I can not hear any of its sound output; I can launch 'Record' but I can't see on the screen what the XO-1 camera is picking up. Thanks for a nice build, mikus

2 1

olpc-powerd on soas devxo-1
by Mikus Grinbergs 17 Jun '09

17 Jun '09

This is the first F11-based build to come with this module included. I'm going to have to play with the thresholds -- it acts too soon for my liking. Was doing a 100MB+ rsync to my XO-1. The screen dimmed, but the data transfer continued; then the 'power' light started blinking, but the data transfer stopped (though unlike how 'suspend' worked in Joyride, here the external ethernet adapter did not get powered off). When I awakened the XO (by pressing the <shift> key), it took quite a bit of cogitation by the XO before the data transfer resumed -- but resume it did. Still, would be nice to inhibit (even if manually) 'suspending' while lengthy data transfers take place. mikus

2 1

browse on devxo-1
by Mikus Grinbergs 17 Jun '09

17 Jun '09

Tried launching Browse (108) on devxo-1. Failed. The error message (on webactivity.py line 35) - "ImportError: No module named gnome". I compared Soas2-20090614 (on which Browse launched) against devxo-1 (on which Browse did not launch). No difference in the source files in the Browse.activity subtree. In neither build version could I find a separate module named 'gnome.py' -- my guess is that this is a 'built-in' somewhere (kernel?). The 'import gnome' line was added by sugarlabs/ticket/456. I have no idea why that line worked on Soas-20090624, but not on devxo-1. mikus

1 0

Re: [OT] Test run of 2009/05/25 image
by Mikus Grinbergs 17 Jun '09

17 Jun '09

>> I think that people who focus on "slimming" the OLPC are missing the >> point. What they end up with is a slow, small Linux system. > > Are you seriously considering the implications of your statement? > > If slimming ends up on a slow small GNU/Linux system, then *not* slimming > ends up with a slower and bloated GNU/Linux system. Yes, I am seriously considering the implications of my statement. My motivation for starting this thread was to go on record as preferring that people "add to" what they believe the OLPC can do well, rather than "subtract from" what has been done so far because aspects of the OLPC's behavior do not meet their expectations. Given that 'netbooks' are already outselling the OLPC, and that in my opinion the development resources available to the producers of netbook systems far exceed the resources of organizations producing the OLPC, I think trying to sell the OLPC in competition with netbook systems will fail. Sooner or later, netbooks will cost less than the OLPC, while outperforming the OLPC, whether slimmed or not. My concern is that, even when offered with a non-Sugar interface, the OLPC __as a GNU/Linux system__ ( or as a Windows system !) will be non-competitive. Therefore I would rather have thought be given by those working on the OLPC to how it can be made to 'stand out' from other small systems, instead of thought being devoted to fit the OLPC into a "me too" mold. Let's not get sidetracked. > >> For those who think the OLPC *is* suited to >> the environments in which it is being deployed - let's work on developing >> OLPC-scale applications to assist 'the things people do' wherever such >> "computerization" could improve matters. > > Then what's your problem, man? :) My problem is that a number of people want to change the OLPC to improve the way it does things __that other systems already do__. If there are other systems that work (better) with "square pegs", why fashion the OLPC to be "square"? Think "round". mikus

4 4

Development of XO-1.5 software release started
by Daniel Drake 16 Jun '09

16 Jun '09

A small group of us have started working on the software release for the XO-1.5, based on Fedora 11. Some details here: http://wiki.laptop.org/go/F11_for_1.5 We're looking forward to engaging the community as much as possible, especially as we become more and more able to get test hardware out to developers and testers. Daniel

5 6

Default 32-bit x86 arch for Fedora 12
by Paul W. Frields 15 Jun '09

15 Jun '09

I thought this might be of interest to builders/developers here: http://www.redhat.com/archives/fedora-devel-list/2009-June/msg01199.html Of note: Proposed change for F12 would mean the CPU in the OLPC-1.0 hardware would explicitly not be supported beyond F11. After talking to a few folks, my understanding is this isn't a big surprise, but I wanted to make sure we were explicitly calling it out for this group's information and, if needed, input. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

1 0

Looking for a ucspi-ipc style tool in Fedora
by Martin Langhoff 13 Jun '09

13 Jun '09

In my neverending quest for the School Server, I am looking for a 'unix socket superserver', something akin to xinetd listening on oldstyle unix sockets. Connecting to the right socket triggers the superserver to spawn a (potentially memory-heavy, privileged) process to handle the connection, with the superserver handling rate limiting, etc. xinetd doesn't seem to know how to do this at all. ucspi-unix and its close cousin ucspi-ipc seem to cover the requirements but are not in Fedora. Are there alternatives that I am overlooking? thanks! m -- martin.langhoff(a)gmail.com martin(a)laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff

4 4

"Cannot find root file system!" with 2009-06-03 SoaS on XO-1
by S Page 13 Jun '09

13 Jun '09

I made a live USB for my XO-1 in Kubuntu 9.04. I downloaded http://people.sugarlabs.org/sdz/livecd-iso-to-disk.sh and the current SoaS-2 snapshot. I installed the package dependencies. I synthesized the overlapping instructions in http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Linux and http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC (the latter only documents Fedora) , using commands like sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 --home-size-mb 160 --unencrypted-home Soas2-200906031834.iso /dev/sdc1 sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 --unencrypted-home --noverify --skipcopy --xo --xo-no-home Soas2-200906031834.iso /dev/sdc1 I inserted this in my unlocked XO-1 running q2e41 firmware, and got: ... starting udev4 creating devices ------------------------ WARNING: cannot find root file system! ------------------------ Create symlink /dev/root and then exit this shell to continue the boot sequence. bash: no job control in this shell bash-4-0# scsi 0:0:0:0: Direct-Access SanDisk Cruzer Pattern 7.01 PQ: 0 ANSI: 0 CCS sd 0:0:0:0: [sda] (disk size stuff...) (... more sda mesages) This rings a bell, I think it happened to me months ago with Rawhide-XO. It sounds like http://dev.sugarlabs.org/ticket/421 , marked Closed. I looked through the comments in there and https://fedorahosted.org/liveusb-creator/ticket/53 and didn't see anything that helped: the overlay UUID matches, reinserting USB and/or exiting shell doesn't help, etc. Also, can anyone point to a reasonable explanation of what goes on during a LiveUSB boot? initrd, syslinux.cfg, squash-fs, overlays... This stuff clearly isn't bulletproof but is cloaked in obscurity-fu. Thanks, -- =S Page

2 1

Fwd: plymouth performance
by Daniel Drake 11 Jun '09

11 Jun '09

FYI... ---------- Forwarded message ---------- From: Daniel Drake <dsd(a)laptop.org> Date: 2009/6/11 Subject: plymouth performance To: plymouth(a)lists.freedesktop.org Hi, I've done some timings of plymouth vs non-plymouth boots on my XO laptops, to see how much of an impact it has on boot time. I took each measurement 3 times and then averaged. All recorded times were without much variance; these timings were reliable. I measured by pausing OFW during boot, entering "boot", and then starting a stopwatch at the same time as pressing enter to execute the boot command. On the XO-1 I stopped the stopwatch as soon as I saw the mouse cursor (just before gdm comes up). On the XO-1.5 I stopped the stopwatch as soon as I saw the text at the center of the gdm login screen. For the "without" tests, I removed the rhgb kernel parameter parameter and added console=tty0 On the XO-1: Without plymouth: 61.53 seconds bootup time With plymouth: 79.82 seconds bootup time +18.29 seconds increase, or 30% regression On the XO-1.5: Without plymouth: 24.78 seconds bootup time With plymouth: 27.07 seconds bootup time +2.29 seconds increase, or 10% regression We have a similar problem with OLPC's boot animation code on the XO-1. We recently found out that it slows down boot by about 15 seconds with just a simple animation. However, two superheroes came along and implemented an awesome new algorithm which only redraws the parts of the screen that have changed from the last frame. This completely cuts out the 15-second regression to the point where when you measure timings like the above tests, it often appears that it is tiny bit faster to boot *with* the animation... I wonder if that could be implemented in plymouth. The code is here: http://dev.laptop.org/git/users/bobbyp/bootanim/ Daniel

1 0

[OT] Test run of 2009/05/25 image
by Mikus Grinbergs 11 Jun '09

11 Jun '09

Disclaimer: This post contains Off-Topic meta discussion >>> Conclusion: >>> >>> fedora-olpc, to be a sucess, needs a much slimmer UI than that >>> of GNOME. >> >> "Success" needs to be defined. Seems to me the OLPC was envisioned >> mainly for a single-application environment. Except for being slow at >> processing, I think it succeeds admirably. > > I'm not talking about the sugar interface, which is what you're talking > about. > > Non-sugar interface is something I'm also interested. The reason for my enthusiasm: I think the OLPC offers the bringing of technological assistance to economically disadvantaged locations. I think that people who focus on "slimming" the OLPC are missing the point. What they end up with is a slow, small Linux system. But if what they want is a small Linux system, today's 'netbooks' offer more capability (and as netbooks continue to be produced by the millions, I expect tomorrow's models to cost less than the OLPC). For those who are interested in using the OLPC to bring conventional applications to people who already have access to technology - why not work with a netbook instead? For those who think the OLPC *is* suited to the environments in which it is being deployed - let's work on developing OLPC-scale applications to assist 'the things people do' wherever such "computerization" could improve matters. mikus

2 1

Re: Reminder: no new Fedora 9 CVS branches
by Paul Fox 08 Jun '09

08 Jun '09

dennis wrote: > As Fedora 11 is released on Tuesday June 9th there will be no > new CVS branches allowed for F-9 > http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL > lists the policy in effect. This means that F-9 is now in a > maintenance only cycle, with EOL fast approaching, the exact > EOL date will be set at the FESCo meeting this week. so this means, from OLPC's standpoint, that until F11 is available and useful on an XO, no new or revised packages will be available to XO owners. is that right? (i'm not disagreeing or complaining about the fedora policy -- i'm just thinking that since there was no F10, and F11 doesn't yet run fully, the XO is further behind than it otherwise might be.) paul =--------------------- paul fox, pgf(a)laptop.org

1 0

Re: Test run of 2009/05/25 image
by Mikus Grinbergs 07 Jun '09

07 Jun '09

These days I do almost all my running with the most recent F11-based builds available (e.g., 2009/05/25 image and newer). It is only the lack of audio or video in F11-on-XO that keeps me from abandoning my 8.2.1 systems. Most of the items mentioned don't bother me: [Note: My XOs all have a "permanent" SD card, which holds lots of executables (including activities) + gigs of data + swap partition.] > Forewarning: non scientific tests... > > * "occasional" creating devices hang > > For me, it was "occasional" boot. Once it took 16 boots, the last > 3 of which separated by two hours from the other 13. My *average* number of repeats before boot is successful: 5 or so > > * wasted memory > GNOME just SHOULDN'T be there. A simpler window manager will > make it much better. I installed OpenBox but it was very hard > because of OOM killer :) Looking only at what XO-1s I have powered up at this instant: nand occupancy for 2009/05/28+: 516 MB nand occupancy for build 801: 504 MB [Both values are affected by how many Activities installed in nand.] 256 MB of RAM is not much. That's why I have an active swap partition. I'm not sure how much a smaller "resident system" would help. I do experience [particularly when using 'find /'] unwanted system stalls (OOM killer?) after the system has been running for a while. My guess would be that there are memory leaks - which would be a problem even if initially available amount of memory were greater. Here's hoping that eventually enough people will be using F11-on-XO to justify investigating such problems. > > * OpenBox launches way too many GNOME daemons. > I had to kill a lot of them by hand in order to get some more > free memory. I normally run applications with Sugar instead of Gnome as the manager. Haven't tried to overcommit with F11-on-XO builds, but in my experience with F9-based builds, two "monster" applications active simultaneously (e.g., Firefox + Adobe Reader) are as much as the XO-1 can handle. > > * not enough memory for yum > 99% of the attempts to install anything resulted in OOM kills Helps to periodically do 'yum clean all'. Yum normally runs fine. [Did cause a system stall once when trying to update glibc - but that was on a 'yum upgrade' that was pulling in some 40 packages.] > > * speed of GNOME interface was acceptable > really, this was the biggest surprise I had... > > Conclusion: > > fedora-olpc, to be a sucess, needs a much slimmer UI than that > of GNOME. "Success" needs to be defined. Seems to me the OLPC was envisioned mainly for a single-application environment. Except for being slow at processing, I think it succeeds admirably. [GNOME-on-XO has the advantage of clarity and not-very-complicated. Yes, other UIs can be fashioned, but work would have to be put in to make them "do enough to make it easy for users". <See how much effort it has taken to fashion Sugar.>] mikus

2 1

livecd-iso-to-xo for XO-1.5
by Daniel Drake 04 Jun '09

04 Jun '09

Hi, Here's my initial attempt at an equivalent livecd-iso-to-xo.sh for the XO-1.5. This involves a filesystem change to ext2 as we no longer have raw flash access (right?). Completely untested. Open questions: 1. What should the root= kernel parameter be? 2. How would we distribute this to testers and developers? The resultant file is 4gb, albeit sparse. Maybe rsync can handle sparse files efficiently. 3. How do we use OFW to flash this, including a partition table etc? Daniel

6 10

working around boot problems
by Daniel Drake 04 Jun '09

04 Jun '09

It's frustratingly difficult to immediately work on the "unknown filesystem jffs2" problem because more often than not, the same kernel for me fails to even reach that stage (see my "another boot hang" thread). Switching to Deepak's 2.6.30-rc5 kernel for XO, both problems mysteriously go away. Here are the files and the procedure if anyone else wants to try it out. http://dev.laptop.org/~dsd/20090604/ I don't know what else works or fails in Deepak's kernel, or if there are any plans to ship it instead of the Fedora kernel for these XO-1 efforts. Daniel

2 1

jffs2 mounting problem
by Daniel Drake 04 Jun '09

04 Jun '09

Hi, I've been digging into the "unknown filesystem type: jffs2" problem that makes boot fail most of the time on XO-1. First observation, this isn't the message that appears furthest down on the screen, it's about halfway down. The one at the bottom of the screen says "creating devices", making it appear like the hang has happened there, but actually the screen is screwed up at this point and lines being printed are appearing in something like this order: 5 6 7 8 unknown filesystem type jffs2 1 2 3 4 creating devices I added some initrd debug messages and confirmed that jffs2 is not loaded before the "mount" call is made. The mount procedure (on the kernel side) is therefore responsible for loading the module. Turning plymouth off (by commenting out the appropriate lines in the initrd scripts) causes messages to appear on-screen in the right order *and* seems to reliably work around the race bug. At this point I'm having severe difficulty to boot this kernel to add more diagnostics, even after a fresh reflash, even on a 2nd XO, due to an even earlier hang problem (see my "another boot hang" thread). Daniel

1 0

another boot hang (not the jffs2 one)
by Daniel Drake 04 Jun '09

04 Jun '09

I'm seeing a hang during early boot of recent F11-XO images. Right now I have reproduced on freshly-reflashed 20090528 and 20090525, on 2 different XOs. It is not the "Unknown filesystem jffs2" hang or the "Creating devices" hang. It is much earlier, before the kernel has even kicked the framebuffer. At the point of the hang, the output on screen is: Boot device: /nandflash:....... Loading ramdisk image from nand:\boot\initrd0.img ... (this screen is from the OpenFirmware boot process, the screen background is still grey, the Linux kernel does not appear to have become alive at all) It hangs at this point, with no extra output on serial console, and is unresponsive to OFW frame key for interruption. Is anyone else seeing this? (please don't confuse this with other boot hangs, where the screen contents are different) Daniel

2 2

Re: another boot hang (not the jffs2 one)
by Mikus Grinbergs 04 Jun '09

04 Jun '09

Console ends with > Loading ramdisk image from nand:\boot\initrd0.img ... The question is - how repeatable is this situation ? I get these from time to time on my XO-1s. My usual response is to repeat the boot sequence from the beginning, *after* having changed my external device configuration (for instance, by pulling some cables from the USB sockets on the XO). [My guess is that the boot software gets "stuck" waiting for something -- and that by changing the external devices I somehow change the internal timings of boot.] ---- For me, booting sometimes also gets "stuck" soon after > Type the Esc key to interrupt automatic startup My response is to just repeat the boot sequence from the beginning. Without me doing anything except glaring at the XO, it appears to alter its internal timings enough to next time get past this point. mikus

1 0

Package Honey Activities?
by Bryan Kearney 04 Jun '09

04 Jun '09

Hopefully this will not get in anyone spam folder.... Are we still trying to package honey activities for Fedora? I have an open-review for paint.. and if the plan is to get them in I am happy to finish it. However, if the plan is to upgrade via .xo I am happy to close it out. -- bk

3 3

Test run of 2009/05/25 image
by Rui Miguel Silva Seabra 04 Jun '09

04 Jun '09

Hi, Forewarning: non scientific tests... * "occasional" creating devices hang For me, it was "occasional" boot. Once it took 16 boots, the last 3 of which separated by two hours from the other 13. * wasted memory GNOME just SHOULDN'T be there. A simpler window manager will make it much better. I installed OpenBox but it was very hard because of OOM killer :) * OpenBox launches way too many GNOME daemons. I had to kill a lot of them by hand in order to get some more free memory. * not enough memory for yum 99% of the attempts to install anything resulted in OOM kills * speed of GNOME interface was acceptable really, this was the biggest surprise I had... Conclusion: fedora-olpc, to be a sucess, needs a much slimmer UI than that of GNOME. Rui

2 2

Re: rsync on F11 on XO-1 is giving me trouble
by Mikus Grinbergs 03 Jun '09

03 Jun '09

> > Lately I've been encountering a lot of trouble with using 'rsync' > > between F11-on-XO systems. > > since i know you use ethernet quite a bit, is this with a wired > or a wireless connection (or both)? I do not have any wireless at home. This is with multiple XOs connected to my home ethernet LAN; the daemon is started on the sending XO; the 'rsync' command is issued from the receiving XO, giving the dotted-decimal IP address of the (passive) sending XO. [Collaborative Activities between XOs, such as Chat or Write, work fine over the wired ethernet.] [As an experiment, I was able to manually configure F10-based Joyride to use mesh instead of the ethernet for 'rsync'. But I've been too lazy to repeat that experiment with F11-based builds.] mikus

1 0

rsync on F11 on XO-1 is giving me trouble
by Mikus Grinbergs 03 Jun '09

03 Jun '09

Disclaimer: This is "For Your Information" (not for "Action") I have a "permanent" SD card in each of my XOs, and use 'rsync' to keep the contents of these SD cards synchronized between systems. Lately I've been encountering a lot of trouble with using 'rsync' between F11-on-XO systems. Typically, the data transfer stalls (and sometimes leaves the receiving-end SD card corrupted). I'm not sure which end of the rsync data transfer is at fault. The daemon (sending) end is left high and dry, but at least in that machine I can continue (and 'kill -2' the daemon, if need be). The machine at the receiving end typically becomes unresponsive (often the only thing I can do is to power off). My guess is that the receiving end may be running out of memory (though I *do* have a swap partition defined). I'm not writing a bug report, because I cannot deliberately reproduce this (it just happens, sooner or later). I'm seeing this both with recent rawhide-xo builds and with recent SoaS builds. mikus

2 1

package review needed for olpc-kbdshim
by Paul Fox 03 Jun '09

03 Jun '09

i'd like to get olpc-kbdshim upstreamed so that more people can try it, etc. https://bugzilla.redhat.com/show_bug.cgi?id=495902 if anyone can do me the honor of taking a look, and gently telling me all that i've done wrong, or not at all, i'd appreciate it. (i'll be submitting olpc-powerd for review as well, but since i've surely made the same mistakes in both, and olpc-kbdshim is independent of olpc-powerd, i'm doing it first...) thanks! paul =--------------------- paul fox, pgf(a)laptop.org

1 2

Please update your Sugar packages for SoaS!
by Sebastian Dziallas 03 Jun '09

03 Jun '09

Hi all, as we're quite quickly approaching the next release of SoaS, which is scheduled for June 24, it would be great if you could update the Sugar packages you maintain in Fedora to their latest versions. The whole roadmap is listed on our wiki, where you can also find the current version number of your package(s): http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Packaging In case you're unable to do the update, you can drop Steven (listed as CC) an e-mail, who has kindly agreed to help, if needed. Thanks a lot, --Sebastian

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

olpc June 2009