[ROM] [r02 - 2015-12-13] Flashcast-AutoRoot

[metterschling]

Before I send you the files/instruction, do you know whether you have adb enabled on regular boot on your rooted chromecast? That would be the easiest way to transfer the needed files to your rooted chromecast's /data/ folder.

Another method is to reboot to flashcast and transfer it while in flashcast.

Yes, ADB is enabled in the rooted CC (still at last Eureka release 44433.001) and I can successfully connect and adb shell into it.

Update: ADB is not really required if you start from the Eureka 44433 release as you can always easily set up a http server with for example "python3 -m http.server 8000" somewhere on a PC and then use "busybox wget ..." (busybox is included on that release) to pull the files on your CC.
In the meanwhile I copied your loopmount.sh script to /cache on the CC, then downloaded the 159268 OTA to a PC and extracted it ... now waiting for your instructions to get/build the modified initrd.sqfs and system.sqfs. I'd prefer a script to create them myself rather than binaries, but that is your choice.

Update2: Played around a bit, generating unmodified system and initrd sqashfs images on my PC to test the process:

# prereqs
sudo apt install abootimg
git clone https://github.com/ReFirmLabs/binwalk
cd binwalk/
sudo python3 ./setup.py install
# real stuff
mkdir -p ~/tmp/chromecast
cd ~/tmp/chromecast
./adb push ~/tmp/loopmount.sh /cache/
wget http://redirector.gvt1.com/edgedl/googletv-eureka/stable-channel/ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip
binwalk -e ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip 
cd _ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip.extracted/
# get the system image
file system.img 
binwalk -e system.img 
cd _system.img.extracted/squashfs-root/
mksquashfs . ~/tmp/chromecast/system.sqfs -all-root
# test system image
sudo mount -t squashfs -o loop ~/tmp/system.sqfs /mnt/
sudo umount /mnt/
# Now get the initrd
binwalk -e boot.img 
dd bs=256 skip=1 if=boot.img of=~/tmp/chromecast/aboot.img
cd ~/tmp/chromecast/
abootimg -x aboot.img 
file initrd.img 
mkdir rd
cd rd/
xz -d -c ../initrd.img | cpio -i -d -H newc --no-absolute-filenames
mksquashfs . ~/tmp/chromecast/initrd.sqfs -all-root
# test initrd image
sudo mount -t squashfs -o loop initrd.sqfs /mnt/
sudo umount /mnt/

Copied the images to the CC and executed the loopback.sh script. At first run I recognized that the sequence is wrong, as soon as system mount is overloaded, busybox is no longer available. So corrected loopmount.sh looks like:

#!/bin/sh
/chrome/cast_cli stop cast
mkdir -p /initrd
busybox mount -o loop,ro /cache/initrd.sqfs /initrd
busybox mount -o bind /initrd/lib /lib
busybox mount -o bind /initrd/sbin /sbin
busybox mount -o loop,ro /cache/system.sqfs /system
# cp -a /initrd/root/* /. #### this step is optional
start cast_receiver

Result: CC was still working a minute or so after the script ran, but then the screen turned black and CC was no longer reachable from Google Home app. Shell login (here: adb shell) still was there, so issued a reboot to verify that nothing is broken. After reboot CC came back up successfully so indeed nothing is broken permanently as expected.
So finally I only need your tweaks to the squashfs images for another attempt

 

[morchu]

Try this :

https://drive.google.com/file/d/14zOVskgL4Eo_hxIbl3LJe9VHb9HOXZV5/view
https://drive.google.com/file/d/1HPKz5oRtJ4rWduINUkZCc54dEUFxEW8J/view

Second file is a readme. You want to upload (via adb is easiest) and untar the first file which contains the modified system squashfs and initird squashfs into /data/. This should create a directory /data/newsys in the chromecast. All needed files are in there. The script you want to execute is /data/newsys/newsys.sh

Let me know how it works out.

If this works and gives a stable chromecast in latest system for at least 30 minutes, then we can always restart other services.

One thing to note is that probably the dropbear executable compiled with Eureka may not be compatable with the new libc files. So you may want to execute the dropbear/ssh before executing the loopmount script, if you ever make the script execution automatic. But this is not an issue when doing the script execution manually.

Yes, ADB is enabled in the rooted CC (still at last Eureka release 44433.001) and I can successfully connect and adb shell into it.

Update: ADB is not really required if you start from the Eureka 44433 release as you can always easily set up a http server with for example "python3 -m http.server 8000" somewhere on a PC and then use "busybox wget ..." (busybox is included on that release) to pull the files on your CC.
In the meanwhile I copied your loopmount.sh script to /cache on the CC, then downloaded the 159268 OTA to a PC and extracted it ... now waiting for your instructions to get/build the modified initrd.sqfs and system.sqfs. I'd prefer a script to create them myself rather than binaries, but that is your choice.

