Closed Bug 1105200 Opened 5 years ago Closed 5 years ago

Unable to access internal storage on JB v2.2 for OpenC FR

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cogliostro, Assigned: taz)

References

()

Details

(Whiteboard: storage settings)

Attachments

(3 files)

Attached image screenshot_settings.png
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

i maked a build with ubuntu computer.
./config.sh flame ~/openc.xml
./build.sh gecko
./flash.sh gecko
cd gaia
make reset-gaia

---

Boot2Gecko 2.2.0.0-prerelease
Build number : eng..20140806.064432
Version : 20141122094352
Commits Git 2014-11-25 21:55:37 (3c3455aa)


Actual results:

i can't select internal storage for media data in setting, only external SD card.


     adb shell vdc volume list :
110 0 sdcard /storage/sdcard 1 
110 0 extsdcard /storage/sdcard1 7 
200 0 Volumes listed

     adb shell df :
Filesystem               Size     Used     Free   Blksize
/dev                   201.3M    64.0K   201.2M   4096
/mnt/secure            201.3M     0.0K   201.3M   4096
/mnt/asec              201.3M     0.0K   201.3M   4096
/mnt/obb               201.3M     0.0K   201.3M   4096
/system                755.2M   298.3M   456.9M   4096
/data                 1006.7M    30.0M   976.7M   4096
/cache                 251.9M    24.2M   227.6M   4096
/persist                14.7M     4.1M    10.7M   4096
/firmware               64.0M    31.0M    32.9M   16384
/mnt/shell/emulated   1006.7M    30.0M   976.7M   4096
/storage/emulated/legacy  1006.7M    30.0M   976.7M   4096

     adb shell ls -l :
drwxr-xr-x root     root              1970-01-02 05:54 acct
drwxrwx--- system   cache             1970-01-01 12:21 cache
-rwxr-x--- root     root       280560 1970-01-01 01:00 charger
dr-x------ root     root              1970-01-02 05:54 config
lrwxrwxrwx root     root              1970-01-02 05:54 d -> /sys/kernel/debug
drwxrwx--x system   system            1970-01-02 05:54 data
-rw-r--r-- root     root          206 1970-01-01 01:00 default.prop
drwxr-xr-x root     root              2014-11-21 13:19 dev
lrwxrwxrwx root     root              1970-01-02 05:54 etc -> /system/etc
-rw-r--r-- root     root         8753 1970-01-01 01:00 file_contexts
dr-xr-x--- system   system            1970-01-01 01:00 firmware
-rw-r----- root     root         1599 1970-01-01 01:00 fstab.qcom
-rwxr-x--- root     root       158612 1970-01-01 01:00 init
-rwxr-x--- root     root          866 1970-01-01 01:00 init.b2g.rc
-rwxr-x--- root     root         7770 1970-01-01 01:00 init.qcom.class_core.sh
-rwxr-x--- root     root         2530 1970-01-01 01:00 init.qcom.class_main.sh
-rwxr-x--- root     root         7301 1970-01-01 01:00 init.qcom.early_boot.sh
-rwxr-x--- root     root        12428 1970-01-01 01:00 init.qcom.factory.sh
-rwxr-x--- root     root        24223 1970-01-01 01:00 init.qcom.rc
-rwxr-x--- root     root         1990 1970-01-01 01:00 init.qcom.ril.sh
-rwxr-x--- root     root         7247 1970-01-01 01:00 init.qcom.sh
-rwxr-x--- root     root         4561 1970-01-01 01:00 init.qcom.ssr.sh
-rwxr-x--- root     root         3072 1970-01-01 01:00 init.qcom.syspart_fixup.sh
-rwxr-x--- root     root        48347 1970-01-01 01:00 init.qcom.usb.rc
-rwxr-x--- root     root         8886 1970-01-01 01:00 init.qcom.usb.sh
-rwxr-x--- root     root        22546 1970-01-01 01:00 init.rc
-rwxr-x--- root     root         5325 1970-01-01 01:00 init.target.rc
-rwxr-x--- root     root         1795 1970-01-01 01:00 init.trace.rc
-rwxr-x--- root     root         3915 1970-01-01 01:00 init.usb.rc
drwxrwxr-x root     system            1970-01-02 05:54 mnt
drwxrwx--x system   system            2014-11-20 02:27 persist
dr-xr-xr-x root     root              1970-01-01 01:00 proc
-rw-r--r-- root     root         2109 1970-01-01 01:00 property_contexts
drwxr-xr-x root     root              1970-01-01 01:00 res
drwx------ root     root              2014-08-06 01:02 root
drwxr-x--- root     root              1970-01-01 01:00 sbin
lrwxrwxrwx root     root              1970-01-02 05:54 sdcard -> /storage/emulated/legacy
-rw-r--r-- root     root          611 1970-01-01 01:00 seapp_contexts
-rw-r--r-- root     root        63747 1970-01-01 01:00 sepolicy
d--xr-x--- system   sdcard_r          1970-01-02 05:54 storage
dr-xr-xr-x root     root              1970-01-02 05:54 sys
drwxr-xr-x root     root              1970-01-18 06:22 system
lrwxrwxrwx root     root              1970-01-02 05:54 tombstones -> /data/tombstones
-rw-r--r-- root     root         8675 1970-01-01 01:00 ueventd.qcom.rc
-rw-r--r-- root     root         4080 1970-01-01 01:00 ueventd.rc
lrwxrwxrwx root     root              1970-01-02 05:54 vendor -> /system/vendor

     file /etc/vold.fstab :
