yashsingh1/xdaforums huggingface dataset:
[Google Chromecast] 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.
[Google Chromecast] 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?
[Google Chromecast] 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.

---------- 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).
[Google Chromecast] metterschling:
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
[Google Chromecast] 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.
[Google Chromecast] 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 [MENTION=1635564]morchu[/MENTION]

with changes from [MENTION=5463045]metterschling[/MENTION]

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 .
[Google Chromecast] 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.
[Google Chromecast] onyx1337:
[MENTION=5463045]metterschling[/MENTION] 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) ?
[Google Chromecast] metterschling:
Nothing I am aware of. If a reset does not help, you need to to re-install via Flashcast.
[Google Chromecast] onyx1337:
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
[Google Chromecast] metterschling:
Take a look at this parallel thread and the FlashCast instructions linked there for instructions to go back to a working Eureka: https://xdaforums.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.
[Google Chromecast] rbeavers:
Been updating for an hour and a half. When should I, reboot, give up and buy a new one? ?
[Google Chromecast] jasenko:
No issues upgrading here.

Would like to see some examples how and what people enabled in their scripts. Not sure where to find the available options / syntax?
[Google Chromecast] rbeavers:
Still flashing, pulled log says, replace stock recovery. Input output error.

Any idea if getting the teensy out and re rooting while do more harm than good?

---------- Post added at 12:47 PM ---------- Previous post was at 12:39 PM ----------

I only see, did two commands?
[Google Chromecast] rbeavers:
Teensy didn't work no Recovery? Will try adb?
[Google Chromecast] Disconn3ct:
I was reading over the script and I caught a minor potential bug. (Potential because it will only kick in if you change a path, but it will be pretty unexpected if it does and it will unroot the device..)

On line 126:

flash_image --scan-all recovery /data/temp/root-recovery.img

For consistencies sake, it should probably use the same variable as elsewhere in the code:

flash_image --scan-all recovery "$ImgSave"

---------- Post added at 10:53 AM ---------- Previous post was at 10:03 AM ----------

Try connecting via ssh (root / letmein) and see if it is hung up in flashcast.

Looking at the log in /tmp/tmp.xFqtjM/flashcast-data/3/log.txt (your path will vary) mine just hung at:

Copying /usr/share/flasher/autoroot-ota to /tmp/tmp.Q2MGBL
Flashing mod at /tmp/tmp.Q2MGBL
Extracting ota.zip to /tmp/tmp.IAJLgg
Archive: /tmp/tmp.xFqtjM/ota.zip
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
inflating: META-INF/com/android/metadata
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: boot.img
inflating: bootloader.eureka-b3
inflating: ota.prop
inflating: system.img
Flashing Kernel
Flashing /tmp/tmp.IAJLgg/boot.img to kernel (mtd2)
Flashing System
Flashing /tmp/tmp.IAJLgg/system.img to rootfs (mtd3)
Cleaning Up
Starting System Modification
Setting up squashfs union at /tmp/tmp.xFqtjM/flashcast-data/3/tmp/tmp.TlBHmO
Replacing Stock Recovery
dd: /dev/mtdblock6: Input/output error

Dmesg is showing IO errors on mtdblock6. Time for some more investigating.

Update: After a reboot it tried to unroot. So be very careful if you end up here. I'll post a fix when I get it (or at least, whether redoing eureka works) Redoing flashcast 1.3 and eureka worked, back to where I started. DON'T let it do any updates - if you see the spinning chrome logo at any point, unplug it and regroup.
[Google Chromecast] rbeavers:
Ok back to where I started, in putty used rebooted command (thanks Disconn3ct for the idea) . Got Red light rebooted to white light no screen no network ip. Teensy then worked, still on newest build.

Tried to rerun busybox wget http://pdl.team-eureka.com/recovery/install.sh -O /cache/install.sh , said it downloaded but busybox chmod +x /cache/install.sh /cache/install.sh

does nothing.

Guess I'll try on 2nd CC ?
[Google Chromecast] manaox2:
I just did the update from the latest Eureka. I did get the error "First block failed verification at byte 8 of 10743808. Wrote 11 replacement blocks to recovery."

Then it took about 10 minutes or so in flashcast, but then the spinning chrome logo came up. SSH does not work, but telnet does. Looks good!

Posting in case someone else was concerned about doing this update. Thanks!
[Google Chromecast] winnph:
Just did the update from Eureka, everything went OK (did get the error about failing verification and writing to recovery though), except after the reboot it's now hung on the Eureka "Please Wait" screen for nearly half an hour. I tried to telnet in, that timed out. How long to wait until I give up? What is the next step if this keeps up?

UPDATE: On a whim I tried to use ssh and that logged in fine. I sent a reboot command and... spinning Chrome logo, WHAM! lost root. So... well, at least now I'm at the latest OTA! But root is gone. Oh well.
[Google Chromecast] Asphyx:
You didn't lose root...

