yashsingh1/xdaforums huggingface dataset:
[Magisk] gnirtS:
Ive just done a fresh install (lineage 20) and installed Magisk-delta (canary) along with Deltas safety net mod which seems to work fine.

I don't seem to have access to root though.

Attempting AdAway and it complains of no root access, in a terminal emulator "su" is inaccessible or not found.

In Magisk itself i have MagiskHide enabled, Enforce SuList enabled and the relevant apps added to the list.

Below that i have Superuser Access set as "Apps and ADB".

The SuperUser tab shows no apps have requested permission. The log itself on start shows sulist add and the relvent processes. No errors.

Previous install was a Magisk 26 on Lineage 18 and it worked fine.

Any idea what settings im messing up here?
[Magisk] pndwal:
Still can't see the point... Having two partitions is for seamless delta OTA updates, and so that when these fail you still have a bootable slot ... In your case you'd need to manually swap, but you need to have both bootable first... You said

I explained why this doesn't work from factory, but seems you never managed to set up bootable images on B yet anyway... Even if you did, why do the same flashes when A isn't working?... Even if both are working people normally do flashes one slot at a time so if something fails you still have one working slot... Factory delta updates simply work in reverse fassion; inactive slot is updated and active is untouched so that update engine can revert in case of corruption...

My bad... You said flashfile.xml specifies wipe... I assumed you'd included that but forgot you hadn't...

If data had been wiped as I had assumed, if must be an altered/corrupt partition... Now seems it's likely some setting in /data. PW
[Magisk] pndwal:
Do you see Magisk Installed version in App home screen?... What do you see if you type Magisk -c in a standard terminal emulator (not termux)?...

I'm not familiar with Delta peculiarities, but these clues may help... PW
[Magisk] gnirtS:
Update, ive just found the solution by accident so i'll post here in case others need it.

My install was set to use the SD card as local, non removable storage.

By default its putting terminal,adaway etc on "external". Moving them to internal and they see root.

Looks like anything set to external storage cant see it by default.
[Magisk] J.Michael:
Were you able to run @ctcx's script?

Did it reproduce the Magisk manager app's "Ramdisk: Yes/No"?
[Magisk] Human Person:
Slot B is legitimately never boot-able, made that mistake while doing otas with Magisk on slot A on this device before. Speaking from experience the device turns into a hardbrick if I apply an ota and move slots via Magisk's official means. Seems likely a janky implementation of a/b slot.

Just flashing one slot and boot just leads to logo hang on A and bootloop on B. B will always bootloop regardless of if the flash is good or bad, the slot must be changed to A for boot to even be possible in all scenarios on this device.

What do you believe would rectify altered/corrupt partitions? Do you think it would have to do with the ddr or metadata partition? Both those partitions seem to unrelated to sensitive data, but I'm unsure
[Magisk] pndwal:
Yup... No root apps or functions work on 'adopted' storage AFAIK... PW
[Magisk] pndwal:
Maybe not... Magisk OTA method for root preservation itself was completely broken for some time... It got fixed about a year(?) ago, and works again on many A/B devices but still fails for many, eg on late builds for Pixel 6 & 7 for many users, apparently due to new Google partition digest checks on reboot (Magisk must be installed before that). The method is still not linked in Magisk doc's index and Magisk Devs have appealed to other interested Devs to investigate and submit fixes... Guess 'Patch to Inactive slot' function remains in limbo till this happens...

Not sure why you can't make B active, install a ROM normally and boot to it however... Did you ever take a stock Delta OTA without root?... That would be the definitive test, but you may have hardware, eMMC etc damage...

So is official method for fastboot flashing also broken, or does that flash dual slots also?

Not sure, but normally flashing a fastboot ROM (not necessarily flashing a recovery ROM) fixes most mods users or custom ROMs apply... There are a number of lower level partitions but TWRP etc don't access these for good reason, and unless user has messed with them, eg to change boot logo, IMEI etc, they just don't get messed up...

If dirty flashing fastboot ROM doesn't fix things I guess issue is in data... You may be able to locate issues or need to factory reset... PW
[Magisk] pndwal:
Of course stub APK is tiny and isn't supposed to be downloaded; it exists in GitHub assets for App to call online if needed for 'additional setup' etc...

@badabing2003 said:

