Bug 7432 - (int-151021) /opt and /home/user not cleared after firmware reflash
(int-151021)
: /opt and /home/user not cleared after firmware reflash
Status: RESOLVED FIXED
Product: System software
File system
: 5.0/(3.2010.02-8)
: N900 Maemo
: Low normal with 6 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: file-system-bugs
:
:
:
: int-152026
  Show dependency tree
 
Reported: 2009-12-29 02:49 UTC by Frantisek Dufka
Modified: 2010-05-27 13:13 UTC (History)
15 users (show)

See Also:


Attachments
Updated version of maemo-optify-firstboot.sh (2.18 KB, text/plain)
2010-03-22 21:56 UTC, Neil MacLeod
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Frantisek Dufka (reporter) maemo.org 2009-12-29 02:49:39 UTC
SOFTWARE VERSION:
(Settings > General > About product)
2.2009.51-1


EXACT STEPS LEADING TO PROBLEM: 

1. reflash firmware from .bin image

EXPECTED OUTCOME:

/opt is empty
/home/user is preferably initialized to clean state
/home/user/MyDocs stays (as it is on big FAT eMMC data partition)

ACTUAL OUTCOME:

eMMC is not touched at all, this is fine for big FAT eMMC data partition but
for /opt it leaves a lot of garbage from optified software installed in
previous system. Also for /home/user many settings created by previously
installed (but not present anymore) software is retained

OTHER COMMENTS:

Actually I'm not sure what the emmc flasher image is for but I guess it clears
also the big data partition which is not what is needed here. Basically whole
/home ext2 partition should be cleared when the system is first booted after
firmware reflash when the configuration wizard is shown.
Comment 1 Thomas Tanner 2009-12-30 19:13:41 UTC
IMO this is not a bug but a feature and absolutely reasonable behavior!

The firmware is for the NAND partition and should only touch that
unless the user explicitly ask for it (e.g. reflash of MMC or maybe a new
option
--clear-home for the flasher?).
If you restore a backup it will simply reinstall the applications over /opt w/o
problems.

Settings -> "reset to defaults" cleans some of user but apparently not
everything.
Maybe thats the real bug.

In consider this bug as INVALID.
Comment 2 Neil MacLeod maemo.org 2009-12-30 20:27:25 UTC
I can see the validity of this bug - if you are reflashing the root partition,
you are essentially flashing the device back to factory defaults. Yet /opt is
being left full of third-party application files that are now inaccessible to
the newly flashed device.

If you were to reinstall all of the applications that you had on the device
prior to reflashing then sure, most of the files in /opt will be overwritten,
but if you decide not reinstall one or more applications then /opt will still
contain the data associated with these applications, consuming precious file
space.

For example I installed Bounce Evolution and Fennec, subsequently re-flashed my
device and decided I didn't want to re-install these two apps again... however
Bounce Evolution and Fennec are both still sat on my device in /opt, consuming
22MB and 30MB of file space respectively.

Install enough applications, reflash enough times, and it's possible that /opt
will fill up completely with dross preventing the installation of any new
applications.

Basically, each time you reflash the device, you will "lose" a bit of /opt. The
NAND and /opt are intrinsically linked - if you restore one to factory fresh
you need to restore the other as well.

So I agree that upon first boot after a reflash, it would make sense for /opt
to be wiped clean.

