Re: Daily builds are no longer livecd images
by Mikus Grinbergs
> > I did the zcat 20090525.bootable.gz > /dev/sdf1 (USB stick).
> > That USB stick failed to boot on the XO.
>
> I think that's because you should have used /dev/sdf, not /dev/sdf1.
> Using /dev/sdf1 fails to copy over the correct partition table to
> the start of the disk.
Thank you. That was the mistake I had made.
Now, booting from USB stick created from zcat 20090525.bootable.gz
consistently stalls on me subsequent to showing the message " mount:
unknown filesystem type 'jffs2' " and the message " Bug in initramfs
/init detected. Dropping to a shell. Good luck! ". [I repeated
the power-on boot more than 10 times, and it stalled each time.]
[In contrast, when the booting XO from nand (created by 'copy-nand'
from 20090525.img) sequence stalls (typically subsequent to that "
unknown filesytem type 'jffs2' " message having been shown), I often
manage to get past that point by persistently re-trying the power-on
boot sequence over and over - if I'm lucky, I eventually get no
error message and no stall.]
Thanks, mikus
15 years
Re: Daily builds are no longer livecd images
by Mikus Grinbergs
>> But in the case of booting from an USB stick, I believe the system does
>> *not* write the contents of changed memory pages back out to the USB stick.
>> When I reboot from that USB stick (particularly if I've powered-down the
>> system in the meantime), why would the changes still be there ??
>
> Because USB sticks are not CDs. We use a persistent overlay on live
> USBs so that you can store your changes.
I am not seeing what you describe.
[The only machines I have to experiment on are XO-1s.]
Since I do not see the "changes still there" that you keep talking
about, all I can figure out is that we are talking past each other.
--------
If I look at the contents of an USB stick (df, ls -la) before using
that USB stick to boot from; then boot the system and make changes;
then shutdown -- when I again look at the contents of that USB
stick, I do not notice those contents having been changed.
If in fact the content of that USB stick has not changed, where does
the "persistent overlay on live USBs" (that you describe) get kept ?
Thanks, mikus
p.s. I just did an experiment. I made a copy of the USB stick I
created with 'livecd-iso-to-disk' from rawhide-xo
20090525.iso. I then booted an XO with the original USB
stick, and made changes to / and to /etc (in memory) once
Gnome was running. I then shut down the XO, and compared the
original USB stick to the earlier copy. They were
byte-for-byte identical. To me, that says that *nothing* got
written to the original USB stick (used to boot from) when I
made those changes to the booted system.
15 years
Re: Daily builds are no longer livecd images
by Mikus Grinbergs
One of the posts to this topic said:
> Before, *every* time you booted the XO with Rawhide-XO, there was a
> number of scripts initiated, for example to create the liveuser or to
> check for changed hardware. This is of course nonsense, as the XO's
> hardware won't change.
In my case, the XO hardware does change from boot to boot.
I plug (or unplug) various "external" devices (hard disks or other
storage devices, USB hubs, ethernet adapters, keyboards, etc. (even
multiple SD cards)) as I need them. Also, sometimes the boot-up
process stalls on me -- my experience has been that changing the
external device configuration of the XO is sometimes enough to alter
the "internal timings" of the boot-up process sufficiently to get
past some instances of stalling.
mikus
15 years
[SoaS] Important Schedule Changes - Please Read!
by Sebastian Dziallas
Hi everybody,
please read this carefully, as it concerns major schedule changes
regarding our upcoming Sugar on a Stick release in the end of June.
The original plan was have a Release Candidate based on F11 Final and
Sugar 0.84 at that time and a Final Version later in Q3. After serious
consideration, it looks way more sensible to do the following:
=> Omit the RC release and replace it with our Final Release!
This means that Sugar on a Stick is going be released in June, on
2009-06-24. Now, why? Well, there were quite some reasons:
* Fedora 11 will be released on June 2 and Sugar 0.84 has already had
it's release some time ago. By moving our final release later into the
year, we'd be either forced to use some outdated or unstable components,
as the next major Sugar version will be 0.86, which is targeted for
Fedora 12. We're preventing this by having our release now just a month
after F11's.
* It helps us a lot to get feedback from students over the summer break,
so that we're increasing the likelihood of gaining more users.
* Sugar on a Stick is rather stable right now - I'll outline this in a
separate e-mail!
The updated roadmap is located here:
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap
Package Maintainers will receive reminders to update their RPM packages
soonish! Again, please make sure to follow the deadlines. The last date
for changes is 2009-06-10. Afterwards, dev team's approval is required.
Please contact me with any concerns you may have - also off-list, if needed!
Best Regards,
--Sebastian Dziallas
15 years
Re: Daily builds are no longer livecd images
by Mikus Grinbergs
> Starting with today's 20090525 build, the images are no longer livecd
> images, so changes will persist across reboots.
> http://dev.laptop.org/~cjb/rawhide-xo/20090525/
>
> Thanks to Sebastian for the script to make installed images!
Chris, I'm not sure what this post is telling me.
I visually compared the 20090525 subdirectory with the 20050519
subdirectory - they both contain the same number of files (of
comparable size). And when I used 'copy-nand' to install the
20090525.img file, my XO-1's nand contents did not seem organized
any different from when I installed 20090519.img.
What does "no longer livecd images" mean ?
[Having now tried 20090525, I see that directory '/home/liveuser'
has now reverted to '/home/user'. Oh well - I'll just change all my
customization scripts back to updating '/home/user'.]
Thanks, mikus
p.s. On my Ubuntu 9.04 system, I'm unable to run the
'livecd-iso-to-xo' script (mounting the squashfs fails).
Could you perhaps ask Sebastian to get together with the Soas2 folks
- they currently release only a .iso file, which I could only
install to an USB stick (where changes didn't persist). It would be
useful to me to be able to install Soas2 builds onto XO-1 nand, and
be able to reboot and have changes persist from the previous time.
15 years
rawhide-xo 20090525 problems
by Mikus Grinbergs
Using 'copy-nand', flashed ~cjb/rawhide-xo 20090525.img to nand.
Have just started to customize it (have to change all references to
/home/liveuser back to /home/olpc), but in the meantime have already
encountered two problems that 20090519 did not have:
- In Gnome (and on the logon screen), buttons that have had the
focus (e.g., by being clicked on) are given a black background.
[There is already a FC11 bug for this.] (Changing the focus
appears to give back the appearance the button ought to have.)
- In 'Terminal' (in Sugar), a click in the scrollbar gets
"multiplied" -- a single click (for "scroll page up") results in
the display scrolling *many* pages. [This is an old OLPC
problem, which however is for me now showing up in rawhide-xo
for the first time.]
mikus
15 years
rawhide-xo 20090519 has great difficulty booting on XO-1
by Mikus Grinbergs
Using 'copy-nand', flashed ~cjb/fedora-xo 20090519.img to nand.
Booted. A number of boot-time messages scrolled by; then the the
XO-1 became completely unresponsive (i.e., the boot process stalled)
- only thing that would work was the button to power off.
Last two "boot-up" lines that were output (before the stall) were:
"starting udevd"
"creating devices"
Had to repeat the power-on sequence many many times before the
boot-up process happened to get past the "creating devices" point.
mikus
p.s. During the boot-up process, the boot-time messages scroll by.
This scrolling gets 'interrupted' by a from-top-down "erase" of the
lines on the screen (as though a squeegee had been used to wipe out
what had been written to the screen). This "screen cleaning" action
usually occurs twice before the rawhide boot-up process gets to the
"creating devices" point (where all too often the process stalls).
However (and I can *not* swear to how consistent this is), in those
cases where the boot-up process got past that stall point (and the
system came up as it should), I've noticed that the "screen
cleaning" action (i.e., the squeegeeing) occurred *three* times (not
two times) before the boot-up got to that "creating devices" point.
15 years
Help with testing a patch for xulrunner...
by Martin Langhoff
Hi list,
while working on a webbased project (as part of the OLPC School
Server), we're hitting on a performance bug / oddity with Browse.xo
(which is the sugarised face of xulrunner on the XO) on the 8.2
release.
Rob O'Callahan proposes we test a patch (attached) to see if things
get better. Can anyone help with this? The xulrunner we ship on 8.2
has some OLPC-specific patches, and I'd hope to add this patch to the
pile.
I couldn't find the spec or srpm, but here's the Koji task. Presumably
it's retrievable from there?
http://koji.fedoraproject.org/koji/taskinfo?taskID=783777
cheers,
martin
---------- Forwarded message ----------
From: Robert O'Callahan <robert(a)ocallahan.org>
Date: Fri, May 15, 2009 at 1:07 PM
Subject: Re: Browse.xo performance & resolution - Hulahop 200dpi vs
Browse 134dpi
To: Mihai Sucan <mihai.sucan(a)gmail.com>
Cc: Martin Langhoff <martin.langhoff(a)gmail.com>
On Fri, May 15, 2009 at 10:54 PM, Mihai Sucan <mihai.sucan(a)gmail.com> wrote:
>
> Le Fri, 15 May 2009 13:22:15 +0300, Robert O'Callahan <robert(a)ocallahan.org> a écrit:
>
>> Another thing we could do is implement what I suggested here:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=394103#c53
>> That would let you set the dpi to the correct value (so physical units,
>> including fonts in pt, display correctly) but force images and canvases (and
>> other CSS px units) to not be scaled. They'd be too small, but fast :-).
>
> This is what would be best.
OK, I'll do that.
> Another idea is to have some CSS property to disable scaling entirely for the canvas elements I want.
I don't really want to do that, because I don't want Web developers to
write applications that depend on zoom or dpi.
If you're willing to assume you're 200dpi, you can just write <canvas
width="200" height="200" style="width:100px; height:100px;"> ...
suboptimal though.
I don't know if you can apply a patch to Gecko, but if you can, the
attached patch would let us render the <canvas> in a local surface
instead of using X. That should provide a speedup in your benchmarks,
where X isn't giving much hw acceleration and you're doing a large
amount of drawing operations and hardly any displaying to the screen.
I'd be interested to hear what effect it has. However, in real-world
usage I imagine the canvas is drawn to the screen far more often
compared to the number of drawing operations, so this patch might not
make sense for actual users.
Rob
--
"He was pierced for our transgressions, he was crushed for our
iniquities; the punishment that brought us peace was upon him, and by
his wounds we are healed. We all, like sheep, have gone astray, each
of us has turned to his own way; and the LORD has laid on him the
iniquity of us all." [Isaiah 53:5-6]
--
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
15 years
Re: The XO-1.5 software plan.
by Martin Langhoff
On Fri, May 15, 2009 at 10:17 PM, Chris Ball <cjb(a)laptop.org> wrote:
> We think we'll need to use our own kernel and initrd, but the other
> base packages we expect to need are present in Fedora already,
One area we'll also need help with is the "under a tree" networking scenario.
If you've used an XO, you know what it works like: by default the OS
automatically forms an ad-hoc network between the machines present
using wifi but not relying on an AP. People refer to this as 'mesh'
colloquially but it doesn't actually require 802.11s (as long as all
the XOs are nearby).
In theory at least. In practice, the ad-hoc network facility is tied
to our use of a patched NM and our 'msh0' devices.
The current plans don't include using 802.11s, and there are hopes to
ship a more vanilla NM. This means that the 'under a tree' scenario
needs help in NM integration and a bit of elbow grease.
Ad-hoc networks can work pretty well for small numbers of nodes -- I
suspect that that Fedora users (specially laptop users) would benefit
from an easy way to run an ad-hoc network amongst machines, without
the need of a 'hostap'-able driver.
Cerebro has interesting code in this area -- a more ambitious goal
would be to integrate it into our stack, as it can mimic some of the
802.11s mesh behaviour. But even without magic routing and path
discovery, small ad hoc networks can and do work.
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
15 years
OLPC's XO-1.5 software plan.
by Chris Ball
We have some good news: OLPC has decided to base its software release
for the new XO-1.5 laptop on Fedora 11. Unlike previous releases, we
plan to use a full Fedora desktop build, booting into Sugar but giving
users the option to switch into a standard GNOME install instead.
(This will mostly be useful for older kids in high school.)
I'm particularly happy about this plan because it will allow us to
catch up with the awesome work present in the Sugar community's most
recent release, Sugar 0.84, as well as merging the latest Fedora work
and including GNOME into the mix for the first time. The new machines
will have 1GB of RAM and 4GB of flash, so we have enough room for both
environments at once.
We think we'll need to use our own kernel and initrd, but the other
base packages we expect to need are present in Fedora already,
including Sugar; in fact, we already have an F11+Sugar+GNOME build
for the XO-1 using pure Fedora packages. That build will get better
as a result of this work (although OLPC's focus will be on getting
the XO-1.5 running) and it will form the basis for the XO-1.5 build.
If you're interested in contributing, we'd certainly love your help,
and you can find us on the fedora-olpc mailing list¹, and freenode
IRC's #fedora-olpc channel. Our existing F11 build images for the
XO-1 are here², and we'll soon begin publishing images for the XO-1.5
too. XO-1.5 beta machines will start to be manufactured over the next
few months, and will be available to contributors as part of our
Contributors Program³ once the hardware's up and running.
Finally, thanks are due to the volunteer Fedora packagers and testers
who helped us get to the point of being able to commit to Fedora 11
for this new build, in particular: Fabian Affolter, Kushal Das, Greg
DeKoenigsberg, Martin Dengler, Scott Douglass, Sebastian Dziallas,
Mikus Grinbergs, Bryan Kearney, Gary C. Martin, Steven M. Parrish,
and Peter Robinson. Thanks!
- Chris, for the OLPC techteam.
¹: http://www.redhat.com/mailman/listinfo/fedora-olpc-list
²: http://dev.laptop.org/~cjb/rawhide-xo/
³: http://wiki.laptop.org/go/Contributors_program
--
Chris Ball <cjb(a)laptop.org>
15 years