My point is that you do have more than the stub; hidden App is stub with data populated with all the binaries in full app... If you check its size including data after hiding routine, it's much the same size as the full Magisk app used for its data. As such it does work for patching... Many get consistent good results; others get random failures to remove full app with direct install, but the patching works...

With the correct package name, PF etc should also be able to use hidden app (stub with data populated) for patching as requisite scripts etc are in fact all there AFAICS...

Not going too... @ctcx had misunderstood how Magisk derives Ramdisk status but understands now...

We have established that the method Magisk uses is correct... We just need to understand the bootloader factor. As John points out there's no script or method that can be used to poll that. 😜 PW
[Magisk] badabing2003:
I'd like to understand how that is.

If you're referring to the /data/adb/magisk folder, of course that is still there, but the user might not have granted root access to adb, hence can't be used.

Furthermore, the installed application can be of a newer version than what is in /data/adb/magisk hence probably the one that should be used to create a patch.

PF uses the package name to find the apk path, then it uses the apk to unpack it and extract the relevant components, this assuming that root approach is not available or chosen.

When you look for the app based on the package name, all you get it is the stub,

Which is smaller in size and does not have the necessary components to create a patch, of course the UI can create a patch, but where are those parts? How do I find them?

Here's an example of stub (base.apk)

redfin:/ $ cd /data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g==/
redfin:/data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g== $ ls -l
total 31
-rw-r--r-- 1 system system 28263 2023-05-07 07:49 base.apk
drwxrwx--x 3 system install 3452 2023-05-07 07:49 oat
redfin:/data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g== $ cd oat
1|redfin:/data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g==/oat $ su
redfin:/data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g==/oat # ls -l
total 3
drwxrwx--x 2 system install 3452 2023-05-07 07:49 arm64
redfin:/data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g==/oat # cd arm64/
redfin:/data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g==/oat/arm64 # ls -l
total 56
-rw-r--r-- 1 system all_a18 17296 2023-05-07 07:49 base.odex
-rw-r--r-- 1 system all_a18 36472 2023-05-07 07:49 base.vdex
redfin:/data/app/~~71xxg0Eo_kKkok5PaeAqIg==/wzuzpwh.ufnj.lql.h-1-sxuU7IzLt6febQzit-8g==/oat/arm64 #
[Magisk] xdaroot1nox:
Thank you for your reply, root for me is secondary, the main focus for me is to hide that I use an emulator. If that is achievable without root, I would very welcome such a method. But right now I do not find any solution which fits my purpouse.
[Magisk] ctcx:
Yes, I'm aware of all of that.

But my original goal with that was only to replicate what Magisk app says in the app UI, regardless of whether it's actually 100% correct under the hood or not. I was only trying to replicate what the graphic interface says in scripting form; not trying to magically "fix" the bootloader factor.

Though certainly, given this factor, and if script part really worked, it would be good idea to also echo a warning/disclaimer specifying this.

With this said, do you think you could still try that part please? I think it's innocuous enough.

Thanks again.
[Magisk] pndwal:
Sorry guys, I'd overlooked that last script and your purpose...

I've never written or run scripts AFAICR...

I've just pasted an saved the code as is in a txt editor as attached, then did this in terminal emulator:

:/ $ /storage/emulated/0/documents/test.sh
/system/bin/sh: /storage/emulated/0/documents/test.sh: can't execute: Permission denied
126|:/ $ su
:/ $ /storage/emulated/0/documents/test.sh
Permission denied
13|:/ $ :/ $ /storage/emulated/0/documents/test.sh
/system/bin/sh: :/: inaccessible or not found

... I've messed something up. 🙁... Someone please walk me through it. 🙃 PW
[Magisk] badabing2003:
You can't run it from documents

You need top copy it to /data/local/tmp

and then make it executable

chmod 755 /data/local/tmp/test.sh

then you can run it ./test.sh

Update:

Fixed the line endings, they were CRLF
[Magisk] HippoMan:
The /storage/emulated/0 filesystem is a FAT filesystem, and it doesn't offer the standard unix/linux file permissions. For that reason, the "executable" bits cannot be set for the file attributes in /storage/emulated/0, and therefore, scripts can't be run under that filesystem simply by typing their pathnames on the command line.

It doesn't matter whether or not you're running as root.

In order to run scripts in the /storage/emulated/0 filesystem, you have to run them explicitly via /system/bin/sh. In your example, this would be ...

