editing hosts file on HP Chromebook X2 71.0.3578.27

[nolirium]

editing hosts file on HP Chromebook X2 71.0.3578.27

[nolirium]

So it looks like the rooting script needs updating a bit. Hopefully I'll get that sorted quite soon. In the meantime, I took out my OG Flip (arm) on v72 and just tried the script again on this device for the first time in a little while. I did notice an error from sed near the start, as it couldn't find /etc/init/arc-setup-env.

It turns out that the location on the filesystem of the pair of flags that tell /usr/sbin/arc-setup to set up a writable container mount and to make Android boot with ro.debuggable has been recently changed (again), and, at least in v72, these are now in /usr/share/arc-setup/config.json.

I guess something like the following has to be added to the script now.

if [ -e /usr/share/arc-setup/config.json ]; then
  mkdir -p /usr/local/Backup/arc-setup
  echo "Copying usr/share/arc-setup/config.json to /usr/local/Backup/arc-setup/config.json.old"
  cp -a /usr/share/arc-setup/config.json /usr/local/Backup/arc-setup/config.json.old
  cp -a /usr/share/arc-setup/config.json /usr/share/arc-setup/config.json.old
  echo "Setting '"ANDROID_DEBUGGABLE": true' and '"WRITABLE_MOUNT": true' in /usr/share/arc-setup/config.json"
   sed -i 's/"ANDROID_DEBUGGABLE": false/"ANDROID_DEBUGGABLE": true/g' /usr/share/arc-setup/config.json 2>/dev/null
   sed -i 's/"WRITABLE_MOUNT": false/"WRITABLE_MOUNT": true/g' /usr/share/arc-setup/config.json 2>/dev/null
fi

After running the above in the CrOS shell, rebooting CrOS, and then also changing the 'ro' to 'rw' in init.rc and rebooting Android

sed -i.old 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
printf reboot | android-sh

Everything was then writable as normal. Hopefully that'll be the same for you? (Although I wouldn't be surprised if there may be something different in v71)...

Oh, and regarding the issue with the hosts, not too sure about that - I do remember having trouble with a relative symlink there at some point myself, but I can't recall the specifics now, unfortunately. I think it might have been problematic having a relative symlink that's pointing outside of the container, maybe? It was a while back now and I can't remember now whether I got it working or if I just dropped the attempt in favor of figuring out how to get the system writable again.

[mmirg]

Editing /usr/share/arc-setup/config.json fixes the mounting the ARC rootfs as writeable and everything seems to be working as normal again in v71. I'm perplexed as to the issue I was having with editing the hosts file. It works when the rootfs is writeable but it doesn't work when I have the file symlinked to /data. I can't figure out what mechanism might be causing this.

I haven't been submitting pull requests against the script as I figured that you might want to merge the two branches and get things up to speed in the future. Perhaps it's worth waiting for v73 to hit dev? My understanding is that canary on some devices is running Android Pie in ARC++ and I assume some further tweaks will be needed when that change lands.

As for editing init.rc to mount rootfs as rw, I presume this can be done in the script and applied to /usr/local/Android_Images/Mounted beforehand rather than rebooting and then manually patching init.rc?

[nolirium]

Apologies for the delayed response. I was waiting until after I'd had a proper chance to look into why the symlinked hosts file wasn't working. Unfortunately I haven't been able to figure it out yet either.

Editing /usr/share/arc-setup/config.json fixes the mounting the ARC rootfs as writeable and everything seems to be working as normal again in v71. I'm perplexed as to the issue I was having with editing the hosts file. It works when the rootfs is writeable but it doesn't work when I have the file symlinked to /data. I can't figure out what mechanism might be causing this.

My initial thought was that it could be to do with the ongoing "Hardening against malicious stateful data" efforts, which have lately included much blocking of symlinks etc. on the stateful partition, with some whitelisting.

I'm not too familiar with some of the vagaries of the cryptohome mount flow etc., so am unsure about this at this point. The arc++ container-bundle readme has the following:

Once the user signs in, arc_setup.cc‘s OnBootContinue() function unmounts the read-only /data, and then bind-mounts /home/root/${HASH}/android-data/{data,cache} to /data and /data/cache, respectively. These source directories are writable and in Chrome OS user’s encrypted directory managed by cryptohome.

If the issue were caused by the symlink blocking policy, then per /sbin/cros_startup (source) we should normally be able to manage it by either creating /usr/share/cros/startup/disable_stateful_security_hardening, or maybe just adding the correct file path into the file located at /usr/share/cros/startup/symlink_exceptions/arc-symlink-exceptions.txt

However, those didn't work for me, and I am still unsure about whether this actually is the cause of the issue.

I haven't been submitting pull requests against the script as I figured that you might want to merge the two branches and get things up to speed in the future. Perhaps it's worth waiting for v73 to hit dev? My understanding is that canary on some devices is running Android Pie in ARC++ and I assume some further tweaks will be needed when that change lands.

Yes, I imagine some changes may be needed, and as you suggest, once the dust settles on P, it might be a good time to tidy up the script/merge the branches and such.

In the meantime, if it isn't too much trouble, please feel free to let me know of any major issues or potential improvements though.

As for editing init.rc to mount rootfs as rw, I presume this can be done in the script and applied to /usr/local/Android_Images/Mounted beforehand rather than rebooting and then manually patching init.rc?

Oh yes, sure. I've added this to the script now. I was just intending to emphasise in my comment for anyone else reading at the time, that the config.json fix wouldn't work without also doing the init.rc fix.

[OScommander]

Is there an updated script to address these issues?