There is no Eureka screen once you instal this...
[Google Chromecast] monleylord:
You have root, latest chromecast Version and telnet "only"
[Google Chromecast] fldc:
Well, I have no telnet, no root, no nothing after this. :P
[Google Chromecast] winnph:
No, the Eureka screen came up during the install, then after it finished and rebooted, I have lost root. No telnet access, nothing.

---------- Post added at 02:43 PM ---------- Previous post was at 02:35 PM ----------

Yeah, same here. I mean I wasn't really using root anyhow, so I guess it's not the end of the world. But for anyone who cares about having root, don't install this until someone can explain why it's broken for some users.
[Google Chromecast] Asphyx:
What makes you say you lost root?

The fact Telnet didn't work or something else?
[Google Chromecast] Srandista:
Just to let you guys know, I was a bit frighten before updating my CCs, since there was posts from some, that you may loose root during update. I can say though, that I update both my old gen CCs to newest version without any problems, and root is still presented on both of them.
[Google Chromecast] Asphyx:
Either the folks who think they lost root have an issue with Telnet (port blocked?) and just assumed that meant they lost root or something went wrong with their installation.

To be honest there really isn't a great need for root anyway unless you wish to play with DNS settings.

This project just allows us to keep it while being fully up to date should something else come up later on.
[Google Chromecast] Ashcunak:
going from 44433.001 Eureka-ROM ran the script via telnet got the error as per below:

First block failed verification at byte 8 of 10743808. Wrote 11 replacement blocks to recovery.
AutoRoot-Recovery: Process Complete! Cleaning and rebooting...

it rebooted on its own and than it went to a stock chromecast is updating screen so i pulled the plug as it was downloading an image, i could reconnect via telnet while it was downloading.

i assume something has failed now on this?

how do i recover do i need to go back and use my teensy or is there a way i can avoid using that?

OORRR.. is this operating as its expected?
[Google Chromecast] Asphyx:
I think you guys are expecting to see a Eureka screen instead of the standard Chromecast and screwing up the install because you are panicking and powering the unit off.

THIS IS NOT EUREKA!

This is simply a bootloader that makes sure Standard Chromecast updates stay rooted!

When it boots up it looks very much like a stock CCast.
[Google Chromecast] Ashcunak:
i am not expecting a eureka screen, i am wondering if its okay to let it auto update like this

Just reading through i see nobody else mentioning that after it finalizes and flashes it starts to download an update from google right away, is the install script when its ran downloading an old image

I want to know if this is a normal thing for it to be doing.
[Google Chromecast] Asphyx:
Yes that is the whole point of the Autoroot!

It replaces the stock bootloader and Roots all normal OTA updates when they install.

The updates look just like the stock non-rooted updates do. Because they are pretty much stock updates with a hidden secret thanks to the AutoRoot bootloader installed.
[Google Chromecast] Ashcunak:
so yes, its operating as expected.

Okay thanks.
[Google Chromecast] vagabondin:
How do i know if I am rooted or not. Cant SSH or Telnet. I am on Mac

telnet 192.168.1.4

Trying 192.168.1.4...

telnet: connect to address 192.168.1.4: Connection refused

telnet: Unable to connect to remote host

ssh root@192.168.1.4

ssh: connect to host 192.168.1.4 port 22: Connection refused
[Google Chromecast] Asphyx:
Port 23 Only with Telnet
[Google Chromecast] vagabondin:
I pinged chromecast

ping 192.168.1.4

PING 192.168.1.4 (192.168.1.4): 56 data bytes

64 bytes from 192.168.1.4: icmp_seq=0 ttl=64 time=2.213 ms

64 bytes from 192.168.1.4: icmp_seq=1 ttl=64 time=2.147 ms

Then tried this from terminal:

telnet 192.168.1.4 23

Trying 192.168.1.4...

telnet: connect to address 192.168.1.4: Connection refused

telnet: Unable to connect to remote host

I have a feeling that it managed to update itself in middle of process. Now i can even access flashcast log. On the log it had shown error same as of of the previous posts. at some point i got chrome thingie. Problem is I am trying to do flash again with OTG cable but the light on chromecast is red all the way from start.
[Google Chromecast] Asphyx:
Well did you interrupt the initial install like others did?

That may have screwed up root I suppose....

All I know is I'm on the latest and Telnet works fine for me which means it's nothing about the Google Update version that is breaking the root.
[Google Chromecast] vagabondin:
Well it was on FlashCast screen for an hour and nothing moved. So, i rebooted from SSH and then it came back on and had the logo.
[Google Chromecast] Asphyx:
Well (I'm only guessing here) it may be that any interruption to the Flashcast Autoroot installation can cause you to lose root.

It does take quite awhile for the install to complete on the initial install.

You should have seen the install progress from SSH or Telnet not go by the CCast itself.
[Google Chromecast] Pietplezier:
Everything went well, have telnet connection!

But how to change the DNS Ip addresses? i need this :)

I guess i need to edit /etc/resolv.conf, but how to edit this file?
[Google Chromecast] Asphyx:
(From 1st Post!)

Q: How do I setup custom DNS servers?

