Ask / Submit

[Improvement] Enhanced mounting scripts for SD-cards

asked 2018-10-26 02:15:56 +0300

olf gravatar image

updated 2018-10-26 05:27:14 +0300

Dear Sailors,

please consider improving SailfisOS' mounting of SD-cards in order to prevent data loss (e.g. by not unmounting cleanly) and enhance usability.
Provided are the following enhancements compared to the original version (as of SailfishOS 2.2.x) in descending importance:

  1. Start mounting (partitions on) SD-card via udisks at the earliest sensible time: Right after udisks2.service has started. Also unmount before udisks2.service begins stopping, hence achieving a clean unmount.
    Suggested changes for employing point 1:

    $ diff /lib/systemd/system/mount-sd\@.service /etc/systemd/system/mount-sd\@.service.patched
    < Description=Handle udisks sd mount
    < After=dev-%i.device
    < BindsTo=dev-%i.device
    > Description=Handle udisks mount of SD-card %i
    > After=udisks2.service dev-%i.device
    > BindsTo=udisks2.service dev-%i.device
    < ExecStop=-/usr/bin/udisksctl unmount -b /dev/%i
    > ExecStop=/usr/bin/udisksctl unmount -b /dev/%i

  2. Ensure, that AlienDalvik begins starting after mounting succeeded. Even more importantly this also ensures, that unmounting occurs only after AlienDalvik is completely stopped. Nevertheless, this still is also applicable to devices without AlienDalvik installed.
    Suggested change for employing point 2:

    $ diff /etc/systemd/system/mount-sd\@.service.patched /etc/systemd/system/mount-sd\@.service.patched2
    > Before=alien-service-manager.service

  3. Do not try to mount block devices without a filesystem recognised by the kernel / udev.
    Suggested change for employing point 3:

    $ diff /lib/udev/rules.d/80-udisks2.rules /etc/udev/rules.d/80-udisks2.rules.patched
    < KERNEL=="mmcblk1*|sd[a-z][0-9]", SUBSYSTEM=="block", ACTION=="add", MODE="0660", TAG+="systemd", ENV{SYSTEMD_WANTS}="mount-sd@%k.service"
    > KERNEL=="mmcblk1*|sd[a-z][0-9]", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", ACTION=="add", MODE="0660", TAG+="systemd", ENV{SYSTEMD_WANTS}="mount-sd@%k.service"

  4. Create a "compatibility symlink" to allow older apps seamlessly accessing (partitions on) SD-cards at their new (since SailfishOS 2.2.0) mount point.
    For the suggested changes to employ point 4, please see mount-sdcard's systemd services.

For users, who want to enjoy these enhancements right away, an installable RPM is available at OpenRepos.

HTH & happy sailing

edit retag flag offensive close delete


2 Answers

Sort by » oldest newest most voted

answered 2018-10-26 15:18:58 +0300

rainemak gravatar image

Thank you @olf for you valuable feedback.

I'll do my best to reply to you in reverse order.

4) It looks that you're looking for this, we realized the same compatibility issue. Thanks for raising this one again

3) Good improvement idea, took a liberty to create a PR out of this:

2) & 1) The mount-sd service might fade away let's see.

Thanks and have a nice weekend. Raine

edit flag offensive delete publish link more



