[Android Head-Units] Miwer:
No I haven't tried that solution, and I'm not going to either, since we don't know what those update files do exactly, and the mere fact, that they are from some "reset/format" package (without the format part) I'm not going to risk anything.

Also I believe that the boot image installed by this package is from an older version, so lord knows what kind of other compatibility issues (or missing fixes, security related or not) we can see by using this boot image.

This is pure speculation of course, and since we don't have access to decode the update files, we cannot be sure.

But I have been researching a bit, and I actually do have an educated guess as to why we cannot get permanent root, and I can think of two ways to fix it:

Problem:

su isn't running as a daemon after rebooting the device.

Elaboration:

During rooting process, Baidu installs a script in /system/etc/install-recovery.sh which is normally launched by the init script (which is part of the boot image).

Baidu also launces "su --daemon" during the rooting process, so superuser access can be obtained until the device is rebooted.

After version 2.7.35 (or thereabout), the boot image has been modified (fixed if you will), to NOT launch the install-recovery.sh script during boot. (I have extracted and unpacked the boot images and compared the init scripts, so I'm pretty sure of this).

This means, that after reboot, the "su --daemon" will NOT be running, and the user will not be able to gain super user access by running the su binary.

How to fix (the "bad" way, untested)

Modifying the init script in the boot image, and UN-commenting the section launching the install-recovery.sh script, should solve it.

However, it requires that the boot image is unpacked, modified, packed and "flashed" (copy with dd) into partition 4 - I dare not do this, since there's also a lot of binary code in the image, and I don't know if there's some hash validation going on.

One could potentially render their device unbootable by doing this.

How to fix (the good way)

The SU binary should be modified to not require a running daemon process. You'd think that having the SUID bit set on the executable file would be enough, but it obviously isn't (I don't know if SELinux has any play in this?)

Why does the reset package fix this?

My guess is, that the reset package replaces the boot image (the file with a size of about 8MB) with an older version that IS launching the install-recovery.sh script (and thus the su daemon) during the boot process, which enables the user to gain super user access.

If this is so, then that also means, that the reset package must be flashed after every upgrade (and as such, downgrade the boot image), since all updates I've seen comes with it's own boot image besides the /system image.

Anyway....

I've thought about contacting Koushik Dutta (the author of ClockworkMod superuser) and ask if he is able to fix the su binary, but I haven't gotten around to it yet.

Anyone know if the SuperSU (or any other super user solution) has it's own binary, and if that can possibly fix it? I haven't tested that yet.

Personally I would prefer the ClockworkMod solution, simply because it's open source :)

Bonus info: The SU binary included in Baidu root, is allegedly a modded version of the open source binary from ClockworkMod Superuser (which also doesn't work after reboot).

Them Chinese developers are good at taking other peoples open source work and package it in their own closed source product. ;)

/Miwer

---------- Post added at 11:10 AM ---------- Previous post was at 10:48 AM ----------

So you've replaced the "older" boot image from the reset package with the correct boot image from the 2.8.7 update. I'm guessing you won't have permanent root after this. (please do get back to us on this, it's good to know) ;)

Well, after reading these posts, and based on my research I posted in the previous post, I cannot in good conscience recommend anyone to try and flash those four files.

In my point of view, you'll risk breaking things that worked before, just to be able to have permanent root (which should be fixed another way).

Please also keep in mind, that the boot image also contains the kernel, and therefore also the drivers for (at least some of) the hardware components.

It's quite possible, that people with newer devices, will not be able to use the reset package, if it downgrades the kernel and drivers to older versions, and that's where things stop working.

It's interesting to see where this is going... :)

Cheers,

/Miwer