Re: soas63xo impressions
On Tue, Sep 15, 2009 at 08:37:15PM -0400, Mikus Grinbergs wrote: Disclaimer: I am not asking for help; I'm sharing my experiences. Thanks for reporting your experiences. You're good at finding builds that aren't even announced :). Ran with soas63xo (booted from nand) on my XO-1. Many of the difficulties with previous SoaS builds were still present. That last SoaS-on-XO build that was publicised was based on F11. This one (and recent ones) are based on Rawhide. So I expect there to be more bugs, rather than fewer, in the short term. My Settings - DateTime - as soon as (to move the selection off UTC to my timezone) I pressed (cursor was on vertical scrollbar) the left mouse button, sugar crashed. [Sugar also crashed when I clicked in the horizontal scrollbar in Browse.] I experienced this as well. No idea why. 'rpm -q kernel' shows *two* kernels applied to soas63xo. This is expected and not a problem. From the point of view of users running an XO, the SugarLabs software is now on a fork. It's on Fedora, and SugarLabs is upstream of OLPC. So it would be more usual to say OLPC's distribution of GNU/Linux with Sugar is F11-based, and SoaS is F12-based. If you drew a graph to try to find forks you might find it hard to usefully define that term: 0.82 0.84 0.86 Sugar ---O-OO--- Sugar HEAD \ \\ | | | F11 -oO-o--O---|-- F11 HEAD | \ | | --|-- OLPC HEAD || F12 --|o-O F12 HEAD | | SoaS--o--o SoaS HEAD \ \ --- Strawberry--- Blueberry O = branch point o = merge point (landing a branch on another codeline) | = connection between branch and merge point mikus Martin pgpHciRH7bkpg.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux
On Wed, Sep 16, 2009 at 11:18:17AM +0800, Mitch Bradley wrote: It is gratifying that so many people like the idea of being able to zap back into OFW from Linux - especially since I got such intense pushback when I first proposed leaving OFW resident on OLPC. Why? Security reasons? Martin pgp4TMiTW7u3t.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux
Martin Dengler wrote: On Wed, Sep 16, 2009 at 11:18:17AM +0800, Mitch Bradley wrote: It is gratifying that so many people like the idea of being able to zap back into OFW from Linux - especially since I got such intense pushback when I first proposed leaving OFW resident on OLPC. Why? Security reasons? Other than it uses some memory and every byte is precious, a lot of the objections were of the ilk I wouldn't use it so it's not useful. It seems to me that some fraction of kernel developers have an attitude that some BIOSes have given us a lot of trouble therefore anything in the BIOS realm sucks and firmware is not to be trusted and the only true and blessed code is in the Linux kernel. That's obviously a caricature, but I think it conveys an undercurrent of thought that exists at some level. Martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux
Another objection, now that I think about it, is that some people didn't like the way I made OFW coexist within Linux's virtual address space by injecting a page directory entry at the top of one of Linux's page tables. Admittedly, the solution that I chose is rather brute force, but empirically it seems to work quite well in the OLPC context. Martin Dengler wrote: On Wed, Sep 16, 2009 at 11:18:17AM +0800, Mitch Bradley wrote: It is gratifying that so many people like the idea of being able to zap back into OFW from Linux - especially since I got such intense pushback when I first proposed leaving OFW resident on OLPC. Why? Security reasons? Martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO-1 Mesh support in F11, testing request
Hi, Anyone interested in helping the last few steps in getting XO-1 mesh support running again? Recently, OLPC mesh support was committed to NetworkManager-0.8 git master. I've now backported this to 0.7 and packaged it up, and packaged sugar to readd OLPC mesh support there too. Completely untested as I don't have an XO to hand. There are probably a couple of trivial mistakes so testing plus logs/technical investigation/patches would be really helpful all rpms at http://dev.laptop.org/~dsd/20090916/ cheers Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux - kgdb
it sounded like there was also some thought that the emphasis should be on tools, like kgdb, which can be more general purpose, and more widely used and maintained. to which i'd say, the more the merrier -- i'd love to use kgdb regularly, but it requires a second machine, and it ties up scarce serial ports. so OFW is a win, for my current uses. In theory we could make one OLPC kernel debuggable by another OLPC, just using the WiFi interfaces and a simple matter of software. kgdb should be able to use an ethernet, if the Ethernet driver implements the NETPOLL interface. I think WiFi counts as Ethernet, at least if you use ad-hoc mode, or if you can get the interface brought up (by the usual means) before you need the debugger. You still need two machines, unless the kernel you're debugging is running in a virtual machine. The machine you run GDB on can be any computer, it doesn't have to match the one you're debugging. See: http://kernel.org/pub/linux/kernel/people/jwessel/kgdb/index.html which was readily findable via Wikipedia's kgdb entry. For all I know, OFW has a gdb debug stub in it somewhere, too... John (I used to maintain gdb, in the distant past.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 B2 bringup
Great news! Keep up the great work. Best regards, Tiago Marques On Tue, Sep 15, 2009 at 11:02 AM, John Watlington w...@laptop.org wrote: The XO-1.5 bringup is proceeding smoothly. At this time, Mitch is working on streamlining the production test process and integrating the production test code into Open Firmware and our Linux releases. This will eliminate the need for OLPC to continuously support Quanta's separate production test Linux release. We expect to produce 300 B2 prototypes on Wednesday afternoon. It will then take another week or so for these to be shipped to 1CC for distribution. More information about the B2 prototypes is available at: http://wiki.laptop.org/go/XO_1.5_B2 Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC Slackware 13.0 ready for D/L
at http://AhatThailand.org/OLPC/ To install: copy-nand u:\slak-13.img good luck, zxc555 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux
On Tue, Sep 15, 2009 at 7:42 AM, Paul Fox p...@laptop.org wrote: on the XO, openfirmware stays resident when linux runs, and is accessible via an API specified in arch/x86/kernel/ofw.c. i've just pushed a commit to our 2.6.30 kernel branch that adds a sysrq hook (SysRq-y) for starting (returning to?) the resident OFW command line interface. when invoked, you can do all the usual OFW peeking and poking, and even play pong. (and, since linux is still active, you can royally trash your system if you're not careful.) there's no SysRq key on the XO keyboard, so you'll need to use a break on the serial console to invoke it, or, usually easier: echo y /proc/sysrq-trigger. use resume from OFW to let linux run again. Added to http://wiki.sugarlabs.org/go/The_undiscoverable http://wiki.laptop.org/go/Open_Firmware Thanks. http://wiki.olpc.org/go/Open_Firmware http://wiki.sugarlabs.org/go/The undiscoverable Thanks again. OFW itself prevents invocation on secure machines, so this only works when unlocked. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://earthtreasury.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Attempting to re-install jabber component of XS without re-installing the entire server
On Wed, Sep 16, 2009 at 12:55 PM, Daniel Bennett dant...@gmail.com wrote: 3) Any other newbie level recommendations? If the XS is on 0.5.x, and you can make a backup, I would strongly recommend yum --enablerepo=olpcxs-testing update which will bring updates from the Fedora-9 series (good!) and will upgrade your install to the latest XS-0.6 code (which is not yet formally released, but is significantly better than 0.5.x). This brings in a lot of enhancements, should not be a very large download (though maybe the Fedora-9 updates are a bit bulky). The main update affecting you is that it includes the new ejabberd that does everything magically. Once yum update is complete, you need to rerun your domain_config command. Just once. And reboot. cheers, m -- martin.langh...@gmail.com mar...@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 ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] timestamps on backups
Hello, I'm not sure if anybody has noticed this yet but after doing a backup, it seems the datestamps on the backup page are wrong. For instance, after a recent backup the backup page in moodle says that the last backup was 4 hours ago even though monitoring the cron logs show that it has just completed a backup. Even weirder, moodle claims that some backups are 40 years old ! :-) I am using XS on 0.6d5 and Sugar on a Stick. Is there something about time zones and time synchronization that we need to be aware of with regards to backups. Thanks, Hamilton ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Troubles running F9 mock chroot under F11
On Wed, 2009-09-16 at 10:32 +0545, Daniel Drake wrote:
2009/9/15 Jerry Vonau jvo...@shaw.ca:
Are you just adding rpms to the install media? Or are you trying
something more difficult? I have a process in mind if you're just adding
rpms to the mix...
Just adding RPMs would be enough, but also we're customizing the
kickstart file a little.
That should be do-able using mkslim (read it first) from xs-livecd's git
repo, along with my idea to use a pre-configured updates repo on the
iso.
http://lists.laptop.org/pipermail/server-devel/2009-February/002937.html
You would create an overlay tree in lets say /tmp/xsupdates/, this
will hold what files you want to add/change on the iso. Now just make a
tree for the files in /tmp/xsupdates/. Create a directory updates,
populate it with rpms and run createrepo against it. If you wish to
replace/add a file on the iso, just have them be in the same place in
the xsupdates directory, as it would be on the iso. eg: xsupdates/ks.cfg
xsupdates/isolinux/isolinux.cfg. Then call
mkslim path to iso output dir /tmp/xsupdates
Remember to add the repo line to the kickstart file or add them as a
boot argument, for usb:
repo --name=updates --baseurl=file:///mnt/isodir/updates
for cdrom:
repo --name=updates --baseurl=file:///mnt/stage2/updates
The usb method is tested, while I have not tested the cdrom iso
However, I see that the older buildinstall(s) are not present any
more(?)! (File a bug I guess) If you were to add the buildinstall from
F9's anaconda in revisor's script directory as F9-buildinstall, then the
buildinstall from F9 should be used instead of the one on the host
system.
I did that and it now fails at a later point. I first had to modify pungi.py
+buildinstall.append('--output')
buildinstall.append(self.topdir)
and the end result is:
Linking in release notes:
100.0%
Size of the installation tree is 518 MB
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/revisor/__init__.py, line 528, in
run
self.base.run()
File /usr/lib/python2.6/site-packages/revisor/base.py, line 106, in run
self.cli.run()
File /usr/lib/python2.6/site-packages/revisor/cli.py, line 44, in run
self.base.lift_off()
File /usr/lib/python2.6/site-packages/revisor/base.py, line 867, in
lift_off
self.buildInstallationMedia()
File /usr/lib/python2.6/site-packages/revisor/base.py, line 1478,
in buildInstallationMedia
f = open(os.path.join(mypungi.topdir,isolinux,isolinux.cfg),rw+)
IOError: [Errno 2] No such file or directory:
'/var/tmp/revisor-pungi/0.5.2/xs-f9-i386/i386/os/isolinux/isolinux.cfg'
Traceback occurred, please report a bug at http://fedorahosted.org/revisor
The size should be more like 850mb.
Did you have any luck in your own experiment?
No, I stopped when it bombed out, had to do my real work, must of been
at the point you got past with the patched pungi.py.
Jerry
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] timestamps on backups
On Wed, Sep 16, 2009 at 5:37 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Sep 16, 2009 at 2:28 PM, Hamilton Chua hamilton.c...@gmail.com wrote: I'm not sure if anybody has noticed this yet but after doing a backup, it seems the datestamps on the backup page are wrong. We might need more detail than that if we're to understand the situation :-) Is there something about time zones and time synchronization that we need to be aware of with regards to backups. Yes, the utc time on all machines should make sense. So do date --utc on XS and on the laptops involved to make sure all players are in the same decade. This has been tested with machines on different TZs so it should work. As long as utc agrees across machines. -- martin.langh...@gmail.com http://lists.laptop.org/listinfo/server-devel The two numbers 4 hours and 40 years are almost telling. Linux keeps time as seconds from midnight January 1, 1970 12:00:00 GMT. Today GMT (Greenwich Mean Time) has been replaced by UTS (Coordinated Universal Time) which is GMT done better with atomic clocks. Since you are using XS on 0.6d5 and Sugar on a Stick the system gets the initial time of day (date) from the local hardware clock. A unix/Linux system default sets the local hardware clock to UTS while windows sets it to local time. Depending on daylight savings time in (say) Oklahoma four hours looks like a Windows system setting the hardware time of day. Since Linux can be configured to play nice with windows and set the hardware clock to local time windows is not always the issue in possiblly confusing the offset from GMT/UTS. The 40 years is very close to the beginnig of unix time (zero seconds) and can be seen on a confused local time of day clock. NTP (network time protocol) tools can be used to set the time of day on a network connected system to the correct UTS time. Local time is computed based on UTS and an offset time zone. Since all binary time stamps are UTS different users can set different timezone values in their environment and the system will do the 'right' thing. See: date date --uts date -u (export TZ=Europe/Paris;date;date-u) # touch /tmp/now stat /tmp/now (export TZ=Europe/Paris; stat now) -- T o m M i t c h e l l mitch-at-niftyegg-dot-com ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