Update2: Played around a bit, generating unmodified system and initrd sqashfs images on my PC to test the process:

# prereqs
sudo apt install abootimg
git clone https://github.com/ReFirmLabs/binwalk
cd binwalk/
sudo python3 ./setup.py install
# real stuff
mkdir -p ~/tmp/chromecast
cd ~/tmp/chromecast
./adb push ~/tmp/loopmount.sh /cache/
wget http://redirector.gvt1.com/edgedl/googletv-eureka/stable-channel/ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip
binwalk -e ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip 
cd _ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip.extracted/
# get the system image
file system.img 
binwalk -e system.img 
cd _system.img.extracted/squashfs-root/
mksquashfs . ~/tmp/chromecast/system.sqfs -all-root
# test system image
sudo mount -t squashfs -o loop ~/tmp/system.sqfs /mnt/
sudo umount /mnt/
# Now get the initrd
binwalk -e boot.img 
dd bs=256 skip=1 if=boot.img of=~/tmp/chromecast/aboot.img
cd ~/tmp/chromecast/
abootimg -x aboot.img 
file initrd.img 
mkdir rd
cd rd/
xz -d -c ../initrd.img | cpio -i -d -H newc --no-absolute-filenames
mksquashfs . ~/tmp/chromecast/initrd.sqfs -all-root
# test initrd image
sudo mount -t squashfs -o loop initrd.sqfs /mnt/
sudo umount /mnt/

Copied the images to the CC and executed the loopback.sh script. At first run I recognized that the sequence is wrong, as soon as system mount is overloaded, busybox is no longer available. So corrected loopmount.sh looks like:

#!/bin/sh
/chrome/cast_cli stop cast
mkdir -p /initrd
busybox mount -o loop,ro /cache/initrd.sqfs /initrd
busybox mount -o bind /initrd/lib /lib
busybox mount -o bind /initrd/sbin /sbin
busybox mount -o loop,ro /cache/system.sqfs /system
# cp -a /initrd/root/* /. #### this step is optional
start cast_receiver

Result: CC was still working a minute or so after the script ran, but then the screen turned black and CC was no longer reachable from Google Home app. Shell login (here: adb shell) still was there, so issued a reboot to verify that nothing is broken. After reboot CC came back up successfully so indeed nothing is broken permanently as expected.
So finally I only need your tweaks to the squashfs images for another attempt

 

[morchu]

i do not think it matters as much on which version of system and boot image you are currently running, to use the above loopmounts over and use latest system, as long as it is rooted (so that you can login and run the scripts). But it may work better with the latest version possible in the system/boot. I beleieve this was 80438 , which was the last version of bootimage which did not had internal key checks. After that Ken made a rooted version of 124602 using an older Eureka kernel. I am not sure which one works better.

The reason is the service definishions in the init.rc is already loaded to kernel memory before you execute any loopmounts, also there is a watchdog running monitoring the application /bin/PE_Single_CPU. So technically even though you can restart every other service from new system, you cannot restart the PE_Single_CPU binary using the above method.

But chromecasts main function.... which is casting is maintained by other binaries (mainly cast application). So I would think it should still functiion properly.

 

[metterschling]

Tried the process today.
The adb command sequence needs to be modified to

adb push newsys.tar.gz /data/.
adb shell 'cd /data && busybox tar -zxf newsys.tar.gz'
adb shell '/data/newsys/newsys.sh'

So this is running and the CC still stays alive, and I can confirm that the re-mounts are being performed.
The last command terminates with the following message:

./adb shell  '/data/newsys/newsys.sh'
[0508/162642:ERROR:cast_cli.cc(480)] failed to stop process_manager; manually deleting pidfile: pid=778
[0508/162642.903771:ERROR:package_utils.cc(432)] Cannot read PID of process manager: path=/tmp/process_manager.pid

however I can see additional tasks in the ps output that were not present before starting the script:

 1265 1000       0:00 /bin/logwrapper /chrome/cast_cli start cast async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify
 1266 1000       0:00 /chrome/cast_cli start cast async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify

Unfortunately I don't see any difference functionality-wise. Google Home still reports 1.16.44433.
The following processes were not impacted by the script:

  762 1000       0:00 /bin/logwrapper /system/chrome/process_manager --async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify
  763 1000       0:00 /system/chrome/process_manager --async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify

so could it be the case that these still do the main work and the new cast_cli is ignored?

 

[morchu]

What was the version of system/kernel you were running originally (before the loopmount of system)?

