Magisk
Magisk copied to clipboard
topjohnwu
Request for root directory partition support: odm (all), optics and prism (Samsung), my_* (OPPO/OnePlus), vendor_dlkm (Android 12+)
Hi - I am following on from Didgeridoohan's suggestion that i should raise a request to see if we can get Optics and Prism partitions mirrored on Samsung devices. The CSC features and the accompanying files which can activate hidden features are in these two partitions for most 2020 Samsung devices .
Can this be done? thread on xda here.......
https://forum.xda-developers.com/apps/magisk/getting-magisk-to-mirror-optics-prism-t4155533
I see these in recovery.fstab, but are there symlinks in /system to them in a booted device? Everything Magisk handles currently uses symlinks from /system.
/dev/block/bootdevice/by-name/prism /prism ext4 defaults recoveryonly
/dev/block/bootdevice/by-name/optics /optics ext4 defaults recoveryonly
@osm0sis cool. Thanks for picking this up.
AFAIK it's mounted as
/dev/block/by-name/#partition#
Apologies if super wooly as have been taking a couple of weeks time out 😂
That's not the mount point that's where it's mounted from. The question was where is the filesystem access into those, which I think I answered above; /prism and /optics, but was wondering if /system/prism or /system/optics also exist.
Everything Magisk handles currently uses symlinks from /system.
I think honestly that although it would be more work, moving away from this would be easier long term. There's loads of OEM partitions out there, each with it's fair share of bloatware, and we can't always count on a symlink existing.
I think the best solution would be to allow modifying anything in a root folder - not adding folders, not deleting or emptying root folders, but allow anything to be added. Of course, this could get tricky with root folders that are just symlinks, and modules may have to charge format, bu in the end, it would open up a lot of possibilities.
I do understand that this could be a lot of work though.
Please add bunch of 'my_*' partitions of oplus too. This is from oplus.fstab in ramdisk of Realme 7 5G(RMX2111) and many oppo/oneplus(ColorOS base)/realme devices follow this. Symlink of these partitions do not exist in /system.
#todo
my_product /mnt/vendor/my_product ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_engineering /mnt/vendor/my_engineering ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_company /mnt/vendor/my_company ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_carrier /mnt/vendor/my_carrier ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_region /mnt/vendor/my_region ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_heytap /mnt/vendor/my_heytap ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_stock /mnt/vendor/my_stock ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_preload /mnt/vendor/my_preload ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
my_manifest /mnt/vendor/my_manifest ext4 ro,barrier=1 wait,logical,first_stage_mount,avb_keys=/vendor/etc/oplus_avb.pubkey,nofail
###
/mnt/vendor/my_product /my_product none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_engineering /my_engineering none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_company /my_company none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_carrier /my_carrier none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_region /my_region none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_heytap /my_heytap none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_stock /my_stock none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_preload /my_preload none ro,bind wait,nofail,first_stage_mount,nofail
/mnt/vendor/my_manifest /my_manifest none ro,bind wait,nofail,first_stage_mount,nofail
#endif
Things get more complicated with the move to read-only by the nature of the erofs filesystem, so now even remounting partitions won't help. And taking into account the fact that more and more components are moving from the system and vendor folders to other partitions that are unreadable by Magisk, the sense of systemless becomes less, and the full potential is not used Can any of the developers answer in what priority is adding the ability to edit systemlessly system partitions other than system and vendor, for example the realme partitions that are mentioned in the previous post? Thanks
Adding new partitions is easy, but we need to make modules support them. The entry point of modules is system, all other partitions are located under system, we don't want to break this yet.
Adding new partitions is easy, but we need to make modules support them. The entry point of modules is system, all other partitions are located under system, we don't want to break this yet.
Got it, thanks for reply
Have you make system76 and system84 compatible?
On Sat, Jul 30, 2022, 5:28 AM Hryniuk1 @.***> wrote:
Adding new partitions is easy, but we need to make modules support them. The entry point of modules is system, all other partitions are located under system, we don't want to break this yet.
Got it, thanks for reply
— Reply to this email directly, view it on GitHub https://github.com/topjohnwu/Magisk/issues/3338#issuecomment-1200123856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWIIQLZIEQOXOGYKTQGPBG3VWTYUVANCNFSM4SPJL7EQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I'll be intrigued to see how to set up a module for modifying /optics or /prism now that this is merged! 😯
I'll be intrigued to see how to set up a module for modifying /optics or /prism now that this is merged! 😯
I'm afraid the changes concern only these partitions. I checked, yes, the magic mount now works in /odm, but oplus-specific my_* partitions ( my_region, my_product, etc. ) don't work. I guess the same goes for /prism, /optics .
I hope it's just that I just don't know how to mount the missing partitions
We only allow magic-mounting some standard partitions from AOSP. my_*, /prism and /optics are OEM-specific partitions, and we would not support them. /cache, /persist , etc., generally do not worth supporting?
We internally discussed mounting more partitions dynamically, but it's hard to determine which should be supported. We lack the criteria. Mounting arbitrary partitions is too dangerous (say, mounting /dev, and /proc will break the whole system).
Why not (pardon me if this isn't feasible) operate on a list of non allowed instead of allowed partitions? OEMs love stuffing bloatware in OEM specific partitions, after all.
Yep I gotta agree with Androidacy here. A blacklist seems like the better option to protect the obvious core critical Android root directories.
Then if module users/devs want to f around and find out with different OEM partitions then they should be allowed to.
There are no doubt a lot of use cases for OEM partition mods and it seems arbitrarily restrictive to not allow that. Also, this unfortunately means the currently merged solution doesn't actually fully close this feature request.
Ok, we will revert the current support of extra partitions, since we definitely need a new API to mount more partitions.
That sounds like a passive aggressive move. You could just iterate on what you've got.
That's your subjective point. We internally discussed it. We raised multiple solutions for it and finally stuck to hardcoding some partitions. But you guys are not accepting it, so we must move to our Plan B: redesigning a new API. However, the stable release is coming, so we must revert it because hardcoding partition names break the semantic of /system (see https://github.com/topjohnwu/Magisk/pull/6682#issuecomment-1453932333).
im just going to add more paths like "/india" and "/my_bigball" which some really useful modules look for files to modify/replace in that are usualy on "standard" paths on most devices. locking it down to just "standard" paths without realising oems/vendors are working outside the "rules/standard" is myopic....
at best...
it could be viewed as punishing users for the choices of oems/vendors
last time i checked, magisk wasnt for that....
That's your subjective point. We internally discussed it. We raised multiple solutions for it and finally stuck to hardcoding some partitions. But you guys are not accepting it, so we must move to our Plan B: redesigning a new API. However, the stable release is coming, so we must revert it because hardcoding partition names break the semantic of
/system(see #6682 (comment)).
Fair enough given the technical details, however I hope you can see why this initially read as a knee-jerk reaction from yourself. Thank you for explaining further. I'll expand the title back to encompass the previous request. Shall we reopen the overlay issue as well?
Fair enough given the technical details, however I hope you can see why this initially read as a knee-jerk reaction from yourself. Thank you for explaining further. I'll expand the title back to encompass the previous request. Shall we reopen the overlay issue as well?
And for clarity, sorry, my more pointed lines of commentary (starting from "locking it down...") werent directed at you, dear man....but for the at times rude and obstructionist folk who seem to needlessly flex while defending/protecting their precious. I often wonder why topjohnwu couldnt have cast a wider net for people to steward magisk onward...my primary vote would have been for yourself to be on the board...
Adrian Miller (aka 73sydney)
Please note all opinions I'm expressing are my own and not Androidacy's, nor should they be reflected as such
At times, the contributors on this repo have been extremely toxic, rude, and altogether not community friendly. I will name no names.
Magisk has a habit of taking the stance of "if you have OEM X or do Y, you're on your own", which is not the attitude that suits a community funded and oriented project, especially one as large and far reaching as magisk is. Magisk has hundreds of millions of users, decisions and statements made here have far reaching consequences.
That is not to belittle magisk or it's contributions to the community - magisk in and of itself is an amazing feat worthy of every commendation I can think of.
But as seen here even if unintentionally, magisk contributors can come across as very brash and defensive quite often. And as certain team members on our end have learned, that has a negative community reaction 😉
Thanks for attending my Ted talk.
🤔We have been working on this feature request for three months after many trials and errors. And just because we didn't 100% satisfy the community, we became "rude", "toxic", "obstructionist", and "not community friendly". Personally, that's hurtful. I am afraid of this community now. I will keep away from implementing new feature requests and just work on bug fixes and features not requested by the community. Luckily, most feature requests are done and this seems to be the only "big" one.
No worries, it's just my personal complaints, and I will hide this comment myself. 😉
Locked this issue because it's becoming off-topic.
@osm0sis
Shall we reopen the overlay issue as well?
We are not reverting the whole commit. So overlay will still be kept compatible with magic-mount.