Bug 8148 - Cannot backup after 2.2009.51.1(PR1.1) update
: Cannot backup after 2.2009.51.1(PR1.1) update
Status: CLOSED INVALID
Product: Settings and Maintenance
Backup/Restore
: 5.0/(2.2009.51-1)
: N900 Maemo
: Low critical (vote)
: ---
Assigned To: unassigned
: backup-restore-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2010-01-17 13:30 UTC by anapospastos
Modified: 2010-03-05 16:38 UTC (History)
5 users (show)

See Also:


Attachments
The screen which appears to me when I try to backup (26.66 KB, image/png)
2010-01-17 13:40 UTC, anapospastos
Details
log file (47 bytes, application/gzip)
2010-01-23 21:13 UTC, anapospastos
Details
Strace log (14.42 KB, application/gzip)
2010-01-24 14:25 UTC, anapospastos
Details
strace log(not root executed) (14.39 KB, application/gzip)
2010-01-24 17:40 UTC, anapospastos
Details
env output in xterm (2.36 KB, text/html)
2010-01-27 23:54 UTC, anapospastos
Details
output of AF_DEFINES_SOURCED= sh -x /etc/osso-af-init/af-defines.sh in xterm (3.73 KB, text/plain)
2010-01-28 20:04 UTC, anapospastos
Details


Note

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


Description anapospastos (reporter) 2010-01-17 13:30:23 UTC
SOFTWARE VERSION:
(Settings > General > About product)

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. I want to backup
2. Im opening menu->settings->more->back up
3. 

EXPECTED OUTCOME: See the back up window and choose to back up

ACTUAL OUTCOME: It says "No memory card inserted" and I cant tap the 3 choises
down "New backup", "Restore" and "Delete"

REPRODUCIBILITY: always

EXTRA SOFTWARE INSTALLED: Many but anything to cause this

OTHER COMMENTS: It just appeared after the PR1.1 update