/system/bin/sh /storage/emulated/0/documents/test.sh

If you still get an error about /system/bin/sh not being found, that's a completely different problem. /system/bin/sh is a standard executable on every Android system I have ever dealt with, and if that executable is not found, then there is something rather seriously messed up on your device.
[Magisk] J.Michael:
You shouldn't need "su" -- this is @ctcx's summary of Magisk manager app's determination of "Ramdisk: Yes/No", so should run with no privilege.

I don't understand what you did differently in the last two lines:

:/ $ /storage/emulated/0/documents/test.sh
Permission denied
13|:/ $ :/ $ /storage/emulated/0/documents/test.sh
/system/bin/sh: :/: inaccessible or not found

You can run a script from anywhere. You only need to set the execute permission if you insist on running the script as if it were an executable, i.e., by typing the name of the script as if it were a command (the way you were trying to do it).

You can also run a script by typing

source test.sh

And there is an "alias" (don't know if it's really the same mechanism, I am using "alias" as an English word) of "." to "source", so you can type

. test.sh

(Note there is a space after the period.)
[Magisk] pndwal:
Only difference in 2 tests shown was second was after su obtained... Gave more info.

Just tried that:

... Will try other suggestions as soon as I have a few minutes... Thanks for pointers! 🙂 PW
[Magisk] HippoMan:
Actually, you cannot run a script on an Android device symply by typing its pathname if it's resident on the FAT filesystem. And /storage/emulated/0 is indeed a FAT filesystem on every Android device I've ever examined.

The FAT filesystem does not offer execute-permission bits in file attributes. That's why you have to do /system/bin/sh /storage/emulated/0/[WHATEVER] in order to run scripts on that FAT filesystem.

But yes, /data/tmp works, because the /data filesystem (and most other filesystems on Android other than /storage/emulated) use ext4 ( I think), and that filesystem is "standard" for linux and indeed allows execute permission attributes on files. Therefore, if you do a chmod +x filename under /data and most other Android filesystems, you will indeed then be able to run the filename script or progam simply by typing its pathname on the command line.

PS: if you don't believe me about the lack of execute bits in file attributes on a FAT filesystem, try the following

cd /storage/emulated/0
echo "echo success" >xxx.sh
chmod +x xxx.sh
/storage/emulated/0/xxx.sh

The final statement will fail.
[Magisk] HippoMan:
In this case, it might work if you use the word "source" instead of using a dot. In other words ...

source /storage/emulated/0/documents/test.sh

Howeveer, it's not recommended that normal shell scripts be "sourced". That's because in "sourcing" them, all the environmental and shell variable changes that they might make will be visible in your shell session after the script completes. That could affect other actions you might subsequently run in your current session.

By actually executing a script (i.e., not using dot or "source"), everything it does occurs in a subprocess, and it won't affect your environment or local shell variables after the script completes.
[Magisk] J.Michael:
From your original try, what I'm calling your third attempt, the one starting "13|", it looks like you copied the ":/" of the prompt of a previous line: the error message is saying ":/" is not found.

I'm surprised that the prompt doesn't change when you run "su", but like I said, for this test you shouldn't need it.

Did you see @badabing2003's note about line endings? Sometimes carriage-returns provoke error messages.

Another note about "source": it's not exactly the same as running the script like an executable. When you are allowed to run a script by typing its name, it runs in a new shell -- when it exits, the environment of the place that ran it is not changed, the new shell is gone. When you run by saying "source scriptname", it runs in the current shell, any changes it makes to the environment survive.

How did you put the script, and where did you put the script?

Try

cd /sdcard
ls -l test.sh
cat test.sh

just to make sure that the terminal emulator you are using has access to the file.

Even when you are in the right directory, ". test.sh" will say "No such file", you have to say ". /test.sh" -- "source test.sh" works, damfino, I thought I read that "." was an alias for "source", but "." behaves more like it uses the PATH.

If your terminal emulator is like mine, it set you up with a HOME directory, although it doesn't default to starting you there. That HOME directory will be on a full-strength Linux filesystem, so you would be able to set permissions. From the command prompt you can use "~" to refer to the HOME directory, so "cd ~" will go to it, "~/test.sh" will refer to the a file in it,...
[Magisk] ipdev:
To borrow from our xda bror on hiatus. 😉

