II. For me a getting complete logs to diagnose looks more easy and logic for start.
You wrote: You can edit /etc/systemd/journalctl.conf to make Storage=Persistent and have more backlog.
You mean that need to change this file?
cat /data/.stowaways/sailfishos/etc/systemd/journald.conf
[Journal]
Storage=volatile
Changed to test
# sed -i ‘s/volatile/persistent/’ /data/.stowaways/sailfishos/etc/systemd/journald.conf
Sorry for not replying earlier. Some links to block devices fail to create and from there the rest of the mounts fail. That would explain most of the following errors.
So there is something different with toco in this particular case. Maybe you can find what file to modify until I get the chance to inspect my device.
Don’t worry. I will try to find what file need to modify. As I understood kernel from tucana is suitable for toco. Or not? Maybe, better take kernel for toco, and modify this with your patches?
Yeah, kernel goes prettty far if it boots and you have telenet. I was thinking that these are woryying: systemd-udevd[972]: Process '/bin/ln -s /dev/block/sda1 /dev/block/platform/soc/1d84000.ufshc/by-num/p1' failed with exit code 1.
Indeed that might be a kernel difference. As in, different stirage hardware is used. Do you have something equivalent in dev/block/platform/soc?
Finding a toco kernel that already builds for a Lineage 17.1 rom and applying the defconfig patches and the ramfs one would be another way forward, yes. Packaging it into a hybris boot would require partial steps from hadk
In the second post here I say “probably it would be better to use the lineage xiaomi sm6150 kernel if there’s a lineage 17.1 version and patch it for hybris with my config changes” and give some context.
That route from Xiaomi Open Source is much longer and prone to errors and you should be able now to find a kernel with all the modules and mabve even some security patches backported.
Ok, so you have many options;)
But before building another kernel you could do some more checks. I have extracted a similar journal from my device: https://paste.fo/raw/317c5c587159
It seems that udevd ln -s is also failing, so that is not the problem.
However, mine does not say this after “mount for /vendor”
mount: /vendor: wrong fs type, bad option, bad superblock on /dev/sda24, missing codepage or helper program, or other error.
If indeed you don’t have the /dev/sda24 at all that would be a problem.
Maybe you can figure out the system / vendor and other partitions that fail to mount from /dev/block/platform/soc/1d84000.ufshc/by-name ? If you do, you would need to change the systemd mount files
Ah, you’re right, the by-name are defined by me in hybris-boot
I think I determined them from running mount in Android shell… which means you’d have to flash one of the android boot.img s you had before and boot into that. Might require re-formatting of data afterwords.
Of course you could just try to mount each /dev/block/sd* by hand and see which one looks like a system or vendor partition (or the other missing ones…)
To get that mapping, you should flash and boot an image of your Android base and execute adb shell on
your host and something like this: ls -l /dev/block/platform/*/by-name/ on your device.
To get the correct path you must find Android’s fstab in device repository or in device itself and get by-name path like: block/bootdevice/by-name/userdata, ls -l /dev/block/platform/*/*/by-name/ or block/platform/*/by-name/userdata from it.
or better to use patched.img boot with root?
Steps for flashing are correct?
'# fastboot devices
'# fastboot flash boot magisk_patched-27000_XxPuq.img
'# fastboot reboot
Sure, use the root one. Maybe not even flash, fastboot boot it. But that still may encrypt your /data…
When you get a hold of what the system or vendor partions are, we could fix that too from the on-device fstab
Oops. You have Dynamic Partitions…are you sure your device came like this 4-5 years ago? That’s a newer thing. There might have been custom roms that added that later, though.
That was actually visible from lsblk. And it explainds missing /dev/sda24 (as it got merged into sda23 probably, for more space).
Need to think more if we can retrofitt dynparts easily, maybe you have instructions how to revert if they were created by a custom ROM?
offline on linux computer using (official) Dynamic Partition Toolslpunpack and lpmake for which precompiled binaries are available from (unofficial) OTA Tools
offline on device from TWRP recovery with 3rd party tool super image dumper for which precompiled binaries can be downloaded from XDA super image tools
online on device via 3rd party bash script SystemRW running entirely from /data/local/tmp