It appears like the original cast process was not stopped for whatever reason. There are ways to force kill it. Maybe you can try the steps in the shell script individually one at a time and make sure the original cast process was killed properly before doing to loopmounts and restarting of new cast process.

Tried the process today.
.........
so could it be the case that these still do the main work and the new cast_cli is ignored?

---------- Post added at 06:40 PM ---------- Previous post was at 06:19 PM ----------

Ohh I see you have listed it above. So you were using "1.16.44433."

Another local user had reported success with a rooted 80438 system with 1.22 kernel (1.22.80438), and doing loopmount on top of it, with the same exact script. I think that system/kernel combo rooted is in one of the xda threads. If I remember correct, that was the latest kernel /system combination with root builted and did not cause bricks.

But again, I do think it should still work with 1.16 kernel. It is probably just that you might have to stop a different service as well. Check the init.rc file in the root of your device to see the services started at run time. The hint is in the error message "failed to stop process_manager". So see what is the related service in there and see if you can stop that service gracefully.

I think only the PE_Single_CPU service/process is monitored by watchdog. So except that you can kill/restart other service. Even if you disturb the watchdog, the worst that can happen is a reboot.

It would be preferable to get it working on 1.16 kernel (so that no need to make any permanent changes).

What was the version of system/kernel you were running originally (before the loopmount of system)?

It appears like the original cast process was not stopped for whatever reason. There are ways to force kill it. Maybe you can try the steps in the shell script individually one at a time and make sure the original cast process was killed properly before doing to loopmounts and restarting of new cast process.

 

[metterschling]

It appears like the original cast process was not stopped for whatever reason. There are ways to force kill it. Maybe you can try the steps in the shell script individually one at a time and make sure the original cast process was killed properly before doing to loopmounts and restarting of new cast process.

But again, I do think it should still work with 1.16 kernel. It is probably just that you might have to stop a different service as well. Check the init.rc file in the root of your device to see the services started at run time. The hint is in the error message "failed to stop process_manager". So see what is the related service in there and see if you can stop that service gracefully.

I think only the PE_Single_CPU service/process is monitored by watchdog. So except that you can kill/restart other service. Even if you disturb the watchdog, the worst that can happen is a reboot.

It would be preferable to get it working on 1.16 kernel (so that no need to make any permanent changes).

You are right, executing the steps manually resulted in

# The stop at the beginning of the script
/chrome/cast_cli stop cast
/chrome/cast_cli: error while loading shared libraries: libcutils.so: cannot open shared object file: No such file or directory
# The stop at the end of the script
/chrome/cast_cli stop cast
[0515/144601.702682:ERROR:cast_cli.cc(564)] Timeout stopping process_manager at pid '765'. Please try again or manually clean package
echo $?
10
# So I waited a couple of seconds, then re-tried
/chrome/cast_cli stop cast
[0515/144631.142633:INFO:cast_cli.cc(586)] Successfully stopped process_manager at pid 765 in 10451 ms
echo $?
0

So if I start cast_receiver afterwards, I can report partial success. Google home is reporting 1.36.159268.
Unfortunately casting does not work, Google home is stuck forever "connecting", other apps start casting then drop back to disconnected state before playback starts.
So the script needs to be changed to wait for the proper exit code - this one works for me:

cat /data/newsys/newsys.sh
#!/data/newsys/busybox sh

/chrome/cast_cli stop cast

if /data/newsys/busybox test ! -f /initrd/root/build.prop; then
/data/newsys/busybox mkdir -p /initrd
/data/newsys/busybox mount -o loop,ro /data/newsys/initrd.sqfs /initrd
/data/newsys/busybox mount -o bind /initrd/sbin /sbin
/data/newsys/busybox mount -o bind /initrd/lib /lib
/data/newsys/busybox mount -o loop,ro /data/newsys/system.sqfs /system
#/data/newsys/busybox cp -a /initrd/root/* /.
fi

for i in `seq 0 9`; do
  /chrome/cast_cli stop cast
  if [ $? -eq 0 ]; then
    break;
  fi
  sleep 1
done
start cast_receiver

 

[morchu]

The message "error while loading shared libraries" while trying to stop the cast process indicates the issue.
Really the old cast process should be stopped "BEFORE" the loop mounts, since the libraries changed after the loopmount.

So to exit the process more elegantly, maybe add the wait before the loop mounts, and make sure the old cast process exited before even starting the loop mounts.

Another thing you can try is the command
"stop cast_receiver"

This should also stop the defined cast_receiver service, which has the cast binary process defined in init.rc

Either way, not having the error code on stopping the cast process to guarantee an elegant exit would make sure there are no memory leaks.

But I am glad that you got it working.

You are right, executing the steps manually resulted in

