Thanks to a pointer from warren, I've just pushed a workaround to the spins-kickstart repo to help some of the graphical glitches that have been seen on on the OLPC. This includes the blacked out buttons and also the cut-off text. Unfortunately, this probably won't make the Fedora 10 Preview release next week, although it will be in the final release. If you'd like to test it yourself, you can edit /etc/X11/xorg.conf and add a line

Option “MigrationHeuristic” “greedy”

below the EXA line.

As an update to my post last week, Snapshot 2 of Fedora 10 should be available via bittorrent now. (I had intended to post this update on Friday, but then my main laptop decided to start randomly and regularly dying on me :-/)

Again if you ensure that you have the latest livecd-iso-to-disk script, there are a few changes and improvements with Snap2

• If you pass –swap-size-mb to the script, you'll get a swap file set up which gets automatically activated on boot. As mentioned by others, having some swap makes a huge difference.
• We set up the inernal nand (flash) to be used for /home. We don't reuse the homedir from the main XO OS but the data is written there so you can update images without losing changes
• Related to that, we now reset the overlay on every boot. This means the only saved bits are the things in /home. But this lets us worry (less) about filling the overlay and causing things to crash.

On the other hand, from my quick reading of mailing lists so far, there may also be some other performance regressions vs Snap1. Testing and details from people appreciated as always.

As the Fedora 10 release cycle moves forward, we are now in the stage where there are regular “snapshot” releases planned for every week. These snapshots are just a 'point in time' test of rawhide and released based on whether they work and if not, then we end up just waiting for the next week. The intent is to keep the required effort level relatively low but still give a basis for testing between the beta and the preview release.

On Friday, the first of these post-beta snapshots was released. This includes a set of live images which can run without modifications on the OLPC. This is nice as it will make me not have to do builds of images and host them on fedorapeople anymore 🙂

With this image plus the updated livecd-iso-to-disk, the performance of the image on the XO is much better. How is this achieved? The single biggest thing that helps is changing to putting the ext3fs on the SD card as opposed to the squashfs. This means we're not paying the penalty of decompression. The downside is that this requires a 4 GB (or more) SD card as opposed to a 2 GB one.

A second thing which helps (significantly) is not using a RAM based overlay and instead putting the overlay on the SD card. There are some upsides and some downsides to doing this, but at this point, the upsides seem to outweigh the downsides. This will even more be the case for this week's snapshot with a few of the things I'm planning to have ready for that (more details below…).

So that said, what is the invocation of livecd-iso-to-disk that I'm using (and thus would recommend to testers)? Presently, it's

~/src/fedora/livecd-tools/tools/livecd-iso-to-disk.sh –force –xo –overlay-size-mb 512 – ~/Desktop/Live/F10-Snap1-i686-Live.iso /dev/mmcblk0p1

This sets up a 512 MB (persistent) overlay on the SD card and with –xo, we set up a boot/olpc.fth as well as moving over the embedded ext3fs instead of the squashfs.

So the obvious question is what's next/on my plate to make sure is in better shape for this week's snapshot?

• Fix up handling so that we can easily set up having some swap on the SD card. This again feels like a situation where we're better off doing than not. Most of the mechanism should be present in Snap1, but for some reason, I'm not seeing /mnt/live being properly mounted from the live initscript. This should be a pretty straight-forward thing if someone wanted to take a look and send me a patch 🙂 The live initscript itself lives in the spin-kickstarts repo
• Non-persistent, disk-based overlay. The “persistence” is kind of kludgey in that it can pretty easily fill up and cause problems. Unfortunately, with dm-snapshot, there's not a lot we can do about that. Hopefully we'll get some form of unionfs in the future, but that definitely won't land for F10. This should just be a matter of changing the initrd to recognize a flag and recreate the snapshot store on the SD card when requested. The initrd is created from mkliveinitrd in the mkinitrd package.
• Persistent /home on the internal nand (mtd0). Again, this should be mostly ready to go with Snap1, but was acting weird the end of last week for me. Should get mounted within the live initscript
• Start making a dent in some of the reported bugs
• Investigate the question which was asked of just sticking the ext3fs on the SD card directly and not doing the “normal” live image bits for the overlay. While this is interesting to explore, I have a sinking suspicion that it's not something that's really doable in the timeframe of Fedora 10, although it is certainly one that bears looking at more for Fedora 11.

Took a long weekend from pretty much everything work related (although I had to do some school work) and then got back this evening and spent way too much time on some homework for System Architecture. This process was made more frustrating by OpenOffice deciding to crash and corrupt its own backup file in the process. I'm so glad that office software really hasn't improved :-/

So if you've sent an email and expected to see a response from me, hopefully I'll get to it tomorrow. Direct mail looks quiet, but I see there are some 800 messages on various Fedora related lists for me to get through…

For those chomping at the bit about Fedora on OLPC, the new snapshot images that went up on Friday should work better on the XO and integrate everything that's needed without requiring a special OLPC build. You'll also want the updated <a href="http://katzj.fedorapeople.org/olpc/livecd-iso-to-disklivecd-iso-to-disk which copies the uncompressed ext3fs.img onto your SD card rather than the squashfs. You'll definitely need a 4 GB SD card instead of a 2 GB one for that and there are also some corner cases like running out of disk space that I haven't fixed up in the script, hence why it's not in git yet. And if none of that makes sense, I'm intending to get a more verbose update up tomorrow.

But right now, it's after midnight and I was up before 5 am to head down to a bike race and so I'm exhausted and going to go crash into bed for a few hours so that I can wake up in the morning and maybe even make it to class on time…

