yashsingh1/xdaforums huggingface dataset:
[Chromebooks] ChrisBeeezy:
Wayyyy out of my area of expertise, but here's my (completely novice) best guess.

>All Chromebooks are write-protected with a screw on the motherboard

>Putting a Chromebook in developer mode allows for some tinkering ie things like chroots, and on the asus flip, the ability to install apks from unknown sources.

>Unscrewing the write-protect screw allows for the ability to completely install a new operating system or dual boot setup.

>Maybe you need to do that before you're able to accomplish root access?

My other idea would be to try and figure out a way of doing a systemless root?

Also, total aside but since this is the only thread I've found on XDA about this device, I think chroots are theoretically possible now without the need to be in developer mode via Android apps (even without root on Android). Download the GIMP port from the Play Store to see what I'm talking about. Playing around with that for a few minutes really made me wish that it didn't use emulated mouse/keyboard in it's implementation. Also, it appears that apt-get is broken, but regardless it might interest someone out there looking for a project.
[Chromebooks] trevorcobb:
back from the dead, any progress on this?
[Chromebooks] Nolirum:
I have been able to successfully root the Android image on my Asus Flip.

I built a blank image with dd in /usr/local, formatted it with mkfs, mounted it to a folder, mounted the original system.raw.img to a folder, copied the files across, placed *all* the SuperSU files listed as 'required' in the SuperSU update-binary in the relevant places in /system in my new image, set permissions & contexts for those files, edited arc-system-mount.conf and arc-ureadahead.conf to point to the new image and, finally, patched /etc/selinux/arc/policy/policy.30 with the SuperSU sepolicy patching tool in order to boot my rooted Android instance with selinux set to enforcing.

I have created a couple of scripts which more-or-less fully automate this procedure, which can be downloaded from nolirium.blogspot.com. Please feel free to download, open the scripts in a text editor to check them out, and try them out if you like. Only tested on Asus Flip, though.

I seem to be unable to post attachments at the moment so I will just add the descriptions here, I could probably post the entire scripts here too if anyone wants. Feel free to let me know what you think.

DESCRIPTIONS:

1-3.sh

Combines the first three scripts listed below.

01Makecontainer.sh

Creates an 900MB filesystem image in /usr/local/Android_Images, formats it, then copies Android system files therein.

02Editconf.sh

Modifies two system files: arc-system-mount.conf - changing the mount-as-read-only flag and replacing the Android system image location with a new location; and arc-ureadahead.conf - again replacing the Android system image location. Originals are renamed .old - copies of which are also placed in /usr/local/Backup.

03Androidroot.sh

Mounts the previously created Android filesystem image to a folder, and copies SuperSU files to the mounted image as specified in the SuperSU update-binary.

04SEpatch.sh

Copies an SELinux policy file found at /etc/selinux/arc/policy/policy.30 to the Downloads folder, opens an Android root shell for the SuperSU policy patching command to be entered, then copies the patched policy back to the original location. A copy of the original policy.30 is saved at /etc/selinux/arc/policy/policy.30.old and /usr/local/Backup/policy.30.old

Uninstall.sh

Removes the folder /usr/local/Android_Images and attempts to restore the modified system files arc-system-mount.conf and arc-ureadahead.conf.
[Chromebooks] keithkaaos:
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
[Chromebooks] Nolirum:
The R13 has a 64-bit Mediatek processor, right?

I have added a version for ARM64, but I haven't tested it.

You can find the instructions and scripts at nolirium.blogspot.com
[Chromebooks] keithkaaos:
ya, its a mediatek. and thanks ill go see if i can find it :)

---------- Post added at 03:31 AM ---------- Previous post was at 02:58 AM ----------

wow, ok. i can do this but im not sure i want to.. after reading the possible problems i may run into. Im going to be getting the G. Home in a couple weeks and i gotta keep things running smooth. This seems like going a tad too far then i need to. The other day i had action launcher going and it looked pretty damn good but i really want to try and get the action3.apk that i have put into the pri-app folder or whatever the chromebook uses i found the syst folder but cant access it. Im wondering if i make the machine writable it would work but im afraid of losing my updates, as long as i could do them manualy, i guess that would be cool. Also since im already going on... has anyone found a way to disable the dev boot screen without tinkering with the physical chromebook yet?
[Chromebooks] keithkaaos:
SuperSU on Chromebook

Hey there I love this post but unfortunately im on the mediatek (well not unfortunately cause i love it) but i do really want super su .. But i found this other post that i tried out but i am having a problem executing the scripts. When i go to run the first one, it says can not open "name of script" but the dev takes a pretty cool approach. Im still new to Chrome OS but thanks for the post and if you have any advice on executing scripts id love to hear it!!:D http://nolirium.blogspot.com/
[Chromebooks] Nolirum:
I'm guessing the above post was moved from another thread...

Anyway, it turns out that zipping/unzipping the files in Chrome OS's file manager sets all the permissions to read-only. Apologies! sudo chmod+x *scriptname* should fix it...

Regarding OS updates, I actually haven't had a problem receiving auto-updates with software write-protect switched off; the main possible potential issue I could imagine arising from the procedure I outlined would involve restoring the original conf files if both sets of backups get deleted/overwritten. This seems unlikely, but in that case either manually editing the files to insert the original string (/opt/google/containers/android/system.raw.img), or doing a powerwash with forced update might be necessary in order to get the original Android container booting again.

I don't think anyone's found a way to shorten/disable the dev boot screen without removing the hardware write-protect screw - from what I've read, the flags are set in a part of the firmware which is essentially read-only unless the screw is removed. Perhaps at some point the Chrome OS devs will get fed up of reading reports from users whose relatives accidentally reset the device by pressing spacebar, and change the setup. Here's hoping.
[Chromebooks] fattire:
Hey just jumpig in the thread right quick to see if these instructions are old or what-- got a chromebook pro and the notion of having to update a squashed filesystem every timeto install su seems like a pain..

Is there any kind of authoritative documentation/breakdown regarding what Chromeos is mounting where before I start breaking things? Also anyone happen to know if there's a write-protect screw anywhere in the chromebook plus/pro?

Other questions:

* adbd is running, but is not accessible from adb in the (linux) shell, which shows no devices. Do I need to access adb from another device (i'm short a usb c cable right now) or can I use adb (which is there!) on the chrome side to access adbd on the android side?

* Anyone know if adb via tcp/ip is available? Don't see it in the android settings.
[Chromebooks] fattire:
Hey this is a great response.. thanks!

verity

Yeah playing with it now, I'm looking at these /etc/init/arc-*-conf files... I see that the /dev/loop# files are being set up... (more below)

Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is? (update: I guess that's what rootfs verification does, and we can turn it off....)

Also you mean arc-setup.conf:

env ANDROID_DEBUGGABLE = 0

right?

I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...

Heh.. not gonna be me..

Cool-- adb connect 100.115.92.2 does indeed work :) I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon... btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example... would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?

It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default witho no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...

Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while :)

Cool I'll take a look at these scripts.
[Chromebooks] fattire:
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:

if [ -e /etc/init/arc-setup-env ]; then

echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"

This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf

Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
[Chromebooks] Nolirum:
Oh, the arc-setup-env thing is intentional. There does appear to be another issue with the x86 version though. I've written up a detailed response to your previous post; it's in a text file at the moment so I'll copy it over and format it for posting here with quotes etc now - should only take a few minutes. Yeah, sticking them on github might be a good idea; I've been meaning to create an account over there anyway.
[Chromebooks] fattire:
Great response! I read it once and I'll read it again in more detail then will probably have questions :) For whatever it may be worth, my only experience with chromiumos was building the whole thing maybe 4 years ago for my original 2011 Samsung "snow" Chromebook-- and making a bootable USB (or was it an SDcard?) to run it on (with a modified firmware that did... something I can't remember.. i think it was basically a stripped down uboot and I remember adding a simple menu or something-- I think I was trying to bypass that white startupscreen or something..). However, after doing this a few times to play with it, I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.

I did have it re-partitioned to run linux as a dual boot from the SD slot or something-- I remember using that cgpt thing to select the different boot modes and vaguely recall the way it would A/B the updates (which "O" is now doing)... but anyhoo I was using the armhf ubuntu releases with the native kernel and ran into all kinds of sound issues and framebuffer only was a little crappy so...

I'm gonna re-read in more detail soon and I'm sure I'll have questions-- one of which will be-- assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?

This is the -env file I'm missing, I presume?

It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?

Here's what I'd ideally like to see:

* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos

* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...

* what else... I dunno watch this space.
[Chromebooks] Nolirum:
An update from a couple of guys that have tested out the scripts on Intel: It seems to be that while they are able to launch daemonsu manually (with daemonsu --auto-daemon), it apparently does not seem to be getting launched at boot.

I am waiting for some more information on this. Previously, for Marshmallow, the script was setting up the app_process hijack method in order to to launch daemonsu at boot; to support Nougat I changed it to instead create an .rc file with a service for daemonsu, and add a line to init.rc importing it. This works for me, and from what I can gather, it copied/created all files successfully on the testers devices, too, so I'm not sure at this point what the issue is there.

Edit: Fixed the issue. I updated my previous post with further details.

lol yeah. True, that.

It's literally just two things that differ: the few lines where we copy the su binary over e.g.

/x86/su.pie → /system/xbin/su, daemonsu, sugote

vs

/armv7/su → /system/xbin/su, daemonsu, sugote

...and also the size of the created container. The x86 container is about 30 percent larger than the Arm one.

I had a little look at how to determine the CPU architecture programmatically on Chrome OS a while back, but couldn't seem to find a reliable way of doing this, at least not without maybe getting a bunch of people with different CrOS devices to run something like, as you mentioned, uname -i (which returns 'Rockchip' on my device, uname -m (which returns 'armv7'), or such similar, and collating the results. It was just easier to do separate versions for x86/arm, rather than introduce more conditionals (with potential for errors). I'm certainly not averse to adding a check for $ARCH, and thus standardizing the script, as long as it's reliable.

Yep! It's just the same few envs as in the .confs, moved into a new file. I'm fairly confident that the script's conditionals deals with them OK.

Yeah, although the respondant there perhaps doesn't seem to realise that he's talking to a Google/Chromium dev, the way he responds. Not that that makes anything he says in his post is necessarily less valid, though.

Interesting... I agree, those would both be useful additions to the functionality of ARC++...
[Chromebooks] fattire:
Quick question-- has Samsung provided the source for the GPL components (including the kernel, obviously)? I looked here but didn't see anything...? Previously the kernel was included along with the chromium source and there was like a kernel and kernel-next repository.. but this was like five years ago. I think the codename for the samsung chromebook pro is called caroline... let me quickly see if I can find a defconfig in the chromium source...

Back.. nothing here in the chromeos-4.4 branch. Nothing here either in the master branch. Maybe I'm looking in the wrong branches-- master is probably mainline kernel. Also the directories.. it took me five minutes to realize it wasn't going to be in arch/arm - force of habit I guess. I'll keep looking unless anyone knows. This "chromium-container-vm-x86" one seems to have dm_verity as an unused option. Ah, this is looking promising.

...and... here!

So it would seem that this would be built as part of the chromiumos build system, which seemed to be half gentoo five years ago building out of a chroot and was kind of a pain to set up... still, I'm guessing that since it's got that weird script to make the defconfig, what you could do is use google's chromiumos build script to make the kernel image (with whatever changes you want), then, assuming that it doesn't care if you replace the kernel, just throw it over the right Kernel A/B partition and see if it boots and starts up chromeos... it's weird cuz the kernel has to do double-duty for chromeos and android.. but I bet you can just replace it and it would work fine...
[Chromebooks] Nolirum:
I had a cursory go at building a couple of kernel modules for my Flip C100 a while back - I didn't get too far though, lol. People do seem to have had success building their own kernels and running them with Chrome OS though, as with most things I suppose it's just how much time/effort you're willing to put in.

I think I used this and maybe this, from the crouton project to guide me.

From what I remember, I just got fed up of all the arcane errors/config choices. I remember that even though I'd imported my current device config from modprobe configs, there were then such an incredibly long string of hoops/config choices to have to go through one by one, to then be confronted with various errors (different every time ISTR) that I think I just thought "screw this". I think there were some other issue with the Ubuntu version I was using at the time as well. I know that sort of stuff's kind of par for the course with kernel compilation, but I was mainly only doing it so I could edit xpad in order to get my joypad working, in the end I found a different solution.

It shouldn't be too much hassle though, in theory I guess.... Oh, also, in order to get a freshly built kernel booting up with the CrOS rootfs, in addition to the gpt flags, I think you might have to sign it, too? (just with the devkeys & vbutil_kernel tool provided on the rootfs), some info here, and here.
[Wileyfox Storm] DoctorDoctrine:
Hi all,

I got my Wileyfox storm running stock CMOS 13.0 in April and had no problems for about a month. Eventually, I got a pop-up notification with an "Incremental Update" for the phone. I downloaded it and when ready to install, I did so - or at least tried. The update finished and booted into recovery for some reason. At the time I didn't question it and just rebooted the phone from recovery. This led to a boot hang on the "Cyanogen Mod Ready" boot screen.

After searching around for a fix I eventually tried to flash over the stock ROM via Fastboot - which for some reason errored on emmc_appsboot and the phone rebooted itself - with a penguin instead of the Wileyfox boot logo and STILL hangs on the Cyanogen screen. I can also now not boot into fastboot and not boot to fastboot from recovery either (which I CAN still boot to).

Does anyone have any ideas on how to fix this ASAP??? Help would be greatly appreciated!

Many thanks.
[Wileyfox Storm] runnaround:
I've finally found something that works, unplug the battery for a day or two, then plug in and charge and turn on and might boot properly. Frustrating having to do it every time you get into the bootloop hang and doesn't work every time but still probably salvageable.....I discovered after being bricked for 14 months.
[Android Q&A, Help & Troubleshooting] bhaskarslg:
I need usb drivers for Infocus M2 3G to root the device.
[Networking] robertouk:
I just bought a 3 sim card and using the £5 a month payg data plan.

Internet explorer and opera is fine, google maps is fine. but windows live messenger will not connect. gets to checking internet connectivity and hangs . never connects.

Has anyone managed to get any version of live messenger to work with a 3 sim ?

Im using it in an AMEO , Wm6

tia
[Networking] 300000:
no way to connect it I have the same that and i think they block all port except 80 for internet explorer , i have some app to which go to the net to update information but fail to connect so that is price 5 pound for 2 g data just use explorer
[Networking] sl9:
That "data plan" only allows you to access 3's own web sites, it is NOT full (or even partial!) internet access at all. It is a big con basically, if you want data then join another network - T-Mobile have the best data plan right now!
[Networking] robertouk:
hi, im using it to send this. web access is fine. no restrictions i can see. would be complete if messenger ran, wondered if there was some way around or specific version of msn.
[OnePlus 3 Questions & Answers] jordanday98:
Hi guys, let me be clear, I really messed up and I'm freaking out. I'm a flashing noob and I really shouldn't have tried doing this.

I tried to follow a guide on how to unlock the bootloader, flash TWRP, root and flash a custom ROM, everything was fine up until the rooting part. I figured I'd stay on stock ROM, so I flashed the full zip of what was the latest stock ROM then (3.1.3) and left it at that.

I've since tried to update to 3.2.0 and 3.2.1, and it's been a nightmare. TWRP wouldn't install the incremental update zips so I flashed back to stock recovery and tried it with that, didn't work. I've tried ADB sideloading the incremental update but it stays at 48% and then fails. I don't know if I can RMA the device, so I'm reaching out to you guys for help here. I want to flash back to 100% stock so I can just update as normal.
[OnePlus 3 Questions & Answers] Le_Zouave:
1/ flash again twrp

2/ flash one of the full rom but not 3.2.1

3/ wipe userdata

4/ boot to see if everything is ok

5/ flash the OTA to 3.2.1 according to the version you flashed in step 2 (if you don't understand that part, just ask)

6/ flash supersu if you want to root

It's important to wipe your data even if it can work without wiping. On nexus device for example a full official zip contained a blank user userdata.img so it wipe all the data, it's not the case for OP3 full image.

You can directly flash 3.2.1 but it's not the point, you have to test the OTA that way.

And at last, the link for the full rom and OTA

https://forums.oneplus.net/threads/...ficial-oxygen-os-roms-and-ota-updates.450783/

http://xdaforums.com/oneplus-3/how-to/mirrors-official-oxygen-os-roms-ota-t3410870
[OnePlus 3 Questions & Answers] jordanday98:
Thank you, I'll try that. For step 2 I presume you mean a full clean flash, with everything wiped beforehand?

And if all this is successful, will I just need to flash incremental updates in recovery after this in order to keep updated?
[OnePlus 3 Questions & Answers] Le_Zouave:
for step 2, you will wipe in step 3. But you can wipe before flashing or after flashing. What is important is to wipe and flash before rebooting.
[OnePlus 3 Questions & Answers] nimrodsv:
Why not 3.2.1??
[OnePlus 3 Questions & Answers] Le_Zouave:
Because he won't test OTA that way

Envoyé de mon ONEPLUS A3003 en utilisant Tapatalk
[OnePlus 3 Questions & Answers] jordanday98:
Yeah, I'll flash a version that isn't 3.2..1 then flash an incremental update just to confirm that the update works.
[OnePlus 3 Questions & Answers] jordanday98:
3.2.0 file worked, but incremental update to 3.2.1 returned error 7 in TWRP.

Should I just flash the whole 3.2.1 file?

Now that I've booted up and am setting it up, I've connected to wifi and added my Google account, but it's stuck at the "just a sec" screen.
[OnePlus 3 Questions & Answers] billamin:
have faced the same issue..just flash 3.2.1 and be done with it. None of the incremental update method works..guess will stay with it till the next update comes..

on another note, I cannot remove encryption from my device anymore. So no multirom for me, unless i install a custom kernel/ recovery, which I wont due to the unavailability of dash charge.
[OnePlus 3 Questions & Answers] Angadadlakha:
OTA breaks after root. Incremental updates will not flash. You will always need to download full rom. Just dirty flash them and then su.