Ticket #5033 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

olpc-update wipes out persistent activity directories

Reported by: bert Owned by: dgilmore
Priority: blocker Milestone: Update.1
Component: upgrade utility Version:
Keywords: Update.1? rainbow Cc: mstone, marco, cscott, bernie, ffm, tomeu
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

After olpc-update from 305 to 319, the /activities directory only had empty subdirectories. The persistent files in $SUGAR_ACTIVITY_ROOT/data are gone.

Change History

  Changed 6 years ago by bert

  • keywords Update.1? added; Update.1 removed

IMHO this should be an Update.1 blocker ...

follow-up: ↓ 4   Changed 6 years ago by cscott

  • cc mstone added

cc'ing mstone. I know nothing about this. If it is not in /home, it is not going to be preserved, by design.

  Changed 6 years ago by cscott

  • cc marco added
  • owner changed from cscott to mstone

in reply to: ↑ 2   Changed 6 years ago by bert

  • keywords rainbow added

Replying to cscott:

cc'ing mstone. I know nothing about this. If it is not in /home, it is not going to be preserved, by design.

An argument could be made that the persistent activity data should reside in /home ...

  Changed 6 years ago by jg

  • priority changed from high to blocker
  • milestone changed from Never Assigned to Update.1

  Changed 6 years ago by mstone

  • cc cscott added

While we clearly could store rainbow's spool inside /home or /security, both of these directories have pre-existing semantics that differ from what we want. Why do you prefer to change the semantics of one of these directories instead of inventing a new directory?

  Changed 6 years ago by mstone

cscott points out that major hacks would be required to olpc-update in order to get it to preserve /etc/passwd and /etc/group. Consequently, we need to save the Rainbow-supplied component of these files elsewhere on disk. The most straightforward 'good' implementation seems to be to write an NSS module that will supply this information.

I'm presently intending to finesse the data storage issues here by storing a fixed array of records in a sparse file. This way, POSIX locking can be used for safe concurrent updates and read-only mmap's can be used for efficient reads.

  Changed 6 years ago by cscott

As a kludge for update.1, we could consider just logging all additions to a file in /security and adding a snippet to olpc-configure which will replay the log on upgrade. /activities could then be moved to /security/activities easily.

  Changed 6 years ago by cscott

where by "additions" above I mean "additions to /etc/password and /etc/group".

  Changed 6 years ago by mstone

  • cc bernie added
  • owner changed from mstone to ApprovalForUpdate

joyride-1508 contains versions of rainbow, sugar-datastore, and olpc-utils which give us a working build (custom activity installation, datastore resume, network access all work) and which preserve or regenerate rainbow's spool information across updates.

It may still be worth pursuing the NSS module scheme since this will improve the efficiency of olpc-update; however, I am content that we have a workable solution to this bug for Update.1.

Special thanks are due to Bernie who was extraordinarily helpful in producing and qualifying these packages, and to Scott for suggesting this implementation strategy.

Reassigning to ApprovalForUpdate, where these packages can be vetted for as long as seems wise.

  Changed 6 years ago by ffm

  • cc ffm added

  Changed 6 years ago by jg

  • owner changed from ApprovalForUpdate to dgilmore

  Changed 6 years ago by dgilmore

  • status changed from new to assigned

nothing will go in without specific versions. I will not guess at the versions.

  Changed 6 years ago by mstone

  • cc tomeu added

'The versions of rainbow, sugar-datastore, and olpc-utils contained in joyride-1508' is a perfectly precise description of packages; however, I support your desire to be picky so I suggest: rainbow-0.7.6-1

Bernie, Tomeu: please indicate what versions of sugar-datastore and olpc-utils should be used.

  Changed 6 years ago by bernie

At least these:

sugar-datastore-0.7.2-2 olpc-utils-0.63-1

  Changed 6 years ago by tomeu

Note that sugar-datastore-0.7.3-1.olpc2 is already tagged for update.1

  Changed 6 years ago by bernie

olpc-utils-0.63-1 is also in update.1-677. Can we close this bug then?

  Changed 6 years ago by mstone

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.