Closed androidacy-user closed 1 year ago
03-06 09:07:50.673 867 869 E : mount /data/adb/modules -> /dev/rcdehA5/.magisk/modules failed with 2: No such file or directory
03-06 09:07:50.673 867 869 E : mount (null) -> /dev/rcdehA5/.magisk/modules failed with 2: No such file or directory
03-06 09:07:50.673 867 869 E : mount (null) -> /dev/rcdehA5/.magisk/modules failed with 2: No such file or directory
Are the relevant logs
The problem might come from this commit https://github.com/topjohnwu/Magisk/commit/9e07eb592ce05f8fb94e63198138d0f1678749fd
i mean this https://github.com/topjohnwu/Magisk/commit/9e07eb592ce05f8fb94e63198138d0f1678749fd, this commit forgot to mkdir MODULEMNT before bind mount MODULEROOT
@topjohnwu Please release a new canary build with this fix. With GitHub Actions builds signed with different keys and no ability to downgrade the Magisk app to a previous version, my modules have been broken for days.
@topjohnwu Please release a new canary build with this fix. With GitHub Actions builds signed with different keys and no ability to downgrade the Magisk app to a previous version, my modules have been broken for days.
Flash the 25209 APK after renaming it to zip - You can't downgrade the manager, but you can downgrade the rest.
For some of you who want to revert to 25209
This is the old apk https://github.com/topjohnwu/magisk-files/blob/0b9eca062198e568f9cc101eaf64bb5d9edb8a34/app-release.apk
Traced from https://github.com/topjohnwu/magisk-files/tree/0b9eca062198e568f9cc101eaf64bb5d9edb8a34
Bug confirmed on LOS 17.1/ Android 10: ViPER4Android driver not loading anymore with Magisk Canary 981ccabb (25210).
I'm sufficiently technically inclined that I was able to correct the situation myself once I became sufficiently annoyed by it, but I feel sorry for anyone who isn't or who hasn't happened upon this thread and the very helpful instructions submitted today by Stanley. Absolutely shameful release management here by the devs. If you push out an update that breaks everything, you immediately push out the hotfix when it's ready. How many more duplicate issues do we need here and even at other projects before someone does something about this mess?
I'm sufficiently technically inclined that I was able to correct the situation myself once I became sufficiently annoyed by it, but I feel sorry for anyone who isn't or who hasn't happened upon this thread and the very helpful instructions submitted today by Stanley. Absolutely shameful release management here by the devs. If you push out an update that breaks everything, you immediately push out the hotfix when it's ready. How many more duplicate issues do we need here and even at other projects before someone does something about this mess?
To be fair, the Canary channel is for testing. And people have lives. It's not so hard to go back to an earlier version.
As I've said already - it's not hard to go back to 25209
which still works. A new release would be nice, obviously, but since there is a stopgap measure it's not an absolute emergency.
To be fair, the Canary channel is for testing.
Is it? Because I suspect the overwhelming majority of us are on Canary because we have newer phones and stable and beta just plain don't work for one reason or another. And as long as that's the case -- as long as over five months after its release, for example, there still isn't even a beta that works on the Pixel 7 series -- Canary needs to always be in a functional state.
Testers can test from master; the rest of us just want something that works. If tagging new Canaries is done willy-nilly and not at strategically chosen points in development when there's a reasonable level of confidence in the current code's stability, there's no reason to tag them at all.
Is it? Because I suspect the overwhelming majority of us are on Canary because we have newer phones and stable and beta just plain don't work for one reason or another. And as long as that's the case -- as long as over five months after its release, for example, there still isn't even a beta that works on the Pixel 7 series -- Canary needs to always be in a functional state.
Testers can test from master; the rest of us just want something that works. If tagging new Canaries is done willy-nilly and not at strategically chosen points in development when there's a reasonable level of confidence in the current code's stability, there's no reason to tag them at all.
Stable 25.2 is working fine on the Pixel 7 series for me. Canary 25206 & 25209 are also working. And yes, even though they are release builds, Canary is still considered "bleeding edge of the source". It doesn't always need to "be in a functional state", in my opinion. That's what stable builds are for. Why do you think there are separate stable, beta, canary and debug channels? If the latest Canary isn't working for you, why not just go back to the last one that was?
Or magisk delta
Interesting that you had no issue with stable. I did, and I certainly wouldn't be on Canary or here arguing this (nevertheless correct) point about release management otherwise.
Ultimately, while downgrading might be "not so hard" for us -- indeed, I did just go back to the last one that was working -- what about the average Magisk user who had no choice but to go bleeding edge? It's not obvious where to get old Canaries. It's not obvious how to downgrade. I imagine there's a non-trivial number of users who've been in a real pickle these past few weeks.
All of us here understand and appreciate the purpose and value of the release channel model. If users are being forced into bleeding edge builds because betas aren't being proactively released to support emerging platform quirks, though, Canary becomes the de facto beta and needs to be treated as such. Again, release management. If there was a functional beta, we could all shrug our shoulders about this situation just like the devs are doing.
Here's the issue I'm having with this: this topic was closed even though the issue hasn't been fixed yet. Latest Magisk Canary still the faulty 25210.
Before I installed 25210, I went to https://github.com/topjohnwu/Magisk/issues to check if there were any issues with 25210, and there weren't any visible to the open eye. Why? Because the topic had been closed.. It shouldn't be required to search closed topics for (in this particular case) 25210.
In contrast to closing this topic, thus swiping this bug under the carpet which doesn't fix anything, it would much rather have needed to be pinned ontop.
I love Magisk, and I am more than grateful for all the work you devs put into this project. But please also do reflect on how this has been (and still is) handled, and how you could do it more smoothly and with much less friction in the future, all right ;)?
Indeed, much respect to John, the LSPosed folks, and everyone else who's contributing here. I get it, devs just want to write good code, and the Magisk devs are doing it in spades these days. But the project clearly needs someone to manage it the way John did so well in his pre-Google days. Get the word out early about breaking changes to Android, get the word out about Samsung's latest pointless platform rearchitectures, keep us updated on how close you are to cracking the latest mega-problem, drop a beta where appropriate so Canary is a value-add rather than a necessity... these are all things we used to be able to count on from Magisk. Hopefully we'll get back there someday.
Here's the issue I'm having with this: this topic was closed even though the issue hasn't been fixed yet. Latest Magisk Canary still the faulty 25210.
After writing this, I feel like I have to clarify first that I don't want to offend you or devalue your oppinion with the following, I'm just trying to give an explanation and add my opinion to this.
Issues are closed when a fix gets added to the codebase, not with the next release, that's just standard procedure. Otherwise it would be much harder to track which issues got taken care of already and which ones still need to be worked at. As for this specific issue, it got closed with https://github.com/topjohnwu/Magisk/pull/6690, as you can also see above since this is tracked.
Yes it would be less hassle for a lot of people if a new canary release containing the fix would have already been released, but as already described above, it's generally really simple to downgrade if you encounter issues. For me, this took 5 minutes: Go to https://github.com/topjohnwu/magisk-files/commits/master, download the apk which was released right before 981ccabb, which is 2717feac by copying the link, rename to zip and install in magisk manager, like any module, don't even need a PC, in my opinion it's even easier than installing magisk in the first place.
For me personally, I use Pixel Flasher, which did in fact show me a warning when trying to use the latest canary build, saying it has known issues. While I agree this warning could also be placed somewhere in the Readme (e.g. 'latest canary has issues, please use build 25209 which you can find here'), I kinda expect that people who use canary, or even use magisk or any other rooting method in general for that matter, are willing to do some troubleshooting if something doesn't work at first. I mean by rooting your device you literally risk bricking your phone if you don't know what you're doing so is it really too much to ask?
I just encountered this issue as I updated to 25210. NanoDroid stopped working so I lost access to some apps, and the stock apps that I once hid reappeared. It took me a search of all issues to find one of the duplicates which led me to this.
Reverting to 25209 fixed it. However, user data for some of the apps brought in via NanoDroid were irreversibly lost, though fortunately my microG settings were still there, so it's not really a big deal.
Considering the issue has been fixed upstream, and this issue closed, I think a new canary build should be put up ASAP, or at least revert the Canary channel back to 25209 release (so they will update to 25209 instead of this bugged build), to contain this bug's impact so it will stop affecting other people who are on Canary.
EDIT (Apr 2023): Newer builds have come out. I'm now on 26001 and it's currently working fine, so this major breakage is finally addressed.
@Xerunala partly agreed. Regarding Pixel Flasher: as the name clearly indicates, it is a tool that can only be used with Google Pixel phones and may therefore not be considered a debugging tool, not even an unofficial one.
Device: Pixel 7 Pro Android version: 13 QPR2 Magisk version name: v981ccabb Magisk version code: 25210
With the latest version, mounting all mounts fails saying
No such file or directory
, i.e.mount /data/adb/modules -> /dev/random/magisk/.modules failed: no such file or directory
. 25209 works fine.