dev_mount sdcard /storage/sdcard1 auto /devices/msm_sdcc.2/mmc_host

     file /etc/volume.cfg :
create sdcard /storage/sdcard


Expected results:

possibility to select storage
OS: All → Linux
Hardware: All → x86_64
Whiteboard: storage settings
OS: Linux → All
Hardware: x86_64 → All
That's clearly not a Gaia::System issue, since it's about Open C with a hacked JB basis. According to your |df| output, there is indeed the internal storage, but there is no external sdcard.

There may be several root cause to this, nothing we can address in the current state since it's not a device that we are supposed to be supporting in this setup ...
Flags: needinfo?(olivier.porcherel)
Component: Gaia::System → GonkIntegration
You should check the output of |dmesg| to make sure all sdcard devices are properly detected by the kernel. Then, make sure the device tree configuration and the system mount points do matches.

|ls -l| only shows /sdcard, we would need |ls -l /storage/| and also |ls -rl /dev/disk/|
Summary: [FLAME][OPENC] | unavailable to access internal storage → [OPENC] | unavailable to access internal storage
Flags: needinfo?(olivier.porcherel)
Summary: [OPENC] | unavailable to access internal storage → Unable to access internal storage on JB v2.2 for OpenC FR
For ls -l /dev/disk/ :                                    
/dev/disk/: No such file or directory
adb shell ls -al /storage/sdcard*/
Flags: needinfo?(taz)
adb shell ls -al /storage/sdcard*/ output nothing
Flags: needinfo?(taz)
adb shell ls -alR /storage/
Flags: needinfo?(taz)
With my Open_C

>> adb shell ls -al /storage/sdcard*/
drwxrwxrwx root     sdcard_rw          1970-01-02 05:54 clockworkmod


>> adb shell ls -alR /storage/
/storage/:
dr-xr-xr-x root     root              1970-01-11 19:12 emulated
drwxrwxrwx system   sdcard_r          1970-01-11 19:12 sdcard
lrwxrwxrwx root     root              1970-01-11 19:12 sdcard0 -> /storage/emulated/legacy
drwxrwxrwx system   sdcard_r          1970-01-11 19:12 sdcard1

/storage//emulated:
drwxrwxrwx root     sdcard_rw          1970-01-02 05:54 legacy

