Opened 9 years ago

Last modified 9 years ago

#6317 new defect

olpc-update 656 disassociates external apps installed in previous build

Reported by: chihyu Owned by: kimquirk
Priority: high Milestone:
Component: website Version:
Keywords: Cc: katie, ffm, rmyers7@…, adricnet, mchua
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


A secured MP machine was upgraded from 653 to 656 via olpc-update 656.

The only external application I installed in 653 was Adobe Flash, and it was gone after the update. (Flash player version test shows GSH 8,0,99,0).

Build 653 can be retrieved by holding down the O key while rebooting, and flash payer version test shows LNX 9,0,115,0, which is the Adobe Flash version I installed.

Please also refer to the following user feedback (excerpt from

> I just updated to 656, using the internet incremental update. Everything 
> I installed on 653 is gone -- Java, Flash, XFCE, OpenOffice, a Java 
> application, preference folders. You get the idea. However, all the 
> space that they took up still seems used. I'm not back down to anything 
> resembling a 300mb clean image.
> So where's it hiding? Can it be recovered? If it can't be recovered, how 
> do I reclaim the space?

Change History (10)

comment:1 Changed 9 years ago by chihyu

  • Cc katie ffm added

comment:2 Changed 9 years ago by chihyu

  • Component changed from distro to upgrade utility
  • Owner changed from jg to cscott
  • Priority changed from normal to high

comment:3 follow-up: Changed 9 years ago by cscott

  • Component changed from upgrade utility to website
  • Owner changed from cscott to kimquirk

This is a bug in our flash installation instructions, not in the upgrade utility. Kim, my understanding was that this had been fixed. Do you know anything more about it?

comment:4 Changed 9 years ago by chihyu

Another response from the user (, rephrased):

The old external applications were put in /versions/run/653. Is there a mechanism to 'mv' the them back into the main tree when running 656, other than 'cp' everything? (since there is no enough free space)

If we actually run 'mv', then the alternate build (653) won't be able to run them when holding down the 'O' button.

comment:5 in reply to: ↑ 3 Changed 9 years ago by Rmyers

Replying to cscott:

This is a bug in our flash installation instructions, not in the upgrade utility. Kim, my understanding was that this had been fixed. Do you know anything more about it?

This is not just a Flash installation bug. I am the original reporter of this bug. On my machine it moved all of the considerable third party installs I've done. 'chihyu' had only Flash on his machine when he reproduced the bug and wrote the ticket.

I'd suggest that this defect be split into a 'wiki' ticket to get a warning up quickly, and an olpc-update ticket to really fix it.

All of my 653 stuff got moved to /versions/run/653 by olpc-update. Short term, it would be nice to have a script to restore them to the main tree. Longer term, the olpc-update should respect external apps.

comment:6 Changed 9 years ago by chihyu

  • Cc rmyers7@… added

comment:7 Changed 9 years ago by gnu

This is not a bug, per se. The problem is conceptual.

When you run "olpc-update N", you are really saying, "Install version N of the operating system,
from scratch, for me". You'll end up with a clean version N of the operating system. Your user directory (/home/olpc) will remain, but everything else will be from a fresh install.

Perhaps you were thinking that olpc-update was doing something more like "apt-get upgrade", which
updates all the system-provided packages, leaving any modifications you had already made. OLPC deliberately chose not to do this, for reasons that are valid in their own context, e.g. having a consistent set of programs across a whole classroom or a whole school.

The real issue is that half the things you install go into system files, and the other half go into /home/olpc, but the user never knows which is which (because the system is hiding those supposedly "non essential details"). So the user doesn't know what stuff will be wiped out by olpc-update and what will be retained. And they'll keep reporting bugs until the system makes it clear.

comment:8 Changed 9 years ago by adricnet

  • Cc adricnet added

Some users have requested a way to install RPMs into a different location to avoid this.

I have not gone so far as to suggest chroot, but I have told a few folks who I thought could use the information that if they wanted their installed software to stick around then they should put it in /home (or /opt ..) or on an SD drive and modify their PATH.
Or get used to yumming in subversion everytime you olpc-update (which is what I'm doing, more or less).

This is obviously well beyond the realm of normal support, but may function as a work around. Another idea is to retarget yum/rpm installs but I don't know enough RedHat to say how that could be done.

Note: IMHO This bug really is a Feature. I'm not really qualified to explain the details, butI believe that Bitfrost will eventually use this and copy-on-write to implement the protection of system files. In short, you can 'get root' and make quite a mess but will still be able to reboot into a running system. It's not fully implemented yet, afaik. If someone with $clue could correct me please ?

comment:9 Changed 9 years ago by mchua

  • Cc mchua added

comment:10 Changed 9 years ago by gregorio

  • Milestone Never Assigned deleted

Milestone Never Assigned deleted

Note: See TracTickets for help on using tickets.