"If you edit the configuration file in Windows, make sure that you use a text editor that can handle Unix file endings, such as Notepad++ and similar editors (not regular Windows Notepad)."

Also, copy and past does not always work correctly. 😉

Normally I will double check script using `nano` to double check (fix) line endings and extra spaces.

---

As for script files, do not get too hung up on file permissions.

A simple script like this does not need special permissions, just run it using the sh command.

- Using badabing2003's corrected version..

panther:/ $
panther:/ $ ls -la /storage/emulated/0/Documents/test.sh
-rw-rw---- 1 u0_a222 media_rw 328 2023-05-07 20:56 /storage/emulated/0/Documents/test.sh
panther:/ $
panther:/ $ sh /storage/emulated/0/Documents/test.sh
Ramdisk value = yes
panther:/ $ . /storage/emulated/0/Documents/test.sh
Ramdisk value = yes
panther:/ $

- Using your original script, I get nothing.

panther:/ $
panther:/ $ ls -la /sdcard/Documents/test-pnd.sh
-rw-rw---- 1 u0_a222 media_rw 301 2023-05-08 18:47 /sdcard/Documents/test-pnd.sh
panther:/ $ sh /sdcard/Documents/test-pnd.sh
panther:/ $

As for changing the file permissions to make it executable (0755 [rwxr-xr-x] or higher).

You would have to use a directory that has heighten permissions so you can set the script file to higher permissions.

You would have to use data/local/tmp or data/adb for example.

Cheers. :cowboy:

PS.

Why not call it from /sdcard/Documents/ ?

Last time I checked, miui symlinks storage/emulated/0 to sdcard.

Just like almost ever other Android device.

PPS.

If you really want to run you script in a single line mode...

Use a semicolon ; in place of a new line (line ending). 🙃

You would also need to skip the shebang (hashbang) at the beginning.
[Magisk] manjaroid:
I believe it. It's why the gods made NTFS.
[Magisk] pndwal:
I wasn't...

Looks like @J.Michael properly understood you method then...

Well this is what I meant; stub is tiny of course, but the App that is Magisk is not just stub once set up; the Magisk binaries are in the stub app's populated data rather in an .apk package however... I'm assuming this data includes all the regular Magisk tools for patching etc. also... I recall that when I checked previously stub with data and full loaded Magisk App's sizes were quite close... Now there seems to be a few MB difference... I'm checking with Alpha installed however:

Anyway, I took your comment:

at face value... Magisk App, even if stub App (full App is uninstalled) certainly has enough to create a patch. 😜

... I have no idea about the level of difficulty extracting tools etc from app data, but I'm assuming Magisk does do this... Please let me know what I'm missing...

Of course you can poll Magisk current binary & running daemon version so should be able to automate download of matching package and extract what's needed... But I guess that's your point. 😛 PW
[Magisk] pndwal:
Just looking at this now...

Yes; actually hadn't copied anything... :/ $ was prompt, so first return:

:/ $ /storage/emulated/0/documents/test.sh
/system/bin/sh: /storage/emulated/0/documents/test.sh: can't execute: Permission denied

2nd:

126|:/ $ su

3rd

:/ $ /storage/emulated/0/documents/test.sh
Permission denied
13|:/ $ :/ $ /storage/emulated/0/documents/test.sh
/system/bin/sh: :/: inaccessible or not found

So Su seemed to fail but something changed as info returned is quite different in 3 compared to 1...

The strange behaviour seems to be due to two Terminal Emulator apps; I used the 2nd:

but in Magisk, Superuser:

I see [SharedUID], permission is off and wasn't offered in terminal session... Prompt didn't change to #, but no errors either!?

... Removing one terminal instance now. 😛 PW
[Magisk] pndwal:
Used fixed script from:

Here you go:

126|:/ # chmod 755 /data/local/tmp/test.sh
:/ # /data/local/tmp/test.sh
Ramdisk value = no

Thanks for pointers everyone! 😋 PW
[Magisk] ctcx:
@pndwal :

Thanks very much for your tests, that helped.

Though, after all of this, wouldn't all of it have been simpler by using just "adb shell"?

@badabing2003 :

I know this was just one device for testing, but would this be enough to reconsider the RECOVERYMODE flag in PF, or would you need more different results?

Thanks again.
[Magisk] badabing2003:
I did some testing, and here's what I know / observed.

Stub by itself is not enough.