A: Put the IP addresses of the DNS servers in a file at /data/dns.conf, one per line. On next boot these will be used for DNS requests. Note if you are coming from EurekaROM, it will already have your old settings in place.

See this for copying files in Telnet

http://unix.stackexchange.com/questions/171456/download-n-upload-files-via-telnet-session
[Google Chromecast] KenMacD:
For others that screw this up and reboot during the second stage, you may not have lost root.

I did the same, and was unable to telnet or ssh in to the chromecast.

I used an OTG cable and flashed an old version of Eureka-ROM from a USB stick by holding the chromecast button.

I then had to allow Eureka-ROM to update to avoid the error:

usage: flash_image partition file.img

Finally I redid the original steps but allowed the flashcast state to complete and everything works.
[Google Chromecast] mobileman88:
Hi, how should I clean up all my customizations to pass it to a friend while keeping this flashcast autoroot? The unit seems to have already updated to the newest Google rom. I can still telnet to the unit.
[Google Chromecast] Asphyx:
As I suspected the Root is retained but interrupting the initial GRom install messed up Telnet.

Nice fix for those who freaked out and didn't let the install finish.

What kind of customizations did you make?

You can change the DNS by editing the file. Just put in Google DNS entries and let your friend edit those as needed.
[Google Chromecast] mobileman88:
I was playing around with it quite a bit last year which is why I would prefer to reset it while keeping it rooted before I pass it to him. It'd be much easier for him to use it without any changes.
[Google Chromecast] Asphyx:
Well without specifics it would be difficult to reset it without having to go through what [MENTION=5427201]KenMacD[/MENTION] did and reflash Eureka then redo the Autoroot. install.

Flashing Eureka should wipe out any modifications you made to autoroot.
[Google Chromecast] mobileman88:
Thanks. Will probably do that when I find the time over the weekend.
[Google Chromecast] woody1:
Does anybody know how I can enable SSH on Flashcast-AutoRoot? Sounds like some BusyBox apps are installed already, but not SSH. How hard would it be to install DropBear (or OpenSSH)?
[Google Chromecast] Asphyx:
Not sure exactly what it would entail....

But I suppose if the Telnet is done via an executable on the device, replacing it with an SSH executable instead might be one way to go.

But I really have never looked at the internals of what the Autoroot has on the device.

And it might be that Telnet is required for it to do what it does so I suggest Writing to [MENTION=2212097]ddggttff3[/MENTION] and asking before you attempt that idea.
[Google Chromecast] ddggttff3:
If you use the SSH binary from our stock rom, it should be as easy as uploading the binary to the device via telnet/wget or whatnot, and then creating a script to start it with the device.

So for example you could do the following over telnet on the device, where 192.168.1.2 is your local computer running a web server with the files from https://github.com/team-eureka/Eureka-ROM/tree/master/basefiles/bin

busybox mkdir /data/ssh
cd /data/ssh
busybox wget http://192.168.1.1/dropbear
busybox wget http://192.168.1.1/dropbearkey
busybox chmod +x ./*

Once done, make a file at /data/user_boot_script.sh and set it to be executable. Once done, just add the following:

if busybox test -f /data/flashcast/dropbear/dropbear_dss_host_key && busybox test -f /data/flashcast/dropbear/dropbear_rsa_host_key; then
echo "Triggering SSH " > /dev/ttyS0
/data/ssh/dropbear -d /data/flashcast/dropbear/dropbear_dss_host_key -r /data/flashcast/dropbear/dropbear_rsa_host_key -P /tmp/dropbear.pid &
else
echo "SSH Keys Missing, Generating " > /dev/ttyS0
busybox mkdir -p /data/flashcast/dropbear/
/data/ssh/dropbearkey -t rsa -f "/data/flashcast/dropbear/dropbear_rsa_host_key" > /dev/null 2>&1
/data/ssh/dropbearkey -t dss -f "/data/flashcast/dropbear/dropbear_dss_host_key" > /dev/null 2>&1
echo "Triggering SSH " > /dev/ttyS0
/data/ssh/dropbear -d /data/flashcast/dropbear/dropbear_dss_host_key -r /data/flashcast/dropbear/dropbear_rsa_host_key -P /tmp/dropbear.pid &
fi

Note this is just an example, and I did not test it (as my dev chromecast is sadly dead), but this in theory should work. Now back to the shadows I go.....
[Google Chromecast] woody1:
Thanks! Your solution for adding an SSH server worked perfectly!
[Google Chromecast] mathorv:
[MENTION=2212097]ddggttff3[/MENTION]

Is there any way to use ssh with user/pass and disable telnet at the same time?
[Google Chromecast] mathorv:
[MENTION=2212097]ddggttff3[/MENTION]

or alternatively way for telnet automatically disable after x second without user interaction(to cancel planned daemon stop)

This would narrow possible attack surface.
[Google Chromecast] ddggttff3:
There is no way to setup a user/pass for SSH with that specific binary, but if you want to disable telnet this can easily be done by having your startup script kill the "busybox telnetd" process (via name or pid) on the chromecast.