Maybe someone can try symlink with the SD name. It might work.
Just another (at least ‘internally filed’) bug/regression since 2 releases!
Without any pointer if it may get resolved or left in this state for another x number of releases or never and to be seen as the default (again! which would be bad, imho).
These are plain text files, you should be able to sed them to a working form.
In the meantime, you can do:
devel-su ln -s /run/media/nemo/YouCardID /run/media/nemo/YourPrettyName
nemo or defaultuser, depending on your installation.
However, this is lost on reboot.
Has anybody written a unit file?
Yeah, I’ve been thinking about opening the playlists in Mousepad and do a "Search for ‘64Gb_Xtra’ Replace with ‘76ad5f1-aae7-4c5a-ba0b-5dd99a1a9c0c’ ", and then copy them over to the phone again. But, no. I’m thinking that as long as I don’t understand why the SD card changed name, it might happen again, then I’ll have to do a ‘Search for - Replace with’ in the playlists again. That seems silly. A better solution is to be able to rename the SD card.
Sorry, I think there is no better advice than the ones peterleinchen and nephros have provided; specifically do contribute to the extant bug report (at least writing, “I am affected too and also want this to be fixed.”) instead of continuing to discuss this duplicate here.
I made a symbolic link in home directory (using File Browser), with name ‘SD-Card’ and target /run/media/defaultuser . Clicking there, I come first to an entry ‘0123-4567’, which is the SD card. Clicking on ‘0123-4567’ leads me to the content of the SD card. One click more to access the SD card, but this doesn’t disappear on reboot.
edit: ‘0123-4567’ is not a placeholder that I wrote, this is really there! I think, the real name or number of the SD card is kind of replaced to this name by SFOS.
Right. But this is for future “playlists”. The old “playlists” have a path like “/run/media/nemo/YourPrettyName”, AFAIK…
Yes, there are differences to old or updated system with username ‘nemo’. The observations mentioned above I made on fresh flashed SFOS 4.3.0.12 . Before flashing (continuously updated since 3.3) the username remains ‘nemo’ and some paths remain ‘old style’. After flashing I saw some changes. With fresh flashing there occur a lot of changes.
Didn’t mean that issue. If you have the songs (or whatever) pointing ot “/run/media/[nemo|defaultuser]/YourPrettyName/Music/Songs”, it doen’t help to have a link “/home/[nemo|defaultuser]/mySDCard” (or alike). But, it’s up to Jolla to fix it…
This part of the path what you named ‘YourPrettyName’ , if you look with file Browser what there is really displayed, and insert this into the path, doesn’t it work then?
This ‘0123-4567’ I wrote before is not out of my fantasy, this is what File Browser really displays here if I look into ‘/run/media/’ (why ever).
I want to clear this for the reason, that not a misunderstanding occurs.
My working link is in ‘/home/defaultuser/’, points to ‘/run/media/defaultuser/’ and is named ‘SD-Card’. And this works. If I tap on this link in File Browser, the folder ‘/run/media/defaultuser/’ opens and the visible content of the folder is ‘0123-4567’. Tapping there, accesses the content of the SD-card. I did so with File Browser to open mp4, mp3 and jpeg files to play videos, music or display images.
Before I also tried to make a symlink that points direct to ‘/run/media/defaultuser/0123-4567/’ to avoid an extra tap, but this never worked.
Can it be, that SFOS always overwrites prettynames of SD cards with 0123-4567 ?
Where was your SD card formatted? Did you use SFOS to do that?
0123-4567
looks very much like a weird FAT volume ID (the FAT32 filesystem cannot do proper long UUIDs, just this). This ID is set by the application which formats the fat filesystem (or something like fatlabel
on Linux).
I wouldn’t put it beyond Jolla to choose such an exceedingly uninspired default (cough defaultuser
cough) for new filesystems, but to me it sounds more like something done during mass-producing and perhaps cloning SD cards.
Just as an example, here’s how to get a device UUID of 1234-5678:
dd if=/dev/zero of=/tmp/fat bs=1k count=$((1024 *16))
mkfs.vfat /tmp/fat
fatlabel -i /tmp/fat 12345678
losetup -f /tmp/fat
ls -l /dev/disk/by-uuid/
lrwxrwxrwx 1 root root 11 Dec 15 17:41 1234-5678 -> ../../loop0
I might not be following you.
On the commandline, as nemo, in home, which is “/home/nemo” on my X, I did (for testing):
ln -s /run/media/nemo/5C41-ECC0 SD-card
In the File Browser, tapping on “SD-card”, goes to the SD card and I get the listing of the content, tapped just once.
If you do (as root):
blkid /dev/mmcblk1p1
You should get something like:
/dev/mmcblk1p1: LABEL_FATBOOT=“AMTMXG_01” LABEL=“AMTMXG_01” UUID=“5C41-ECC0” TYPE=“vfat”
“AMTMXG_01” is my “YourPrettyName”, not substituted.
My SD-card is directly out of the box into the phone. I did nothing before plugging it into the phone. I did it always in this way with many cards and many old and new installations of SFOS, and it always worked and still working without any issues.
Then SFOS did not set the weird Volume-ID, the manufacturer did.
Therefore, no.
Here’s the (part) result of running blkid on my phone -
/dev/mmcblk1p1: LABEL=“Jolla_64GB” UUID=“c12a0062-1aa7-4691-88e0-2392f23551fa” TYPE=“ext4” PARTLABEL=“Jolla_sdcard” PARTUUID=“b9af30a2-67cc-4361-b502-0f8537295df3”
I formatted the card on the phone, then took it out to add all my music to it but all other functions have been done on the phone so it’s down to SFOS to ‘adjust’ the name.
I think it’s time to take the advice from @olf as per the text below and add any useful contributions to the other thread and abandon this one.
If you are still able to edit your first post, you might add the link to the mentioned bug report there directly?
It doesn’t appear that I can edit it but if I click on the down arrow it shows ‘Popular Links’ and that points to the bug report. Hopefully that’s enough to encourage people to go to that topic rather than this one. One can but hope!
Sorry for cross posting here, but this topic show high on googe results for relevant keyword (Sailfish os mount by label).
So here is the solution I am using in file /etc/udev/rules.d/99-udisknames.rules
:
SUBSYSTEM=="block", ENV{PARTNAME}!="", ENV{UDISKS_NAME}="$env{PARTNAME}"
This forces UDEV to use the partition name instead of the UUID if one happens to be available for all block devices (USB-C sticks, SD cards, etc.)
Thanks Dr Yak for this solution - worked for me on an xz2c with 126Gb card with 2 partitions. I keep all my flac files on one and the rest on the other so that if I want to personalize an alarm or ringtone I don’t have to scroll through a million songs. A browse to file option would be even better.