data: I tried to find where this data is stored, but then realized that even if I know where this data is stored (which is not in usual places because a root app can have their data anywhere), to potentially use it to extract the relevant parts, I need root access, without root access one does not have permissions to app folders. And the whole premise for needing this is the following scenario:

User has not granted root access to adb

User has hidden Magisk

You cannot have a hidden Magisk if your system is not rooted, Magisk display this.

Interestingly, online access is not required to do the restore, Magisk will restore un-hidden app.

If you delete data of a hidden rooted Magisk, then Magisk needs online access to restore it, there is no copying / building done from /data/adb/magisk.

In summary, the following is still the case as far as PF is concerned: There is no way for PF to use files on the phone if Magisk is hidden and root to adb is denied.

I'd be very curious to know the output of running the following script (attached as test2.zip)

#!/system/bin/sh

cd /data/adb/magisk
grep ' / ' /proc/mounts | grep -qv 'rootfs' && SYSTEM_ROOT=true
. ./util_functions.sh
get_flags
echo -------------------------
echo "SYSTEM_ROOT: $SYSTEM_ROOT"
echo "KEEPVERITY: $KEEPVERITY"
echo "KEEPFORCEENCRYPT: $KEEPFORCEENCRYPT"
echo "RECOVERYMODE: $RECOVERYMODE"
echo "PATCHVBMETAFLAG: $PATCHVBMETAFLAG"
echo "ISENCRYPTED: $ISENCRYPTED"
echo "VBMETAEXIST: $VBMETAEXIST"

If @pndwal could be kind enough to run it, it would be great.

Your test is enough, I'm just curious to see what would be reported if we didn't include the slot checks.

Note: test2.sh needs to be run as root, because I didn't want to bother you with unpacking of the apk.
[Magisk] HippoMan:
That "permission denied" error has nothing to do with which terminal app is being utilized, nor with whether or not the command is being run from within an "su" session.

The "permission denied" message is simply due to the fact that /storage/emulated/0 is a FAT filesystem, and FAT doesn't support the "execute" attribute on its contents.

You have to do /system/bin/sh /storage/emulated/0/documents/test.sh , and then it should run, and that should work from both terminal emulators.

If you copy test.sh to /data/local/tmp and then invoke chmod +x /data/local/tmp/test.sh , the script will then be able to run as follows, because /data/local/tmp is not a FAT filesystem:

/data/local/tmp/test.sh

I'm not suggesting to run the script from /data/local/tmp. I'm just using that as an example to illustrate the difference between the FAT and non-FAT filesystems in Android with regard to the "execute" attribute.

My recommended solution to the problem is what I mentioned above:

/system/bin/sh /storage/emulated/0/documents/test.sh

UPDATE: I originally made several references above to "/data/tmp", but in doing so, I had forgotten that there isn't normally a /data/tmp directory under Android, but rather, /data/local/tmp, and that's the directory I was thinking of. I realized this error of mine when reading the message below by @bnsmb , and so now, I have changed all "/data/tmp" references in this message to "/data/local/tmp".
[Magisk] bnsmb:
... and If there is no /data/tmp (like in the OmniROM) there should be a /data/local/tmp on an Linux filesystem that is writable by the user shell and supports the execute permission:

1|ASUS_I006D:/ $ ls /data/tmp
ls: /data/tmp: No such file or directory
1|ASUS_I006D:/ $

SUS_I006D:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0

ASUS_I006D:/ $ ls -l /data/local/tmp/test.sh
-rwxr-xr-x 1 shell shell 11 2023-05-09 21:01 /data/local/tmp/test.sh
ASUS_I006D:/ $

ASUS_I006D:/ $ cat /data/local/tmp/test.sh
echo Hello
ASUS_I006D:/ $

ASUS_I006D:/ $ /data/local/tmp/test.sh
Hello
ASUS_I006D:/

regards

Bernd
[Magisk] HippoMan:
I was thinking of /data/local/tmp when I wrote my message above, but I had forgotten its proper name and kept incorrectly referring to it as /data/tmp.

Thank you for pointing this out!

And I corrected that in my message above.
[Magisk] m0han:
FMMM Update

Version 2.1.0 not only fixes bugs, but also brings a fresh batch of improvements and new features to help you install and update.......

https://www.androidacy.com/update-magisk-module-manager-to-2-1-0