# The stop at the beginning of the script
/chrome/cast_cli stop cast
/chrome/cast_cli: error while loading shared libraries: libcutils.so: cannot open shared object file: No such file or directory
# The stop at the end of the script
/chrome/cast_cli stop cast
[0515/144601.702682:ERROR:cast_cli.cc(564)] Timeout stopping process_manager at pid '765'. Please try again or manually clean package
echo $?
10
# So I waited a couple of seconds, then re-tried
/chrome/cast_cli stop cast
[0515/144631.142633:INFO:cast_cli.cc(586)] Successfully stopped process_manager at pid 765 in 10451 ms
echo $?
0

So if I start cast_receiver afterwards, I can report partial success. Google home is reporting 1.36.159268.
Unfortunately casting does not work, Google home is stuck forever "connecting", other apps start casting then drop back to disconnected state before playback starts.
So the script needs to be changed to wait for the proper exit code - this one works for me:

cat /data/newsys/newsys.sh
#!/data/newsys/busybox sh

/chrome/cast_cli stop cast

if /data/newsys/busybox test ! -f /initrd/root/build.prop; then
/data/newsys/busybox mkdir -p /initrd
/data/newsys/busybox mount -o loop,ro /data/newsys/initrd.sqfs /initrd
/data/newsys/busybox mount -o bind /initrd/sbin /sbin
/data/newsys/busybox mount -o bind /initrd/lib /lib
/data/newsys/busybox mount -o loop,ro /data/newsys/system.sqfs /system
#/data/newsys/busybox cp -a /initrd/root/* /.
fi

for i in `seq 0 9`; do
  /chrome/cast_cli stop cast
  if [ $? -eq 0 ]; then
    break;
  fi
  sleep 1
done
start cast_receiver

 

[onyx1337]

Hi, guys decide to upgrade my cc from 44433.001 [2015-11-15] Eureka-ROM to something new to make spotify work.
I tried several steps from latest messages, but faced issue. Please help me.

so I tried firmware from @morchu

Try this :
https://drive.google.com/file/d/14zOVskgL4Eo_hxIbl3LJe9VHb9HOXZV5/view

with changes from @metterschling

cat /data/newsys/newsys.sh
#!/data/newsys/busybox sh

/chrome/cast_cli stop cast

if /data/newsys/busybox test ! -f /initrd/root/build.prop; then
/data/newsys/busybox mkdir -p /initrd
/data/newsys/busybox mount -o loop,ro /data/newsys/initrd.sqfs /initrd
/data/newsys/busybox mount -o bind /initrd/sbin /sbin
/data/newsys/busybox mount -o bind /initrd/lib /lib
/data/newsys/busybox mount -o loop,ro /data/newsys/system.sqfs /system
#/data/newsys/busybox cp -a /initrd/root/* /.
fi

for i in `seq 0 9`; do
/chrome/cast_cli stop cast
if [ $? -eq 0 ]; then
break;
fi
sleep 1
done
start cast_receiver

But something go wrong. It seems that flashed but after reboot nothing changed (spotify and other apps still doesn't work) and now in phone in chromcast settings I get next message 'Device is invalid or out of date. Please wait for software update to install or factory reset'


P.S.: after I made factory reset through web interface , I had a chance to go into settings and find out that firmware still 1.16.444333, but then several minutes later it showed previous error .

 

[metterschling]

Note that the above method does not really flash anything, it just live patches the system, so all changes are lost after a re-boot. Also note that my last post might have been misleading as it includes "worked for me". That was referring to the patching process, not the overall result.

In short: I got the patching script running as described, but the overall result did not work, casting was not possible with the patched system. I gave up.

 

[onyx1337]

@metterschling thank you, I got it,
then the last question is there any way to restore firmware to default using adb or ssh (without using otg cable) ?

 

[metterschling]

@metterschling thank you, I got it,
then the last question is there any way to restore firmware to default using adb or ssh (without using otg cable) ?

Nothing I am aware of. If a reset does not help, you need to to re-install via Flashcast.

 

[onyx1337]

Nothing I am aware of. If a reset does not help, you need to to re-install via Flashcast.

Hi, finnaly I found needed cable, but can you help and show me where I can find how to return to stock firmware using FlashCast, because In thread I can't find reset tutorial

 

[metterschling]

Hi, finnaly I found needed cable, but can you help and show me where I can find how to return to stock firmware using FlashCast, because In thread I can't find reset tutorial

Take a look at this parallel thread and the FlashCast instructions linked there for instructions to go back to a working Eureka: https://forum.xda-developers.com/showthread.php?t=2578653
It is simply too long ago since I did it last time so I don't have the exact steps at the top of my head.
If you want to switch to stock and lose root forever, a search in one of these threads should reveal the instructions. I never did that, want to keep root access for my device.