So, you just got your XO to do some testing of Fedora on OLPC. You update the software that was on there, get a developer key, wait a day, and then get all ready to boot your Fedora image off of the SD card ….

And it boots. But it's slow. Very very slow. Some slowness is to be expected… this isn't a fast machine. But it should probably be a little bit speedier than it is. So want to try out a few experiments to try to help pin down the cause of the slowness? Then read on, pick a case and leave comments about your results.

1. Try using a persistent overlay instead of the in-memory one. Add –overlay-size-mb to your livecd-iso-to-disk invocation. Amount should be relative to the size of your SD card.
2. See if/how much having swap available helps. You can create a file on the SD card with dd, run mkswap against the file and then enable it on the XO. The best test for this would probably be to boot the XO single-user and run swapon from there and then do telinit 5.
3. Try disabling some services from the live image. Again boot to single-user, chkconfig some services and then telinit 5
4. … your idea here. Hopefully other people have some ideas of things to try as well. Try them out and let us know how it goes.

Made some more progress today with running Fedora on the XO. Until I manage to go and pick up the right SD card, I figured I'd give performance a little bit of a rest and so instead focused on seeing which bits of the hardware appeared to work (or not). So I booted up into run-level 3 with the image I posted last night and started poking.

• Wireless: First thing to check was the wireless to see if it worked. And it does, the driver gets loaded, we have the firmware and it managed to find the access point at my house and associate without problems. Haven't really looked at mesh at all, and also haven't dived into making sure wpa works, but at least for the basics, it seems okay.
• Camera: From the quick test of “does the driver load” and “does the driver give data”, this looks okay too. Doing cat < /dev/video0 as a user turns on the LED for the camera and prints garbage to the screen.
• Sound: Driver loads and the mixer shows elements, but playing sound isn't looking like it's working. Needs more investigation
• Internal Flash (NAND): Driver seems to load and with a couple of pointers from dwmw2, is mountable without having to do any more module loads. Went ahead and did the next obvious step and changed things so that we can use that for the persistent /home.
• Special keys: Most of the keys on the keyboard seem to be appropriately mapped, but there are some that will need mapping via hal. Should be straight-forward to sit down and do as it's just writing some fdi file bits (hint: if someone wants to volunteer to do this, I can point you in the right direction 🙂
• Power management: Suspend to RAM isn't showing up as available at all right now. I suspect some kernel bits that haven't been upstreamed need to be pulled out. Will probably look closer at this tomorrow

And now, I think it is time to go watch some tv

A new image for testing Fedora on the XO is now available. This image runs quite a bit slower than the previous one in X and I haven't gotten to why yet, so if you try it, I recommend quite a bit of patience. But I wanted to get something up in the near-term so that people would see some sort of progress 🙂

Changes and improvements in this image…:

• Updated packages to match those that are included in the Fedora 10 beta that was released yesterday
• Slightly newer kernel (the one that davej built last night) which has debugging disabled. Sadly, this wasn't the help I hoped it would be.

Booting to runlevel 3 is okay for at least some testing, though. So be sure to add –extra-kernel-args 3 to your invocation of livecd-iso-to-disk in addition to passing –xo. And hopefully we'll have a new image up shortly that fixes some of the slowness and makes things more reasonable for general use “soon”

As I mentioned before, one thing that I've been spending some time on is getting a “stock” Fedora to run on the OLPC XO hardware. Obviously there's not a CD drive, but there is a USB port and there is also an SD card slot. Which given the support in our live images for running off of such things, there seemed to be a bit of an obvious matchup.

There's just one (large-ish) problem. The XO is a Geode, so an i586 processor with cmov. So the stock i686 kernel on the live images definitely doesn't boot there. Unfortunately, neither does the i586 kernel. I'm working on tracking down what the relevant configuration difference is so that it can be fixed — interestingly enough, if you don't load an initrd, a Fedora i586 kernel can boot fine. So there's definitely something a little odd going on. If you have experience in debugging early boot of an XO and have any tips, leave a comment or catch me on IRC or send me mail 🙂

So, instead I've done a modified version of the main OLPC kernel with the help of sdziallas that includes squashfs and also turns on things like dm-snapshot which we need for live images.

That plus a pretty straight-forward image config and we can build a live image that boots into the GNOME desktop on the XO off of either an SD card or a USB stick. There are definitely still things to be fixed, though. To try to help some of that, I've created a tracking bug that can be used by those who have an XO and try running a Fedora live image on it.

Do you have an XO and are interested in trying it out? If so, first be sure that you have a developer key for your system. Then, you can download an image based on today's rawhide (debranded) from here. I've basically tested that it boots, logs in to the desktop and associates to my access point. Then gpk-update-icon fires up and we run out of memory for things. If you kill it quick enough, then you can fire up firefox and slowly do a little bit of other stuff.

Some things that are continuing to be worked on:

• Having somewhere to swap would help a lot
• Using the SD card/USB stick for your persistence instead of eating up valuable RAM
• Persistent /home on the internal NAND (jffs2)
• Looking at high memory usage things and helping to make them better
• Fixing the standard kernel so that we can boot it on the XO
• And if we do the last one then we can boot the standard live images, any of them, on the XO

Any help appreciated! Any bugs you find, please be sure to make them block the tracker so that we can keep up with them accordingly.

As for the questions about what the end goal is here — ultimately, I'd like to have any Fedora spin working on the XO just like it works on lots of other hardware. For Fedora 10, this may be a stretch (although I'm going to land any small changes that can be identified in that timeframe even though it's not a feature and we're at feature/beta freeze). But for Fedora 11, it should certainly be doable.