[Flame KK] FOTAs cannot be installed

RESOLVED WONTFIX

Status

Firefox OS
General
RESOLVED WONTFIX
3 years ago
11 months ago

People

(Reporter: amac, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

3 years ago
STR: 
0. You might need to flash a recovery img on the device that has the test
   keys.
1. Build a user or userdebug flame KK build over the 180 build. On this build, set 
pref("app.update.url", "http://SOME_SERVER/APATH/update.xml");
2. Flash that build

3. Prepare a FOTA with:
./build.sh gecko-update-fota
3. Create the update.xml as:

./tools/update-tools/build-update-xml.py -v 99.0 -V 99.0 -o update.xml -u http://SOME_SERVER/APATH/update.xml ${PATH_TO_MAR}

4. Copy the update.xml and .mar files to your SOME_SERVER on APATH 

5. Ensure that the device doesn't have a external SD card installed

6. Search for updates on the phone and download and apply the update.

Expected:

The device is rebooted and the update is applied.

Actual: 

The device is rebooted but the update is not applied. Checking /cache/recovery/last_log something like:

Command: "/sbin/recovery" "--update_package=/storage/sdcard1/updates/fota/update.zip"
E:failed to mount /sdcard (No such file or directory)
(replacing path "/storage/sdcard1/updates/fota/update.zip" with "/updates/fota/update.zip")

is reported.
(Reporter)

Comment 1

3 years ago
I believe the problem is with the translation librecovery does between the normal-running paths and the recovery-mode paths. In librecovery.c there's a convertExternalStoragePath that uses a build time macro (RECOVERY_EXTERNAL_STORAGE) to translate the normal mode path (stored on the env variable EXTERNAL_STORAGE) to the recovery mode path (stored on the macro).

But that macro is not defined for the flame (in fact in librecovery/device there's no flame.mk) and so it's taking the (I assume) default value which is /sdcard. That's incorrect for the flame.

In fact, it's incorrect even with a external card inserted...

root@flame:/mnt/media_rw/sdcard1 # echo $EXTERNAL_STORAGE
echo $EXTERNAL_STORAGE
/mnt/media_rw/sdcard

I get that with and without the external sdcard inserted. The external card is mounted at /mnt/media_rw/sdcard1
(Reporter)

Comment 2

3 years ago
Effectively, tried this with an SD Card (I had to hunt for one :)) and it fails the same way. Gecko copies the update.zip to the EXTERNAL_STORAGE directory (the internal sdcard-like memory) and then the recovery tries finding it on the external sdcard.
Summary: [Flame KK] FOTAs cannot be installed without a SD card inserted → [Flame KK] FOTAs cannot be installed
RECOVERY_EXTERNAL_STORAGE is defined in BoardConfig.mk: https://github.com/mozilla-b2g/device-flame/blob/master/BoardConfig.mk#L19 with /storage/sdcard1
Antonio, we may need to make sure that the recovery is not doing weird things regarding mounting the external storage partition.
Flags: needinfo?(amac.bug)
(Reporter)

Comment 5

3 years ago
I don't think it's doing weird things. This are the relevant partitions during recovery:

recovery filesystem table
=========================
  5 /recovery emmc /dev/block/platform/msm_sdcc.1/by-name/recovery 0
  16 /storage/sdcard0 vfat /dev/block/platform/msm_sdcc.1/by-name/usbmsc 0

That's also what's on out/target/product/flame/recovery/root/etc/recovery.fstab after a build:

/dev/block/mmcblk1p1                              /sdcard           vfat    nosuid,nodev,barrier=1,data=ordered,nodelalloc                  wait
#Fota internal sdcard mount
/dev/block/platform/msm_sdcc.1/by-name/usbmsc       /storage/sdcard0 vfat   defaults                                                        wait

Partition 5 is the external sdcard (that is, the actual sdcard). Partition 16 is the internal sdcard (the internal memory partitioned as sdcard). /storage/sdcard1 (which is the value of RECOVERY_EXTERNAL_STORAGE) doesn't even exist on the partition table as reported by the log or the fstab file).
Flags: needinfo?(amac.bug)
(Reporter)

Comment 6

3 years ago
Created attachment 8489516 [details] [diff] [review]
WIP patch for build/core
(Reporter)

Comment 7

3 years ago
Created attachment 8489517 [details] [diff] [review]
WIP patch for device/t2m/flame

With the changes here and on the other patch (for build/core) I've managed to at least start the patching. It stills fails on some assertion but at least now it finds the update.

Summarizing, what's needed is to:
1. Create the storage directory on the recovery partition (or change the recovery.cpp to do the equivalent of a mkdir -p instead of a simple mkdir)
2. Change the RECOVERY_EXTERNAL_STORAGE macro/var to point to the correct location for the internal sdcard.
(Reporter)

Updated

3 years ago
Depends on: 1067005
(Reporter)

Comment 8

3 years ago
Created attachment 8490089 [details] [review]
Set the external storage path to the internal sdcard
Attachment #8489517 - Attachment is obsolete: true
Attachment #8490089 - Flags: review?(gsvelto)
Attachment #8490089 - Flags: feedback?(lissyx+mozillians)
(Reporter)

Comment 9

3 years ago
Created attachment 8490090 [details] [review]
Create the /storage directory on the recovery partition
Assignee: nobody → amac.bug
Attachment #8489516 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8490090 - Flags: review?(gsvelto)
Attachment #8490090 - Flags: feedback?(lissyx+mozillians)
(Reporter)

Updated

3 years ago
Attachment #8490089 - Flags: review?(gsvelto) → review?(mwu)
(Reporter)

Updated

3 years ago
Attachment #8490090 - Flags: review?(gsvelto) → review?(mwu)

Comment 10

3 years ago
On the recovery image provided by the vendor, /storage is generated by the recovery image's init.rc. I would prefer a similar approach.

Updated

3 years ago
Attachment #8490090 - Flags: review?(mwu)
(Reporter)

Comment 11

3 years ago
Yeah, I see it now: https://github.com/t2m-foxfone/platform_bootable_recovery/blob/foxfone-one-v1.4/etc/init.rc#L14

Then it's better to wait till that branch is merged (bug 1067005).
(Reporter)

Comment 12

3 years ago
Ok, I've tried using the recovery from the foxfone-one-1.4 branch of T2M repository, and the device/t2m/flame patch (https://bugzilla.mozilla.org/attachment.cgi?id=8490089) and although the recovery ui is borked (as mentioned in comment 4 of bug 1067005) the update is applied correctly. So the build patch isn't needed (or won't be needed once bug 1067005 is fixed)
(Reporter)

Updated

3 years ago
Attachment #8490090 - Attachment is obsolete: true
Attachment #8490090 - Flags: feedback?(lissyx+mozillians)
(Reporter)

Comment 13

3 years ago
I've also tried the recovery provided by the OEM (modified to change the keys) and the update is applied correctly with the currently proposed patch *AND* commenting out [1]. 

It seems that getprop isn't working as expected (neither on the recovery compiled from Mozilla's repo, nor on recovery compiled from T2M's repo nor on T2M pre-compiled recovery for v180). I think that might be because of [2] or simply because it relies on system/build.prop and system isn't mounted at boot time. Whatever the reason is (I didn't had time to investigate it), it doesn't work and stops the update unless commented out. A possible workaround to avoid removing the check completely could be replacing the getprops with file_getprop("/default.prop", "whatever")

[1] https://github.com/mozilla-b2g/B2G/blob/2.0/tools/update-tools/update_tools.py#L937
[2] https://code.google.com/p/chromium/issues/detail?id=392191

Let me know if you want me to change that also in this bug, if it'll be changed on bug 1067005 or we should file another bug for that.
Partner's init.rc does mount /system when in recovery: https://github.com/t2m-foxfone/platform_bootable_recovery/commit/445a4aa145166aeafce96f04dca3aa9d25ebac0d#diff-b77e6cdd0be299afb0bf6f0fbe9449a8R42

You should try to either get into the device when in recovery (adb shell should work), or attach the last_log from /cache/recovery/ so that we can cross check the status of /proc/mounts (maybe you need to hack the edify script to dump it, I can't remember if it's done by default).
Flags: needinfo?(amac.bug)
Flags: needinfo?(amac.bug)
(Reporter)

Comment 15

3 years ago
I didn't check that with the partner recovery. But with mozilla-b2g's recovery, I did modify the recovery sources so that it printed the /proc/mounts every time it checked it, and system wasn't mounted. Precisely because of those differences between both recoveries (OEM and Mozilla's) I decided to let this sit until they're merged.

In any case and as we talked on IRC, I think it's more probable that the updater-binary script that's packaged on the update.zip isn't valid for the OS version present on the recovery partition.  Oh, one thing I also tried (and didn't work) is modifying the edify script so it mounted the system partition before checking the properties. Since that didn't work either, that reinforces the incorrect updater binary theory.

Comment 16

3 years ago
Comment on attachment 8490089 [details] [review]
Set the external storage path to the internal sdcard

Clearing review since we want to do this by merging the vendor branch.
Attachment #8490089 - Flags: review?(mwu)
Comment on attachment 8490089 [details] [review]
Set the external storage path to the internal sdcard

Clearing as per comment 16.
Attachment #8490089 - Flags: feedback?(lissyx+mozillians)
(Reporter)

Updated

2 years ago
Assignee: amac.bug → nobody
Status: ASSIGNED → NEW
Blocks: 1211965
Is this applicable any more?  I ran into something different when trying this on a recent build.

Can we close this out in favor of the bug 1213331?
Flags: needinfo?(amac.bug)
(Reporter)

Comment 19

2 years ago
Yes, by all means. I haven't tested this in a long time.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(amac.bug)
Resolution: --- → DUPLICATE
Duplicate of bug: 1213331
(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #19)
> Yes, by all means. I haven't tested this in a long time.
> 
> *** This bug has been marked as a duplicate of bug 1213331 ***

That bug has nothing to do with the present one.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Looks like the /storage/sdcard0/updates/fota/update.zip is being used.

Alexandre told me that this bug is still needed, so I'm leaving this open.

Updated

11 months ago
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago11 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.