Too many devices mounted on XperiaXZ2c@SFOS4.0.1 #41
Comments
|
open question answer: yes, both versions. |
|
output: brw-rw---- 1 root disk 8, 0 May 29 14:24 /dev/sda |
|
Your command line output shows that the mapping of partition on internal eMMC on this community port of SailfishOS is quite different to all officially supported devices.
|
[OT] Side note & off topic
Supposedly you are addressing the statement "Ensure, that AlienDalvik begins starting after mounting succeeded, to allow for android_storage on SD-card." (from the third bullet point at https://openrepos.net/content/olf/mount-sdcard). TL;DR: Currently that does not work with AlienDalvik 8, 9 or 10, because Jolla changed something (again), and nobody has traced what and how to workaround it, yet. |
Back on topic, againWas your output generated with or without an SD-card inserted? Well, what I really want to know is: To which devices names does (partitions on) an SD-card become assigned on your XperiaXZ2c@SFOS4.0.1? |
|
On Sony Tama (XZ2{c}/3), system partitions are on /dev/sd{a,b} and maybe few more. SD card is mounted on
We have been asking few times for getting some proper fix using udev, but nothing happened so far. |
|
@rinigus, O.K., I think I can handle that ("system partitions are on /dev/sd{a,b}"), but "and maybe few more" might be tricky. But "SD card is mounted on mmcblk0" collides with the system partitions on all officially supported devices, which are all at some And which device names does USB-attached storage become assigned to? |
|
After thinking about it a little, I believe this device naming scheme has the potential to cause big trouble (up to bricking devices non-manually; mount-sdcard currently just enables one to do that manually), because it more or less conflicts with what Jolla chose for their device adaptations. Hence I will consider to limit the |
|
The naming scheme for devices comes from Android layer/SOC and cannot be changed. The devices in question are using SD 835, 845 and I suspect that the later SDs as well (don't know though). So, in my eyes, real solution would be to instruct UDEV to attach some label to removable devices and use that label to handle mounting. I agree, it is a dangerous situation and users should be aware of it. |
|
PS: I have not checked specific devices as I didn't have time for it. But, in principle, we should not look for solution where each app or subsystem has to write down all possible configs. Hence I wasn't documenting it here. |
That is unfortunate, tough I was expecting this to be reason.
Oh, that would be the perfect solution. But only Jolla and the udev project are in the position to change that for SailfishOS (or all distros using udev) in general.
I fully agree, but what else can be done to fix this clash between mount-sdcard and some community adaptations soon? |
|
O.K., I drafted a workaround per commit 89bc3d1. But as I wrote
@rinigus, is it possible to assign the sd-card slot to mmcblk1, or to put it more generically: |
|
I am massively swamped right now and will probably be next week as well. After that I can have a meaningful discussion on it. Sorry for it. Don't count on us to be able to block mmcblk0 from appearing. However, maybe we could tag it somehow as removable device. I will have to pull my notes regarding it, hopefully I wrote it down in the corresponding issue of Tama port. But that will have to wait. |
No, don't! ;-) TL;DR: Ping us here, when you have some time to deal with this. Side note: |
|
Please test mount-sdcard-1.8.0-1.sfos340.noarch.rpm on XperiaXZ[23]{c}, Pro¹ or another affected community device adaptation with SFOS4.x.y, @levone1.
Does it now work as expected / indented (by me)? Suggested procedures (either one):
|
Olf0
added
enhancement
[OT] continued@levone1, as Jolla has been fixing stuff lately and had explicitly broken SD-card access for the AlienDalvik runtime environment in SailfishOS 3.3.0 - 3.4.0, you may just retry the suggestions in this sub-thread (please read it twice in its completeness, which is just a few messages, before starting to test / try things): https://together.jolla.com/question/203539/guide-externalising-android_storage-and-other-directories-files-to-sd-card/?answer=206350#post-id-206350 Please report you success or lack thereof somewhere and point me to that. |
|
@levone1, as you were so keen on having this quickly addressed and fixed: P.S.: I would like to release v1.8.0 at Openrepos today, but preferably after knowing that this fixed your issue. |
|
Closing, as there is no feedback by the original reporter and because mount-sdcard 1.8.0 is likely working well on these niche devices. @rinigus, you may utilise this (closed) thread (or by some other means) to notify me, when you have found a way to somehow mark a "removable" |
Olf0
added
enhancement
|
Update installed and working fine - no additional "removable media" devices. Thanks p.s. Sorry you feel so put-out by it. It really wasn't a big problem for me; I thought I was being helpful to you. |
|
@levone1, thanks for your feedback. As you asked, two things were problematic for me:
|
|
P.S.: And as stated, @levone1, if you like to try out things / contribute to a long lost open question / serve your original interest of having |
|
Externalizing seems interesting ... I'll probably mess with it at some point to test. My current sd card is nearly full, but I'll pull one out to work with. Are yo saying that as of now, there is no possible way for AD to access the card directly? My interest was more in that realm, but workarounds work... |
|
???
P.S.: It was reported at FSO that simply accessing an SD-card from Android apps works again with SFOS ≥ 4.0.1. I have not tried that yet, because my "production phone" is still on SFOS 3.2.1 due to the massive amount of bugs introduced in each following release. |
|
My initial fiddling ... Then I tested the guide by mynameisnotimportant posted under yours, and I found a significant difference in my config file compared to his. I tried the tweaks he posted anyway, just to see, but it caused AD to not start, (tried a few different paths/syntaxes). Here is the content of my AD config file: lxc.init.cmd = /init lxc.mount.auto = cgroup:ro sys:ro necessary dev nodes (renamed)lxc.mount.entry = /dev/puddlejumper dev/binder none bind,create=file 0 0 necessary device nodes (same name)lxc.mount.entry = /dev/ashmem dev/ashmem none bind,create=file 0 0 lxc.mount.entry = /dev/fuse dev/fuse none bind,create=file 0 0 Mount /data - always /home/.android nowlxc.mount.entry = tmpfs mnt tmpfs mode=0755,uid=0,gid=1000 useful device properties from the hostlxc.mount.entry = /tmp/aliendalvik/generated_props system/vendor/alien.prop none bind,create=file 0 0 Xkb - required for on screen keyboardlxc.mount.entry = /usr/share/X11/xkb usr/share/X11/xkb none bind 0 0 lxc.include = /var/lib/lxc/aliendalvik/bsp_config ` |
... is still off-topic to this issue thread: Please open a new one.
Well, my advice is still to wholly read threads, before starting to experiment / trying to reproduce.
Structurally I expected that outcome, but thanks for checking.
... where I pointed you to, twice.
Which ones?
The original or patched content? Also, please upload larger (> ~300 Bytes) files as a file-attachment to a post.
Thanks for this result. |
Environment
Issue description
"Storage is mounted normally until installing mount-sdcard, then the issue apears." from this OpenRepos thread, which refers back to this FSO thread.
Open question
Which version of mount-sdcard was used (might have been v1.6.1 and / or v1.7.2)?
Steps for a first analysis
Please execute the following commands:
devel-su# become rootls -l /dev/mmcblk[1-9]* /dev/sd[a-z]* /dev/sr* | tee ls-l_dev.txtThen upload the resulting file
ls-l_dev.txthere, or copy & paste its whole content here.The text was updated successfully, but these errors were encountered: