yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
Not quite...

The indication is "100%" reliable when you understand what it means...

1) It's NOT saying device has no ramdisk... Of course device has multiple ramdisks regardless of yes/no status...

2) It's not saying boot image has no ramdisk either... If boot is already Magisk patched it necessary now has basic generic ramdisk but Magisk still reports Ramdisk = No because there's no value in reporting an added ramdisk...

3) This status is designed to be an indicator of bootloader support for Magisk in boot and since Magisk is always installed in ramdisk it must report whether the manufacturer has added requisite support for ramdisk in boot... So Magisk reports 'Yes' for

OEM supplied ramdisk in boot

meaning "effectively Magisk is guaranteed support for boot mode on this device", or 'No' for

no OEM supplied ramdisk in boot

meaning "there is no guarantee that OEM has enabled bootloader support for ramdisk in boot partition"... Ie. "There's no reason to expect such support since device architecture never uses generic ramdisk in boot partition, but you can try if you wish since OEM may just include/leave bootloader support for no good reason in which case Magisk can use it... But logically it shouldn't work..."

No, A-only devices all have both partitions...

A) If Ramdisk = Yes, assume usable ramdisk in boot. (100% guarantee.)

B) if Ramdisk = No assume nothing. (No guarantees)... Try patching boot image (this should always succeed without errors) and flashing (this will also succeed) then booting (this will probably fail, but just rejoice if it works! 🤪... Otherwise prepare to use Magisk in Recovery mode and use recovery key combo + release timing to boot to system via recovery each time)...

As John says, the only way to test if Magisk in boot with Ramdisk = No is to try... There are simply no software indicators of bootloader support for ramdisk/Magisk in boot.

🤠 PW
[Magisk] Nergal di Cuthah:
There are probably members in @ctcx device subforum who are able to answer that for them, don't you think?
[Magisk] badabing2003:
How are you searching?

Have you seen this?

Steps to find it.

Go to https://github.com/topjohnwu/Magisk

hit . (dot), this should load online vscode

CTRL+SHIFT+F (search button) and type ramdisk

inspect the matches,

This one looks interesting,

search for RAMDISKEXIST (double click the keyword, and hit CTRL+SHIFT+F)

This one looks interesting

search for check_boot_ramdisk

you land at function: check_boot_ramdisk()
[Magisk] zgfg:
Bingo

It 'concludes' Ramdisk No just from Legacy SAR and not A/B

Hence @ctcx you see that it could be false positive and that it's worth trying to patch boot.img (btw, the whole saga could have been ended kong ago, knowing for sure does it work for you or not)
[Magisk] ctcx:
Of course I did ALL of that already:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2783#post-88471305

@zgfg : yes, thanks again.
[Magisk] pndwal:
Well put, except that you will still totally succeed in installing Magisk in boot image (magiskinit in ramdisk CPIO) because Magisk adds fully functional ramdisk whenever one is absent...

The issue is that it's functioning depends on bootloader...

Really, 'What is uncertain is whether you will succeed in booting system with Magisk in the boot image if there was no ramdisk in the original boot image' rather than 'installing Magisk in the boot image'...

Well actually it doesn't find ramdisk as any generic ramdisk is still absent at this point... It actually adds a basic ramdisk with Magisk patch (magiskinit in ramdisk CPIO) where ramdisk is absent.

Here is the 2019 commit adding this function:

https://github.com/topjohnwu/Magisk/commit/e72c6685edf81706617a3444575c4500b9b8fe6c

Prior to this Magisk would simply fail to patch boot.img due to absence of ramdisk.

🤠 PW
[Magisk] pndwal:
Nah... * Legacy SAR A/B devices are always Ramdisk = Yes...

*Edit: I may have misinterpreted this per:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88476123

This is recovery ramdisk but it has been moved to /boot as /recovery is eliminated on these devices, and Magisk can use it...

@ctcx never had Ramdisk = No; Device is Legacy Ramdisk boot type. PW
[Magisk] badabing2003:
Silly me, why I would I get that idea?:rolleyes:
[Magisk] martyfender:
I am posting this here considering this ongoing discussion for information only. I don't wish to get into the argument.

Devices:

Onn 8 1st generation tablet.

Mediatek MT8133 Arm 8A Cortex-A53 @ 1399 MHz.

Android 9 stock.

Ramdisk No

Separate recovery partition flashed with twrp-3.3.1-1-ONA19TB002.img

Is this SAR legacy A only?

Boot.img patched with official Magisk debug on one device and Magisk Delta on the other.

When unrooted the Magisk app automatically checks recovery mode option and checks to patch vbmeta.

The above is wrong for my devices. I have to uncheck the above 2 before patching.

I have to patch the boot.img only Then flash it with fastboot or TWRP.

After it is rooted I can use the direct install to update.
[Magisk] J.Michael:
If we're going to be fussy, then it is really "What is uncertain is whether Magisk will be active after you boot a system having installed Magisk in the boot image when there was no ramdisk in the boot image before you installed Magisk in the boot image."

I have been assuming that if you install Magisk in the boot image, and the bootloader / kernel do not use the ramdisk, that you will still succeed in booting Android, you just will not have Magisk active. Have you seen a case where the addition of the ramdisk (and whatever patching is done to the kernel itself) results in the system failing to boot at all?
[Magisk] pndwal:
Exactly... But isn't that precisely what I said? 🤔:

... Isn't "whether you will succeed in booting system with Magisk" the same as "whether Magisk will be active after you boot"?

No... You are correct, bootloader generally still succeeds in booting unrooted system as the added ramdisk is just ignored (so magiskinit is necessarily ignored) and the kernel proceeds to directly mount the system partition as rootdir and execute /init to boot uninterrupted... But I didn't say differently!... 🙃 PW
[Magisk] J.Michael:
If you think you said "succeed in booting system with Magisk", there is no difference.

I read "succeed in booting system with Magisk in the boot image", as in "Magisk is in the boot image; the boot image has been patched by Magisk", and "succeed in booting system" -- but no mention of whether Magisk was actually active.
[Magisk] pndwal:
I see how you could have read it that way, but sorry, I wasn't discussing whether a Magisk-patched boot image will prevent system from booting normally...

I did mean ' "succeed in booting system with Magisk in the boot image", as in "Magisk is in the boot image; the boot image has been patched by Magisk", and in the context of this discussion this is as opposed to booting system via recovery with Magisk in recovery image... The point of this discussion was not 'whether a Magisk-patched boot image will prevent system from booting normally', ie just "succeed in booting system". This would be irrelevant as I was simply pointing out the uncertainty of having bootloader support for Magisk in boot:

What I wanted to clarify was your statement:

My point was that patching and flashing ("installing Magisk in the boot image") generally always succeeds (without errors because there are no reliable signals Magisk can use to determine if proper support exists or not) regardless of ramdisk status... That's not the uncertainty...

What is uncertain is whether you will succeed in

booting

system with Magisk this way (rather than "succeed in

installing

Magisk in the boot image") because while Magisk is certainly installed in a boot.img ramdisk successfully, the bootloader likely won't support such a ramdisk and will simply allow system to be directly mounted as rootdir; initramfs is therefore just never used...

-----​

However, I may have made a similar mistake interpreting a comment related to Ramdisk = No topic; looking back here:

... I thought @zgfg meant "It 'concludes' Ramdisk No just from [checking if device type is] Legacy SAR and not [from checking if device type is] A/B", so I said:

... I now think he actually meant "It 'concludes' Ramdisk No just from [checking if device type is] Legacy SAR and [from checking if device type is] not A/B [ie. is A-only]. 🤪

In this case he is probably spot on... 😬 👍

Sorry mate! 🥴 🙃 PW
[Magisk] pndwal:
Legacy SAR, A-only, yes...

Expected (same for Xiaomi, other)... Magisk cannot know if bootloader support for a manually added ramdisk exists...

Probably expected per vbmeta location.

For Recovery mode, yes, you need to check if it works unchecked yourself per this discussion... Magisk logically assumes boot mode is unsupported since OEM doesn't supply a generic ramdisk in boot, but still allows it and actually adds missing ramdisk so it can work as long as there is inexplicable bootloader support...

Re. patching vbmeta, this option should only be checked if your device does NOT have a separate vbmeta partition and Installation Instruction page tells you to check for this manually... Assuming you have checked and vbmeta partition(s) is absent, does checking the box actually break Magisk installation?

Normal...

🤠 PW
[Magisk] duven87:
Hi,

After updating the magisk version from version 25 to 26.1 on my samsung galaxy s5 with Lineage official (android 11) I can't install anything.

I have tried to install version 2.0 of bitgapps and version 2.0 of the webview addon also from bitgapps and I always get the same message:

Copying zip to temp directory
Installing webView-v2.0.zip
Read-only file system
Installation failed
[Magisk] pndwal:
Aside from the code you found in manager.sh, I took a look at the files in the commit I found for adding a ramdisk in devices lacking OEM ramdisk in boot... Link here:

For detection purposes, boot_patch.sh file is interesting:

# Test patch status and do restore
ui_print "- Checking ramdisk status"
if [ -e ramdisk.cpio ]; then
./magiskboot --cpio ramdisk.cpio test
STATUS=$?
else
# Stock A only system-as-root
STATUS=0
...

👀 PW
[Magisk] martyfender:
yes, my device does have a separate vbmeta partition.
[Magisk] pndwal:
That's interesting.... My Ramdisk = No Xiaomi device doesn't display vbmeta option... I'd assumed it only showed for older devices...

Guess Magisk can't reliably detect seperate vbmeta partitions on some A-only Legacy SAR devices at least... So John was right to instruct you to test for seperated vbmeta and set check box as needed yourself... 😜 PW
[Magisk] martyfender:
yes, it definitely shows up in /sys/dev/block/by-name.
[Magisk] ctcx:
Just for easy reference, taking from here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2784#post-88473989

Like I said, I did find and check each and all of that stuff when searching Github repo myself; albeit I didn't mention something: I still don't know C++ very much...

For that segment in boot_patch.sh, IIUC, that just tests whether Magisk patched or not.

Just reviewed what the cpio test is for here.

...I guess I also finished off annoying @osm0sis ; what a frustration
[Magisk] osm0sis:
Magisk/app/src/main/res/raw/manager.sh at master · topjohnwu/Magisk

The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.

github.com
[Magisk] J.Michael:
Someone with a device for which Magisk manager app reports "Ramdisk: No", but who has succeeded in installing Magisk in the boot partition:

Can you pass the original, unpatched, boot image to Android Image Kitchen to see if there is a initramdisk?
[Magisk] martyfender:
Here is my stock boot.img unpacked in AIK. The ramdisk folder appears to be empty. The second screenshot is from the Magisk patched image.
[Magisk] pndwal:
Someone else can do that, but here are John's notes on that commit I linked:

Support A only System-as-root Devices …

Most Chinese devices (and supposedly Galaxy S10) running Android Pie is using system-as-root without A/B partition.

https://source.android.com/devices/bootloader/system-as-root#about-system-as-root

According to the docs above, these devices will have a ramdisk block with size 0 in their boot images. Since magiskinit can run independently on system-as-root devices, we simply just create an empty ramdisk with

magiskinit added as init.

Huge thanks to @vvb2060 for the heads up and original PR.

Close #980, close #1102

👀 PW
[Magisk] pndwal:
Can you show ramdisk block size? 👍 PW
[Magisk] martyfender:
If you tell me how to do that in the image I copied to my Linux Mint desktop, or on my device.

Thanks
[Magisk] J.Michael:
700KB

"Ramdisk: No" does not mean what I thought it meant.
[Magisk] ctcx:
The angry sir answered with something I already had learned (again, my fault as always...)

And worse, as mentioned in the link, that's NOT it at all. Even other users such as zgfg pointed out this very fact.

...I'll take it as direct consequence of my very being. Devs are clearly unwilling to help.

Thanks everyone else for all your advises. At least the other flags were able to be figured out.
[Magisk] pndwal:
Mate, aside from that, have you clicked the 'like' button even once?...

Many have been helping you with this and it's not clear if you are even reading some responses... And I haven't seen any 'angry' ones / 'angry sirs'... 🙄

Anyway, what information is still missing?... PW
[Magisk] pndwal:
Oh... Johns note indicates it should be a "ramdisk block with size 0"...

Is it perhaps 700KB size after patching (ramdisk added)?

What is your understanding/thinking now? PW
[Magisk] ipdev:
Before this spins out of control. 🙃

---

Most here would just read past (skip) your post if they can not help or give a constructive response.

or they are short of time and can not give your question the proper attention it needs.

Instead they might give a quick answer to the question, even if you do not understand the (your own) question. 😉

---

No one is angry.

We all learn and ask questions.

If anyone gets angry at you (or any one) for asking question, we will report them to the xda mods. 🪓

Cheers. :cowboy:
[Magisk] J.Michael:
Wu described a situation. I think this is not that situation.

I assumed @martyfender checked an unpatched image. Especially since the root directory of the ramdisk was so empty.

It is also possible that AIK fabricates a ramdisk when it doesn't find one. I consider that unlikely. I haven't slogged through the scripts to find how to check the "ramdisk block size".

My current thinking: "Ramdisk: No" is not to be interpreted as an English phrase. We have been treated to an assortment of snippets of scripts associated with Magisk. We have *not* been shown what I recognize as code within Magisk manager app responsible for displaying "Ramdisk: No". The snippets we've seen indicate that there is no effort made to read the "ramdisk block" and determine whether it is empty. Variables with names suggesting they are related to the decision to recommend patching recovery are derived from some logic that seems to me to be more indirect -- like "I don't see two slots, and the root filesystem is not of type rootfs, which suggests that the age of this system corresponds to an interval when there would be no ramdisk".

As I said, I don't think these scripts are quite the same as the app, and I don't follow all of the references to properties, and whether Magisk has patched the ramdisk. For years I have assumed "Ramdisk: No" meant exactly what it said. Now, I have my doubts.
[Magisk] osm0sis:
I'm not angry, please don't characterize me as such. I'm not currently following this thread, nor whatever journey/rabbithole you're on/in, but I'm doing pop-ins to help when I'm called, if I can help, as I always do. 🙂

But that is where "Ramdisk Yes" comes from:

Magisk/app/src/main/res/raw/manager.sh at cdfbc02922908f4fef59f01a50be14f51d63a7ab · topjohnwu/Magisk

The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.

github.com

check_boot_ramdisk populates the RAMDISKEXIST shell Boolean, which becomes the Java/Kotlin Info.ramdisk Boolean, which become the translated app strings Ramdisk Yes/No:

Build software better, together

GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.

github.com

Edit:

P.S. AIK will tell you very clearly when there's no ramdisk inside a boot.img:

Android-Image-Kitchen/unpackimg.bat at master · osm0sis/Android-Image-Kitchen

Automated scripts to unpack/repack Android kernel/recovery images + ramdisks - osm0sis/Android-Image-Kitchen

github.com

But that's neither here nor there for how Magisk makes that assumption, as you can see. 👍
[Magisk] zgfg:
IMO, there is no doubt about Ramdisk Yes declaration

Only about Ramdisk No

And in fact not about Ramdisk No per se, but about the official Installation guide that directs you in that case to patch recovery.img

That was actually my understanding also before the whole this debate here - but it was based on the practical (experimental) basis, not the theory, and now we've seen also the theoretical aspects (parts of Magisk code responsible for displaying the ad-hoc conclusion Ramdisk No)

---

Note: When I moved from Huawei to Xiaomi, and although I was already a seasonal Magisk and custom ROM user on Huawei, I spent maybe 10 days of mostly searching and just reading (without asking) before I went to install Magisk for the first time to that my new Xiaomi back in 2019 summertime

And I well remember my own confusion about Magisk No and the official installation guide instructions (and also instructions to similar users here in this thread at that time) versus the certain rooting guide thread on XDA (for a similar, albeit Pro model to mine) that clearly instructed to ignore that and patch the boot.img

Since I had TWRP and knew that I can always recover by reflashing the original boot.img and even dirty the whole ROM, I decided back then to bite the bullet and to try with patching boot.img - and it went good

And later I clashed here (guess with whom - later he also changed the stance) when I boldly answered to another Xiaomi Ramdisk No user (I think it was early Covid times) to break the Bible and patch the boot img

Btw, why - since I well understood that installing Magisk to Recovery (alongside the healthy Boot partition) would make me a dual-boot phone: normal/default boot to Android w/o Magisk and only a cumbersome booting via Recovery to Magisk
[Magisk] J.Michael:
@osm0sis That Github search forced me to log in, then returned no matches. Did XDA alter it from what you intended?
[Magisk] Nergal di Cuthah:
Same, usually would open in github app but opened web browser instead
[Magisk] zgfg:
+1
[Magisk] pndwal:
Are you thinking of our discussion where you said Magisk's Ramdisk status indicator has a bug bacause it 'looks for ramdisk and reports No' but when flashing "happily finds Ramdisk and reports successful patching", and @Didgeridoohan and I said 'It doesn't "find" ramdisk!... It adds it when missing

always

and booting will fail unless

bootloader

supports ramdisk in /boot'?... And further that Magisk shouldn't change the 'No' indication after installing a ramdisk with Magisk as it would then say 'Yes' on every device after Magisk patching, including those with the expected incompatible bootloaders rendering the Ramdisk indication meaningless...

I hope you aren't still remembering that 'clash'! 😬 PW
[Magisk] osm0sis:
Weird. Still works for me, it's:

RAMDISKEXIST OR Info.ramdisk repo:topjohnwu/Magisk
[Magisk] ctcx:
Ok, sir, sorry.

What I could not digest back then here, was that, with that old device, I indeed tried the tests in manager.sh, and they all gave as in "Ramdisk = No; Recoverymode = Yes". But in Magisk manager in the device, the app UI itself, it says "Ramdisk = Yes".

Aside the details in that post, that device was launched with Android 5, officially upgradable up to Android 6; but this one in particular had custom ROM based on Android 10.

IIRC, mr zgfg had pointed out in past posts that one should not 100% trust that indicator, and the best way to know was to directly test oneself, looking at app's output, and flashing.
[Magisk] J.Michael:
@pndwal I was saying Wu described a situation where there would be no initramdisk in the boot image, but this case (the boot image @martyfender checked) was not that case.

I can't deal with your references to "recovery ramdisk".

Does anyone have a case of a device on which there is truly *no* initramdisk in the boot image, but Magisk can be installed in the boot image?
[Magisk] pndwal:
Why would you think that?... Onn 8 (gen 1) tablet launched with Android 9 and is single slot device!... Kernel simply does not use initramfs as rootdir in any of these devices; it directly mounts system...

... That is, until Magisk patching adds ramdisk for magiskinit of course.

A/B Legacy SAR devices and A/B 2SI ramdisk SAR devices (generally) have (only) recovery ramdisk in /boot; 2SI A-only and some hybrid 2SI A/B devices (eg OnePlus 8T) with separate recovery partitions have a standard boot type ramdisk... A-only Legacy SAR devices have no ramdisk in /boot, and that's the whole problem for Magisk with these devices.

Yes, I have Xiaomi Redmi Note 8T... The ramdisk Magisk patches to /boot is accepted by the bootloader and system boots with Magisk root without booting via recovery. 🙃 PW
[Magisk] J.Michael:
Maybe we're just talking past each other.

@martyfender posted results showing that an original boot image, labelled "Ramdisk: No" by Magisk manager app, actually *did* have an initramdisk. Your statements about what was thought to be true do not change his evidence.

Again with "recovery ramdisk". I tried Googling, and I still don't know what that means. If you mean that there is enough in *the* ramdisk to allow the device to boot to recovery -- if something tells it that it is supposed to boot to recovery rather than to normal Android -- I don't see the value in calling it "recovery ramdisk".

Until you run your unpatched boot image through Android Image Kitchen to confirm that there is *no* ramdisk, you have not answered my last question. The fact that Magisk says "Ramdisk: No", and yet you installed Magisk in the boot image, puts you in the running, but the question was whether you had confirmed, separately from the assumptions in all the documentation we've both read, that there was *no* ramdisk.
[Magisk] J.Michael:
@pndwal I had wondered why @martyfender posted a picture of a directory "ramdisk" containing 700 KB while saying "appears to be empty". Now I know: he didn't, I missed the qualifier "2nd screenshot is from Magisk-patched image".

Another elegant theory derailed by inconvenient facts.
[Magisk] martyfender:
Yes, I updated that the day after as it appeared that you didn’t realize I had posted 2 screenshots.

I do most of my posting from my triple boot, linux Mint, Nobara and Windows11 desktop. Where those are very clear.
[Magisk] pndwal:
I included the Google/OHA doc refs re. recovery ramdisk as you said "I can't deal with your references to "recovery ramdisk"" and 'Googling it didn't help'... Hope this and use of BOARD_USES_RECOVERY_AS_BOOT in modern devices is clearer for you now. PW
[Magisk] ctcx:
@osm0sis :

By chance, any help with this issue?
[Magisk] J.Michael:
What issue?
[Magisk] zgfg:
Sorry to interrupt again but what is still a showstopper here

Have you ever tried patching your boot.img - what did Magisk say while patching (you will have a box printing logs in front of your eyes and you can save the log to Download)?

Then, I actually did not advice to "fastboot flash boot <patched.img>" but to "fastboot boot <patched.img>" (important: command flash is missing to avoid any risk of bricking) - so did you try, did it boot to Magisk?

If it does, then advised you to finish with Direct install (see my original answer) - and you will be done with Magisk installed

If something does not work then ask by describing what exactly went wrong, providing the log, screenshot or so