Related
Alright, so the root filesystem image is in /mnt/system/androidmerged.squashfs.secure
So do a temp root, copy to /mnt/storage, and then a adb pull gets it over.
The squashfs itself is offset by 256 bytes, so:
losetup -o 256 /dev/loop0 ./androidmerged.squashfs.secure
At this point, the FS can be mounted or unsquashfs can be used to extract it.
So, what's the first 256 bytes? The secure implies some type of signature, but what kind, and what else is in all those bytes?
I'm not feeling brave enough to try just grabbing the first 256 bytes and appending a modified squashfs image to it on my device just yet, but if others try please report back. (On both if it works, and if not what it takes to recover the unit.)
how big is it? can you upload it somewhere? (or would this be illegal?)
damm.. i need my 101!
chulri said:
how big is it? can you upload it somewhere? (or would this be illegal?)
damm.. i need my 101!
Click to expand...
Click to collapse
75 MB - uploading now
Edit: And up: http://hotfile.com/dl/88050103/f99f306/androidmerged.squashfs.secure.html
thx!
how would you replace the root fs image on the device?
chulri said:
how would you replace the root fs image on the device?
Click to expand...
Click to collapse
Connect via ADB, do a temproot, put the file in /mnt/storage, then copy it into /mnt/system overwriting the existing file. /mnt/storage is an ext3 filesystem mounted read/write, however I simply do not know if it will be possible to recover the unit if there is some kind of signature verification and we fail due to a modified image.
Again, someone braver then I should make this attempt and let us know how it goes.
The source did not give all that many hints, but I need to dig through in some more detail.
zelch said:
Connect via ADB, do a temproot, put the file in /mnt/storage, then copy it into /mnt/system overwriting the existing file. /mnt/storage is an ext3 filesystem mounted read/write, however I simply do not know if it will be possible to recover the unit if there is some kind of signature verification and we fail due to a modified image.
Again, someone braver then I should make this attempt and let us know how it goes.
The source did not give all that many hints, but I need to dig through in some more detail.
Click to expand...
Click to collapse
If the unit will still boot to recovery could a full wipe and reinstall of the base AOS over USB get it back up and running?
krohnjw said:
If the unit will still boot to recovery could a full wipe and reinstall of the base AOS over USB get it back up and running?
Click to expand...
Click to collapse
Recovery shouldn't be part of the FS so at worst, you'd have to do a format/firmware install.
You can do a full system wipe/format from recovery. it's not in any damageable storage by us without flashing a new recovery image.
Interesting about the front 256 bytes. It must be a signature. Not sure what good rebuilding the squashfs will do as it'll still be read only but it's a start. We could at least update the system properly and install the appropriate apps. Maybe in make some of the system dirs symlinks to writable locations possibly.
Permroot, giving us a filesystem mounted RW and not no-suid.
Ideally, I'd like to have decent support for the internal storage being ext3 without nosuid, but first we need to be able to replace the root filesystem image.
Other notes..
Looking at the hexdumps, the 256 byte chunk does not contain the start of the md5, sha1, sha224, sha256, sha384, or sha512 checksums.
The most troubling option which comes to mind is that it is the right size for a RSA 2048 bit block, hopefully not.
Anyone have ideas on how to find the initramfs image that the bootloader is feeding the kernel?
For that matter, has anyone tried taking apart the OS update images?
zelch said:
For that matter, has anyone tried taking apart the OS update images?
Click to expand...
Click to collapse
I think the aos file or the responsible installer/updater should give us a lot of information about how this stuff can be updated.
chulri said:
I think the aos file or the responsible installer/updater should give us a lot of information about how this stuff can be updated.
Click to expand...
Click to collapse
Agreed.
It looks like usr/bin/abcbox in the root filesystem has something to do with the update process.
zelch said:
Agreed.
It looks like usr/bin/abcbox in the root filesystem has something to do with the update process.
Click to expand...
Click to collapse
And it definitely is!
On a rooted device:
Code:
/usr/bin # PATH=$PATH:/tmp
/usr/bin # ln -s /usr/bin/abcbox /tmp/cramfschecker
/usr/bin # cramfschecker
USAGE: cramfschecker FILENAME
/usr/bin # cramfschecker /mnt/system/androidmerged.squashfs.secure
cramfschecker : check against 2.0.54
cramfschecker verification OK
Anyone with some ARM disassembly skills feeling up to taking abcbox apart to see how it's doing the signature check?
And so I've been digging into this, and it turns out that this is really quite similar to how the Gen 7 Archos 5 IT is locked.
The signature there is a RSA + MD5 signature, which is really the worst case as that means a 2048 bit RSA key, so we're kinda screwed there.
http://strazzere.com/blog/?p=320 has a good description of the situation on the 5IT. Getting a flash_unlock binary should be fairly trivial, so perhaps we can tamper with the key store to add additional keys.
ah zelch, this is good stuff.
i'm gonna diff the archos gpl kernel, looking for changes at mtd stuff. maybe we can build a kernel module which enables r/w access to stage1
edit: or do we already have r/w access?
This stuff is all pretty interesting to read, but if I'm reading this correctly (and it is entirely possible I'm not) it looks kind of like this device is going to be a total pain in the ass to root, and it may take a considerable amount of time for us to get there.
Can someone who is more knowledgeable on this sort of thing verify that? Thanks for all your hard work guys. It's appreciated.
its definitly not going to be that easy as other android devices were but would it be so interesting if it wouldn't be so hard to root?
While that's true, it will make it a bigger triumph when it is finally rooted, the tinkerer in me is dying to mess with roms on this device and see what it can really do once it's cracked open. Keep up the great work guys, I'm following with baited breath.
Write to stage1 appears to exist, and indeed looking at /proc/mounts /mnt/rawfs is mounted rw. Looking at the kernel source, write support should Just Work.
So, looking through /mnt/rawfs avboot is clearly the boot loader which verifies stuff, but we lack source for it.
I have absolutely no knowledge of ARM asm, and screwing this up will absolutely brick your device, quite possibly beyond repair. (And I wouldn't bet on ArchOS being willing to replace it either, I sure wouldn't.)
So, anyone with the right background willing to step in here?
I'll keep digging, perhaps we can still find the answers.
Note: avboot has some strings which reference a development kernel, this bears some additional hunting.
I still haven't got my A101, but its finally on its way to my home.
can you please upload these files and give me kind of a tree of the folder structure?
I've been running SHOstock3 for a few days to get comfortable with it. Tonight, I decided to encrypt the device. It rebooted, encrypted itself, then rebooted again and asked me for the password. For over half an hour now, it's been playing the SHOstock3 boot animation over and over again. The SAMSUNG screen doesn't show up between loops.
Is that normal behavior? Should I just give it more time?
The power button was able to turn it off. After restarting, it would ask for the password and do the same thing. I should point out that entering the wrong password would make it ask again, so it was working "properly". I decided it was toast and tried wiping it. However, it still asked for the password. Repeatedly entering the wrong password to force a wipe didn't work properly either. It still remembered that it had a password, but forgot what it was.
To fix it, I had to go back to stock Jelly Bean (flash stock Gingerbread then use Kies to upgrade; Gingerbread doesn't know about encryption). When the newly flashed Jelly Bean asked for a password, but as soon as I entered something, it rebooted. I presume that it wiped whatever encryption information was left because it rebooted properly.
I'm still trying to decide where to go from here. I keep work stuff on my phone, so encryption is fairly important to me.
I found this information regarding encryption on Android:
http://source.android.com/tech/encryption/android_crypto_implementation.html
It's for Honeycomb, but I'm going to assume that it hasn't changed significantly. It looks like all the encryption information is stored at the end of the /data partition. However, it's not part of the filesystem itself. If init can't mount /data, it assumes that it's encrypted and takes appropriate action.
As such, I would assume that completely erasing the entire /data partition would take care of it. Note that the /data partition needs to be erased, not just the filesystem. Based on what I've read, I think that the /data partition needs to be wiped/erased/formatted in such a way that the last 16KB of the partition is erased. After that, a new filesystem would need to be created to keep it from asking for a non-existent password.
So, does anyone know what the wipes actually do in recovery?
A couple of observations.
I don't think it is advisable to work at this level of the file system while making assumptions. In my view, you make two very questionable assumptions in your remarks.
I don't have any information on the workings of wipe and format in recovery. You can, however, work with eMMC blocks using Linux commands. For instance, if you use the dd command to make a copy of the data partition, you will get the whole partition, not just the file system. You could then use reverse engineering to see what is contained in the last 16 kb of the partition. This would require a skill set that is certainly way beyond me, and I suspect beyond you. You could also use dd to write to just the last 16 kb as well.
Well, at this point, I'm not really trying to find a "solution", I'm just trying to understand why it's so hard to wipe the phone after it's been encrypted. The only reliable method I've found is to put on the stock firmware, then repeatedly enter the wrong password until it wipes itself.
I was poking around in the jeboo github (SHOstock3 uses the jeboo kernel) to see if I could figure out what's going on. I found the following line in fstab.smdk4210:
Code:
/dev/block/mmcblk0p10 /data ext4 noatime,nosuid,nodev,discard,noauto_da_alloc,journal_async_commit,errors=panic wait,check,encryptable=/efs/metadata
I'm currently running stock 4.1.2 and I found the same file with that line. After doing some research, I found that the encryptable flag tells the system to allow encryption for that particular filesystem. Its argument says were to keep the encryption metadata. In this case, it's kept in /efs/metadata. That file exists on my encrypted stock JB system and the file happens to be exactly 16KB. The first part of the file is plain-text and it appears to be encryption related. After further research, I found that "footer" is an acceptable value for encryptable. In that case, it stores the metadata in the last 16KB of the partition (but the filesystem can't extend into it for obvious reasons).
Given the behavior I've seen, my guess is that if init sees /efs/metadata, it asks for the password. This would explain how wiping /data would cause the system to still remember the password. Even if you were to erase everything in /data, /efs/metadata would still exist. I also suspect that certain methods of "wiping" /data don't actually do so because they attempt a check before doing the wipe. I'm far from an Android expert, most standard methods of checking a filesystem in linux would fail if said filesystem were encrypted.
So, I think I've figured out why wiping an encrypted phone is so hard, but I still haven't figured out why SHOstock3 doesn't boot after it encrypts the phone.
Jebo knows a lot about the kernel. You could probably get into a meaningful discussion with him on encryption. I don't know if he has a chat channel of his own, but he is probably in Shoman94's chat channel quite a lot. You can find that in the OP of the SHOstock3 thread.
I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
miguelg_ said:
I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
Click to expand...
Click to collapse
Why not just reformat to ext4?
es0tericcha0s said:
Why not just reformat to ext4?
Click to expand...
Click to collapse
Ultimately that's what I'll need to do but was hoping to use the non-journalled ext2. Is it not supported by Android or it the case that only some versions support it (in which case, what idiocy!)?
Have to say I'm beginning to truly hate Android. They might as well build their own kernel such that Linux (and by implication UNIX) is removed from the mix for they have completely butchered this OS. I suppose this is what happens when egos larger than the world are responsible for designing software; NIH syndrome.
Answering myself: if anyone is wondering how to automount a partition at boot time, you'll have to create your own init script and place in /system/etc/init.d/.
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
es0tericcha0s said:
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
Click to expand...
Click to collapse
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
es0tericcha0s said:
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
Click to expand...
Click to collapse
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
miguelg_ said:
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
Click to expand...
Click to collapse
Well, cripple might be a bit of hyperbole considering it's not something most people would need. I get your point though, it is weird that it's not native since it works with Linux generally. You can link symbolically to FAT systems while rooted with something like this:
https://play.google.com/store/apps/details?id=com.devasque.fmount
And yes, the tech people are creating software for these devices, but they are made for the general public, because that's who buy 90% of these things.
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
miguelg_ said:
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
Click to expand...
Click to collapse
Sure. Most android devices, actually I can't think of any of the top of my head, don't come with native init.d support or even have init.d that is not accessible. It's just not there. It's enabled in almost all custom roms, or you can add it yourself to many stock roms via a couple different ways like this:
https://play.google.com/store/apps/details?id=com.androguide.universal.init.d
As far as the system RW issue, some phones, like many newer HTCs, have the system protected so that you can make changes to the /system while booted, no problem, but once you reboot, all the changes will get undone. Very annoying. Example:
https://www.youtube.com/watch?v=KV3YaMBnEYI
Brickbug Aftermath: Speeding up the Galaxy S2 i9100, S2 AT&T i777, S2 Epic 4G Touch d710 and Note n7000
UPDATE: KERNELS CAN TRIM FAT PARTITIONS
contrary to what has been said in this thread and elsewhere, the S2 TRIM kernels could always trim FAT partitions. the problem is that the FAT file system implementation does not support batch trimming (ie: fstrim), but the fact that the DISCARD mount option has always been supported on FAT has eluded us all. the mainline commit that introduced the option is here, and the corresponding code in CM's repo is here.
this means that it would probably be a good idea to add DISCARD to the default mount options of the internal sdcard in CM. deleting files from internal storage would probably become slower, but the expectation would be that overall performance should increase. the performance issues related to queue flushing that plague non-queued TRIM commands should not be a big problem in this case, since the sdcard is used mostly for media (few big files without multitasking access).
UPDATE: VICTORY !!!
2016-03-02: after two years of tests and discussions, folklore, FUD and evidence, @Lysergic Acid finally took the plunge and merged! TRIM is now part of the official CM 12.1 and CM 13.0 kernels, and this project can at last be retired, yoohoo!!! CM 13 users now enjoy TRIM out of the box, but users of CM 12.1 builds older than Match 2016 as well as CM 11.0 users continue to require a separate TRIM kernel.
this thread is dedicated to Entropy and the brave users who risked their devices to run the very first TRIM tests.
IMPORTANT NOTE FOR USERS
i am tried of lazy users sending private messages to me instead of reading the thread. i am especially tired of users asking over and over on PMs whether TRIM is safe. if you read the threads you would know: TRIM is completely safe on every supported device, stop asking! and please, never PM technical questions to anyone on XDA unless you already know the guy.
DOWNLOAD FROM -> HERE
IMPORTANT NOTE FOR KERNEL DEVELOPERS ONLY
you should not blindly merge these changes into your kernel. doing so can result in unrecoverable bricks!!! you need to check that certain patches are already merged in your kernel before enabling TRIM. please follow these steps; you can get help from this post. please contact me when in doubt, let's not revive the slumbering brickbug monster from hell, thank you!
UPDATE: CM 13.0 kernels are now available!!! (for CM 13.0-supported platforms only: i9100 and i777.)
UPDATE: several enhancements in new kernel batch:
CM 12.1 kernels are now available!!! (for CM 12.1-supported platforms only: i9100 and i777.)
kernels can now be flashed with the official, restricted cyanogen recovery that is bundled with CM 12.1.
rom-independent kernels: kernels are no longer dependent one-to-one on specific official CM builds (they might work with other roms too), and their names no longer reference a specific CM build.
although there are no official CM 11 builds for the i777, thanks to rom independence CM 11-based kernels for that device are now available.
CM 11 i9100-to-i777 cross-flash kernels for the i777 may now work with other i9100 roms besides official CM.
UPDATE: Dic 25, 2014: a holiday present!!! as kernel maintainers swiftly acted to patch PFBug, @Gustavo_s took the plunge and merged TRIM support in his latest kernel. i have verified that his kernel is as safe as mine regarding TRIM. finally a more mainstream kernel is getting this functionality, hopefully i will be able to discontinue my kernels soon!
UPDATE: great news, we have fixed FPBug!!! fixed TRIM kernels are online!
UPDATE: this project now supports all roms and kernels!
if you are not running CyanogenMod M snapshots, please see this post.
this project restores TRIM capability to CyanogenMod kernels for the Galaxy S2 family of 4210-based devices: i9100, i777, d710 and n7000. TRIM is needed to avoid "aging" of the state of the eMMC, the internal flash storage, that eventually slows the device to a crawl. TRIM functionality is built into android 4.3 and later. however, due to historical and safety concerns, TRIM capability was removed from the CM kernels for these devices (and from most if not all other AOSP-based kernels).
an in-depth discussion of this matter, including safety, risks and current state of the kernels for various devices, can be found in the main project thread. you can review that content if you are curious. get the source for this project: patches and patcher script are here (git) and base system here (repo). for instructions on how to recreate my kernels from source, see this post.
STATS: Nov 5: 500+ kernel downloads (latest version only).
Oct 1: 250+ kernel downloads (then-latest version only), top 5th thread in its forum (ThreadRank).
PROJECT STATUS: testing still needed on MAG2GA TRIM bug-affected devices before TRIM patches go mainstream. IMHO, TRIM patches are ready to be merged into mainstream kernels. kernel maintainers please read the warning at the very top of this post!
UPDATE: kernel wifi issues fixed! thanks to invaluable help from @mparus. also, ART works just fine.
What to expect
some users see big changes while others do not. there are many different eMMC models with different firmware versions embedded in these devices, and it is clear that some are faster than others. it is even possible that some eMMCs may have firmwares that completely ignore trim commands. following are some benchmarks and comments submitted by users.
@defecat0r run before-and-after benchmarks and packed it all in this neat graph (thanks so much!):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
@defecat0r also says: "I've been dicking around copying stuff back and forward, factory resetting and restoring cwm recoveries while on this kernel for a day now, if this fix was going to trigger superbrick i'm sure it would have done it by now. As far as i'm concerned this is safe as houses. [...] This is the biggest thing to happen to these devices since i don't know when!" (post)
@smoke2tun got better results: "My phone is blazing fast". he says: "The phone is really snappy and responsive. [...] After runing Antutu v5.1 the overall score is 17816. On NeatRom the score had an average of 11000." (post)
@Roxxors: "My phone had become so unbearably slow I was about to toss it in the garbage, [...] I'm coming from NeatROM 4.1.2, and let me tell you something, after installing C11 M9 with this kernel, my phone is FLYING." (post)
@|Vyp|: "Nice work, the device is flying now." (post)
@bihslk: "OMG! Installed CM11 M10 and your TRIM. Phone is flying now,,, WoW" (post)
@burninghouse: "i installed it and i can say only one word....."AWESOME"... My s2 is blazingly fast with same battery life" (post)
@dirtyhewr: "Omg... I don't think my device has ever been this fast... No lags at all" (post)
@Dudebowski: "[...] the increase in write ops nearly doubled! Regardless of the numbers for proof, this trim along with the floater fix [ed. note: FPBug] has made this device enjoyable to use again for the first time in years. The change in responsiveness after trim is night and day." (post)
thank you so much for the feedback and benchmarks guys!!
When things do not work
then again, some users do not get big improvements. check out the case of @desvariando.
speculation about these cases can be made. TRIM failing to provide advantages can be attributed to one of two causes:
when the fstrim command is run on some devices, it reports success but runs in zero time instead of taking the usual couple of seconds it takes on most devices. it looks like samsung disabled ERASE/TRIM support in some eMMCs, as a stopgap measure while they researched the issue further and before they output a final fix. if your eMMC trims in zero time, there is probably no realistic way to ever trim it. once your device gets slow, it can never be rejuvenated. if you fall under this group, and you have not yet ever filled the device's internal memory and your device still performs well, i would reduce the internal sdcard partition in size asap and leave a healthy sized area of 2GB inaccessible. this overprovisions the eMMC and ensures that it will never ran out of untrimmed space (assuming that the disk area you are leaving out is in fact still trimmed from factory). UPDATE: so now i know of a way to trim these untrimmable devices. it is extremely dangerous though (unless you have JTAG access to the eMMC). these eMMCs have a command to resize their boot partitions (boot0/boot1). these partitions are treated differently from all others by these modules. you can think of them as separate, safe, small, virtual disks; even if you write all over the main disk, you will never touch these partitions. also, wear leveling on the main disk will never move data around on these partitions. contrary to data on the main disk, once you write something here, it stays written forever (until you write something else). because they are treated differently, the eMMC needs to know their size. for versatility there is a non-standard command that will resize these partitions, and as a side effect it will repurpose the rest of the flash as the "main disk", creating all of its FTL structures from scratch. this full, low-level reformatting will fix a brickbug-damaged eMMC and will also trim an untrimmable device. the trick is to resize the boot partitions to some strange value, then resize them back to original size. all data everywhere will be lost, including the bootloaders, and this is why it is so dangerous. these phones will brick unless there are proper bootloaders and friends in place (though with JTAG access you could restore all this data). so the procedure would go like this: boot into recovery, make backups of all partitions you care about (bootloaders, EFS, etc), resize boot0/boot1, resize them back, and restore the needed partitions. but if anything goes wrong before you finish... you have a brick! because it is so dangerous, AFAIK this procedure has never been attempted to fix a brickbugged S2, much less to just trim one. but it has been carried on successfully on devices that boot from alternative sources when their eMMC is wiped, check it out here.
your device still had a reasonable amount of trimmed space when you installed this kernel and trimmed, and was not in need of trim. this can happen if you never filled the device's internal memory throughout its entire lifetime, or if you trimmed your device recently without knowing it. you could have trimmed by using the stock 4.1.2 kernel (which is TRIM-capable) in two ways: by wiping data from android or recovery, or by using an app such as LagFix.
otherwise, your device should be more responsive and use less battery after trimming. the need for trim is a well established reality that no FTL-based flash storage can escape.
STOP!!! DRAGONS AHEAD!!!
in theory there could be risk of hard-bricking your device forever. i believe this risk to be non-existent, based on reasons i detail in the aforementioned thread, and also based on recent experience: many people are already using these kernels without any kind of incident. however, the standard disclaimer applies: you accept full responsibility for what happens to your device.
READ and FOLLOW the instructions carefully.
Downloads
for the supported devices, you will find IsoRec-compatible CyanogenMod-based kernels here. (old kernels without IsoRec support can be found here. yet older retired kernels without FPBug fix are still available here.) note that for some supported devices, no releases or M snapshots are currently being produced. for those devices i can produce kernels based on known 'stable' nightlies if users ask.
A word about CyanogenMod 10.1.3
UPDATE: great news, we have fixed FPBug!!!
there are no CM stable releases for 4210-based devices after CM 10.1.3. the sad truth is that the kernel for these devices is broken. this affects all roms, not just CM. there seems to be some unidentified defect in the hardware itself, and no workaround for it has been implemented in the kernel so far (if such a thing is even possible). after years, @cgx finally observed the bug in action and now we at least know what we are up against. it is nasty as hell: random stack corruption. in layman's terms, any process can randomly misbehave, crash, be corrupted, corrupt data, etc... all bets are off, anything could happen. and it looks like this might never be fixed.
for whatever reason this was not much of a problem in the CM 10.1.3 days. these days, with a much more advanced and demanding android, the bug is real trouble. most people find that the last reliable CM version for their 4210-based device is 10.1.3 (including the CM team itself). i made kernels for this version, find them in the downloads section.
NOTE: the CM 10.1.3 kernels are untested. do take a nandroid! and please post your results.
Instructions
prerequisites: you need to already be running a fully official version of CyanogenMod supported by this project. (i mean fully official: dual booters, alternative kernel/recovery users, etc are not invited to this party.) you will replace your current official CM kernel with the patched, EXACT SAME VERSION kernel from this project.
download this app and run it to check if your device is affected by hardware bugs. root is requested but not needed for this test. do not trust the app's verdict! instead use the reported eMMC model name and the firmware revision (fwrev) to look up your eMMC in this table.
is your eMMC model an MAG2GA? if so you are affected by TRIM bug. WARNING: this configuration is untested. my kernels should be safe but they have never been tested on this particular eMMC, so risk cannot be completely ruled out. please read this post and decide whether you would like to test. testers are needed! i believe this is the last remaining piece of evidence needed to establish the general safety of trim on this family of devices and start pushing for its inclusion in the standard kernels, which is the ultimate objective of this project. UPDATE: things are looking much better, see this post. testing is still needed though, please help. UPDATE: MAG2GA eMMCs with fwrev 0x0E can be found in d710 devices and were tested to TRIM without problems. i personally believe this configuration to be safe.
are you affected by WL Bug? impossible. according to the available data, no 4210-based device has ever been produced with this eMMC... SO YOU MUST BE MISTAKING. please double check your situation; then post. (in any case, this bug is supposed to involve data corruption only, and not bricking.)
are you affected by Brickbug? my kernels contain samsung's fix for this bug, but samsung's fix was never exercised in practice with TRIM. i will accept ONE volunteer to test. i do not want more than one device to brick if the test fails. know that testing can potentially brick your device beyond repair. i would prefer someone with a compromised S2 (eg: lost IMEI, cracked screen) to do the first test. please post your willingness to test on this thread (include eMMC and fwrev). UPDATE: many people affected by this bug are already using my kernels without incidents. i personally believe this configuration to be safe.
if you are not affected by the previous bugs, you run no special risks by flashing my kernels.
you should start on a supported official CyanogenMod; if you are not already running it, flash it now and test it.
optional: as an extra safety step, back up your EFS and store it OUTSIDE your phone. you should have done this years ago! you never know when you might need that backup.
optional: preferably no apps should be moved to the internal sd card (check 'apps' in settings). this could slow the device a bit, but is no problem otherwise. note that apps moved to the EXTERNAL sdcard can cause BIG SLOWDOWNS.
optional: make sure you have 20% (or at the very least 10%) free space in your internal 2GB /data partition (where apps are normally installed). you will not notice speed improvements unless/until you have free space in /data.
optional: if you have been on official CM (including kernel) for a long time, and this is the first time you are going to trim your device, please contribute benchmarks. install Androbench and run all benchmarks, it takes just a few seconds. in the history section you can see most if not all results in a single screen; please take a snapshot for your before-and-after comparison.
make a nandroid backup. if you need to back out of the change for whatever reason, you will be happy to have it.
download the appropriate kernel for your CM build (includes CWM-based recovery). flash it without wiping. (at any time you can reflash official CM without wiping or upgrade to a newer CM -loosing TRIM support, of course.)
reboot.
install the LagFix (free) app from xda (the market version is declared to be incompatible with the i9100). go to the lagfix tab, check the 3 partitions, and tap on run. grant root access. the 3 fstrim operations should be successful ("partition was trimmed" means success).
UPDATE: there is a replacement app for LagFix called Trimmer that has several advantages over the former: is fully free, can schedule TRIMs, and is compatible with Android 5.
alternatively, instead of using lagfix you can run one of these commands (these are better because they also trim /preload):
# on the phone in the terminal app:
su -c "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload"
# on your PC if you are connected to the phone via adb:
adb shell su -c "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload"
reboot.
optional: contribute benchmarks if you qualify. run Androbench again to take an 'after' snapshot and share your before-and-after shots below.
your device should now run FAST... profit!
Please donate hardware to test
i do not have any of the supported devices to test, i am developing blind. i would gladly accept an i9100 with a cracked screen as a test bed if you can send it to an address in USA or Argentina (or any other supported device).
But wait, there's more...
Automatic trimming
android 4.3 and later should trim all writable file systems each night during charging automatically (/cache, /efs, /data and /preload). you do not need to invoke fstrim or lagfix manually again. if you want to be extra tidy you can invoke lagfix after each flash of a CM upgrade to trim /system (which is normally read-only).
because of this offline auto trimming, android 4.3 and later should not mount partitions with the discard mount option (which implements online trimming whenever space is freed), but CM does anyway. this is a bug that slows down the device and i have uploaded a patch to CM's gerrit. my kernels fix this as of Sep 14 2014.
if you use CM 10.1.3 (android 4.2.2), you might be thinking that you need to regularly trim the file systems yourself (you could use scripts or lagfix premium for automation). but as of Sep 14 2014 my kernels mount /cache, /data and /preload with the discard option, meaning that freed space on these partitions is immediately trimmed (which, again, slows down the device compared to offline trimming but is better than no trimming at all). so you only need to invoke lagfix after each flash of a CM upgrade to trim /system if you want to obsess about it. (the /efs partition is not mounted with discard; call me superstitious.) btw, i made the /preload partition writable (it is normally read-only in CM 10.1.3) so you can trim it and/or use it for whatever purpose you want. i could create 10.1.3 kernels without the discard mount option for those who wish to roll their own periodic trim feature; just ask.
The internal sdcard partition
the majority of the phone's flash is devoted to the internal sdcard partition which is formatted in a vesion of FAT. unfortunately the linux kernel file system driver for FAT is unable to trim its free space. some people format this partition to ext4 for performance and safety reasons (google). if you do that, you can fstrim it.
The preload partition
these devices have 0.5 GB ext4 /preload partition (also called "hidden"). in CyanogenMod it is unused and should be empty (you can check with the file manager). you can manually fstrim this partition (open a terminal on the phone and type: su -c "fstrim -v /preload" or from the PC via adb: adb shell su -c "fstrim -v /preload") or format it from my recovery to increase the trimmed free space in your eMMC, effectively increasing its over-provisioning by 0.5 GB. this makes the eMMC faster and extends its useful life.
UPDATE: i have removed the trim-on-format functionality (partition wiping) from the kernel patches, and thus all future kernels. there are no safety concerns with the previous kernels, but there can be problems if someone uses my patches to build a complete ROM (as opposed to just a kernel, as i have been doing). please refer to the commit for details. [Oct 3]
Adjusting partition sizes
you can repartition your phone to better distribute available flash space. i recommend vestigial /preload (unless you want to go back to stock roms later), 1 GB /system (the original 0.5 GB /system is too small for android 4.4 and gapps; 0.75 GB is enough, but the Nexus 5 comes with 1 GB, so i guess google expects it to keep growing), 6 GB /data (of which you should always keep 2 or 1 GB free to provide the eMMC with trimmable free space -remember the FAT partition does not trim), and the rest (about 8 GB) used for the internal sdcard. you can format the internal sdcard as some FAT or as ext4. (but windows does not understand ext4, but there is MTP... google!)
you can use ODIN (windows-only) or heimdall to repartition. @Roxxors contributed a nice partitioning how-to that you should read. note that he embedded my M9 kernel in his ODIN files. to create a file with the right kernel for your needs, read this.
here are some PIT files (these files are for the i9100 16 GB only, but you can use PIT Magic to roll your own):
0.5 GB system
0.75 GB system
1 GB system, 3/4/6 GB data
1 GB system, 8 GB data
1 GB system, 4 GB data, small preload
1 GB system, 6 GB data, small preload <-- this PIT is buggy!
(see attached file for a replacement i made; includes a script to repartition from linux using heimdall.)
in general, 2 GB, or even 1, of trimmable free space (ie: free space in the /data partition) will probably be more than enough to speed up your device, with rapidly diminishing gains over that.
UPDATE: due to a bug in CM, the recovery is unable to format the /preload partition. formatting is needed after repartitioning. to manually format, open a terminal on the phone and type: su -c "mkfs.ext2 /dev/block/platform/dw_mmc/by-name/HIDDEN" or from the PC via adb: adb shell su -c "mkfs.ext2 /dev/block/platform/dw_mmc/by-name/HIDDEN" (you can also use other commands such as mke2fs and mkfs.ext2.)
PLEASE NOTE: this is not a partitioning thread!!! please DO NOT seek partitioning help in this thread. please post in an appropriate thread instead. this thread is for KERNEL ISSUES ONLY. thank you!
XDA:DevDB Information
BrickbugAftermath-i9100, Kernel for the Samsung Galaxy S II
Contributors
Lanchon
Source Code: https://github.com/Lanchon/BrickbugAftermath-SGS2
Kernel Special Features: CyanogenMod kernel with TRIM support
Version Information
Status: Stable
Created 2014-08-10
Last Updated 2016-04-17
TRIM On Other Roms And Kernels
TRIM on custom roms
when running any non-trim enabled kernel, significant speed benefits can be obtained by overprovisioning the eMMC. as long as a portion of the eMMC is in the erased state (trimmed) it will perform well, even if the kernel is not able to trim. this can be seen for example when the device is new: non-trim kernel and still the device runs nicely. as time goes on, normal usage causes the eMMC to be written all over, reducing the amount of trimmed space to zero and killing performance. this situation can be avoided in two ways: 1) by using a trim-enabled kernel that will trim space once it is no longer used by files, or 2) by setting aside an area of the eMMC and never write to it, effectively keeping it in the erased state. this second option is called overprovisioning in SSD parlance.
those of you wanting to run official CM kernels, CM nightlies, or other custom roms altogether can still obtain most of the benefits of a trim-enabled kernel without one by overprovisioning your eMMC. the stock partitioning of the 4210-based devices includes an 0.5 GB /preload partition that is just perfect for the job.
Requirements:
you have not repartitioned your device and shrank the /preload partition to enlarge other partitions.
your custom rom does not use the /preload partition. (CM does not, and I do not know of any that does... but google!)
you are not using dual-boot or other mods that use the /preload partition.
NOTE: if you have shrunk /preload and enlarged /system to 1 GB you can still follow these steps to overprovision using the free space in /system, but you will need to redo them every time you flash a new rom. otherwise, if you have an 0.5 GB /preload, you can do these steps once and just forget about the whole thing (until you flash something to the /preload partition, that is).
Instructions:
NOTE: please read step 9 now and decide if you want to use a root file manager to delete everything in /preload before you start or if you want to try to format the partition with your current recovery.
READ THIS POST IN FULL. find out which bugs your eMMC has if any, and decide whether to run the risk of trimming.
download to your device the newest trim-enabled kernel for your particular device from here.
download to your device a recovery-flashable copy of the kernel that you are currently using. (or else make a nandroid backup in step 6.)
if you want, download to your device the recovery trimmer script attached to this post. (see step 11 for more information.)
reboot to recovery.
make a nandroid backup if you do not have a flashable copy of your current kernel on your device. (make sure your nandroid is compatible with CWM-based recoveries.)
flash the trim-enabled kernel.
in the advanced section, choose reboot recovery. now you are temporarily running a trim-enabled kernel.
in the mounts and storage section, choose format /preload. (make a nandroid backup first if unsure of its contents.)
NOTE: it has been reported that format /preload does not work. this is a bug in CM's recovery. you may want to adb shell to the device to delete all files and folders under /preload, including those hidden. free space in this partition will remain trimmed when you later use the phone so it is important that most of the partition be empty after this step. (bug report)
still in the mounts and storage section, mount (if necessary) the following partitions: /system, /cache, /data and /preload.
choose one of these two options:
attach your device via USB to your PC, open a terminal, and type adb devices to verify that your device is reachable and authorized. (if it is not, under linux type adb kill-server; sudo adb devices to troubleshoot the issue; under windows try restarting the adb server from an administrator console.) in the terminal type adb shell "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload" to trim. for each partition, fstrim should output a message stating the number of bytes trimmed; this indicates success.
flash the attached recovery trimmer script. you will not have any indication of success using this method. (make sure you have mounted the applicable partitions in the previous step!)
flash your old kernel back or, equivalently, restore your nandroid. (you can advance-restore only the boot partition if you want.)
reboot and profit.
TRIM on rooted stock android 4.1.2
this is beyond the scope of this project, but still some people may be interested.
Instructions:
make sure you are rooted.
WARNING: MAKE SURE YOU ARE RUNNING STOCK ANDROID VERSION 4.1.2 (THE RELEASE, NOT A LEAKED VERSION) OR YOU WILL DESTROY YOUR DEVICE DUE TO BRICKBUG!!!
READ THIS POST IN FULL. find out which bugs your eMMC has if any, and decide whether to run the risk of trimming.
WARNING: MAKE SURE YOUR EMMC IS NOT AFFECTED BY TRIM BUG OR YOU WILL DESTROY YOUR DEVICE!!! if you have trim bug, you must not trim on a stock kernel, end of story.
also, it is assumed that release (not a leak) 4.1.2 stock kernel contains this patch and thus is brickbug safe. but there might be different versions, and there is no way to be sure if the corresponding source code was patched by samsung, so...
WARNING: IF YOUR EMMC IS AFFECTED BY BRICKBUG, THE POSSIBILITY HARD BRICKING YOUR DEVICE CANNOT BE COMPLETELY RULED OUT without access to the kernel source code. proceed at your own peril, or better yet, switch to a custom rom/kernel.
install the LagFix (free) app from xda (the market version is declared to be incompatible with some 4210-based devices). go to the LagFix tab, check the 3 partitions, and tap on run. grant root access. the 3 fstrim operations should be successful ("partition was trimmed" means success). alternatively, those with busybox installed can try issuing the fstrim commands themselves. in particular, you must do this to trim /preload. you can also look for the fstrim command in the private files of LagFix.
UPDATE: there is a replacement app for LagFix called Trimmer that has several advantages over the former: is fully free, can schedule TRIMs, and is compatible with Android 5.
reboot and profit.
NOTE: i assume there is little free space in /system and /preload in stock roms, so most benefits will come from trimmed free space in /data. this space will get overwritten in time so you will need to periodically trim.
Recreating My Kernels From Source
i have been wrongly accused of not providing full source code to my kernels. to counter this accusation i am providing step-by-step instructions on how to exactly recreate any of the kernels published in this project from source. to start, all you need to know is the filename of the kernel you want to recreate. then simply follow these steps:
identify and obtain the CM release that corresponds to the kernel based on the kernel filename. example:
kernel: kernel-cm-11-20140915-NIGHTLY-Lanchon-TRIM-20140916-n7000.zip
CM release: cm-11-20140915-NIGHTLY-n7000.zipnote that nightly releases are not kept for long in CM's download servers. that is why i mirror all relevant nightlies right beside my kernels in the downloads section.
extract the build manifest (/system/etc/build-manifest.xml) from the CM release zip file.
using the manifest, checkout the source code corresponding to the release to ~/android/system by following these instructions.
identify the version of the patches that corresponds to the kernel based on the kernel filename. example:
kernel: kernel-cm-11-20140915-NIGHTLY-Lanchon-TRIM-20140916-n7000.zip
branch: cm-11
date: 20140916
tag to match: cm-11-20140916
identify the corresponding tag in my github repo and checkout its tree to ~/android/brickbug/BrickbugAftermath-SGS2. if no tag matches exactly, use the tag in the same branch that sports the closest earlier date.
run ~/android/brickbug/BrickbugAftermath-SGS2/scripts/repo-patch apply to apply the patches.
(repo-patch apply functionality used to be provided by standalone script apply in old versions.)
build the kernel using these instructions.
finally, you can run ~/android/brickbug/BrickbugAftermath-SGS2/scripts/repo-patch reset to unpatch your source tree.
(repo-patch reset functionality used to be provided by standalone script reset in old versions.)
Sh*t...
erdal67 said:
Sh*t...
Click to expand...
Click to collapse
lol brickbug
well someone will have to the guts to try. if you read the main thread (very long), i argue that it is probably safe to run my build in your phone... but then, there's only one way to know for sure
erdal67 said:
Sh*t...
Click to expand...
Click to collapse
Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?
empulse92 said:
Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?
Click to expand...
Click to collapse
i'm sorry you are affected. i personally think it would not brick (for reasons explained in the main thread, you are invited to chip in).
but i could brick! there's risk.
we will never know until somebody tests...
Lanchon said:
i'm sorry you are affected. i personally think it would not brick (for reasons explained in the main thread, you are invited to chip in).
but i could brick! there's risk.
we will never know until somebody tests...
Click to expand...
Click to collapse
I think i may give it a try... Unsure if i should usw another pit? Got 2gb (stock) for now you suggestet to use 4or 6 GB? I got some Mainboards hat home with destroyed imei chips, seems to be good testers if the chip is the same :highfive:
Another question: is the fw Version of the chip upgradeable via Odin vor heimdall? Is it possible to acces the Software used by this chip?
empulse92 said:
I think i may give it a try... Unsure if i should usw another pit? Got 2gb (stock) for now you suggestet to use 4or 6 GB? I got some Mainboards hat home with destroyed imei chips, seems to be good testers if the chip is the same :highfive:
Click to expand...
Click to collapse
boards with lost IMEIs? that would be great to test!!! no big loss in the worse case.
don't bother with the PIT files. just follow the main instructions. this is to test if it TRIM works without bricking in those chips. if you later want to set up a phone for real use, you can try resizing the partitions (i would for my phone).
exactly the same chip! VYLOOM 0x19 :victory: (date differs , 06/2011 but i guess this wont make a big difference at least )
edit: bootin...:fingers-crossed:
edit 2: succesfully booted,
empulse92 said:
exactly the same chip! VYLOOM 0x19 :victory: (date differs , 06/2011 but i guess this wont make a big difference at least )
edit: bootin...:fingers-crossed:
edit 2: succesfully booted,
Click to expand...
Click to collapse
cool!! thanks!!!
and? did you use lagfix?
did u trim /sdcard?
Lanchon said:
cool!! thanks!!!
and? did you use lagfix?
did u trim /sdcard?
Click to expand...
Click to collapse
i did dont know if there are errors if trim isnt supported or not but for now... see yourself
note : play store says lagfix app is incompatible with this device i got the app from xda
http://forum.xda-developers.com/showthread.php?t=2104326
Click to expand...
Click to collapse
empulse92 said:
i did dont know if there are errors if trim isnt supported or not but for now... see yourself
note : play store says lagfix app is incompatible with this device i got the app from xda
View attachment 2891398
Click to expand...
Click to collapse
thanks! yes i'll update the app link then. those trims were successful, and yes it shows errors when you try to trim and the kernel doesn't support it.
i guess now you should use that phone and see if it bricks... for now its looking like the chances of bricking are going way down.
could you do two more tests?
try to trim /sdcard (steps in my first post)
then enable ART (debugging menu) and and see if it boot loops or not.
thanks!
no error when trimming sdcard... should i wait some more before trying art?
empulse92 said:
no error when trimming sdcard... should i wait some more before trying art?
Click to expand...
Click to collapse
great! did the trim sdcard command took some time, like a second or two? or did it end absolutely immediately, like a no operation would?
no, everything checked ok, you can try ART. i think it should work. if it doesnt, wipe data from recovery (i think you are using an empty phone anyway, right?)
there was no delay after using the command.. just as you said, as if nothing happened. this is why i was wondering^^ but still not sure about this
yep the phone is empty, but i cant get into recovery or download mode .. time to set up adb
edit: device offline-.-'
edit 2: i am retarded and forgot to press the home button :')
edit 3: alrighty, now it boots but after wiping its still dalvik cache vm
empulse92 said:
there was no delay after using the command.. just as you said, as if nothing happened. this is why i was wondering^^
yep the phone is empty, but i cant get into recovery or download mode .. time to set up adb
edit: device offline-.-'
edit 2: i am retarded and forgot to press the home button :')
Click to expand...
Click to collapse
hmmm... i've read somewhere the android shell sends stderr to limbo. i just tried to fstrim /sys on my nexus and not a word, exits immediately. on my linux PC it says "fstrim: /sys: FITRIM ioctl failed: Inappropriate ioctl for device".
i'll look into this further. meanwhile, are u testing ART?
EDIT: i dont know why no error is printed. but on android, if you fstrim with -v option you get text if successful:
[email protected]:/ # fstrim -v /system
/system: 0 bytes trimmed
[email protected]:/ # fstrim -v /data
/data: 2399477760 bytes trimmed
[email protected]:/ # fstrim -v /sys
1|[email protected]:/ #
so if you do fstrim -v /sdcard and you get no output, then the kernel is unable to trim FAT32. if this is the case, it would pay to find a alternate solution to this in the long run.
enabling art forces bootloop, formatting data reverts back to dalvik :silly:
no chance to use art for now^^
edit: here's a logcat but i'm not sure if it shows a normal boot or the art bootloop
https://drive.google.com/file/d/0Bw86veXkn-fiZ2FnU3lqdkFuWVE/edit?usp=sharing
edit 2: another screenshot (dont be confused i didnt change the time zone yet)
empulse92 said:
enabling art forces bootloop, formatting data reverts back to dalvik :silly:
no chance to use art for now^^
edit: here's a logcat but i'm not sure if it shows a normal boot or the art bootloop
https://drive.google.com/file/d/0Bw86veXkn-fiZ2FnU3lqdkFuWVE/edit?usp=sharing
edit 2: another screenshot (dont be confused i didnt change the time zone yet)
View attachment 2891493
Click to expand...
Click to collapse
thanks!
assuming official M9 has working ART, there must be some trouble with my build setup. my OpenPDroid build has the same thing, it is not related to TRIM. oh well...
your screenshot clearly shows there is no TRIM support for FAT32
i will think of what to do next. in any case, if you turn off ART and flash this on your working phone (with 20%+ free space in your internal partition) you should notice a big improvement in responsiveness and diminished lags. (a friend told me "feels like a different phone", but maybe he is exaggerating.) i still warn against doing it! i would exercise the internal storage on this phone for a while, installing big apps then deleting them, flashing the rom a couple more times, and using LagFix to trim all partitions.
or you can make a backup of your current phone and restore it here, then lagfix, and see if the increased speed justifies the risk. its your call...
for now i have nothing else to ask you to test. thank you very much!!! you've been amazing help!!!
using this on my daily phone now :good:
empulse92 said:
using this on my daily phone now :good:
Click to expand...
Click to collapse
oops! are you sure??? i hope nothing bad happens...
after LagFix trimming and rebooting, how do you feel the phone in the way of responsiveness?
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
lionclaw said:
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
Click to expand...
Click to collapse
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.
back from the dead, any progress on this?
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.
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
keithkaaos said:
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
Click to expand...
Click to collapse
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
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?
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!! http://nolirium.blogspot.com/
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.
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.
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
I'll attach them to this post in case anyone wants to take a look. There's a readme in the zip, some more details can also be found here and below
EDIT: Fixed the SE Linux issue occurring with the previous version I uploaded (it was launching daemonsu from u:r:init:s0 instead of u:r:supersu:s0).
Anyone considering giving them a spin should bear in mind that the method does involve creating a fairly large file on the device as a rooted copy of the android rootfs. (1GB for arm, 1.4GB for Intel). There's a readme in the zip but the other couple of important points are that:
a) The SuperSU 2.82 SR1 zip also needs to be downloaded and extracted to ~/Downloads on the Chromebook.
b) Rootfs verification needs to be off. The command to force this is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
or the regular command to do it is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
c) If, subsequent to running the scripts, there's a problem loading Android apps (e.g. after a powerwash or failed install), the command to restore the original rootfs image is:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Hey this is a great response.. thanks!
Nolirum said:
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
Click to expand...
Click to collapse
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)
Nolirum said:
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
Click to expand...
Click to collapse
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?
Nolirum said:
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
Click to expand...
Click to collapse
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Nolirum said:
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Click to expand...
Click to collapse
Heh.. not gonna be me..
Nolirum said:
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
Click to expand...
Click to collapse
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
Nolirum said:
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
Click to expand...
Click to collapse
Cool I'll take a look at these scripts.
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)..
fattire said:
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)..
Click to expand...
Click to collapse
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.
Yeah, so... Regarding the scripts, since I've put them up here for people to download - I should mention that the first person to test them (aside from me) has reported that something's not working right (I'm waiting for confirmation but I think he tried out the x86 version). It's likely either an error on my part when copying across from my Arm version, or perhaps something not working right with conditionals, meant to deal with the various OS versions ('if; then' statements, I mean). Once I find out more, I'll edit my earlier post...
fattire said:
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?
Click to expand...
Click to collapse
Oh, sorry for being a bit vague - I just mean perhaps implementing a kind of systemless root à la Magisk/SuperSU (from what I understand of how these work) - avoiding the need to actually replace files in /system. Since I'm mainly just using su for the privileges rather than actually wanting to write to /system, I had the idea that perhaps a sort of overlay on e.g. xbin and a few other locations, rather than actually rebuilding the whole of /system, might be an interesting approach....
Yep, I've been replacing /opt/google/containers/android/system.raw.img with a symlink to my modified image lately. Works fine... I think they've been focused on just getting the apps working properly, maybe something like dm-verity is still to come.
Although, one of the cool things with Chromebooks IMO is that once the Developer Mode (virtual) switch has been flipped, the system's pretty open to being hacked around with. I think a large part of the much-trumpeted "security" of the system is thanks to the regular mode/Dev mode feature, once in Dev Mode with verified boot disabled on the rootfs, we can pretty much do what we want (I like the message that comes up in the shell when entering the first command I posted under the spoiler - it literally says "YOU ARE ON YOUR OWN!").
So yeah, with Dev Mode switched off, verified boot switched on, we can't even get into the shell (just the walled-off 'crosh' prompt), making the system indeed rather secure (but, for some of us, rather limited).
fattire said:
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Click to expand...
Click to collapse
That's what I mean by a moving target, lol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61. Problems with being on the more 'bleeding edge' channels include:
#Sometimes stuff gets broken as they commit experimental changes.
#Any updates sometimes overwrite rootfs customizations; the higher the channel - the more frequent the updates occur.
#Some of the stuff that gets updated, may later get reverted.
And so on...
fattire said:
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Click to expand...
Click to collapse
Yeah you'd think so. Honestly, the more I use CrOS the more it seems like a (very polished) work-in-progress to me. Though, I guess most modern OSs are also works-in-progress though. (I don't mean the former statement in a critical way; I'm very happy that new features keep getting added to the OS - Android app support being a perfect case in point, that was a lovely surprise, greatly extending the functionality of my Chromebook).
fattire said:
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...
Click to expand...
Click to collapse
Netcat's not there but socat, which I haven't any experience with but have seen described as a "more advanced version of netcat", is listed in /etc/portage/make.profile/package.installable, meaning that adding it to CrOS is supported, and as simple as:
Code:
sudo su -
dev_install #(sets up portage in /usr/local)
emerge socat
I tried socat out and it seems to work, might be interesting to play around with.
fattire said:
btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example...
Click to expand...
Click to collapse
Theres a question. I forget some of the exact details now (gleaned from browsing the developer mailing lists and the documentation on chromium.org), but from what I do remember and my experiences tinkering, I can say:
The auto-update model uses kernel/rootfs pairs, e.g. at the moment my device is booting from partition 2 (KERN-A) with the rootfs being partition 3 (ROOTFS-B). My understanding is that with the next OS update pushed to my device, CrOS will download the deltas of the files to be changed, and apply the changes to partitions 4 and 5 (KERN-B and ROOTS-B), setting new kernel GPT flags (priority=, tries=, successful=), which will, post-reboot, let the BIOS know that 4 and 5 will form the new working kernel/rootfs pair. Then the following update will do the same, but with partitions 2 and 3, and so on and so forth, alternating pairs each time. It's a pretty nifty system, and I think something similar might be happening with new Android devices from version O onward (?).
So partitions 2,3,4,5 are fair game for being overwritten (from the perspective of the CrOS updater program). Partition 1, the 'stateful partition') is a bit special, in addition to a big old encrypted file containing all of the userdata (/home/chronos/ dir?), it also has some extra dirs which get overlaid on the rootfs at boot. If you have a look in /mnt/stateful/, there should also be a dir called 'dev_image', which (on a device in Dev mode) gets mounted up over /usr/local/ at boot. As I mentioned above, if you do
Code:
sudo su -
dev_install
you can then emerge anything listed in /etc/portage/make.profile/package.installable (not a great deal of stuff admittedly, compared to Gentoo), which gets installed to subdirs in /usr/local/. So I think stuff in partition 1; /mnt/stateful/, should be safe from being overwritten with an OS update. I think crouton chroots get put there by default.
Most of the other partitions don't really get used, and shouldn't get touched by the updater, here's a design doc on the disk format, and here's a Reddit post (from a Google/Chromium employee) mentioning dual booting from partitions 6 and 7.
fattire said:
would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
Click to expand...
Click to collapse
It's not too hard to mess up the system and get it into an unbootable state, lol. The "powerwash" just seems to remove user data, mainly. If you change up (the contents of) some files in /etc, or /opt, for example, then powerwash, normally they won't get restored to their original state (unless you also change release channel).
But, as long as the write-protect screw's not been removed and the original BIOS overwritten, it's always possible to make a recovery USB in Chrome's Recovery Utility on another device, and then restore the entire disk image fresh (this does overwrite all partitions). Another thing that I did was make a usb to boot into Kali; I was experimenting with the cgpt flags on my internal drive and got it into an unbootable state, but was still able to boot into Kali with Ctrl+U, and restore the flags manually from there. (To successfully boot from USB, it was essential to have previously run the enable_dev_usb_boot or crossystem dev_boot_usb=1 command in CrOS). I understand also that the BIOS type varies with device release date and CPU architecture, and that Intel devices may have some extra potential BIOS options ('legacy boot').
fattire said:
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default with 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...
Click to expand...
Click to collapse
I think I saw something related to this on the bug tracker. If I come across any info, I'll let you know...
fattire said:
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
Click to expand...
Click to collapse
Yeah, I haven't built Chromium OS or anything, but apparently, there's an option to create a 'private' overlay for the build, which doesn't get synced with the public stuff.
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
"That article is a little misleading in terms of open source. While the wayland-server and services that communicate with the ARC++ container are open source, the actual ARC++ container is not."
Perhaps they're waiting to see how similar implementations of Android within a larger Linux setup (e.g. Anbox) fare.
There doesn't seem to be too much that differs from AOSP in the ARC++ container - a few binaries and bits and pieces linking the hardware to the container (e.g. the camera etc), maybe some stuff related to running in a container with the graphics being piped out to Wayland?, and so on.
Oh, I was searching the bug tracker for something else, and just saw this (quoted below). Looks like it might be possible to run AOSP based images on CrOS soon!
arc: Implement android settings link for AOSP image
Reported by [email protected], Today (72 minutes ago)
Status: Started
Pri: 1
Type: Bug
M-60
When ARC started without the Play Store support there is no way for user to activate Android settings. We need implement corresponded section that has
Title: Android settings:
Link: Manage android preferences:
Inner bug: b/62945384
Click to expand...
Click to collapse
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?
ol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61.
Click to expand...
Click to collapse
This is the -env file I'm missing, I presume?
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
Click to expand...
Click to collapse
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.
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.
fattire said:
I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
Click to expand...
Click to collapse
lol yeah. True, that.
fattire said:
...assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
Click to expand...
Click to collapse
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.
fattire said:
This is the -env file I'm missing, I presume?
Click to expand...
Click to collapse
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.
fattire said:
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?
Click to expand...
Click to collapse
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.
fattire said:
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...
Click to expand...
Click to collapse
Interesting... I agree, those would both be useful additions to the functionality of ARC++...
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...
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.
From what I remember, the build system would do whatever key signing was necessary.... although I do now remember you're right there was some manual step when I was building the kernel, but I can't remember if that's because of MY changes or that was just part of the build process.
I I just dug out the old VM (Xubuntu) I was using to build and, well, let's just say I'll be doing a LOT of ubuntu updates before I can even realistically look at this. I do kinda recall setting up the environment was a huge pain so I'm going to see if I can just update the 5 year old source, target the pro and just build the kernel image and see what pops out the other end. At least I won't have to deal with the cross compiler, though I think it should hopefully take care of that itself.
Interesting to see that those crouton projects have emerged (no pun intended) so I'll check them out too while ubuntu updates itself
Thanks for the github links.. I'm going to go read that wiki.
Update: Looked at it-- funny they just stripped out the chromeos-specific parts they needed rather than emerge everything which is smart. My only question is now that Android is involved, there's that script I linked to earlier that seems to say "if you want Android support you'll need these bits too"-- wonder if the same config scripts apply, and if there are any other device tree considerations as well...
I may play a bit and see how smoothly it goes.. Unfortunately I don't have unlimited time either :/
Also, please do let me know if you put the scripts on github and I can send you pull requests if I come up with anything.
Update: Finally updated like 3 major versions of ubuntu... the "depot_tools" repo had its last commit in 2013, so I updated that. Wow, this is so much clearer than previous docs... it looks like something called gclient is used now, which I configured with:
gclient config --spec 'solutions = [
{
"url": "https://chromium.googlesource.com/chromium/src.git",
"managed": False,
"name": "src",
"deps_file": ".DEPS.git",
"custom_deps": {},
},
]
'
that let me do gclient sync --nohooks --no-history ...which i think is updating the ancient source. I probably should have just started over, but anyway... we'll see what happens.
Update again: After updating with this new gclinet tool, it appears that the old repo sync method is still required as described here. That hasn't changed after all, so now I'm going to go through this old method, which will probably completely overwhelm my storage as it's downloading with history.. but anyway, in case anyone is trying this-- looks like the whole chroot/repo sync thing may still be how it's done... the /src directory described above may only be for building just the browser, not the whole OS...
...and here it is. I will have zero room to actually build anything tho, but hey.
* [new branch] release-R58-9334.B-caroline-chromeos-3.18 -> cros/release-R58-9334.B-caroline-chromeos-3.18
Note to self: use cros_sdk --enter to actually get in the chroot. Then:
~/trunk/src/scripts $ ./setup_board --board=caroline
to set up the build for caroline. Then to build:
./build_packages --board=caroline --nowithdebug
Useful links:
* Building ChromiumOS
* [URL="http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq"]eBuild FAQ
[/URL]