Database Users

Compiling CM6 for the Eris

Hey folks. I've wanted to add this functionality to Android Builder for a while, but being me... I've done other things. We'll here's what I have now. It's a script that grabs CM6 source, Conap's vendor tree, and compiles it all into a zip. It's currently a standalone script and has some remnants from the Froyo AOSP version, but anyway... It seems to work although the resulting ROM needs tweaking.
(I had to change out the kernel and modules and it still wouldn't pull up the home screen. It did flash and boot though. Progress!)
Many thanks to Armin Čoralić for the first part of the script, Conap for the vendor tree and helping me to work this out, and the CM team for their awesome work.
Code:
#!/bin/bash
# Armin Čoralić http://blog.coralic.nl
# Part 1 modified by gnarlyc
# Part 2 created mostly by gnarlyc although I just took the commands from the CM site and made them into a script.
# Set $KITCHEN_ROOT equal to the current directory. This makes the code 'portable'.
export KITCHEN_ROOT=`pwd`
echo "Setting up the folders....."
# Create the folder structure. This can be slimmed down, but I made this script by cutting and pasting some of Android Builder...
mkdir -p $KITCHEN_ROOT/builder/source/projects/CM6/
if [ ! -d $KITCHEN_ROOT/builder/bin ]
then
mkdir $KITCHEN_ROOT/builder/bin
fi
# Make sure that buidler/bin is in the path and then get the repo binary.
export PATH=$PATH:$KITCHEN_ROOT/builder/bin
curl http://android.git.kernel.org/repo > $KITCHEN_ROOT/builder/bin/repo
chmod a+x $KITCHEN_ROOT/builder/bin/repo
# Initialize the repo.
echo "Initialize GIT repo....."
cd $KITCHEN_ROOT/builder/source/projects/CM6
repo init -u git://github.com/CyanogenMod/android.git -b froyo
# grab the CM6 source. This will just do updates after you do it once, so there's no harm in doing this every time. Although, you could start over if you wanted...
echo "Sync repo....."
repo sync
# Probably not needed for CM6...
echo "Import GPG key"
echo "-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV
lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7
8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD
u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z
wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq
/HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5
jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4
MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9
b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv
aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k
cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX
gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI
2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl
QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up
hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk
C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX
LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+
OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M
pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s
KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb
N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA
vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo
G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ
hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l
EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=
=Wi5D
-----END PGP PUBLIC KEY BLOCK-----" > /tmp/android.gpg
gpg --import < /tmp/android.gpg
rm -rf /tmp/android.gpg
echo "All Done."
# Cleanup (optional, but I like to start fresh... Just comment out if you want.)
cd $KITCHEN_ROOT/builder/source/projects/CM6/device/htc
rm -rf desirec/
# grab vendor tree
git clone https://github.com/Conap30/android_device_htc_desirec.git
# rename the resulting folder
mv android_device_htc_desirec/ desirec/
#remove unneeded folder
rm -rf desirec/vendor/
# I have already grabbed the needed proprietary files and zipped them up into a zip in a folder above the current folder.
# There are different ways that you can do this.
mkdir -p $KITCHEN_ROOT/builder/source/projects/CM6/vendor/htc/desirec/proprietary
rm -rf $KITCHEN_ROOT/builder/source/projects/CM6/vendor/htc/desirec/proprietary/*
cd $KITCHEN_ROOT
cp ../proprietary.zip $KITCHEN_ROOT/builder/source/projects/CM6/vendor/htc/desirec/proprietary
cd $KITCHEN_ROOT/builder/source/projects/CM6/vendor/htc/desirec/proprietary
unzip proprietary.zip
# I don't know why it wouldn't work for me without modding this. I can't change the source directly, so...
echo 'ro.modversion=CyanogenMod6-Eris' >> $KITCHEN_ROOT/builder/source/projects/CM6/device/htc/desirec/system.prop
# run extract-files.sh --- This needs to be run even though the proprietary files are already there.
cd $KITCHEN_ROOT/builder/source/projects/CM6/device/htc/desirec
./extract-files.sh
# setup the enviroment
cd $KITCHEN_ROOT/builder/source/projects/CM6
. build/envsetup.sh
# If you take out the 'generic_desirec-eng', it will give you a menu instead.
lunch generic_desirec-eng
# This compiles the source with the vendor tree included, makes the zip, signs it, and drops it into the out/target/product/desirec directory. It will tell you this.
make -j$(grep -c processor /proc/cpuinfo) otapackage
Please feel free to use this and help me tweak it. Your comments will be appreciated. You can cut and paste the code or download the attachment and take the '.txt' off of the end. This is LINUX ONLY by the way...
EDIT: Adding latest version to OP.

Thanks!
Thanks for doing this!
It'll be great when this is finished into something that can prompt you for which kernel you would like to use (e.g. conap's CFS) and build a working rom that will always be as up to date as often each of us is willing to build. When I get some time I'll take a look at helping to make contributions back to this.

This is delicious gold. Thanks so much! I know an early version of this helped me out immensely!
Sent from my ERIS using XDA App

Yeah, I thought about pulling the kernel source down too. That won't be hard to add at all.
Thanks!
hoban_eris said:
Thanks for doing this!
It'll be great when this is finished into something that can prompt you for which kernel you would like to use (e.g. conap's CFS) and build a working rom that will always be as up to date as often each of us is willing to build. When I get some time I'll take a look at helping to make contributions back to this.
Click to expand...
Click to collapse

Ok. I am going to run another test with a freshly wiped directory, but here's what I have now...
I've added the code to make it grab the current CFS kernel source from Conap's github, compile it and wlan module, and insert them into the tree... This currently does not get the other modules or give you the option for different kernels, but those can be added later.

great....i'm being replaced by a script....thanks alot lmao....

Conap said:
great....i'm being replaced by a script....thanks alot lmao....
Click to expand...
Click to collapse
ConapBot. 10 char....

It'll be great when this is ready. Good luck guys.
Sent from my Tazz Vanilla

Conap said:
great....i'm being replaced by a script....thanks alot lmao....
Click to expand...
Click to collapse
I've been looking for a good name for the standalone version of this. Maybe I should call it ConapScript? Or how about just c0nap?
Can you tell me what else you can do, so I can add that to the script?
lol
Thanks man for sticking in there and just getting neat things done. Maybe I can 'finish' this one...
EDIT: Sorry, 'roirraW "edor" ehT', I missed this one - "ConapBot". That's it! We have a winner.

gnarlyc said:
... Maybe I can 'finish' this one...
Click to expand...
Click to collapse
I highly doubt it

Conap said:
great....i'm being replaced by a script....thanks alot lmao....
Click to expand...
Click to collapse
lol, I for one, will not be using this script, conap... so, you can feel wanted/needed still
... you know how gnarly gets man, pay no attention

workshed said:
I highly doubt it
Click to expand...
Click to collapse
Well. Since these kinds of things are never really done, I highly doubt it too. As long as it helps others to save time or understand something a little quicker & better than they would otherwise, I'm happy with it.
Jerk. I think you made me cry again. lol
EDIT: Oh, yeah. I forgot to mention. I wrote Android Builder. And this ROM sucks.

gnarlyc said:
Well. Since these kinds of things are never really done, I highly doubt it too. As long as it helps others to save time or understand something a little quicker & better than they would otherwise, I'm happy with it.
Jerk. I think you made me cry again. lol
EDIT: Oh, yeah. I forgot to mention. I wrote Android Builder. And this ROM sucks.
Click to expand...
Click to collapse
Obviously you DIDN'T forget to mention anything
And who's really the "Jerk" here? I don't give people false hopes lol

Oh, and btw... nice job gnar!

workshed said:
Oh, and btw... nice job gnar!
Click to expand...
Click to collapse
Thanks. You're the best. If you weren't in Delaware, I'd hug you.

Polished it up a little and ran it successfully from a fresh and clean directory. My next step is to test the resulting ROM again. Anybody else is free to give it a go and report back though.

gnarlyc said:
Thanks. You're the best. If you weren't in Delaware, I'd hug you.
Click to expand...
Click to collapse
lol, you're thinking of a different, awesomely cool dev named nocap

Awesome. Definitely going to try this...
So it creates a ROM or an update script?

Hungry Man said:
Awesome. Definitely going to try this...
So it creates a ROM or an update script?
Click to expand...
Click to collapse
From the OP page...
It's a script that grabs CM6 source, Conap's vendor tree, and compiles it all into a zip. It's currently a standalone script and has some remnants from the Froyo AOSP version
Click to expand...
Click to collapse

Hungry Man said:
Awesome. Definitely going to try this...
So it creates a ROM or an update script?
Click to expand...
Click to collapse
Yeah man. It creates a ROM. The next update should allow you to select between different kernels too. If I get around to converting it to a plugin for the kitchen, it will drop the ROM into the original_update folder just like Android Builder does.

How to make rootfs / writable

The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
I'm fairly noobish w.r.t. Android (but rapidly less so!), but long in the tooth with unix and linux.
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
For the life of me, examing the output of mount, I can't figure out what device path to use in the command,
mount -o rw -o remount <device> /
I'm guessing it probably isn't this simple, and there is some convoluted loop config with mount or something as part of the Android security mechanism.

You can mount it as r/w with Root Explorer...

SubnetMask said:
You can mount it as r/w with Root Explorer...
Click to expand...
Click to collapse
ES File explorer will also allow you mount as writable. Under Menu>Settings>Root options.
It's a little flaky though, I have to turn on the root options then shut down the app and restart it to get it to work. It's free and available in the Android Market.

dwallersv said:
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
Click to expand...
Click to collapse
You can remount / as read-write with:
Code:
mount -wo remount rootfs /
and read-only again with:
Code:
mount -ro remount rootfs /
However, the root filesystem is actually a ram disk (initramfs), so any changes to it aren't persistent across reboots. You can modify the initramfs, but it requires rebuilding it and packaging it with a kernel, and flashing the kernel containing the new initramfs.
dwallersv said:
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
Click to expand...
Click to collapse
Can you get away with placing it in /data or even /system? If you can't recompile bash, you'll have to invoke it with "bash --init-file /data/local/.bashrc" or something.
If you're using ConnectBot Local, you can do that automatically with "Post-login automation", e.g., "exec bash --init-file /whatever/.bashrc".

I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.

DiGi760 said:
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
Click to expand...
Click to collapse
That's for "/system", OP is asking about "/".

You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot.
The only way you can accomplish what you want, in this circumstance, is the method listed above, or to modify the initramfs.

Thanks everyone, for all the great information... Man, I love this place!
@mkasick: Crap!! Well, that torpedoes this one.
I've already used the various "workarounds" you cited (use connect automation with ConnectBot, for example). My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
I'm not going to go to all the trouble to rebuild a custom initramfs for just this.
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Once again, mkasick, you are a most helpful fellow around here. I must say -- and it may make you blush -- I am a big fan and admirer of yours, with the things you've found and fixed for the community. You are unique among the devs in my view, given the nature of what you have looked into and fixed. I'm a pretty experienced, knowlegable software guy myself, and fancy learning enough about Android to make contributions in the not-too-distant future like you have.
As I mentioned in another thread, I'm looking at a major driver re-design for the keyboard based on your analysis and patch for the dropped keypress problem... I plan to have some discussions with you (if your interested) sometime in the next few weeks about what I'm planning, just to get your feedback, if nothing else. Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Keep up the good work, friend. You are a uniquely valuable member of this community, in my judgement
-- And that's not to shortchange any of the other devs here, it's just that the nature of your work resonates with me especially, given my own background, career, interests, and past work in software.

Dameon87 said:
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot
Click to expand...
Click to collapse
Spot-on, and very good point. However, there are ways around that:
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Click to expand...
Click to collapse
In fact, in a more generalized sense, this approach can be used to make any changes to the rootfs that "persists" across boots, without the pain of rebuilding initramfs and repackaging the kernel. This is especially messy to track and manage when you take advantage of one of the excellent custom ROMs here (in my case, Bonsai).
FWIW, and maybe helpful to others, I already have organically evolved as "reinstall" framework/process for doing some customizations to the system after installing a new/updated ROM. I use shell scripting for a lot of little things, and keeping this stuff working became a challenge across ROM releases, because necessary components -- like shells, busybox versions, whether busybox of toolbox is being called by the default path, and a bunch of other things (like the ALSA tools) are present in places like the /system filesystem.
All this gets mucked up with each ROM/kernel update. Now, I'm slicing this bologna even thinner by messing with rootfs, so I've got to get things to persist across boots!
I have a simple, one-step process for fixing all this after a new ROM. Nothing fancy -- just a flashable, Edify zip of my stuff that I hit right after a ROM update. Found a template zip with very generic Edify script in it that simply copies the file tree. I keep my custom stuff updated there.

dwallersv said:
My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
Click to expand...
Click to collapse
How about setting BASH_ENV or HOME in telnetd's environment? Or is the environment not preserved?
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only.
Click to expand...
Click to collapse
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
There's also using gscript, maybe Tasker, or another program that hooks ACTION_BOOT_COMPLETED. Those won't run at root privileges, but a tie in to "su -c" should work.
dwallersv said:
You are unique among the devs in my view, given the nature of what you have looked into and fixed.
Click to expand...
Click to collapse
Thanks!
I think of my contributions as complementary though. I don't really have the time or patience for "maintaining stuff" that other folks do here very well.
dwallersv said:
Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Click to expand...
Click to collapse
I suppose discussion elsewhere is appropriate. Sounds ambitious, but a good idea. The existing keyboard driver architecture could be improved for certain. To date though, I've tried to make my kernel changes relatively non-invasive, even if not ideal, for maintenance sake.
In a perfect world, a rewritten driver would make it back to Samsung and that would be the "end of it" for us. Personally, I wouldn't want to expend the effort to do so unless I knew it would be merged. But if that something you feel like attempting, there's no harm in trying and seeing what results.

mkasick said:
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
Click to expand...
Click to collapse
I'm not 100% certain at this point, but from what I've found investigating this, it looks like the "user scripts" /etc/init.d/<scripts> mechanism is a standard part of the Android system. I'll see if I can find where I saw that and post a link.

[ee03] add init.d support

I managed to get init.d working on the EE03 leak but it broke logcat, I switched to the no-op scheduler and it seems to be quite a bit more responsive =p
I wish I could post how I did it but xda thinks a file path is an outside link and wont let me submit it...
Is this useful at all? I don't know much about android but I'm a linux nerd by profession

chairface said:
I managed to get init.d working on the EE03 leak but it broke logcat, I switched to the no-op scheduler and it seems to be quite a bit more responsive =p
I wish I could post how I did it but xda thinks a file path is an outside link and wont let me submit it...
Is this useful at all? I don't know much about android but I'm a linux nerd by profession
Click to expand...
Click to collapse
Makes sense that noop i/o would be more responsive as it's designed for flash memory devices. Init.d is supported by default in cm7 and it's always handy to have it around for keeping things out of the original init.<device>.rc without having to recompile initramfs.
All you need is 10 posts and you'll be able to post whatever you need.
You can also use the 'CODE' tags to paste paths, etc.

init.d was enabled via the initramfs in the kernel. Scrips go in /system/etc/init.d - and have on every ROM with initscripts enabled.
Thanks for the tip on the scheduler - feel free to play around with the other settings. Have a look at the tweaks thread for some possibilities.

k0nane said:
init.d was enabled via the initramfs in the kernel. Scrips go in /system/etc/init.d - and have on every ROM with initscripts enabled.
Thanks for the tip on the scheduler - feel free to play around with the other settings. Have a look at the tweaks thread for some possibilities.
Click to expand...
Click to collapse
/system/bin/sh can't parse if [ <x> ] statements...
the block in twilightzone.sh that says
<code>
if [ -d /etc/init.d ]
then
run-parts /etc/init.d
fi
</code>
should be changed to
<code>
/sbin/busybox [ -d /etc/init.d ] && /sbin/busybox run-parts /etc/init.d
</code>
thanks for all your hard work man
also the updater-script has to set everything in /etc/init.d to 755 - it doesn't in ee03

I wasn't aware init.d support was there until after I wrote the script.

oh haha
I changed /system/bin/sh to point to busybox... the only thing it seems to break is logcat =\
before I did this nothing in /etc/init.d worked, if I did
/sbin/twilightzone.sh
it wouldn't run /etc/init.d but if I did busybox sh /sbin/twilightzone.sh it did
I probably broke a lot of other stuff doing this too but it's working well so far.
while I have someone knowledgeable here, is it possible to extract/repack the zImage? I'm assuming either ACS did that or used an older 2.2 kernel

[Call for Help] Kernel Parameters - ro.secure

Ccurrently trying to get the SkyGO app working on the HD2.
One of the devs has suggested that for the app to work properly we need a Kernel with "ro.secure=1" set in it.
Currently I am bouncing between Typhoon 3.7.6 (which uses tytung's r14 kernel) and NexusHD2-ICS-4.0.3 (tytungs ICSr1 Kernel I believe)
Can anyone tell me how to find out if the kernel has this parameter set. If not how easy would it be for me to add it and recompile the kernel (pointers to kernel de/recompilation threads appreciated!
I'm not to worried about doing it myself if I have to.
TIA
mods - if this is in the wrong forum I apologise in advance, could you move it for me if it is

bobjbain said:
Ccurrently trying to get the SkyGO app working on the HD2.
One of the devs has suggested that for the app to work properly we need a Kernel with "ro.secure=1" set in it.
Currently I am bouncing between Typhoon 3.7.6 (which uses tytung's r14 kernel) and NexusHD2-ICS-4.0.3 (tytungs ICSr1 Kernel I believe)
Can anyone tell me how to find out if the kernel has this parameter set. If not how easy would it be for me to add it and recompile the kernel (pointers to kernel de/recompilation threads appreciated!
I'm not to worried about doing it myself if I have to.
TIA
mods - if this is in the wrong forum I apologise in advance, could you move it for me if it is
Click to expand...
Click to collapse
This is a question. [Q&A]

yz.hd said:
This is a question. [Q&A]
Click to expand...
Click to collapse
Thanks for the useful and insightful response
FYI - I realised that it might be after I submitted it! Which is why I caveated the post at the end.

this parameter is in the initrd.gz in the kernel in the boot folder of the ROM.
You should extract it and inside there is a file called default.prop
extract
mkdir initdir
cd initdir
zcat ../initrd.gz | cpio -i -d
compress
cd initdir
find . | cpio -o -H newc | gzip -9 > ../initrd.gz
Each line in the file default.prop is an attribute assignment. There we need to
Note the two properties: ro.secure, and ro.debuggable. . If ro.secure = 0 is allowed us to run the adb root command.
Usually we put the core ROOT refers to the ro.secure = 0. ROOT permission to refer to the general said on the phone
A license management program (Superuser.apk) procedures for the root user can grant permission.

bobjbain said:
Ccurrently trying to get the SkyGO app working on the HD2.
One of the devs has suggested that for the app to work properly we need a Kernel with "ro.secure=1" set in it.
Currently I am bouncing between Typhoon 3.7.6 (which uses tytung's r14 kernel) and NexusHD2-ICS-4.0.3 (tytungs ICSr1 Kernel I believe)
Can anyone tell me how to find out if the kernel has this parameter set. If not how easy would it be for me to add it and recompile the kernel (pointers to kernel de/recompilation threads appreciated!
I'm not to worried about doing it myself if I have to.
TIA
mods - if this is in the wrong forum I apologise in advance, could you move it for me if it is
Click to expand...
Click to collapse
look here this great kernel should have ro.secure set to 1

Bologna said:
look here this great kernel should have ro.secure set to 1
Click to expand...
Click to collapse
it doesn't, it's based on Tytung's Kernel, Tytung's doesn't so I'm not suprised that dorimnax's "greatest ever" (sic) doesn't teither

big thanks to magnus48, have decompressed the kernel, changed ro.secure to 1, recompressed, copied to /boot
Phone booted (which suprised me) and my SkyGo App now works.
Yay

magnus48 said:
The easy way is use root explorer and edit /default.prop on your device but is not free.
ro. means read only you can't change it's value after rom is loaded
Click to expand...
Click to collapse
So, I can either change the value in my kernel OR I can edit default.prop and reboot??
Won't the values in default.prop get overwritten on boot??

bobjbain said:
it doesn't, it's based on Tytung's Kernel, Tytung's doesn't so I'm not suprised that dorimnax's "greatest ever" (sic) doesn't teither
Click to expand...
Click to collapse
First question : Why of this sarcastic reply?
Second question : Can you please share your skygo working app, telling us what's the kernel you're using to have it working?
Thanks in advance

bobjbain said:
So, I can either change the value in my kernel OR I can edit default.prop and reboot??
Won't the values in default.prop get overwritten on boot??
Click to expand...
Click to collapse
forget this way. It did not work when rebooting the kernel overwrites the deafult.prop file.
The change should be done inside initrd.gz

magnus48 said:
forget this way. It did not work when rebooting the kernel overwrites the deafult.prop file.
The shange should be done inside initrd.gz
Click to expand...
Click to collapse
You should be able to pull it, make changes and push it back to phone via adb. Useful if you don't want to reflash
Sent from my HD2 using XDA

jwchips said:
You should be able to pull it, make changes and push it back to phone via adb. Useful if you don't want to reflash
Sent from my HD2 using XDA
Click to expand...
Click to collapse
default.prop is in the initrd.gz, this is extracted when the phone boots, so any changes you make to default.prop WILL be overwritten when the phone boots.
You have to make the changes inside the initrd.gz file.

Bologna said:
First question : Why of this sarcastic reply?
Click to expand...
Click to collapse
I don't quite hold dorimanx in quite the high esteem that others do, his work is good but it can be rushed as shown by his 5.x series of Kernels.
Bologna said:
Second question : Can you please share your skygo working app, telling us what's the kernel you're using to have it working?
Thanks in advance
Click to expand...
Click to collapse
Here although this is an app for UK Sky only and won't work for non-UK subscribers.

bobjbain said:
default.prop is in the initrd.gz, this is extracted when the phone boots, so any changes you make to default.prop WILL be overwritten when the phone boots.
You have to make the changes inside the initrd.gz file.
Click to expand...
Click to collapse
Any chance you could post the modified kernel? I am running R14 on GB3.2a so it would drop right in

CR5N said:
Any chance you could post the modified kernel? I am running R14 on GB3.2a so it would drop right in
Click to expand...
Click to collapse
yertiz.
Take a backup of your current initrd.gz first though to be on the safe side.

bobjbain said:
yertiz.
Take a backup of your current initrd.gz first though to be on the safe side.
Click to expand...
Click to collapse
Thankyou. This works on Tytung GB3.2a. F1 channel now working on this old HD2

What about SD builds?
magnus48 said:
forget this way. It did not work when rebooting the kernel overwrites the deafult.prop file.
The change should be done inside initrd.gz
Click to expand...
Click to collapse
I can access and edit default.prop on my SD build after the phone has booted. This seems to give me access to Sky News at least. But I still can't get premium channels. Do you think I still need to edit initrd.gz as well or is that now redundant?

johnkst said:
I can access and edit default.prop on my SD build after the phone has booted. This seems to give me access to Sky News at least. But I still can't get premium channels. Do you think I still need to edit initrd.gz as well or is that now redundant?
Click to expand...
Click to collapse
No, you will need to edit your initrd.gz
Before I did I could access Sky News only, afterwards the Sky world was my Oyster!!

bobjbain said:
No, you will need to edit your initrd.gz
Before I did I could access Sky News only, afterwards the Sky world was my Oyster!!
Click to expand...
Click to collapse
Thanks Bob. Is there anything else I should edit while I'm at it?
Currently after booting, my default.prop contains the following attributes:
ro.secure=0 (need to change this to 1)
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
I'm particularly suspicious of the last one!
Also... what should I use to edit default.prop within initrd.gz? I tried unzipping it with 7zip, editing the initrd file with a hex editor and re-zipping but it created a significantly smaller file...

johnkst said:
Thanks Bob. Is there anything else I should edit while I'm at it?
Currently after booting, my default.prop contains the following attributes:
ro.secure=0 (need to change this to 1)
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
I'm particularly suspicious of the last one!
Also... what should I use to edit default.prop within initrd.gz? I tried unzipping it with 7zip, editing the initrd file with a hex editor and re-zipping but it created a significantly smaller file...
Click to expand...
Click to collapse
I only ever changed ro.secure, don't have the phone any more so can't check the other values.
To edit the default.prop you need to uncompress the initrd.gz then recompress it using the following linux commands
Code:
extract
mkdir initdir
cd initdir
zcat ../initrd.gz | cpio -i -d
compress
cd initdir
find . | cpio -o -H newc | gzip -9 > ../initrd.gz
As I run windows I downloaded and installed cygwin and used that to uncompress and recompress the kernel.
I edited the default.prop in windows but you can use vi within cygwin if you want.
If you're uncomfortable doing this then attach your kernel to a post and I can do it for you.

[TOOL][BOOT SCRIPTS] bse

Hello, all!
I have recently built a tool that allows users to more efficiently create and run scripts on boot.
These can be python scripts if you have python installed to your system (No, SL4A won't work. At least, not without some work). Usually though, they are bash or sh scripts.
They can be used to do various things, such as fix permissions every reboot, or things such as record a log of the time of every time you boot up your device, or other cool things.
I am currently looking into getting python packed into a flashable zip (lots of more fun with python scripts like showing a toast notification on boot).
To use bse's scripts executing feature, you must place the script you wish to execute under /system/etc/startup. You don't need to worry about chmodding it, there is an init script that does that already. For reference purposes, I recommend you read the contents of that init script (it's in /system/etc/startup).
To clarify, anyone who wants to build an automated installer for this, distribute some scripts, or distribute any modification to be, you have my full permission as long as you provide a link to this thread.
DOWNLOAD
https://docs.google.com/file/d/0ByulRvn_lJmbbnRfMG82Mm9Pb3c/edit?usp=docslist_api
INSTALLATION
- Just flash the zip file in the recovery of your choice
If you have any questions, feel free to ask. I'm sorry, this was written when I was tired (Not the program, the post)
Sent from my Nexus 7 using Tapatalk

FAQ:
What does "bse" stand for?
If you were to run bse alone, you would see that it stands for "Boot Script Executer".
Is BSE open-sourced?
Almost. I lost the source code and I'm in the process of re-creating it from scratch.
Where is the open source repo?
It's at https://github.com/boot-script-executer. PM me with your Github email if you wish to contribute to BSE development or submit your bse scripts. (please tell me which one)
Sent from my Nexus 7 using Tapatalk

Can we have a github source of all the scripts so we can execute in the Roms and execute it in the android source

nice idea
how about adding in a log wrapper to forward all output to the logcat
note: this is untested, but it should work
Code:
function logger() {
# args:
# $1 = message - the message you want to show
# $2 = priority - optional, defaults to i. the priority you want to give the log message
export LOG="/system/bin/log"
tag="BSE_LOGGER"
message=${1}
priority="i"
if [[ $2 ]]
then
options="vdiwe"
if test "${options#*$2}" == "$options"
then
$LOG -p "e" -t "$tag" "invalid priority level: $2"
else
priority=$2
fi
fi
$LOG -p "$priority" -t "$tag" "$message"
}
examples:
Code:
logger "this is a random message"
# I/BSE_LOGGER(15836): this is a random message
logger "another random message" d
# D/BSE_LOGGER(17393): another random message
logger "this message should give an error" t
# E/BSE_LOGGER(17395): invalid priority level: t
# I/BSE_LOGGER(17396): this message should give an error

This is freaking awesome r3. Good job bro.
*Starts slow clapping. Waiting for other people to join in.* ☺
Sent from my SAMSUNG-SGH-I337 using XDA Premium 4 mobile app

cybojenix said:
nice idea
how about adding in a log wrapper to forward all output to the logcat
note: this is untested, but it should work
Code:
function logger() {
# args:
# $1 = message - the message you want to show
# $2 = priority - optional, defaults to i. the priority you want to give the log message
export LOG="/system/bin/log"
tag="BSE_LOGGER"
message=${1}
priority="i"
if [[ $2 ]]
then
options="vdiwe"
if test "${options#*$2}" == "$options"
then
$LOG -p "e" -t "$tag" "invalid priority level: $2"
else
priority=$2
fi
fi
$LOG -p "$priority" -t "$tag" "$message"
}
Click to expand...
Click to collapse
i like the thought of this!

this is realy cool,great idea and work,thanx man.

Sorry if this sounds like a stupid question, but what's the difference between using init.d and your tool or even using script manager to run scripts at boot?
Sent from my GT-P7500 using Tapatalk

Hehe. Funny story about this. All of its source code (There wasn't too much... Don't worry) was on my trusty (not really) old Kindle Fire HD, which I managed to brick. I will have to re-write the source (Again, I didn't really lose that much) and I'll make everything open-sourced (see 2nd post if you want to help contribute).
cybojenix said:
nice idea ...
Click to expand...
Click to collapse
Thanks... I will try to see if I can implement that. If I have no sucess, you could try for yourself once I get everything re-written.

eushaun99 said:
Sorry if this sounds like a stupid question, but what's the difference between using init.d and your tool or even using script manager to run scripts at boot?
Sent from my GT-P7500 using Tapatalk
Click to expand...
Click to collapse
init.d triggered through the rom not the kernel, and it supports python scripts aswell

ricky310711 said:
init.d triggered through the rom not the kernel, and it supports python scripts aswell
Click to expand...
Click to collapse
Hi
I didn't understand this answer...
This solution also relies on init.d. Apart from python interpreting, what's the thing that makes it more robust aganist init.d scripts?
If a Rom (it's kernel) does not or only via 3rd part apps supports init.d, there could be problems the same.

Publiuss said:
Hi
I didn't understand this answer...
This solution also relies on init.d. Apart from python interpreting, what's the thing that makes it more robust aganist init.d scripts?
If a Rom (it's kernel) does not or only via 3rd part apps supports init.d, there could be problems the same.
Click to expand...
Click to collapse
what do you mean?
this doesnt rely on init.d, it is init.d.
this makes your device run init.d scripts WITHOUT the need to modify the kernel unlike some previous methods... but the scripts are called from /system/etc/startup/
the python script support is a featured currently in progress(from what i read)

ricky310711 said:
what do you mean?
this doesnt rely on init.d, it is init.d.
this makes your device run init.d scripts WITHOUT the need to modify the kernel unlike some previous methods... but the scripts are called from /system/etc/startup/
the python script support is a featured currently in progress(from what i read)
Click to expand...
Click to collapse
It does rely on init.d to call the "bse" binary, but I'm looking for an alternative method.
Sent from my Nexus 7 using Tapatalk

ricky310711 said:
what do you mean?
this doesnt rely on init.d, it is init.d.
this makes your device run init.d scripts WITHOUT the need to modify the kernel unlike some previous methods... but the scripts are called from /system/etc/startup/
the python script support is a featured currently in progress(from what i read)
Click to expand...
Click to collapse
Mhhh...
I'm not so expert, but I saw some metods using /etc/install_recovery.sh to call (another script that calls) run-parts to execute all /etc/init.d scripts, don't know if it's a way to make init.d work despite kernel not supporting it...
This one uses init.d itself to call bse executable so... well if init.d is no way supported it won't work?

Publiuss said:
Mhhh...
I'm not so expert, but I saw some metods using /etc/install_recovery.sh to call (another script that calls) run-parts to execute all /etc/init.d scripts, don't know if it's a way to make init.d work despite kernel not supporting it...
This one uses init.d itself to call bse executable so... well if init.d is no way supported it won't work?
Click to expand...
Click to collapse
justarchi has an init.d method where he calls the scripts from debuggerd!

The link is broken ... can upload? please!

Can anyone give me the download link of this tool