User-Agent:     (Windows;) Chrome/3.0.195.38
Comment 1 anapospastos (reporter) 2010-01-17 13:40:51 UTC
Created an attachment (id=2020) [details]
The screen which appears to me when I try to backup
Comment 2 anapospastos (reporter) 2010-01-17 13:41:32 UTC
I dont have a mmc card in my device.
Comment 3 Lucas Maneos 2010-01-17 16:06:47 UTC
Thanks for the report.  I can reproduce this only by unmounting both internal
and external memory cards (in which case it is as expected).  Is your
/home/user/MyDocs mounted and read-write?
Comment 4 Venomrush 2010-01-18 07:48:21 UTC
(In reply to comment #2)
> I dont have a mmc card in my device.
> 

Where are you saving the backup to? (When it asked where to save it, default =
\Backup)
Comment 5 anapospastos (reporter) 2010-01-19 11:54:22 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > I dont have a mmc card in my device.
> > 
> 
> Where are you saving the backup to? (When it asked where to save it, default =
> \Backup)
> 
I cant tap the three buttons. They are unchoosable(if it is the right word). I
cant even start to backup.
Comment 6 anapospastos (reporter) 2010-01-19 11:57:30 UTC
(In reply to comment #3)
> Thanks for the report.  I can reproduce this only by unmounting both internal
> and external memory cards (in which case it is as expected).  Is your
> /home/user/MyDocs mounted and read-write?
> 
I can write-delete-read as before all my folders. The issue that it is not
recognize the internal memory produces ONLY for backup.
Comment 7 Lucas Maneos 2010-01-23 16:16:43 UTC
Could you try running the following (all on one line):

strace -f -e trace=file /usr/bin/run-standalone.sh /usr/bin/maemo-summoner
/usr/bin/osso-backup.launch 2>&1 | gzip -9 >
/home/user/MyDocs/.documents/backup.log.gz

from a terminal window or ssh session, wait until the backup application window
appears, verify that the three buttons are still inactive, quit it and then
attach /home/user/MyDocs/.documents/backup.log.gz here?
Comment 8 anapospastos (reporter) 2010-01-23 21:13:11 UTC
(In reply to comment #7)
> Could you try running the following (all on one line):
> 
> strace -f -e trace=file /usr/bin/run-standalone.sh /usr/bin/maemo-summoner
> /usr/bin/osso-backup.launch 2>&1 | gzip -9 >
> /home/user/MyDocs/.documents/backup.log.gz
> 
> from a terminal window or ssh session, wait until the backup application window
> appears, verify that the three buttons are still inactive, quit it and then
> attach /home/user/MyDocs/.documents/backup.log.gz here?
> 
I run this code via xterm but the backup screen didnt appear and the file which
created in .documents folder have the extension .log and not log.gz. I attached
it.
Comment 9 anapospastos (reporter) 2010-01-23 21:13:59 UTC
Created an attachment (id=2107) [details]
log file
Comment 10 anapospastos (reporter) 2010-01-23 21:24:06 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Could you try running the following (all on one line):
> > 
> > strace -f -e trace=file /usr/bin/run-standalone.sh /usr/bin/maemo-summoner
> > /usr/bin/osso-backup.launch 2>&1 | gzip -9 >
> > /home/user/MyDocs/.documents/backup.log.gz
> > 
> > from a terminal window or ssh session, wait until the backup application window
> > appears, verify that the three buttons are still inactive, quit it and then
> > attach /home/user/MyDocs/.documents/backup.log.gz here?
> > 
> I run this code via xterm but the backup screen didnt appear and the file which
> created in .documents folder have the extension .log and not log.gz. I attached
> it.

My mistake. The file created is .log.gz
Comment 11 Lucas Maneos 2010-01-23 22:43:41 UTC
(In reply to comment #8)
> I run this code via xterm but the backup screen didnt appear

Sorry, I neglected to say you need to install strace first - see
<http://wiki.maemo.org/Documentation/devtools/maemo5#Installation>.
Comment 12 anapospastos (reporter) 2010-01-24 14:24:52 UTC
I done this run on xterm, backup screen appeared and I attached you the strace
log.
Comment 13 anapospastos (reporter) 2010-01-24 14:25:18 UTC
Created an attachment (id=2113) [details]
Strace log
Comment 14 Lucas Maneos 2010-01-24 15:08:06 UTC
Thanks for that, but it seems that this was executed as root so may not have
the right environment.  Could you re-run as user (try "su - user" first if
working via a root ssh login)?
Comment 15 anapospastos (reporter) 2010-01-24 17:40:45 UTC
Created an attachment (id=2117) [details]
strace log(not root executed)

Done it without root permissions
Comment 16 Lucas Maneos 2010-01-27 16:15:21 UTC
(In reply to comment #15)
> Done it without root permissions

Thanks!  Something definitely looks broken.  Comparing your log with a working
one, they are more or less similar until line 622.  After that, the working one
proceeds to scan /home/user/MyDocs/backups and /media/mmc1/backups which is
completely missing from your log.

Could you also post the output of the command "env" in a terminal?

At this point it may also be worth listing any extra packages installed or
other tweaks after the reflash to 2.2009.51-1.
Comment 17 anapospastos (reporter) 2010-01-27 23:54:34 UTC
Created an attachment (id=2145) [details]
env output in xterm

The problem appeared just after the update 2.2009.51-1. I had it one more time
in the past(before the update) but I solved it by putting out the battery the
sim card and doing a reboot just after I turned on the device. I tried again
but now its not working.
Comment 18 Lucas Maneos 2010-01-28 17:16:49 UTC
Thanks, these entries definitely look broken:

OSSO_PRODUCT_FULL_NAME=<unknown>
OSSO_PRODUCT_HARDWARE=<unknown>
OSSO_PRODUCT_KEYBOARD=<unknown>
OSSO_PRODUCT_NAME=<unknown>
OSSO_PRODUCT_REGION=<unknown>
OSSO_PRODUCT_RELEASE_FULL_NAME=<unknown>
OSSO_PRODUCT_RELEASE_NAME=<unknown>
OSSO_PRODUCT_RELEASE_VERSION=<unknown>
OSSO_PRODUCT_SHORT_NAME=<unknown>
OSSO_PRODUCT_WLAN_CHANNEL=<unknown>
OSSO_VERSION=<unknown>

Are you also affected by bug 5512 and/or bug 7983?

More importantly, you seem to be missing INTERNAL_MMC_MOUNTPOINT entirely.  So,
I can now reproduce the problem by running "MMC_MOUNTPOINT=
INTERNAL_MMC_MOUNTPOINT= /usr/bin/osso-backup".

More questions I'm afraid:

- Does like "INTERNAL_MMC_MOUNTPOINT=/home/user/MyDocs /usr/bin/osso-backup"
allow you to create a backup?
- What is the output of "/usr/bin/osso-product-info"?
- What is the output of "AF_DEFINES_SOURCED= sh -x
/etc/osso-af-init/af-defines.sh"
- What it the output of "df"?
Comment 19 anapospastos (reporter) 2010-01-28 20:04:39 UTC
Created an attachment (id=2157) [details]
output of AF_DEFINES_SOURCED= sh -x /etc/osso-af-init/af-defines.sh in xterm 

(In reply to comment #18)
>Are you also affected by bug 5512 and/or bug 7983?

No its says "unknown" to me.

>Does like "INTERNAL_MMC_MOUNTPOINT=/home/user/MyDocs /usr/bin/osso-backup"
allow you to create a backup?

Yes it allows me to create restore and delete a backup just fine.

>What is the output of "/usr/bin/osso-product-info"?

OSSO_PRODUCT_HARDWARE='RX-51' 
OSSO_PRODUCT_NAME='N900' 
OSSO_PRODUCT_FULL_NAME='Nokia N900' 
OSSO_PRODUCT_RELEASE_NAME='Maemo 5' 
OSSO_PRODUCT_RELEASE_FULL_NAME='Maemo 5' 
OSSO_PRODUCT_RELEASE_VERSION='2.2009.51-1' 
OSSO_PRODUCT_WLAN_CHANNEL='fcc/us' 
OSSO_PRODUCT_KEYBOARD='English, Dutch' 
OSSO_PRODUCT_REGION='Britain' 
OSSO_PRODUCT_SHORT_NAME='Nokia N900' 
OSSO_VERSION='RX-51_2009SE_2.2009.51-1_PR_MR0' 


>What it the output of "df"?

Filesystem 1k-blocks Used Available Use% Mounted on 
rootfs 233224 182228 46712 80% / 
ubi0:rootfs 233224 182228 46712 80% / 
tmpfs 1024 112 912 11% /tmp 
tmpfs 256 80 176 31% /var/run 
none 10240 72 10168 1% /dev 
tmpfs 65536 4 65532 0% /dev/shm 
/dev/mmcblk0p2 2064208 424860 1534492 22% /home 
/opt/pymaemo/usr/lib/python2.5 
2064208 424860 1534492 22% /usr/lib/python2.5 
/opt/pymaemo/usr/share/pyshared 
2064208 424860 1534492 22% /usr/share/pyshared 
/opt/pymaemo/usr/lib/pyshared 
2064208 424860 1534492 22% /usr/lib/pyshared 
/opt/pymaemo/usr/share/python-support 
2064208 424860 1534492 22% /usr/share/python-support 
/opt/pymaemo/usr/lib/python-support 
2064208 424860 1534492 22% /usr/lib/python-support 
/dev/mmcblk0p1 28312128 4504896 23807232 16% /home/user/MyDocs

Ps: I 've installed fmtx faker(enables fm transmitter) because mine was
disabled by default(greek device) and qwerty12(creator of fmtx faker) told me
that the issue which in settings->about says unknown it is being caused by his
prog. I dont know if it will help you but I mentioned it.
Comment 20 Lucas Maneos 2010-01-29 09:27:30 UTC
(In reply to comment #19)

Right, so osso-product-info sets the wrong OSSO_* values during boot, but works
fine afterwards(?!)

Was the upgrade done by flashing or via SSU by the way?

> Ps: I 've installed fmtx faker(enables fm transmitter) because mine was
> disabled by default(greek device) and qwerty12(creator of fmtx faker) told me
> that the issue which in settings->about says unknown it is being caused by his
> prog. I dont know if it will help you but I mentioned it.

I had a quick look at the package's source but I don't see anything that would
cause this problem.  It does hijack the com.nokia.SystemInfo service (which
osso-product-info uses), but only for fmtxd as far as I can see.  CCing
qwerty12 in case he has any ideas.
Comment 21 Faheem Pervez maemo.org 2010-01-29 10:54:34 UTC
Hiya,

(In reply to comment #20)
> I had a quick look at the package's source but I don't see anything that would
> cause this problem.  It does hijack the com.nokia.SystemInfo service (which
> osso-product-info uses), but only for fmtxd as far as I can see.  CCing
> qwerty12 in case he has any ideas.
> 

FMTX Faker uses com.nok*l*a.SystemInfo, but this may be causing problems when
programs use the Nokia Way(C) to access services - namely, foregoing the
"com.nokia." part. I guess changing the service name and actually doing a
strcmp on the string given to FMTX Faker by the program to check that a program
is actually getting the FM transmitter information would be a start...

If not, then I have no ideas, sorry. The good news is that uninstalling FMTX
Faker won't cause any problems.
Comment 22 Lucas Maneos 2010-01-29 11:27:51 UTC
Thanks!

@anapostpastos: does uninstalling fmtx faker and rebooting fix the problem?
Comment 23 anapospastos (reporter) 2010-01-29 19:32:32 UTC
(In reply to comment #22)
> Thanks!
> 
> @anapostpastos: does uninstalling fmtx faker and rebooting fix the problem?
> 

No it doesnt solve the problem. I uninstalled fmtx faker, put out the battery,
the sim card(for over 30s) put them in again and reboot after this but the
problem remains.

I sent a message to qwerty12 to see this bug.
Comment 24 Faheem Pervez maemo.org 2010-01-29 19:38:19 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > Thanks!
> > 
> > @anapostpastos: does uninstalling fmtx faker and rebooting fix the problem?
> > 
> 
> No it doesnt solve the problem. I uninstalled fmtx faker, put out the battery,
> the sim card(for over 30s) put them in again and reboot after this but the
> problem remains.
> 
> I sent a message to qwerty12 to see this bug.
> 

Faheem Pervez == qwerty12. I already get e-mail notifications from Bugzilla, so
no need to let me know twice.

If removing FMTX Faker has not fixed it, then I'm not inclined to blame it on
FMTX Faker.
Comment 25 Lucas Maneos 2010-01-29 19:47:51 UTC
(In reply to comment #23)
> No it doesnt solve the problem.

Oh well...  Since you rebooted, just to confirm:

- Do you have a file named /tmp/.opi.tmp created at the time of the last reboot
and containing the OSSO_* variables with "<unknown>" values?
- Does osso-product-info still give sane output?

(In reply to comment #24)
> If removing FMTX Faker has not fixed it, then I'm not inclined to blame it on
> FMTX Faker.

Same here, though I would still consider it a Maemo bug if what FMTX Faker does
broke it.
Comment 26 anapospastos (reporter) 2010-01-29 20:48:35 UTC
(In reply to comment #25)
> (In reply to comment #23)
> > No it doesnt solve the problem.
> 
> Oh well...  Since you rebooted, just to confirm:
> 
> - Do you have a file named /tmp/.opi.tmp created at the time of the last reboot
> and containing the OSSO_* variables with "<unknown>" values?

Yes

> - Does osso-product-info still give sane output?

It gives me the right values. NOT "unknown".
Comment 27 Faheem Pervez maemo.org 2010-01-29 21:20:53 UTC
Oh, just to make one thing sure: You did *purge* (dpkg --purge fmtx-faker) FMTX
Faker, right?
Comment 28 anapospastos (reporter) 2010-01-29 22:45:34 UTC
(In reply to comment #27)
> Oh, just to make one thing sure: You did *purge* (dpkg --purge fmtx-faker) FMTX
> Faker, right?
> 

Nope. I didnt.
Comment 29 anapospastos (reporter) 2010-01-30 14:27:38 UTC
I uninstalled again fmtx faker, did purge on it, reboot and the problem solved!
I can backup normally and in settings->about the fields show the right values.
So the conclusion is that the problem is caused by fmtx faker right?

Ps: Im trying to install again fmtx faker but it is unavailable. Do u know why
Faheem?
Comment 30 anapospastos (reporter) 2010-01-30 14:44:10 UTC
Ok I 've found the .deb file installed and the 2 problems(backup and the
settings->about values) are here again.
Comment 31 Lucas Maneos 2010-01-30 17:17:04 UTC
Thanks for testing, that's really helpful.

I'm resolving this as INVALID since it's not an osso-backup bug (plus the usual
caveats about extras-devel apply), but I'd like to open a fresh one for the
underlying problem if we can identify what it is.

So, my best guess is that there's some race condition during boot, when
osso-product-info somehow manages to talk to the wrong dbus service (or none?)
and sets the environment incorrectly.

Running strings | grep SystemInfo on /usr/lib/libossoproductinfo.so.0 shows
that it uses the correct full service/object paths:

com.nokia.SystemInfo
/com/nokia/SystemInfo

The "<unknown>" value itself comes from /usr/lib/libsysinfo.so.0.

Faheem, you are much more knowledgable on dbus than I, any ideas?  Do you have
time to test an fmtxfaker with a different (!= "SystemInfo") path?

(Alternatively it could be an upstart thing).
Comment 32 Faheem Pervez maemo.org 2010-01-30 18:00:12 UTC
(In reply to comment #31)
> Thanks for testing, that's really helpful.
> 
> I'm resolving this as INVALID since it's not an osso-backup bug (plus the usual
> caveats about extras-devel apply), but I'd like to open a fresh one for the
> underlying problem if we can identify what it is.
> 
> So, my best guess is that there's some race condition during boot, when
> osso-product-info somehow manages to talk to the wrong dbus service (or none?)
> and sets the environment incorrectly.
> 
> Running strings | grep SystemInfo on /usr/lib/libossoproductinfo.so.0 shows
> that it uses the correct full service/object paths:
> 
> com.nokia.SystemInfo
> /com/nokia/SystemInfo
> 
> The "<unknown>" value itself comes from /usr/lib/libsysinfo.so.0.
> 
> Faheem, you are much more knowledgable on dbus than I, any ideas?  Do you have
> time to test an fmtxfaker with a different (!= "SystemInfo") path?
> 
> (Alternatively it could be an upstart thing).
> 

Thank you, Lucas, for your time and help.

Admittedly, is there really an underlying bug? I think it's fair to assume
Nokia did not intend for another service running that fakes SystemInfo stuff...

It's not the daemon itself, that can be ruled out; dpkg --remove would have
removed the daemon but left any of its D-Bus service definition files in /etc.
I will get around, eventually, to updating FMTX Faker to use a different path
but I'm currently working on Parasite.
Comment 33 Lucas Maneos 2010-01-30 18:45:28 UTC
(In reply to comment #32)
> Admittedly, is there really an underlying bug? I think it's fair to assume
> Nokia did not intend for another service running that fakes SystemInfo stuff...

Since as pointed out the problem stays even with the fake service removed, it's
probably a bug *somewhere*.

> It's not the daemon itself, that can be ruled out; dpkg --remove would have
> removed the daemon but left any of its D-Bus service definition files in /etc.

Hm, after installing and removing fmtx-faker the actual service file
(/usr/share/dbus-1/system-services/com.nokla.SystemInfo.service) is gone. 
What's left behind is:

/etc/dbus-1/system.d/com.nokla.SystemInfo.conf
/etc/event.d/fmtx-faker
/etc/sudoers.d/fmtx-faker.sudoers

That narrows it down a bit at least (my money's on the event.d file).

The interesting bit is that osso-product-info only fails when executed by the 
first invocation of /etc/osso-af-init/af-defines.sh (evidenced by looking at
/tmp/.opi.tmp).  When /etc/rc2.d/S57rich-core-pattern runs it works fine (see
/tmp/osso-product-info) and of course it works fine when executed manually
after that.  Even more interestingly, the failed version occurs *before* the
working one:

Nokia-N900-51-1:~# stat /tmp/osso-product-info  /tmp/.opi.tmp    
  File: "/tmp/osso-product-info"
  Size: 403           Blocks: 8          IO Block: 4096   regular file
Device: ch/12d    Inode: 3031        Links: 1    
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-01-30 16:29:16.000000000
Modify: 2010-01-30 16:29:16.000000000
Change: 2010-01-30 16:29:16.000000000
  File: "/tmp/.opi.tmp"
  Size: 386           Blocks: 8          IO Block: 4096   regular file
Device: ch/12d    Inode: 3239        Links: 1    
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-01-30 16:29:18.000000000
Modify: 2010-01-30 16:29:18.000000000
Change: 2010-01-30 16:29:18.000000000

so it doesn't look like a race condition after all.  The plot thickens...
Comment 34 Lucas Maneos 2010-01-30 19:28:21 UTC
(In reply to comment #33)
> That narrows it down a bit at least (my money's on the event.d file).

Bingo - two reboots later, after removing the other two files before each one,
the problem's still there.  Just to make sure, I then removed
/etc/event.d/fmtx-faker and rebooted again and all was fine.

> osso-product-info only fails when executed by the 
> first invocation of /etc/osso-af-init/af-defines.sh

Guess what, that's the one started by /etc/event.d/fmtx-faker :-)

Fix:  add

pre-start script
    /usr/sbin/waitdbus system
end script
Comment 35 Faheem Pervez maemo.org 2010-01-30 19:34:59 UTC
(In reply to comment #34)
> (In reply to comment #33)
> > That narrows it down a bit at least (my money's on the event.d file).
> 
> Bingo - two reboots later, after removing the other two files before each one,
> the problem's still there.  Just to make sure, I then removed
> /etc/event.d/fmtx-faker and rebooted again and all was fine.
> 
> > osso-product-info only fails when executed by the 
> > first invocation of /etc/osso-af-init/af-defines.sh
> 
> Guess what, that's the one started by /etc/event.d/fmtx-faker :-)
> 
> Fix:  add
> 
> pre-start script
>         /usr/sbin/waitdbus system
> end script
> 

Thanks! Will get to updating FMTX Faker sometime...
Comment 36 Lucas Maneos 2010-01-30 19:45:18 UTC
FYI, I filed bug 8700 for making the initialisation a bit more robust.
Comment 37 Lucas Maneos 2010-03-05 16:38:33 UTC
*** Bug 9400 has been marked as a duplicate of this bug. ***