Root filesystem ran out of room in F11-on-XO1
by Mikus Grinbergs
Disclaimer: I am not asking for help; I am sharing my experience.
Was running a large 'yum' update to an XO1 with os11 installed -- it
failed, because 'yum' ran out of room in the '/' filesystem. I looked,
and it turned out that before this 'yum' run started, /dev/mtdblock0 had
been nearly 90% "used". [For conveniences sake, because '/' is 1GB,
I'll say 10% of '/' is about 100MB (that disregards jffs2 "packing").]
For comparison, I have a not-used-for-testing XO1 with os10 installed --
its '/' filesystem shows "used" a bit over 50%. The near 40% difference
in "how much was used" between the two systems comes out to over 400MB.
[ os11.zd did come with more facilities installed than did os10.zd ]
The amount of software I had added myself was approximately equal for
those os11 and os10 systems. Let us assume that I had filled some 100MB
of the os11 system's space with "leftovers" from my testing. That still
leaves the os11 system with 300MB plus of "occupancy" to be accounted
for. My suspicion is that the major part of this difference in '/'
filesystem "used" is attributable to directory /versions in os11.
If my suspicion is correct, then the "ease of use" of olpc-update (which
depends upon /versions) needs to be balanced against the potential for
"shock" if the XO-1 user "runs out of room in the XO1" that much sooner.
mikus
p.s.
A partial printout from 'du' on the two systems:
> Directory os11 os10
>
> /bin 6475 6474
> /etc 39513 39455
> /lib 36428 28144
> /tmp 0 0
> /var 35012 36009
> /boot 9319 9308
> /home 122330 44500
> /sbin 12722 12714
> /security 140 140
> /bootpart 0 0
> /usr 964111 868882
> /versions 925311
I have no idea why /usr came out so big - I had told 'du' not to follow
symbolic links. [Note that the numbers for /usr alone are in the
vicinity of the size of the whole /dev/mtdblock0 device -- does jffs2
"packing" account for this ?]
Also, /versions has lots of cross-links, which 'du' might have counted
as though they were separate files.
14 years, 2 months
Re: NetworkManager from fedora-updates-testing broken on F11-XO1
by Bernie Innocenti
On Mon, 2010-02-22 at 18:59 -0300, Bernie Innocenti wrote:
> On Mon, 2010-02-22 at 12:08 -0300, Bernie Innocenti wrote:
> > On Thu, 2010-02-18 at 09:55 -0800, Dan Williams wrote:
> > > It'll probably take more investigation than I have time for this week,
> > > so I'll just patch NM to accept the invalid driver name ('usb') as a
> > > fallback. Which is the behavior that 0.7.2 had anyway, so you can
> > > consider it a regression in 0.7.2.995. We'll eventually fix libertas
> > > but I don't think we should block this on a libertas fix.
> >
> > Can you please build a new NetworkManager package in F11 with this
> > work-around applied?
>
> I've scratch-built custom rpms with a crude patch of mine which seems to
> fix the issue:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2006014
This version still has a problem. It segfaults on resume from suspend.
Any idea where I should look? If not, I'll install debuginfos and see if
I can reproduce the crash under gdb.
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> Waking up...
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> (msh0): now managed
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> (msh0): device state change: 1 -> 2 (reason 2)
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> (msh0): bringing up device.
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> (msh0): preparing device.
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> (msh0): deactivating device (reason: 2).
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> (ttyS0): ignoring due to lack of mobile broadband capabilties
Feb 25 17:01:27 xo-37-38-0f NetworkManager: <info> (msh0): device state change: 2 -> 3 (reason 0)
Feb 25 17:01:27 xo-37-38-0f nm-dispatcher.action: Error in get_property: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist#012
Feb 25 17:01:28 xo-37-38-0f NetworkManager: <info> (msh0): now unmanaged
Feb 25 17:01:28 xo-37-38-0f NetworkManager: <info> (msh0): device state change: 3 -> 1 (reason 36)
Feb 25 17:01:28 xo-37-38-0f NetworkManager: <info> (msh0): cleaning up...
Feb 25 17:01:29 xo-37-38-0f kernel: [ 3479.031967] usb 1-1: new high speed USB device using ehci_hcd and address 3
Feb 25 17:01:29 xo-37-38-0f kernel: [ 3479.191039] usb 1-1: configuration #1 chosen from 1 choice
Feb 25 17:01:29 xo-37-38-0f kernel: [ 3479.192354] usb 1-1: firmware: requesting usb8388.bin
Feb 25 17:01:30 xo-37-38-0f kernel: [ 3480.050711] usb8xxx: Firmware ready event received
Feb 25 17:01:30 xo-37-38-0f kernel: [ 3480.051878] libertas: 00:17:c4:37:38:0f, fw 5.110.22p23, cap 0x000003a3
Feb 25 17:01:30 xo-37-38-0f kernel: [ 3480.058889] libertas: eth0: Marvell WLAN 802.11 adapter
Feb 25 17:01:30 xo-37-38-0f kernel: [ 3480.060094] libertas: Not issuing HOST_SLEEP_CFG on XO-1
Feb 25 17:01:30 xo-37-38-0f kernel: [ 3480.060748] libertas: PREP_CMD: command 0x0074 failed: 2
Feb 25 17:01:30 xo-37-38-0f kernel: [ 3480.060767] usb8xxx: Firmware does not seem to support PS mode
Feb 25 17:01:30 xo-37-38-0f NetworkManager: <info> (eth0): driver supports SSID scans (scan_capa 0x01).
Feb 25 17:01:30 xo-37-38-0f NetworkManager: <info> (eth0): new 802.11 WiFi device (driver: 'usb')
Feb 25 17:01:30 xo-37-38-0f NetworkManager: <info> (eth0): exported as /org/freedesktop/Hal/devices/net_00_17_c4_37_38_0f
Feb 25 17:01:30 xo-37-38-0f NetworkManager: <WARN> nm_signal_handler(): Caught signal 11. Generating backtrace...
Feb 25 17:01:30 xo-37-38-0f NetworkManager: ******************* START **********************************
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 0: NetworkManager(nm_logging_backtrace+0x45) [0x8078da5]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 1: NetworkManager [0x8072f4d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 2: [0xb77c6400]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 3: NetworkManager [0x8067a5b]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 4: /lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__OBJECT+0x88) [0x93f338]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 5: /lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2) [0x932352]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 6: /lib/libgobject-2.0.so.0 [0x947cf0]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 7: /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7bd) [0x94905d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 8: /lib/libgobject-2.0.so.0(g_signal_emit+0x26) [0x9494e6]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 9: NetworkManager(_nm_marshal_VOID__STRING_STRING_POINTER_POINTER+0x9d) [0x808ab1d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 10: /lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2) [0x932352]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 11: /lib/libgobject-2.0.so.0 [0x947cf0]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 12: /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7bd) [0x94905d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 13: /lib/libgobject-2.0.so.0(g_signal_emit+0x26) [0x9494e6]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 14: NetworkManager [0x806df19]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 15: /usr/lib/libhal.so.1 [0x71bc3e3]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 16: /lib/libdbus-1.so.3(dbus_connection_dispatch+0x36d) [0x703287d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 17: /usr/lib/libdbus-glib-1.so.2 [0x71ca19d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 18: /lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f8) [0x852308]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 19: /lib/libglib-2.0.so.0 [0x8559e0]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 20: /lib/libglib-2.0.so.0(g_main_loop_run+0x1bf) [0x855e4f]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 21: NetworkManager(main+0xe37) [0x8073d97]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 22: /lib/libc.so.6(__libc_start_main+0xe6) [0x673a86]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 23: NetworkManager [0x80570d1]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: ******************* END **********************************
Feb 25 17:02:14 xo-37-38-0f kernel: [ 3523.422953] psmouse serio1: detected 37px jump in x
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
14 years, 2 months
Sugar 0.88 in F11-XO1
by Bernie Innocenti
>From today's #sugar-meeting:
<erikos> bernie: I think a big problem to recruit 0.88 testers, is that there are no xo images
<erikos> bernie: scratch builds, like tomeu said, sounds good
<erikos> bernie: and then create a repo
<erikos> bernie: maybe mtd is interested in that, too
Ok, I'll create some custom F11-XO1 builds with the latest Sugar
packages retrofitted for testing purposes. Who would like to help me
out?
Here's an initial draft:
== Packages ==
Setup a yum repository with 0.88 packages backported to Fedora 11 (built
in Koji with --scratch or inside an F11 chroot, whichever is easiest).
It shouldn't require too much time, but it would be great if Fedora
packages could offload this work from me and make the result available
on people.sugarlabs.org in the form of a yum repo. Any volunteers?
== OLPC OS Builds ==
Setup an olpc-os-builder environment to fetch Sugar from the above repo.
I could easily do this at Paraguay Educa, but bandwidth to download the
resulting builds is very limited here, and downloading images of over
500MB from my public_html folder is going to be painfully slow from the
Internet.
Perhaps I could duplicate the build harness on one of our buildbot
slaves (in Italy) or a new VM on Treehouse. I doubt we can make
olpc-os-builder work on Sunjammer, as it's quite Fedora specific.
== Testing team ==
Test these builds with real kids. We have many kids with XO-1's in the
nearby town of Caacupe, but school starts tomorrow and we cannot disrupt
their regular classes too much. I think I could give an extra laptop to
a small number of smart and motivated volunteers to test Sugar 0.88 side
by side with 0.82 and 0.84 running on their regular XO.
I've already identified a group of kids with a hacker attitude who would
be perfect for the job. Educators tell me there are even a few kids who
taught themselves to use the shell.
Small teams of testers from other deployments would also be welcome, of
course.
== Collecting Feedback ==
Since Caacupe is 1hr away from the office, we'll teach our young testers
to communicate with the IRC activity and/or through email. Getting them
directly on #sugar may be problematic, but I don't want to send our
testers to a /dev/null place where nobody would answer their questions.
The best business practice to overcome language, cultural and age
barriers would be to interpose support engineers. But the open source
model requires a tighter feedback loop between users and developers.
I don't speak much Spanish myself, so I'm counting on other community
members to help out. As we're dealing with young people with little
computing experience, we'll have to be tolerant and responsible.
Hopefully, the increased confusion in #sugar will not bother technical
members of our community too much.
== Filing bugs ==
I'll try to file meaningful Trac tickets for our testers, possibly with
logs and a pre-analysis.
While our kids might not be able to report bugs on their own, Paraguay
Educa has a few field technicians who could learn to do it.
== Future opportunity: Fedora 12 ==
Optionally, try to upgrade to F12 or even F13. This would potentially
introduce new distro bugs as well as the Sugar bugs.
The benefit would be that we'd be working closer to upstream, but
perhaps we'd be better off leaving the bulk of the distro hacking work
to OLPC so we can focus our resources on testing only Sugar.
== Future opportunity II: Usability testing ==
The Design Team often expressed the need to test proposed UI patches in
the field. This is now possible to a certain extent, although with a
limited number of testers.
I could act as a dumb proxy: send me patches along with the feedback
forms that you'd like the users to fill-in, or something like that.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
14 years, 2 months
Re: Sugar 0.88 in F11-XO1
by Bernie Innocenti
(re-adding the lists)
On Tue, 2010-02-23 at 06:55 -0600, Mikus Grinbergs wrote:
> But this thread is about F11-on-XO1. Meaning that yum ought to be
> defaulting to accessing the F11 repositories. I just now enabled the
> 'rawhide' repository for my F12-based XO1, and explicitly pulled down
> sugar-0.87.5-1.fc14.noarch.rpm from there.
>
> My point is that the Sugar dependencies may have been upstreamed -- but
> those not in the inner circle don't know WHERE (choose: in releases F12
> or F13 or F14; in repos fedora or rawhide or update or update-testing).
Luckily, all the dependencies mentioned in the 0.88 Roadmap were already
available in F-11, but I've found a few more which weren't documented:
python-decorator (in F11, but not in F11-XO1)
python-dateutil (in F11, but not in F11-XO1)
python-xklavier (not in F11, needs backporting)
I'll build a public yum repo with the sugar packages and missing
dependencies as soon as I find some time.
Meanwhile, I've convinced rpm into installing the rawhide packages on
Fedora 11. In this configuration the Metacity window manager crashes on
startup for reasons yet to be determined.
After restarting Metacity from the console, Sugar 0.88 showed up and
appeared to work normally.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
14 years, 2 months
s/GNOME/LXDE/ as alternate desktop?
by Rui Miguel Silva Seabra
Hi,
Don't read this as a flame thrown, but as a plea of help for a different
challenge.
Am I alone considering GNOME too fat to work as an alternate desktop on
the XO-1 (and perhaps XO-1.5 as well)?
I'm sorry, I don't have a lot of time to help develop the educational
part, the OLPC I got from G1G1 has been way more useful for me as a
travel laptop (last two FOSDEM's for me, for instance) with little to no
private data.
Since a few months ago, I configured LXDE as an alternate desktop, using
claws for email, midori for browsing, and pidgin for identi.ca, XMPP,
MSN and IRC.
It's *usable*. And I don't mean in the sense that you can use if you're
very patient... it's really freaking usable.
Am I the only one feeling this, or are there more who think like me and
would like to help an effort of having an LXDE properly configured to
take the most of this machines?
Best,
Rui
14 years, 2 months
Re: The Saga Continues
by Aleksey Lim
> Disclaimer: I am not asking for help. I'm just sharing my experiences.
>
> The http://dev.laptop.org/ticket/9945 problem shows up in the latest
> Activity versions from SugarLabs - now in Flip Sticks-4 as well as in
> Cartoon Builder-9 and in Speak-12. [Note: I *download* Activities
> using a different machine than the one I *install* the Activities in.]
>
> I believe that the intent of the new code in these Activities is to
> fetch additional modules from a server if those prerequisite "services"
> have not been installed in the environment in which the Activity is
> being launched.
>
> For myself, I do not believe that the target environment for using OLPCs
> should involve "calling home" (to a server on the internet) for missing
> pieces. Although these new Activity versions are described as fitting
> Sugar versions 0.82 - 0.88, I do not think they are suited to the OLPC.
>
> mikus
These activities have all dependencies bundled thus shouldn't fetch any
data from the net, it was tested in last XO-1 image. If they require
connection it's a bug and log with debug enabled will be usefull.
--
Aleksey
14 years, 2 months
The Saga Continues
by Mikus Grinbergs
Disclaimer: I am not asking for help. I'm just sharing my experiences.
The http://dev.laptop.org/ticket/9945 problem shows up in the latest
Activity versions from SugarLabs - now in Flip Sticks-4 as well as in
Cartoon Builder-9 and in Speak-12. [Note: I *download* Activities
using a different machine than the one I *install* the Activities in.]
I believe that the intent of the new code in these Activities is to
fetch additional modules from a server if those prerequisite "services"
have not been installed in the environment in which the Activity is
being launched.
For myself, I do not believe that the target environment for using OLPCs
should involve "calling home" (to a server on the internet) for missing
pieces. Although these new Activity versions are described as fitting
Sugar versions 0.82 - 0.88, I do not think they are suited to the OLPC.
mikus
14 years, 2 months
Fedora Sugar Packaging Queue
by Sebastian Dziallas
Hi all,
I'd like to take the chance to hint once more at our tracking bug [1],
as well as the activity wiki page [2]. Recently, TamTam has been posted
for review, too. I'm a little disappointed with the speed we're
progressing with.
Here's a list of the currently most important things we need to get in.
Settings Manager - https://bugzilla.redhat.com/show_bug.cgi?id=563598
NoDM - https://bugzilla.redhat.com/show_bug.cgi?id=559559
TamTam Suite - https://bugzilla.redhat.com/show_bug.cgi?id=564425
Typing Turtle - https://bugzilla.redhat.com/show_bug.cgi?id=559213
Other reviews still require action, either by the packager or the
reviewer. I'm going to ping the owners directly.
In other news, we're being blocked by licensing issues for some
activities and the boot screen, as I've posted before.
If you get a second, please go ahead and help to unblock us here - for
example by reviewing a package (these aren't really that complicated, so
it shouldn't take too long) or by packaging an activity from the list.
Thanks,
--Sebastian
[1] https://bugzilla.redhat.com/show_bug.cgi?id=558617
[2] https://fedoraproject.org/wiki/Sugar_Activities
14 years, 2 months
