Fwd: update mechanism for new releases
by Mathieu Bridon
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)
14 years, 10 months
Re: update mechanism for new releases
by Martin Langhoff
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
14 years, 10 months
breakthrough - got sound on XO-1 with F11
by Mikus Grinbergs
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
14 years, 10 months
Re: Show Must Go On - SoaS for the XO-1
by Mikus Grinbergs
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
14 years, 11 months
olpc-powerd on soas devxo-1
by Mikus Grinbergs
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
14 years, 11 months
browse on devxo-1
by Mikus Grinbergs
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
14 years, 11 months
Re: [OT] Test run of 2009/05/25 image
by Mikus Grinbergs
>> 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
14 years, 11 months
Looking for a ucspi-ipc style tool in Fedora
by Martin Langhoff
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
14 years, 11 months