Thanks for your prompt reply, which deserves a few comments IMO:

  • 4) Your commit 6 months ago is not what I was "looking for" / aiming at, as it ultimately issues a single ln -s /run/media/nemo /media/sdcard after deleting all directories in /media/sdcard.
    On first sight, this is what SFOS 2.2.x already deploys, right?
    Some older SFOS apps are not happy with that, so that did not solve the "compatibility issue" for them; issuing ln -s /run/media/nemo/<UUID> /media/sdcard/<UUID> for each partition / device found restores their SD-card related functions (e.g. FileCase).
    Edit: Sorry, now having more time available and looking more thoroughly, I see that SFOS 2.2.x issued a ln -s /run/media/nemo /media/sdcard/nemo, not ln -s /run/media/nemo /media/sdcard as your aforementioned commit ultimately does.
    Yes (without having tried that, yet), this change seems to resolve the compatibility issue more elegantly than my suggestion. Although I refrain from adapting mount-sdcard to it, as I would have to delete filesystem elements deployed by Jolla (i.e. the /media/sdcard/nemo symlink), while I want to interfere as little as possible with your past and current work.
    Side note: When reviewing your script, it seems to expect solely empty directories (as potential mount points) in OLD_MOUNT_PATH (i.e. /media/sdcard), but appears to fail if symlinks (e.g. Jolla's nemo link or the ones deployed by mount-sdcard), files or non-empty directories (accidentally or deliberately created by a user) exist there. This may be alleviated by also deleting symlinks in /media/sdcard (e.g. by an additional [ -L ${path} ] && rm -f ${path} in the for loop), before deleting empty directories there, as both operations cannot delete any actual data (but an rmdir may delete an empty directory symlinked to). If that does not suffice (i.e. non-empty directories or files do exist in /media/sdcard), IMO failing is the right option.
    Edit2: Oh, this is what SFOS 2.2.x already deploys, and it creates a symlink /media/sdcard/nemo -> /run/media/nemo, if /media/sdcard contains anything else but empty directories (ln's behavior is somewhat surprising, if the source for a symlink is an extant directory). This PR fixes this.

  • 3) Thank you for creating a PR.

  • 1) and 2) are the really crucial points IMO, i.e. the ones the original posting primarily addresses, hence your non-answer is a bit disappointing for me.
    Side note: Your current mount-sd.service is elegant and easy to adapt, plus it was just altered to utilise udisks in SFOS 2.2.0, hence I expected it to stay (and based my improvements upon it).
    Anyway, whatever substitutes it, shall properly address issues 1. and 2., IMHO.

Best regards and a pleasant weekend for you, too.

olf ( 2018-10-26 17:06:53 +0300 )edit

BTW, others also observed an incorrect symlink created by this script:
See e.g. "SDcard symlink is incorrect" or @eatdirt's comment in "Path to SDCard,".

olf ( 2018-11-03 02:27:50 +0300 )edit

@rainemak, #3 is also applicable to the udisks-rule 90-mount-usbstick.rules, which was introduced in SailfishOS 3.0.0.

olf ( 2018-11-22 22:43:34 +0300 )edit

answered 2018-10-27 00:24:51 +0300

campeon gravatar image

Hi. Sorry for my ignorance. Does this solve the problem we have with the storage data on android apps? I tried and they still don't see my sd, so, for example, i can't download podcast to the sd, using, of course an android podcast app. Thanks for your help

edit flag offensive delete publish link more


Well, with a proper Android file-manager (e.g. "OI File Manager" installable per F-Droid client app), one can "see" and read everything on SD-card by navigating to /run/media/nemo (since SailfishOS 2.2.0, before: /media/sdcard).

But most Android apps only allow accessing Android's "external SD-card", which is mapped to "android_storage" by AlienDalvik (in nemo's homedir on internal eMMC).
If you want such Android apps to read and write to SD-card, you have to reconfigure android_storage to reside on SD-card.
As some data in android_storage may be privacy relevant (browser history, pictures, downloads, etc.), it might make sense to put it on an encrypted partition on SD-card. But for putting android_storage on unencrypted SD-card, above enhancements are indeed useful.

olf ( 2018-10-27 18:49:35 +0300 )edit

Thanks for your time. I see it's a little difficult procedure, and i have some doubts... What will happens if i modify it and then i update to SFOS 30, which is about to arrive? Should i roll it back first?

campeon ( 2018-10-28 01:58:22 +0300 )edit

@campeon, if "it" in

What will happens if i modify it and then i update to SFOS 30, which is about to arrive?

adresses the single line change in /opt/alien/system/script/
I don't know what exactly SailfishOS 3.0.0 will bring, but supposedly (as usual on SFOS updates) nothing "happens". At worst, android_storage is not mounted automatically anymore, but can be mounted manually at the command line. So, if you want to revert something, you can do it anytime after an SFOS upgrade.
~~Furthermore the RPMs of mount-sdcard and crypto-sdcard will be automatically uninstalled when upgrading to SFOS 3.0.0.~~ Edit: Recent versions don't, because they run well with SFOS3. But if you still feel uncomfortable with employing these changes, you might better leave it.

olf ( 2018-10-29 01:03:34 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2018-10-26 02:15:56 +0300

Seen: 491 times

Last updated: Oct 27 '18