SailfishOS support

[M1cha]

ramdisk:

init:DATA_PARTITION=/dev/mmcblk0p20
init:   if [ -f $lun ]; then echo /dev/mmcblk0 > $lun; fi

rootfs:

lib/systemd/system/system.mount:What=/dev/mmcblk0p13
lib/systemd/system/firmware.mount:What=/dev/mmcblk0p1
lib/systemd/system/persist.mount:What=/dev/mmcblk0p14
usr/sbin/clear-device:ROOT=$(grep "/dev/mmc.* / " /proc/mounts | cut -d " " -f1)
etc/fsstorage.d/sd-storage-conf.xml:<storage name="media" blockdev="/dev/mmcblk1" description="SD Card" removable="true"></storage>
init-debug: if [ -f $lun ]; then echo /dev/mmcblk0 > $lun; fi

[z3ntu]

Jolla has a kind of bug tracker, maybe they can improve the situation... https://together.jolla.com/questions/

[M1cha]

but do all devices use the latest version of sailfishOS? If 90% of all people would be using old ROM's like in Android that wouldn't actually change much.

[z3ntu]

I believe some part of SailfishOS is updated from upstream where as the "hardware abstraction layer" gets updated by the community porters. (But I neither know where the "absolute paths" for the mounts are or anything else :/ )
Maybe you/I could ask mal- on #fairphone-sailfish on freenode.

[z3ntu]

[16:04] mal-: Is it possible that you change contents in /lib/systemd/system/system.mount and device mount paths in the ramdisk? It would help if they would use the /dev/block/platform/msm_sdcc.1/by-name/ paths instead of absolute device paths. For the reason see here: #58
[16:07] z3ntu: /dev/block/platform/msm_sdcc.1/by-name/ paths won't work for some reason
[16:17] mal-: Is it possible to store these paths (still your absolute ones) in the ramdisk?
[16:27] z3ntu: not quite sure what you are trying to do
[16:30] #58 (comment)
[16:31] could you explain why those are needed?
[16:32] efidroid (multiboot solution) changes the paths in the ramdisk that it doesn't have to alter the system. and that's not possible as some paths are stored in the rootfs
[16:33] just wondering how different that is compared to multirom
[16:33] multirom works with sailfish
[16:34] I don't know the inner workings of both very well so I can't really answer you that. I just know that efidroid uses intels uefi implementation (=edk2)
[16:38] and I think multirom patches stuff permanently (and is pretty error prone as I have noticed the last 6 months or so)

[M1cha]

the path itself isn't the problem. The problem is that they're storing these path outside the ramdisk which means that efidroid would have to permanently alter the system.

[z3ntu]

I just tried booting with the stock sailfish os install and it instantly reboots.
I have a last_kmsg but unfortunately it's 99.9% unreadable... I don't even attach it as it's just a random pile of garbage...
EDIT: I have a 40% readable one :D lastkmsg.txt

[profOnno]

Here is how my mounts look in a gist for android and sailfish.
The HADKit has some info in chapter 5.3 on this if I am correct.

I just did my first OASP for FP2 this weekend, flashed it and it worked. Now I'm looking to setup the chain for sailfish. There is no docker container for this right now?

[z3ntu]

If I may ask, what's a "OASP"?

[profOnno]

Oops, ment AOSP (Android Open Source Project).

[z3ntu]

What device tree & manifest did you use for that? Or do you mean that you compiled "FP Open"?

[profOnno]

I assumed the "FP Open" to be the same as AOSP, with some extra sugar.

[z3ntu]

Well they use to some extent customized sources to make Android compile which are based on the codeaurora sources.

[profOnno]

Is this helpful?

Some    devices have /dev/block/bootdevice/by-name/ as /dev/block structure  in
CM in which case you need to add the following line to the end of  the
998-droid-system.rules file in the last link:

ENV{ID_PART_ENTRY_SCHEME}=="gpt",    ENV{ID_PART_ENTRY_NAME}=="?*",  
IMPORT{program}="/bin/sh    /lib/udev/platform-device $env{DEVPATH}",   
  SYMLINK+="block/bootdevice/by-name/$env{ID_PART_ENTRY_NAME}"

hadk-faq-v2 @ simcard not detected

[feherneoh]

At least one partition should have an entry on ramdisk, and the ones on /system or any other partition can be replaced without being actually modified by bindmounting another file on top of them

[z3ntu]

First: All files that contain mmcbl in the rootfs:

lib/systemd/system/persist.mount:What=/dev/mmcblk0p14
lib/systemd/system/persist.mount:# mount ext4 /dev/mmcblk0p14 /persist nosuid nodev barrier=1
lib/systemd/system/system.mount:What=/dev/mmcblk0p13
lib/systemd/system/system.mount:# /dev/mmcblk0p13 /system ext4 ro,barrier=1,discard wait
lib/systemd/system/firmware.mount:What=/dev/mmcblk0p1
lib/systemd/system/firmware.mount:# mount vfat /dev/mmcblk0p1 /firmware ro context=u:object_r:firmware_file:s0,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337
lib/udev/rules.d/60-persistent-storage.rules:KERNEL=="mmcblk[0-9]", SUBSYSTEMS=="mmc", ATTRS{name}=="?", ATTRS{serial}=="?", ENV{ID_NAME}="$attr{name}", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/mmc-$env{ID_NAME}$env{ID_SERIAL}"
lib/udev/rules.d/60-persistent-storage.rules:KERNEL=="mmcblk[0-9]p[0-9]", ENV{ID_NAME}=="?", ENV{ID_SERIAL}=="?", SYMLINK+="disk/by-id/mmc-$env{ID_NAME}$env{ID_SERIAL}-part%n"
lib/udev/rules.d/90-mount-sd.rules:SUBSYSTEM=="block", KERNEL=="mmcblk1*", ACTION=="add", MODE="0660", TAG+="systemd", ENV{SYSTEMD_WANTS}="mount-sd@%k.service", ENV{SYSTEMD_USER_WANTS}="tracker-miner-fs.service tracker-store.service"
etc/fsstorage.d/sd-storage-conf.xml:
init-debug: if [ -f $lun ]; then echo /dev/mmcblk0 > $lun; fi
init-debug: if [ -f $lun ]; then echo /dev/mmcblk0 > $lun; fi
var/lib/flash-partition/device-info:PART_REAL_1="mmcblk0p8"
Binary file boot/update-binary matches
Binary file usr/lib/libgio-2.0.so.0.3800.2 matches
Binary file usr/lib/dsme/runlevel.so matches
Binary file usr/libexec/droid-hybris/system/bin/updater matches
usr/sbin/mount-sd.sh:# mkfs.vfat /dev/mmcblk1 then repartitioning to create an empty ext2 partition
Binary file usr/sbin/usb_moded matches

Second: So I wanna try to manually modify the sailfish files manually to just get it booting.
I believe I have to change in the init file:

init:DATA_PARTITION=/dev/mmcblk0p20

Change that to something like (I don't know the mount point on 2nd roms right now) DATA_PARTITION=/sdcard/multiboot/SailfishOS/data/

But I am not sure what I should do with the persist/firmware partition (I think the system.mount file can be made about the same as the DATA_PARTITION variable)

[iamsubhranil]

You can delete both the system.mount files from rootfs and add the mount in init. For MultiROM just deleting the files does the work as mr automatically mounts the partitions for it. I guess the same could be done for any other partitions on the way.

[M1cha]

modifying the rootfs would be a permanent modification - that's why we don't do that.

[z3ntu]

I actually still think it's better than not supporting Sailfish (or other systems). Could be a popup asking if permanent modifications should be done...?

[M1cha]

I'm sure there is a way to do this without permanent modifications - I just didn't invest much time into this yet as we still have more important problems to fix.

[iamsubhranil]

I can't see how it could be done without permanent modifications. systemd will mount the actual system as long as system.mount files stayed.

[feherneoh]

I can't see why everybody ignores my ideas...
bindmount works on files too, not only on folders, so if efidroid can inject a script or anything into the bootchain then right after mounting the partition set in the ramdisk (that we can obviously override before mounting it) we can bindmount modified files over the files containing the original partition paths.
For bind-mounted partitions, we can bind-mount over the binary that mounts them to be able to add bind support.

[M1cha]

@feherneoh nobody is ignoring you, I just didn't look into sailfish support at all yet.
Also, can you post a simple example/instructions for file-based bind mounts? I can't find any info about it and trying myself gives me 'Not a directory' errors.

[M1cha]

@feherneoh got it. I have to create an (empty) file first. works fine.

[feherneoh]

Glad it works, no idea where I saw it, but it was used to fake the kernel cmdline by mounting a file over /proc/cmdline

[z3ntu]

So that means we can have SailfishOS support without patching files? 😊