However I would prefer that /home/user is left untouched, mainly because I
wouldn't then have to reinstall any ssh keys. :) I'd be happy for /home/user to
be wiped clean after a refresh if /home/user/.ssh could be left alone!
Comment 3 Thomas Tanner 2009-12-30 20:41:27 UTC
(In reply to comment #2)
> I can see the validity of this bug - if you are reflashing the root partition,
> you are essentially flashing the device back to factory defaults. Yet /opt is
> being left full of third-party application files that are now inaccessible to
> the newly flashed device.

as long as the filled /opt does not prevent the reflashed device from booting
it's not a bug. If some users also want to wipe /opt after reflash
then there should be an option "Clean /opt" in Settings -> Reset
but this would be a feature request and not a bug.
If /opt was always wiped many users would lose control over whether they can
keep their /opt.

simple solution: just gainroot && rm -rf /home/opt
if you can reflash, you should be able to wipe it yourself.
Comment 4 Neil MacLeod maemo.org 2009-12-30 21:06:11 UTC
(In reply to comment #3)
> If /opt was always wiped many users would lose control over whether they can
> keep their /opt.

Why would you need or want to keep /opt across a reflash?

> 
> simple solution: just gainroot && rm -rf /home/opt
> if you can reflash, you should be able to wipe it yourself.
> 

True, assuming you have the room on /opt to install gainroot or sshd... :)

A simple solution for anyone who wants to keep /opt across a reflash would be
to tar it to somewhere safe, and then restore it.

OK, maybe this should be an enhancement rather than a bug, but I can see why
automatically clearing down /opt makes sense, whereas keeping /opt full of
potential cruft makes no real sense at all (as far as I can tell).
Comment 5 Frantisek Dufka (reporter) maemo.org 2009-12-30 21:18:09 UTC
(In reply to comment #2)
> Install enough applications, reflash enough times, and it's possible that /opt
> will fill up completely with dross preventing the installation of any new
> applications.

Precisely. Also old leftovers can conflict in strange ways with new data.
Imagine old version of package having some file, new version having this file
moved or intentionally removed, now new version can be confused with the mix of
old and new files. Or imagine different debian packages conflicting (on
purpose) with each other and having different set of files (like shareware and
full version of same game) Resulting mix may cause erratic behavior.

> 
> Basically, each time you reflash the device, you will "lose" a bit of /opt. 

Yes and what is important is that end user (!= unix expert) has no chance of
figuring out what is going on. Even as skilled user who knows what rm command
is after installing few applications  to new system you are no longer sure what
files are valid and what is unused garbage.

> However I would prefer that /home/user is left untouched, mainly because I
> wouldn't then have to reinstall any ssh keys. :) I'd be happy for /home/user to
> be wiped clean after a refresh if /home/user/.ssh could be left alone!
> 

This is what the Backup application is for. As end user you have full user
level control of what you want to back up and then also what subset you want to
restore. Having whole /home/user left in place means again accumulated garbage,
source of strange bugs/crashes and no choice of what you want to restore. From
history of previous Maemo version it payed off to be very conservative with the
subset of data to restore (bookmarks and maybe that's all :-)  or strange
things happened. And that was even with backup/restore procedure which is under
each application author's control (so you can backup only relevant data in
version independent way and handle proper restore too). Having random set of
various settings left in /home/user is recipe for disaster.

As for ssh keys this should be handled properly by backup/restore rules of
openssh package.
Comment 6 Thomas Tanner 2009-12-30 21:25:34 UTC
(In reply to comment #4)
> > If /opt was always wiped many users would lose control over whether they can
> > keep their /opt.
> Why would you need or want to keep /opt across a reflash?

my own or proprietary packages hildon-app-manager cannot restore
/opt is a place for user packages and NOT a system directory.

simple rules of thumb:
* don't delete stuff the user the user has not asked for
* if you delete something by default, give the user an option to disable it
neither of those rules are fulfilled by your feature request.

> True, assuming you have the room on /opt to install gainroot or sshd... :)

rootsh lives in /usr

> A simple solution for anyone who wants to keep /opt across a reflash would be
> to tar it to somewhere safe, and then restore it.

usually I need to reflash because of an unforeseen problem during hacking.
should I backup my /opt every second just for the convenience of some users
who don't to press a "Wipe /opt" after a reflash?

> OK, maybe this should be an enhancement rather than a bug, but I can see why
> automatically clearing down /opt makes sense, whereas keeping /opt full of
> potential cruft makes no real sense at all (as far as I can tell).

no one forces you to keep /opt, you want to force me (and other people) to lose
/opt after every reflash?
Comment 7 Thomas Tanner 2009-12-30 21:33:03 UTC
(In reply to comment #5)
> Yes and what is important is that end user (!= unix expert) has no chance of
> figuring out what is going on. Even as skilled user who knows what rm command
> is after installing few applications  to new system you are no longer sure what
> files are valid and what is unused garbage.

what we need is a way to wipe /opt or /home/user even without reflashing.
Settings -> "reset to default" so far only wipes some files in /home/user.
That can be considered as a bug!

> This is what the Backup application is for. As end user you have full user
> level control of what you want to back up and then also what subset you want to
> restore.

no, you don't! Backup doesn't save all your .* files in $HOME and not your
modified files
in /etc. In an ideal world every package would have proper backup rules but
that's not our world...
Comment 8 Neil MacLeod maemo.org 2009-12-30 21:44:18 UTC
(In reply to comment #6)
>
> no one forces you to keep /opt, you want to force me (and other people) to lose
> /opt after every reflash?
> 

Nobody ever had a problem wiping user packages on the 770/N8x0, because for
obvious reasons it was a good thing to do when reflashing the OS. I'm still not
entirely sure why wiping /opt is such a big issue considering you've just blown
away your old root file system, and restoring a user application will (in
almost all cases) mean re-downloading and re-installing the deb. To /opt.

/opt is just a hack to provide enough file space to install a decent number of
applications due to the limited free space on NAND, and an (unfortunate?) side
effect of this hack is that /opt is now persistent across flashes, when it
*probably* should not be.
Comment 9 Neil MacLeod maemo.org 2009-12-30 21:51:32 UTC
(In reply to comment #7)
> what we need is a way to wipe /opt or /home/user even without reflashing.

Surely uninstalling applications is the best way to clear down /opt in a
controlled manner?

Simply wiping /opt on a running system would probably leave the system in an
undefined or unstable state.

Similarly when zapping /home/user - applications that have just had their
configuration files and other data wiped out will probably begin to misbehave.

When an application is uninstalled it should remove all appropriate
dependencies from /opt and /home/user.

It's only when reflashing the OS that /opt is left in a bit of a mess. And
since ordinary end users are expected to be able to reflash their devices I
don't think expecting them to know "sudo gainroot && rm -fr /home/opt" is
entirely reasonable.

And asking them to "confirm deletion of /opt" will probably scare the pants off
them (I wonder how many will say "No" to be on the safe side, and finish up
with an unstable device as a result?)
Comment 10 Thomas Tanner 2010-01-02 22:10:25 UTC
I think I have found a simple solution and a good compromise:
The system should only delete /opt or /home/user on the first boot if there
is no /opt/.keep or /home/user/.keep file, respectively.
Advanced users who want to have full control over their eMMC can simply create
those files.
Other users will just you get the behaviour you described.

PS: I maintain my custom /opt hierarchy and I have copied /var to /home/var.

(In reply to comment #9)
> (In reply to comment #7)
> > what we need is a way to wipe /opt or /home/user even without reflashing.
> Surely uninstalling applications is the best way to clear down /opt in a
> controlled manner?

When average joe wants to sell his device, he surely wants to get rid of
/home/user (and /opt).
With your solution he would have to:
* reflash
* boot to automatically delete /home/user (and /opt)
* perform settings -> reset to hopefully get an almost clean /home.
With a wipe /home function he could always reset his user config
(especially before a reflash). wipe opt could be handy before a reflash,
so that he doesn't need to reboot again and so that the buyer will get a
completely "fresh" device.

> Simply wiping /opt on a running system would probably leave the system in an
> undefined or unstable state.

that would be a bug. everything under /opt should be optional.

> Similarly when zapping /home/user - applications that have just had their
> configuration files and other data wiped out will probably begin to misbehave.

they wouldn't survive the immediate reboot anyway...

> When an application is uninstalled it should remove all appropriate
> dependencies from /opt and /home/user.

true for /opt, but not for /home. there should be a separate purge
option which also removes the settings as in Debian.
Comment 11 Rodrigo Linfati 2010-01-14 15:45:10 UTC
a workaround is run /usr/sbin/fremantle-format-internal-memory-card.sh after
flash?
is safe ?
Comment 12 Lucas Maneos 2010-01-14 16:00:15 UTC
Another workaround may be to flash the eMMC image (currently
RX-51_2009SE_1.2009.41-1.VANILLA_PR_EMMC_MR0_ARM.bin available from
http://tablets-dev.nokia.com/nokia_N900.php).
Comment 13 Frantisek Dufka (reporter) maemo.org 2010-01-14 16:04:51 UTC
(In reply to comment #11)
> a workaround is run /usr/sbin/fremantle-format-internal-memory-card.sh after
> flash?

(In reply to comment #12)
> Another workaround may be to flash the eMMC image (currently
> RX-51_2009SE_1.2009.41-1.VANILLA_PR_EMMC_MR0_ARM.bin available from
> http://tablets-dev.nokia.com/nokia_N900.php).
> 


No and no. Only /opt (and possibly /home/user) should by cleared as it can be
considered part of the firmware. Both solutions mentioned above clear also the
27GB data partition. This is not needed and not wanted.
Comment 14 Thomas Tanner 2010-01-14 16:10:36 UTC
(In reply to comment #13)
> > a workaround is run /usr/sbin/fremantle-format-internal-memory-card.sh after
> > flash?
> No and no. Only /opt (and possibly /home/user) should by cleared as it can be
> considered part of the firmware. Both solutions mentioned above clear also the
> 27GB data partition. This is not needed and not wanted.

in this case the simplest workaround woud be to run
rm -rf /home/opt /home/user
possibly wrapped in a shell script that is called using sudo
(and listed in sudoers) and which asks for confirmation
Comment 15 kv4nbee 2010-01-14 20:22:24 UTC
as a user coming from winmo world im glad someone posted this bug in new
firmware release thread because after countless flashes of previous devices i
always used hard reset option to clean the letovers or use mtty to format the
rom area. of course that is different world and different rules apply but i
believe the idea shoul be the same.instead of asking average joe(not even aware
of all this junk-mostly in /opt) to use commands to clean the phone, why not
enhance the restore factory defaults function to wipe out opt and /home/usr?
i was really surprised that this don't do a lot and found some stuff(in /opt)
that i uninstalled few weeks ago.
if u want to keep your stuff in opt why not enhance backup utility to do so?
to sum up the whole idea of me flashing the device(i've made extra effort to do
it using ubuntu lve cd) was to clean it up from leftovers and mistakes i
defenitely made testing previous(imo beta)firmware.
and this is bug,but don't know exactly where.
that's it average joe has spoken.peace!
Comment 16 farmatito 2010-01-21 19:57:48 UTC
The only correct way to handle this would be:
1) on firmware reflash extract the info of optified debs from  /var/cache
   if i recall correctly.
2) after having flashed at reboot ask the user if he wants to keep the old
programs or reinstall them later
    2A) if yes merge the info of old opt debs to new package database checking 
        for file conflicts and notifying the user about possible conflicting
        packages
    2B) if no purge the old opt deb packages

That way the system would probably stay in a consistent state.

Wiping personal data from the device is a different issue in the sense that it 
does not imply a firmware reflash.
An option under settings with a few warning dialogs would be the best solution.
Comment 17 Neil MacLeod maemo.org 2010-03-01 14:47:56 UTC
(In reply to comment #10)
> I think I have found a simple solution and a good compromise:
> The system should only delete /opt or /home/user on the first boot if there
> is no /opt/.keep or /home/user/.keep file, respectively.
> Advanced users who want to have full control over their eMMC can simply create
> those files.
> Other users will just you get the behaviour you described.
> 
> PS: I maintain my custom /opt hierarchy and I have copied /var to /home/var.
> 

+1 for this.

I've seen users on forums looking to sell-on their devices and asking for
advice on how to reset to factory default, and that's when it becomes apparent
how surprisingly difficult this is to achieve on a N900 without arcane Unix
knowledge.

Implementing this bug as specified below would ensure that personal data
(/home/user) as well as no longer accessible program data (/opt) would be
cleared pretty much automatically and with no special skills required.

All the user would have to do is:

1) Delete any personal media that may be stored on the eMMC (photos, videos,
music etc.)
2) Delete all Backup files visible in the Backup application
3) Reflash rootfs (using Windows NSU or Flasher)
4) Boot the device once so that /opt and /home/user (excluding
/home/user/MyDocs/backups) are automatically zapped unless .keep files are
present in the root of each respective directory
5) Shutdown device before configuring any further - leave this to the next
owner

It's necessary to avoid zapping /home/user/MyDocs/backups in step #4 for those
times when a user is simply reflashing the device to upgrade rather than
sell-on - this is why any backups should be deleted prior to reflashing as they
must always survive a reflash, whenever present.
Comment 18 Venomrush 2010-03-10 18:52:34 UTC
/opt (/home/opt) and /home/user are stored on eMMC I believe.

Firmware reflash does not touch the eMMC to preserve user's data (settings,
contacts, conversations, backups etc.)

I would say this is a WONTFIX 

If you want to clear /opt (/home/opt) and /home/user then flash eMMC (remember
to back up first of course!)
Comment 19 Neil MacLeod maemo.org 2010-03-10 19:09:07 UTC
(In reply to comment #18)
> /opt (/home/opt) and /home/user are stored on eMMC I believe.
> 
> Firmware reflash does not touch the eMMC to preserve user's data (settings,
> contacts, conversations, backups etc.)
> 
> I would say this is a WONTFIX 
> 
> If you want to clear /opt (/home/opt) and /home/user then flash eMMC (remember
> to back up first of course!) 
> 

Did you actually read the comments in this bug report?
Comment 20 Andre Klapper maemo.org 2010-03-16 12:55:57 UTC
This has been fixed in package
maemo-optify-runonce 0.10-5+0m5
which is part of the internal build version
10.2010.08-23
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 21 Venomrush 2010-03-16 13:01:19 UTC
(In reply to comment #20)
> This has been fixed in package
> maemo-optify-runonce 0.10-5+0m5
> which is part of the internal build version
> 10.2010.08-23
> (Note: 2009/2010 is the year, and the number after is the week.)
> 

Showing as fixed in week 8.
Assuming this is fixed in PR1.2?
Comment 22 Andre Klapper maemo.org 2010-03-16 13:02:29 UTC
Oh true. Thanks :)
Comment 23 Neil MacLeod maemo.org 2010-03-16 14:03:33 UTC
(In reply to comment #20)
> Please verify that this new version fixes the bug by marking this bug report as
> VERIFIED after the public update has been released and if you have some time.

Some background on how it has been fixed, what will be deleted and when it will
be deleted might make it easier for us to verify if the bug actually been fixed
as per the requirements outlined in this bug (which vary due to some initial
disagreement).

Just saying the bug is now fixed but not saying how, and then asking us to
verify something that is unexplained isn't very useful. I guess what I'm asking
for is that the developer who fixed this bug to post an update with some
details.

And I would suggest this should become standard practice on anything but
no-brainer defects (which isn't the case with this bug).
Comment 24 Andre Klapper maemo.org 2010-03-16 14:13:11 UTC
Uhm, totally valid request that I can only second, but I simply don't have time
to summarize 45 internal comments and the developers to summarize what they
have exactly changed. :-(
Comment 25 Venomrush 2010-03-16 14:14:25 UTC
(In reply to comment #23)

> Some background on how it has been fixed,

I believe based on the 'fixed in package' note, a new package called
maemo-optify-runonce 0.10-5+0m5 is run (once) that does this optification and
any other after an update.
Comment 26 Venomrush 2010-03-16 14:15:58 UTC
*opps didn't mean optification, rather optimisation
Comment 27 Neil MacLeod maemo.org 2010-03-16 14:35:51 UTC
(In reply to comment #24)
> Uhm, totally valid request that I can only second, but I simply don't have time
> to summarize 45 internal comments and the developers to summarize what they
> have exactly changed. :-(
> 

OK, so we have only have one option which is to review the source code and
verify the implementation based on the code, which is all a bit pointless. Sure
we can verify that what happens is as it is coded in the package, but what was
really meant to happen?

It really would be very helpful to know what the developer intended should
happen when resolving this bug, and to verify that it actually does happen.
Reading the source code is only partially helpful, and not something every bug
reporter is able or willing to do.

I appreciate the developers are busy and don't have time, but we're not raising
these bugs for fun either. I could rant more about bug 630 but it's clearly a
waste of time...

Bug resolved somehow, another bugs.maemo.org failure. :(
Comment 28 Thomas Tanner 2010-03-22 20:23:58 UTC
apparently the "solution" is described in
http://maemo.gitorious.org/maemo-af/maemo-optify-boottime/blobs/master/README
/home/opt will be always be cleared after reflashing or if a user deletes
/var/lib/maemo-optify-firstboot-do-not-clean-home-opt
there is no option to keep or to backup /home/opt.
Comment 29 Neil MacLeod maemo.org 2010-03-22 21:04:34 UTC
(In reply to comment #28)
> apparently the "solution" is described in
> http://maemo.gitorious.org/maemo-af/maemo-optify-boottime/blobs/master/README
> /home/opt will be always be cleared after reflashing or if a user deletes
> /var/lib/maemo-optify-firstboot-do-not-clean-home-opt
> there is no option to keep or to backup /home/opt.
> 

Excellent - thanks for that, now we know what to test and verify! :)

The full entry from gitorious is:

########################################################################
** maemo-optify-firstboot.sh optification process

runs at boot time before /opt is mountbound
runs only if /var/lib/maemo-optify-firstboot-do-not-clean-home-opt does not
exist

    clear dirty /home/opt after reflashing device
    move default data in rootfs /opt into /home/opt
    create /var/lib/maemo-optify-firstboot-do-not-clean-home-opt

########################################################################

Doesn't sound like there is a way to preserve /opt after a reflash however,
which I think was your concern, Thomas.

Bit of a shame the solution doesn't also check /home/user for a
"maemo-optify-firstboot-do-not-clean-home-opt" file, as well as in /var/lib.
Comment 30 Neil MacLeod maemo.org 2010-03-22 21:22:31 UTC
This is the script that implements the solution...

http://maemo.gitorious.org/maemo-af/maemo-optify-boottime/blobs/master/maemo-optify-firstboot.sh

Just a couple of observations, but there is a lot of repetition regarding the
"do-not-clean" filename which would be better referenced as a variable, and a
lack of error checking before continuing with unrecoverable operations (eg. if
the cp fails in line 54, the device will need to be re-flashed, whereas if the
script aborted on a failed copy in line 55 a reboot would re-copy the data
which may succeed).

Thomas' requirements would be satisfied by the addition of the following:

[ -e /home/user/maemo-optify-firstboot-do-not-clean-home-opt ] && return 0

in line 24.
Comment 31 Neil MacLeod maemo.org 2010-03-22 21:34:56 UTC
And line 30 in the script[1] is incorrect - it's missing /var/lib:

It is:

  touch maemo-optify-firstboot-do-not-clean-home-opt && sync

but should be:

  touch /var/lib/maemo-optify-firstboot-do-not-clean-home-opt && sync

Exactly my point about using variables...! :)

Will attach an updated version in a few minutes, for what it's worth, but it
won't be a diff.

1.
http://maemo.gitorious.org/maemo-af/maemo-optify-boottime/blobs/master/maemo-optify-firstboot.sh
Comment 32 Neil MacLeod maemo.org 2010-03-22 21:56:05 UTC
Created an attachment (id=2499) [details]
Updated version of maemo-optify-firstboot.sh

1) Uses a variable for the "flag" file in /var/lib

2) [Assuming /home/user is mounted by this stage] Will not clean /opt if a
hidden flag file exists in /home/user

3) Corrects error in line 30 of original (missing /var/lib/)

4) Doesn't create /var/lib flag file or remove the original /opt if cp of /opt
fails - should make script "restartable" on next reboot?

5) Always performs a final sync (rather than repeat sync three times in "[ -d
/opt ]" if/then block)

WARNING: Untested, naturally. :)
Comment 33 Gary Birkett 2010-03-22 22:22:37 UTC
(In reply to comment #32)
> Created an attachment (id=2499) [details] [details]
> Updated version of maemo-optify-firstboot.sh
> 
> 1) Uses a variable for the "flag" file in /var/lib
> 
> 2) [Assuming /home/user is mounted by this stage] Will not clean /opt if a
> hidden flag file exists in /home/user
> 
> 3) Corrects error in line 30 of original (missing /var/lib/)
> 
> 4) Doesn't create /var/lib flag file or remove the original /opt if cp of /opt
> fails - should make script "restartable" on next reboot?
> 
> 5) Always performs a final sync (rather than repeat sync three times in "[ -d
> /opt ]" if/then block)
> 
> WARNING: Untested, naturally. :)
> 

Neil,
thanks for those catches :)
will review in the morning and discuss with colleagues.
Comment 34 Andre Klapper maemo.org 2010-03-29 13:23:15 UTC
Thanks to Neil's input, this is fixed in
maemo-optify-runonce 0.10-12+0m5
which is part of the internal build version
10.2010.12-4
Comment 35 Joerg Reisenweber 2010-05-10 03:52:00 UTC
I really wonder why nobody noticed the completely moot point of asking for a
complete purge of /opt and /home/user/*, for purpose of privacy prior to
selling the device, and same sentence claiming a complete flash of eMMC is not
what we want as it would erase the valuable data in MyDocs. Come on!
If you want to clean your device completely, then please flash rootfs *and*
eMMC fiasco image - done.

on a sidenote: how hard can it be to have all the files in /opt correctly
synlinked from /usr/bin or whatever, and simply swipe all the files that no
longer have a link pointing at them? For managing your own data, you could keep
a folder /home/user/.myopt with similar links pointing to /home/opt, which
could be used by the cleanup script to keep files user doesn't want to lose.

Deleting ~user/* is a really diabolic idea, please refrain from that
Comment 36 Neil MacLeod maemo.org 2010-05-10 04:15:34 UTC
(In reply to comment #35)
> I really wonder why nobody noticed the completely moot point of asking for a
> complete purge of /opt and /home/user/*, for purpose of privacy prior to
> selling the device, and same sentence claiming a complete flash of eMMC is not
> what we want as it would erase the valuable data in MyDocs. Come on!
> If you want to clean your device completely, then please flash rootfs *and*
> eMMC fiasco image - done.
> 
Probably because this bug is a different issue/requirement to what you are
asking for, and what you want would be considered an enhancement.

What has been implemented here is a completely obvious requirement since not
wiping /opt following a flash could lead to a number of long term problems.
This bug is not about privacy, it's about device stability and reclaiming
otherwise lost space.

If you want privacy and the ability to securely wipe the device, which I agree
is a valid request, then that should be raised as a separate bug/enhancement.
Maybe it could be tacked onto the end of the "reflash then wipe /opt" process,
or it could be a completely independent script that can be selected to run
during boot at any time, independent of a reflash. Discussion for another bug.
:)
Comment 37 gilson.decarvalho 2010-05-27 05:29:44 UTC
(In reply to comment #36)
> (In reply to comment #35)
> > I really wonder why nobody noticed the completely moot point of asking for a
> > complete purge of /opt and /home/user/*, for purpose of privacy prior to
> > selling the device, and same sentence claiming a complete flash of eMMC is not
> > what we want as it would erase the valuable data in MyDocs. Come on!
> > If you want to clean your device completely, then please flash rootfs *and*
> > eMMC fiasco image - done.
> > 
> Probably because this bug is a different issue/requirement to what you are
> asking for, and what you want would be considered an enhancement.
> 
> What has been implemented here is a completely obvious requirement since not
> wiping /opt following a flash could lead to a number of long term problems.
> This bug is not about privacy, it's about device stability and reclaiming
> otherwise lost space.
> 
> If you want privacy and the ability to securely wipe the device, which I agree
> is a valid request, then that should be raised as a separate bug/enhancement.
> Maybe it could be tacked onto the end of the "reflash then wipe /opt" process,
> or it could be a completely independent script that can be selected to run
> during boot at any time, independent of a reflash. Discussion for another bug.
> :)
> 

Hey guys I'm a rumble owner of a N900 needing to go forward and update the
device. The update precess stops with this error: "Upgrading
mp-fremantle-002-pr 1.2009.44-1.002 to 10.2010.19-1.002
apt-worker: free space (/) = 74891264
E: I wasn't able to locate a file for the maemo-optify-runonce package. This
might mean you need to manually fix this package. (due to missing arch)".
Please tell me, step-by-step, how to workaround. I have some Linux expertise.
Thank you.
Comment 38 Andre Klapper maemo.org 2010-05-27 13:13:05 UTC
(In reply to comment #37)
> Hey guys I'm a rumble owner of a N900 needing to go forward and update the
> device. The update precess stops with this error: "Upgrading
> mp-fremantle-002-pr 1.2009.44-1.002 to 10.2010.19-1.002
> apt-worker: free space (/) = 74891264

Please do not quote the entire previous comment. Also, your issue is unrelated
to this bug report. Looks more like bug 10264.