/storage//emulated/legacy:
drwxrwxrwx root     sdcard_rw          1970-01-02 05:54 clockworkmod

/storage//emulated/legacy/clockworkmod:
-rwxrwxrwx root     sdcard_rw       41 1970-01-11 19:02 .recovery_version

/storage//sdcard:

/storage//sdcard1:
The 'sdcard1' is my external_SD : OK
i think that sdcard_rw is the user's data area... not sur
adb shell ls -al /storage/sdcard/
adb shell ls -al /storage/sdcard0/
adb shell ls -al /storage/sdcard01/
adb shell ls -al /storage/sdcard1/
Output nothing 

ls -alR /storage/ :

/storage/:
dr-xr-xr-x root     root              1969-12-31 19:01 emulated
drwxrwxrwx system   sdcard_r          1969-12-31 19:01 sdcard
lrwxrwxrwx root     root              1969-12-31 19:01 sdcard0 -> /storage/emulated/legacy
drwxrwxrwx system   sdcard_r          1969-12-31 19:01 sdcard1

/storage//emulated:
dr-xr-xr-x root     root              1969-12-31 19:01 legacy

/storage//emulated/legacy:

/storage//sdcard:

/storage//sdcard1:
Flags: needinfo?(taz)
(In reply to olivier.porcherel from comment #8)
> The 'sdcard1' is my external_SD : OK
> i think that sdcard_rw is the user's data area... not sur

According to some testing I did with Dattaz, it would looks like the internal SD card does indeed work well, it's just not being mounted.

Can you confirm by running:
> $ adb shell vdc mount sdcard

And then re-launching Settings app, checking the Storage section?
Flags: needinfo?(olivier.porcherel)
hi,

Thanks for your help.

I tested :
adb shell vdc mount sdcard
500 0 Command not recognized
Flags: needinfo?(olivier.porcherel)
(In reply to olivier.porcherel from comment #11)
> hi,
> 
> Thanks for your help.
> 
> I tested :
> adb shell vdc mount sdcard
> 500 0 Command not recognized

> $ adb shell vdc volume mount sdcard
Flags: needinfo?(olivier.porcherel)
it's work !

my terminal reply
 adb shell vdc volume mount sdcard
605 Volume sdcard /storage/sdcard state changed from 1 (Idle-Unmounted) to 3 (Checking)
605 Volume sdcard /storage/sdcard state changed from 3 (Checking) to 4 (Mounted)
200 0 volume operation succeeded


I can write photo on internal memory, but, i can't see this memory form my computer.

it's the begining.... :)

I must use this 'code' after reboot my phone?
Flags: needinfo?(olivier.porcherel)
No, it just means that at least the base system is ok. We will have to bisect Gecko, since at some point this used to work.

Dave, as far as I remember, you worked on this area, do you have any idea what may have made this regress?
Flags: needinfo?(dhylands)
Same problem here with Open C EU, internal sd does not seem to be mounted. I can manually mount it using adb shell:

aroot@ZTE_P821A10:/ # vdc volume list
110 0 sdcard /storage/sdcard 1
110 0 extsdcard /storage/sdcard1 4
200 0 Volumes listed.

root@ZTE_P821A10:/ # vdc volume mount /storage/sdcard                          
605 Volume sdcard /storage/sdcard state changed from 1 (Idle-Unmounted) to 3 (Checking)
605 Volume sdcard /storage/sdcard state changed from 3 (Checking) to 4 (Mounted)
200 0 volume operation succeeded

File /system/etc/vold.fstab contains:
dev_mount sdcard /storage/sdcard1 auto /devices/msm_sdcc.2/mmc_host

File /system/etc/volume.cfg contains (no line-break at EOF):
create sdcard /storage/sdcard
Regression commit : c0310ea8fb2720bbd05f0d6e443734d94e4fc20b (gecko)
See bug 1085743
So all of the stuff around getting the internal sdcard to work is phone specific (not in gecko or gaia).

When you did vdc volume list and it shows a volume with the number 1 - that means that the volume is in the idle state and not mounted.

You should be able to do:

stop b2g
vdc volume unmount sdcard
vdc volume share sdcard ums

and that should make the volume be shared with the PC.

Then do

vdc volume unshare sdcard ums
vdc volume mount sdcard

and you'll be back to seeing it on the local filesystem. The reason you need to stop b2g in order to do this is that otherwise you'll be fighting with the automounter which is trying to get the volumes into a particular state.

But the basics (stuff above with b2g stopped) have to be working before they'll working under B2G.
Flags: needinfo?(dhylands)
Hmm. I see that you also mentioned having:

/etc/volume.cfg:
    create sdcard /storage/sdcard

The above is intended for devices which have the data and sdcard areas both in the same partition. The nexus 4 & 5 do this.

If you use that, then you can't share the sdcard with the host. You can only share the sdcard with the host when it's in its own partiion and its formatted using vfat.
I provided some more information here: https://bugzilla.mozilla.org/show_bug.cgi?id=1085743#c9

I think that you may just need to remove the volume.cfg file. It shouldn't have entries in it to create volumes that you want shared via USB Mass Storage.
Renaming /etc/volume.cfg to /etc/volume.cfg.sav indeed works:
- internal storage is accessible on the phone
- internal storage is shared via USB
Thanks to both of you. So indeed, we should make sure in recovery packages that we trash this file.

Dattaz, you will have to augment the recovery package to make sure we do not keep this file around.

Dave, any reason why this was not impacting earlier releases ?
Flags: needinfo?(taz)
Flags: needinfo?(dhylands)
Assignee: nobody → taz
(In reply to Alexandre LISSY :gerard-majax from comment #21)
> Thanks to both of you. So indeed, we should make sure in recovery packages
> that we trash this file.
> 
> Dattaz, you will have to augment the recovery package to make sure we do not
> keep this file around.
> 
> Dave, any reason why this was not impacting earlier releases ?

In order to support some new features, I moved the place where volume.cfg is parsed.

In earlier releases, the only thing you could put into volume.cfg were "fake" volumes, so we parsed volume.cfg first and then parsed the volumes from vold, and the volumes from vold would wind up overriding the stuff from volume.cfg.

In order to support some new features we needed to move the parsing of volume.cfg to after the vold volumes are known about (so that volume.cfg can now overide/augment what vold does).

For example, this allows us to tag volumes as hot swappable/removable, which in turn allows us to allow/disallow certain types of operations in the UI.

In a properly configured system, this would be transparent.
Flags: needinfo?(dhylands)
You can also add : 
        #modif bug stockage
        cmd = ('run_program("/system/bin/mv", "/system/etc/volume.cfg", "/system/etc/volume.cfg.sav");')
        self.generator.script.append(self.generator._WordWrap(cmd))
        self.generator.Print("Suppress volume config - bug 1105200")

In fonction build_flash_script in the file tools/update-tools/update_tools.py to have the modif for an update.zip/update.mar
Flags: needinfo?(taz)
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Duplicate of this bug: 1113648
Is it possible that this effectively delete any existing internal sdcard data on update ?

see https://bugzilla.frenchmozilla.org/show_bug.cgi?id=666
Flags: needinfo?(dhylands)
(In reply to Julien Wajsberg [:julienw] from comment #25)
> Is it possible that this effectively delete any existing internal sdcard
> data on update ?
> 
> see https://bugzilla.frenchmozilla.org/show_bug.cgi?id=666

If by "this" you mean the commands being discussed in comment 23, then those commands shouldn't cause any data loss.

It is entirely possible that a FOTA update can delete (or format) the internal sdcard.
Flags: needinfo?(dhylands)
Duplicate of this bug: 1117902
You need to log in before you can comment on or make changes to this bug.