fails on SailfishOS 4.0 #115
Comments
|
Thank you very much @fuchsmich for your report. While the journal entries clearly show, that the crypto-sdcard's systemd units for mounting stumble across an incorrectly unescaped (as per systemd-escape) device path (all
The same device appears twice:
Well, it needed many weeks of research to discover the workaround in pull request #2 per systemd-escape in the udev-rules. Yes, something must have been changed (and the systemd package was altered and updated from v225 to v238 in SFOS 4.0.1: search for I will try to upgrade one of my testing devices soon after SFOS 4.0.1 has reached GA (general availability) status and take a look at it, then. |
|
How can I help you? Should I run any commands? |
|
Well, IMO primarily you should try to help yourself, as nobody else seem to have run into this issue yet, presumably because noone of the ~20 crypto-sdcard users has subscribed the "Early Access (EA)" channel of SFOS with their production device. As some things seem to run O.K., I would first follow that route: It may provide a workaround to get things going again, plus some analyses may provide more insights for a proper fix, even if not primarily pursuing this.
|
|
First of all, it's always a joy reading your detailed and well written posts! Second: 4.0.1 isn't EA anymore since yesterday. ;) I switched from X to XA2, so it happend, that I flashed 4.0.1 to my phone yesterday, after the touchscreen had some problems. Third: I wrote non-template systemd units replacing ...but I'm afraid my system is a mess now, as I left |
Good! Thank you for the command line outputs. They are helpful, even though a bit hard to interpret, because the effects of the units you manually fixed and the original ones failing are displayed. I perceived the first Output 2 displays the "usual" mix of correctly and incorrectly escaped paths, either (see suffix) to a Outputs 3, 4 and 5 show, that you have everything up and running, although by your patched units, plus by manually starting them. |
|
I would be the second one to run into that issue :) |
I am just upgrading my new testing device (an XA2+) to SFOS 4.0.1, because my old one dies (and became useless, anyway: it is a Jolla 1). It does not have an encrypted SD-card in it, yet (but I have some SD-cards around), so I may start my own efforts to analyse this issue this weekend.
There are no "keys with password": You just input entropy, which is hashed then. The hash is then used as a "key value", which must match one saved in a "key slot" to unlock the real cryptographic key. So if your "key-file" does not contain newline characters and also only characters which can be entered per keyboard, you can just as well input its content at the SFOS GUI to unlock your encrypted partition. |
|
Easier workaround to manually access the LUKS encrypted partitions (used with crypto-sdcard) at the GUI. Side note: For details, see LUKS key management. Can someone please check, that this works fine? |
|
Looking for possibly relevant changes between Systemd 225 and 238, I found introduced in v236, "If a udev device has a SYSTEMD_WANTS= ...", and (more unlikely to cause this issue) in v233, "When units are about to be started ...". At least something worth investigating. Edit: |
|
I reinstalled crypto-sdcard now. Full output: https://gist.github.com/fuchsmich/9aa70436de48a7bb811b13009cdb5b4c |
|
Thank you, this is interesting: All looks perfectly fine on And there is nothing to observe with
Still puzzled, but I think we're slowly encircling the core of this issue. |
|
Oh, from your third posting, in its second command line output: Is that still there? That seems to have successfully mounted the unlocked partition ( Edit: Apparently not, see last listing in your latest post, above. |
AFAIR, back then I unlocked the sd manually before I ran the commands in my third post. |
|
Well, first (yesterday) I could not really decide to either do some research (primarily reading documentation and searching the web) to gather ideas for reasons and fixes, or to perform some thorough, bottom-up and step-by-step analysis, which is tedious and also involves reading a lot of documentation. Ultimately I slipped into trying a few ideas ("educated guesses"), while also adopting / adapting the recent changes from mount-sdcard. Please download and install the correct variant of crypto-sdcard 1.3.4-1.sfos*.noarch.rpm (e.g., for all Xperias@SFOS≥3.4.0) to check, if it makes a difference for its (automatic) starting and mounting behaviour on SFOS 4.0.1:
|
Olf0
added
open question(s)
No problem, I know now how to test your mods and restore my temporary solution. In my case 1.3.4 doens't work. luks device won't be opened. |
|
:-( Well, my little analysis so far:
|
|
I'm quite sure this dead nonesense-device gets created by the systemd polling it incorrectly. |
This is what I meant with:
|
Olf0
added
help wanted
|
@fuchsmich, can you please try (on SFOS 4.0.1 with crypto-sdcard 1.3.4 installed): Source of this idea: This Ubuntu bug matches exactly this issue and provides this solution (hard quoting of Edit / P.S.: As usual, when knowing which search terms to use (because one has finally found something relevant), more "hits" are easy to achieve, e.g. in the Systemd issue 7109 and the ev3dev issue 1433! |
Revert [commit \#2bf46d9](2bf46d9), because `OPTIONS+="string_escape=none"` should only affect "*strings used for device naming*" [per **udev** documentation](https://www.freedesktop.org/software/systemd/man/udev.html#string_escape=none%7Creplace), e.g. strings used for setting `NAME` and `SYMLINK`.<br /> Rationale: 1. The strings *crypto-sdcard* generates and uses in [96-cryptosd.rules](https://github.com/Olf0/crypto-sdcard/blob/master/udev/rules.d/96-cryptosd.rules) for device naming should always be free of escape sequences and other "potentially dangerous" characters. If some flaw causes this not to be true anymore (e.g., see issue #115), it is fine that *udev* might filter device strings (although this mechanism makes debugging such flaws harder). 1. It did not alleviate the breakage SFOS 4.0.1. brought (issue #115). This also might prove that `string_escape=none` is not applicable to evaluating "`%c`" or inserting a string into `ENV{SYSTEMD_WANTS}=""` / `ENV{SYSTEMD_USER_WANTS}=""` statements, because the strings generated by `systemd-escape` for *crypto-sdcard* contain a lot of C-style escape sequences (or they are not considered "dangerous"). Because OTOH manually calling (at the command line) instanciated Systemd units with pre-escaped instance names works (?does it still on SFOS 4.0.1?), it is apparently the call interface proper which filters (or just misinterprets, e.g. in one of its many automatic detections) the unit string (?or just the instance name?) when handing over the content of a `ENV{SYSTEMD_WANTS}=""` / `ENV{SYSTEMD_USER_WANTS}=""` statement.
Should resolve issue #115, see #115 (comment)
Analysis so farSystemd explicitly calls its function |
|
Sorry, still same result with udev rules in 1.4 |
|
@fuchsmich, @erikderzweite et al, please check crypto-sdcard 1.4.2-1.sfos401regular on your devices with SailfishOS 4.0.1. It is working fine for me. |
Olf0
added
enhancement
|
Hi @Olf0! I've updated crypto-sdcard to last version released at OpenRepos (v1.4.2-1) but it doesn't work for me on my XA2 with SailfishOS 4.0.1: sd-card doesn't mount automatically.
What am I doing wrong? |
|
Thus please update to crypto-sdcard 1.4.3-1.sfos401regular and debug:
|
|
@Olf0 I guess you wanted to address @carmenfdezb :) Sorry, for not responding muhc lately. I got a lot of work these days, but I'm still following you. Yesterday I had trouble re-enabling my workaround. No idea why it broke first and how I fixed it in the end. But then again there are a lot of frustrating things happening on my XA2... (Wifi, GPS, Camera, Calls, Bluetooth, ...) |
Yes! Thanks for the notice. Rectified now.
That's absolutely O.K., though feedback might be helpful (for me, and maybe for @carmenfdezb, too).
Huh!?! |
|
@carmenfdezb, apologies for not paying enough attention to who actually wrote, in my first reply to your comment. I was so absorbed by deciphering the convoluted journal output, that I completely missed it was not fuchsmich posting, because I hoped for a reply from him and up to that point he was the only one active in this thread (aside the issue confirmation by erikderzweite). Nevertheless, I do need more information.
|
|
Hi @olf, sorry for the late answer. Let's see if we can know what go wrong.
|
|
@fuchsmich, @carmenfdezb, @erikderzweite, please download and update crypto-sdcard on your device with SFOS 4.0.1 to v1.5.0 (e.g., per
Background:
|
|
Hi @carmenfdezb,
This is looking good! P.S.: I hope that Jolla's LUKS-mounting mechanisms were not altered with SFOS 4 and now subtly interfere. |
Done :)
|
Yes, no problem with unlocking and mounting sdcard manually, but it doesn't do automatically |
|
@carmenfdezb, thank you very much for your feedback. Sorry, it has been a busy week, I just managed to take a closer look at it right now. Side note: You do not have to use my command suggestions 1:1, if you have ideas to vary them sensibly. Though if they are helpful in the provided form, do use them as provided (i.e., "1:1").
It also makes sense to return to (i.e., rerun) steps 1 and / or 2 after starting crypto-sdcard manually (and successfully), because sometimes the journal does reveal more than the output of steps 3 and 4, especially by looking at context per step 2. Again, we are searching for differences between failing and successful starts of 'crypto-sdcard's* unlocking and mounting units. |
|
@carmenfdezb, this (older) comment at git.sailfishos.org/mer-core/udisks2/ made me think of a very basic "check and balance" (because it hints that udev may have issues with auto-detecting LUKS headers directly on mmcblk1, i.e. not on a partition (e.g., mmcblk1p1)): Do I assume correctly, that crypto-sdcard was working fine on your device, before you upgraded to SFOS 4 (as for @fuchsmich)? |
Exactly, it worked fine before I upgraded to SFOS4 and I did't perform the initial installation and configuration of crypto-sdcard on SFOS 4 |
|
Thank you for your feedback, @carmenfdezb. The issue we are hitting now (which has become visible due to eliminating the first issue), seems to be SFOS 4 specific (-> "phase 3", below). After I while I also started to structurally and generally (i.e., not SFOS 4 specific) enhance crypto-sdcard ("phase 2"), concurrently to "phase 1" because I was gaining a much better understanding by re-reading various Systemd, udev and udisks documentation, guides and examples, especially how these three components interact. This result(ed|s) in the crypto-sdcard releases v1.4.0 to v1.6.0. So I started "phase 3": Thoroughly analysing what is going on by
For that I prepared an old USB "thumb drive" with an unencrypted, a LUKS-encrypted and a "plain"-encrypted partition, with which I can test crypto-sdcard on my XperiaXA2+@SFOS401 and XperiaX@SFOS321 (the USB port of the Jolla1 does not support USB-OTG) much more easily: Plugging / unplugging should have the same effect as rebooting, and both can be tested with it. If any SFOS 4 specific progress is made, I will either denote that here or release a new version, which states that in its release notes. As a reminder, two easy routes allow you to use encrypted (partitions on) SD-cards / USB mass storage with SFOS 4 now, without uninstalling crypto-sdcard:
|
|
Sorry folks, I became so frustrated with this in early April (due to the lack of progress, after fixing two blocker bugs for SFOS4), that I decided to first refactor and vastly enhance the Udev rule file and write the Polkit rule file anew. As a consequence crypto-sdcard was initially completely broken after that, which did not alleviate my mood at all. So I prepared a release v1.7.2 for all supported SFOS releases, this is the one for SFOS 4. |
|
Meanwhile I released crypto-sdcard 1.7.2 at Openrepos.net, so you can install it from there via Storeman. Please report success or the lack of it here, including your phone model, SailfishOS 4.x.y release, if "LUKS"- or "plain"-encrypted, which local device (name only) was used, and what kind of mass storage this physically is. |
You may notice that the device is used directly without a partition table. But I’m not really sure if my problem is the same or even related to what is discussed in this thread. At the same time I’m not convinced it’s a entirely seperate thing. If you think so please let me know and I will open another issue or go looking for a solution upstream (you’ll understand in a second). Even with earlier versions of crypto-sdcard I could manually start it - after I fixed a failed dependency after every boot: Fixing this is easy: I don’t quite know how to fix the "unknown filesystem type 'functionfs'" since it’s compiled into the kernel and my knowledge on how/if AOSP and/or Sailfish use kernel modules is non-existant. So I’m very sorry if this is an unrelated issue. |
|
@kivoli, thank you very much for this report! I will try to analyse, if this is part of the original issue (which already turned out to be comprised of multiple, compounded / layered issues) or not. I cannot tell at the moment and my gut feeling tells me "Yes" and "No" at the same time, just as yours seems to. If I understand correctly, you have not tested an encrypted partition (instead of the whole device / SD-card) with crypto-sdcard 1.7.2, yet? |
No. Unless I somehow find a fix for the “functionfs” error message or an indication that these two (error and partitioning) are somehow related (seems very unlikely) I do not see the point of doing that. |
|
test notes: sadly is is also not auto-unlocking nor auto-mounting when I make a luks v1 partition on the SD card [root@Xperia10II-DualSIM ~]# rpm -q crypto-sdcard
crypto-sdcard-1.7.2-1.sfos401regular.noarch
[root@Xperia10II-DualSIM ~]# lsblk /dev/mmcblk1
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1 179:64 0 29.7G 0 disk
└─mmcblk1p1 179:65 0 29.7G 0 part
[root@Xperia10II-DualSIM ~]# cryptsetup luksDump /dev/mmcblk1p1 | head -n 6
LUKS header information for /dev/mmcblk1p1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256But I can unlock it just fine with side note: dev-mtp.mount failing might be a red herring because already before installing crypto-sdcard I got these failed units on boot [root@Xperia10II-DualSIM ~]# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● dev-mtp.mount loaded failed failed FFS mount
● product.mount loaded failed failed Droid mount for /product
● system.mount loaded failed failed Droid mount for /system
● lxc@multi-user.service loaded failed failed LXC Container: multi-user
● quota@home.service loaded failed failed Enable quota and run quotacheck for home
● user@0.service loaded failed failed User Manager for UID 0
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
6 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'. |
In journalctl I find:
also I found this:
my conclusion is, there is sth wrong in the udev-rule creating the
cryptosd-luks@.service. Maybe the char escaping in newer systemd has changed.The text was updated successfully, but these errors were encountered: