Database Users

(for tereg) NoRecovery custom recovery

Hi tereg,
[SIZE=-1](If you are not tereg, you can stop reading this. I didn't PM because I needed to ship an attachment)[/SIZE]
Have a look at the attached (custom) recovery (pick it apart and diff it against the leak-V3/RUU recovery.img) using split_bootimg.pl and the gunzip | cpio pipeline.
You can flash it to your recovery partition and run it if you like, it doesn't do anything dangerous. Basically, it is the same thing as the Leak-V3(=RUU = OTA-2.1) recovery, with two major changes:
- /sbin/recovery service is turned off so this doesn't run automatically (and as a result you won't see the splash screen change from the 3 skating droids). You can run it manually, though, from the adb shell - just wait 8-10 seconds and adbd will come up.
- I added the shell (sh) and a few of the diagnostic tools (dmesg, dumpstate, logcat... and supporting dynamic link libraries, the linker, etc), and dropped in there both /system/bin/toolbox (HTC) and /system/xbin/busybox and created some of the symlinks so that an adb shell has a useful set of tools available. (Oh yeah, I added an /etc/fstab as a convenience for /system/xbin/mount. Note the system mtd partition mounts at /os-system so it won't cover up all the installed tools underneath /system in the boot image)
- I altered the init.rc (and default.prop) so that adbd will always come alive - not just when a race is won.
The base of this image (kernel, bootscripts, /sbin), is the leak-V3 recovery.img; everything else such as dynamicly linked executables and supporting dynamic libraries comes from Jcase's Plain Jane, which in turn comes from Leak-V3/OTA/RUU, so, essentially everything in this bootable recovery comes from HTC except the version of busybox in /system/xbin and mods to the init scripts and default.prop
Note that the NAND flash partition in the mtd device for the recovery is only something like 5.2 MB - I would have added more, but was starting to get tight on space.
If you want it to run as close as possible to the timing of the HTC leak-V3 recovery.img, what I would do would be the following:
- defer all the symlinking in init.rc (except for the "sh" and "ln", of course) and package that up into a shell script that you can run after the recovery has booted
- uncomment (re-enable) the "recovery" service (/sbin/recovery)
- maybe experiment and see if you can get the complete kernel boot sequence from dmesg without starting logcat as the first service (that's not done in the normal recovery).
The only other useful piece of info that I can think of at the moment is that you need to use the ---base option with mkbootimg with an address that starts with something like 0x11208000..... (I can't recall and my machine is down - crap.) You can discover the value of the kernel base address load offset for the Eris by snooping through a hexdump of the beginning of any valid Eris bootable image
cheers
bftb0
MD5s
5801babcdf4e6e5d51e5f775aad0a09e ErisNoRecovery-recovery-v0.9.0.img.zip
4d280b367be75e7e75563a6357575ea7 ErisNoRecovery-recovery-v0.9.0.img
Sent via my nearly dead crap Pentium II booted from a 2003 version of Knoppix - 256 megs of EDO RAM - woot!

Sorry, here's the attachment

I read it anyway.
Suck it.

Hungry Man said:
I read it anyway.
Suck it.
Click to expand...
Click to collapse
Same Here Brosidon,
Well, actually i attempted to read it. Then I got confused and went and got some beef jerkey.

mmm beef jerky. i read it to maybe there will be a fresh recovery menu for the eris.

i read somones got beef jerkey and not sharing *waves fist* four messin up kid
j/k
it would be nice if we got an updated recovery. especially now learning that we won't need/be able to format our sdcards using FroYo.

Actually, I don't mind if anybody reads or uses that - it just gets me off the hook when somone asks
"But what is this for?"
Now someone will ask, LOL
bftb0

bftb0 said:
Actually, I don't mind if anybody reads or uses that - it just gets me off the hook when somone asks
"But what is this for?"
Now someone will ask, LOL
bftb0
Click to expand...
Click to collapse
but what is this for??? can i root my eris 2.1 v3 leak??? can it make pizza out of code? jk jk lol,

Thank you, I got it now.
I will definitely be experimenting with this. I'll let you know if I have further questions.

Tereg, I'll be online tonight and can help with testing.

[Q] Trying to recompile Hastarin for SuperRAM with CIFS: Issues

*EDIT*
Solved, new thread with download here: http://forum.xda-developers.com/showthread.php?t=887567
*/EDIT*
Hey everyone,
I'm trying to re-compile the Hastarin kernel for DarkStone1337's SuperRAM 1.5 to include CIFS support. I've compiled many a linux kernel, but never for Android, so can anyone point out what I'm doing wrong? Here are the commands I've run through:
Added android-ndk-r5/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin to PATH
git clone git://gitorious.org/~hastarin/linux-on-wince-htc/hastarins-linux_on_wince_htc.git
Grabbed DarkStone1337's patch from: http://pastebin.com/6qjkb4Hh
Renamed hastarins-linux_on_wince_htc to "a" to match the patch
patch -p0 < patch.txt (This did report a pre-mature ending on the patch, but everything appears to have patched OK)
make
The result:
arch/arm/mach-msm/built-in.o: In function `dex_cb_interrupt':
/files/Software/Android/hastarin/source/a/arch/arm/mach-msm/dex_comm.c:248: undefined reference to `notify_vbus_change_intr'
make: *** [.tmp_vmlinux1] Error 1
Click to expand...
Click to collapse
Any ideas?
Thanks,
B.

Hi!
Try using this toolchain instead! http://www.codesourcery.com/sgpp/lite/arm/portal/release1293
Then follow these commands to build the kernel:
make clean
make ARCH=arm htcleo_defconfig
Then change what is necessary to add the CIFS support
make ARCH=arm CROSS_COMPILE=/path-to-toolchain/bin/arm-none-linux-gnueabi- zImage
Taken from: http://htc-linux.org/wiki/index.php?title=QuickDeveloperStartGuide#Kernel
Then follow the same guide I linked to, to create the modules.

Hey Darkstone i saw the thread for SuperRAM 1.5 has been closed requested by you. Was there a major reason? Are we not supposed to use it anymore or was it put on hold. just asking because Im still testing it out and its been rock solid after several reboots.

PENKO956 said:
Hey Darkstone i saw the thread for SuperRAM 1.5 has been closed requested by you. Was there a major reason? Are we not supposed to use it anymore or was it put on hold. just asking because Im still testing it out and its been rock solid after several reboots.
Click to expand...
Click to collapse
prob due to folks refusing to read and do a little research before posting common problem Roth common fixes...

DarkStone1337 said:
Hi!
Try using this toolchain instead! http://www.codesourcery.com/sgpp/lite/arm/portal/release1293
Then follow these commands to build the kernel:
make clean
make ARCH=arm htcleo_defconfig
Then change what is necessary to add the CIFS support
make ARCH=arm CROSS_COMPILE=/path-to-toolchain/bin/arm-none-linux-gnueabi- zImage
Taken from: http://htc-linux.org/wiki/index.php?title=QuickDeveloperStartGuide#Kernel
Then follow the same guide I linked to, to create the modules.
Click to expand...
Click to collapse
First off, thanks a ton for responding, this was very helpful. Secondly, sorry for the threadjackers. Lastly, this both works, and doesn't. The following works fine:
# git clone git://gitorious.org/~hastarin/linux-on-wince-htc/hastarins-linux_on_wince_htc.git
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm clean
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm htcleo_defconfig
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm zImage -j 4
Click to expand...
Click to collapse
But when I try to make an exact copy of the kernel you created for SuperRAM 1.5 (without modifying for CIFS), it doesn't, so I must be doing something wrong. Here was my process there:
# git clone git://gitorious.org/~hastarin/linux-on-wince-htc/hastarins-linux_on_wince_htc.git
# mv hastarins-linux_on_wince_htc a
# cd a
# patch -p0 < patch
(Stripping trailing CRs from patch.)
patching file a/arch/arm/mach-msm/qdsp6_1550/q6audio.c
(Stripping trailing CRs from patch.)
patching file a/drivers/video/msm/gpu/kgsl/kgsl_ringbuffer.c
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 786:
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm clean
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm htcleo_defconfig
# cp ../../config ./.config (This config was pulled from SuperRAM 1.5's /proc/config.gz)
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm menuconfig
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm zImage -j 4
arch/arm/mach-msm/built-in.o: In function `dex_cb_interrupt':
/files/Software/Android/hastarin/source/a/arch/arm/mach-msm/dex_comm.c:248: undefined reference to `notify_vbus_change_intr'
make: *** [.tmp_vmlinux1] Error 1
Click to expand...
Click to collapse
Any additional help would be appreciated. Also, is there a reason (performance, size, etc) CIFS is not included by default? I've noticed a lot of other builds are like that, too.
*EDIT* Is it possible I need to checkout a specific version of Hastarin's kernel?
Thanks,
B.

I posted this in the main thread before it was closed -
insmod: init_module 'cifs.ko' failed (Exec format error)
and I looked in dmesg -
cifs: version magic '2.6.32.15r8.6-gb02686c preempt mod_unload ARMv7' should be '2.6.32.15-g2ef5752.dirty preempt mod_unload ARMv7'
Looks like this might be a side effect of the custom kernel and the magic not matching up with the cifs.ko from hastarin. Could this be recompiled with the correct kernel?
Looks like the cifs.ko that was included in the build was the stock module from hastarin - so when you do recompile it, could you post the module as well? I'd love to help, but I don't have a whole lot of experience with compiling kernels.
Thanks.

indecided said:
I posted this in the main thread before it was closed -
insmod: init_module 'cifs.ko' failed (Exec format error)
and I looked in dmesg -
cifs: version magic '2.6.32.15r8.6-gb02686c preempt mod_unload ARMv7' should be '2.6.32.15-g2ef5752.dirty preempt mod_unload ARMv7'
Looks like this might be a side effect of the custom kernel and the magic not matching up with the cifs.ko from hastarin. Could this be recompiled with the correct kernel?
Looks like the cifs.ko that was included in the build was the stock module from hastarin - so when you do recompile it, could you post the module as well? I'd love to help, but I don't have a whole lot of experience with compiling kernels.
Thanks.
Click to expand...
Click to collapse
Hi indecided,
This is the post I'm looking to resolve for everyone. Once I figure this out, I'll post how to patch the SuperRAM 1.5 to support CIFS.
Thanks,
B.

this is great news and i'm looking forward to this - i hope your efforts can accomplish this - it probably won't be easy, which is why hastarin and darkstone might have needed to focus their efforts on other things first -- i'm not being negative, i'm just saying that if you guys get this to work it might be an impressive thing you did. I need it bad too.

OK, unfortunately I've hit a bit of a roadblock. I've got the kernel to compile using nearly all the same config settings as DarkStone with CIFS added, but upon booting the kernel the phone acts as if there is 0% battery and instantly shuts itself off. I'm guessing it has to do with the one problem I had in compiling explained below.
The only difference in the configs for compiling were (removed CIFS info):
# diff MY.config DARKSTONES.config
119,120c119
< CONFIG_SLOW_WORK=y
< # CONFIG_SLOW_WORK_DEBUG is not set
---
> # CONFIG_SLOW_WORK is not set
241,242c240
< CONFIG_HTC_BATTCHG=y
< # CONFIG_HTC_BATTCHG_SMEM is not set
---
> # CONFIG_HTC_BATTCHG is not set
Click to expand...
Click to collapse
So basically, DarkStone's version had SLOW_WORK and HTC_BATTCHG disabled. I have no idea how he accomplished this. No matter what I set SLOW_WORK to, the compilation always changes it back. And if I try to disable HTC_BATTCHG, the kernel errors out with the message from my previous posts.
I'm also not entirely sure the patch DarkStone posted is complete (unless he responds otherwise) because it does end prematurely and was perhaps cut off by pastebin.
I wish I knew what else to try, but I'm not knowledgable enough to know why it thinks the battery is at 0%. I'm guessing it has something to do with the BATTCHG config, but I have no way around it at the moment.
Thanks,
B.

sorry to disturb here, but if you where to successfully recompile, what will be the benefit?
thanks you

there should be tons of warnings though correct?

Fmstrat said:
Any additional help would be appreciated. Also, is there a reason (performance, size, etc) CIFS is not included by default? I've noticed a lot of other builds are like that, too.
*EDIT* Is it possible I need to checkout a specific version of Hastarin's kernel?
Thanks,
B.
Click to expand...
Click to collapse
Hi! Sorry to hear you're having issues with building the kernel.
Here is a properly formatted patch that I've made: http://www.multiupload.com/FDJ4FXZ4L9
I used the eb_oldcam branch (or was it oldcam_eb? I've forgotten )
Try using the htcleo_hastarinconfig as the defconfig file.
I recommended that toolchain because Hastarin and myself have experienced issues with other toolchains causing the proximity/light sensor to eat up more battery during standby.
Hope this helps!
-------
Oh and Merry Christmas folks!

dapoharoun said:
sorry to disturb here, but if you where to successfully recompile, what will be the benefit?
thanks you
Click to expand...
Click to collapse
Ability to mount shares computers over wifi for playing media.

Fmstrat said:
Ability to mount shares computers over wifi for playing media.
Click to expand...
Click to collapse
It's like having a 4 terabyte sdcard. If you have say a 30,000 song collection, and you connect to your home computer via wifi at home you click the songs and they play instantly. For me, I click any one of my 3000 movies and they play on my hd2 in 10 seconds, and I can fast forward and rewind almost instantly.
If you are on the road and have a vpn to your computer and you 'mount the home share remotely' you now have a "virtual sd card" with 30,000 songs that play when you click the songs after about a 6 second lag.

DarkStone1337 said:
Hi! Sorry to hear you're having issues with building the kernel.
Here is a properly formatted patch that I've made: http://www.multiupload.com/FDJ4FXZ4L9
I used the eb_oldcam branch (or was it oldcam_eb? I've forgotten )
Try using the htcleo_hastarinconfig as the defconfig file.
I recommended that toolchain because Hastarin and myself have experienced issues with other toolchains causing the proximity/light sensor to eat up more battery during standby.
Hope this helps!
-------
Oh and Merry Christmas folks!
Click to expand...
Click to collapse
Good news everyone. It's working.
Thanks DarkStone for all your input, using the default config and eb_oldcam worked with the new patch you provided on the first try this time (Btw, I am using the toolchain you recommended now). I do have one last question though, how do I get it to load cifs.ko on boot? Android doesn't appear to have any modprobe.conf or anything similar that I see, so I must be missing something. I have to insmod it manually right now.
*EDIT*: I ended up rebuilding it directly into the kernel instead of a module for now, which works. I know that's not "proper" but that will ensure CIFS is always loaded even if the build doesn't load it by default. If you know a better way, I'm all ears Thanks again! */EDIT*
For everyone else, this is not an EXACT copy of the SuperRAM kernel that DarkStone used, but it's pretty close and seems to be the config they recommend going forward. Rather than post it here right now, I'll give it out as a Christmas gift later today in the Development forum since it will really apply to any RAM release going forward that uses Hastarin's kernel and post a link here. This will give me some time to test and ensure nothing goes weird.
Thanks,
B.

OK, it's all done: Download, installation instructions, and FAQ
I've also opened a thread back in the Android Development section since this is no longer a Q&A: http://forum.xda-developers.com/showthread.php?t=887567
Thanks,
B.

[GUIDE] New Dev mini-guide [12-27-10]

Ok folks. I got this phone in March. It's my first Android phone. I love it. What do I love most? Hacking, tweaking, building, learning cool stuff. Yeah, it makes calls and stuff like that too. Whatever. So did my Startac.
I've been very slowly creating a 'how to get started' post for people who what to be devs. The info is out there elsewhere, but I'd like to consolidate much of it into kind of an overview with links to more detail. The first part is pretty much ready to post, so I figure I'll post it and keep working on the rest. Maybe some of you would like to contribute. Maybe not. I welcome the help though.
Some basics:
1) ROM structure - unzip an existing ROM and get to know the structure
Here's a fairly standard folder structure for an Eris ROM. Most other devices will have something similar.
Code:
/system
/app <- system apps and others that can't be uninstalled normally
/bin <- system binaries (small, standalone programs)
/customize <- has files that control initial boot and some screen settings (not always here)
/etc <- generally system configuration files
/bluez <- bluetooth config files
/clockwidget <- ? (not always here)
/dhcpd <- dhcp config files (dhcp is used to negotiate a network address)
/dmdata <- ?(not always here)
/firmware <- system firmwares
/iproute2 <- configuration files for network routing? (not always here)
/permissions <- describes permissions that apps may use
/ppp <- ppp configuration files?
/security <- certificates for over-the-air (OTA) updates
/wifi <- configuration files and firmwares for wifi
/fonts <- fonts
/framework <- mostly java jar files that contain code that other apps call
/lib <- C (mostly?) libraries that contain code for the system and apps to call
/bluez-plugin <- bluetooth stuff
/egl <- files needed for hardware 3d rendering
/hw <- files needed for various hardware like lights & sensors
/modules <- modules that the kernel might load, such as wlan (wifi)
/media <- audio and animations (usually here)
/audio <- audio files
bootanimation.zip <- well... (can be done another way or two)
/usr <-
/keychars <- keyboard drivers
/keylayout <- keyboard definitions (you can edit the .kl files!)
/share <- ?
/srec <- dictionaries?
/xbin <- more system binaries
build.prop <- config file that sets system variables and stuff
/META-INF
/com
/google
/android
update-script - script that actually copies the ROM to the phone when you flash
CERT.RSA <- created when ROM is signed
CERT.SF <- created when ROM is signed
MANIFEST.MF <- created when ROM is signed
boot.img - see #2 below
Code:
/data <- user and app data
/app <- apps that are installed by and can be removed by user (not always in ROM, but created on device
/other folders (Android/apps create some folders in here post flash and some devs will also add an extra folder or two occasionally
Some .apks can be removed and some cannot. Many different things tie together. For instance, one apk may call code in a lib file, so it's dependant on the lib file.
If you do take an existing ROM apart and change it, you'll have to zip it back up and resign it before it will flash. Here are some tools that will sign a ROM -
EasySign - http://android.grdlock.net/index.php?&direction=0&order=&directory=HTC Droid Eris/Extras
dsixda's Kitchen - http://forum.xda-developers.com/showthread.php?t=633246
AutoSign - http://androidforums.com/developer-101/8665-how-signing-roms.html
2) boot.img - kernel, ramdisk, and init files
The boot.img has the actual linux kernel with some Android and device specific tweaks. Here's the structure for it -
Code:
boot.img-kernel <--- actual kernel (zImage renamed)
boot.img-ramdisk.cpio.gz <--- ramdisk
/data
/dev
/proc
/sbin
/sys
/system
default.prop
init
init.desirec.rc <-- will be named different for different devices, supposed to be device-specific init file
init.goldfish.rc <-- for emulator (You can lose this.)
init.rc <-- always here, this is run on boot
The *.rc files are initalization files, in case you didn't get that. They run when the phone boots up and do things like start 'services' and change permissions on files/folders. I highly recommend that you look at them and compare different ones with something like WinMerge.
I attached an example. You can see where there's been a typo in the stock init.rc for a long time. This is a comparison between the stock init.rc and the one from CELBFroyo.
3) Hardware
Confused as to what refers to what? Me too! Here's a few things that I've figured out. Please point out anything you think is incorrect or needs to be added.
melfas, capella, synaptics = touchscreen
i2c = bus
akmd/akm8973 = accelerometer
mtd/nand/sdio = internal memory
s5k3e2fx = camera sensor
qdsp/adsp/dsp = audio
brf6350 = bluetooth?
Fw1251r1c/wpa/wifi/tiwlan0 = wifi
gralloc/copybits = framebuffer/video/display/graphics memory
malloc = memory allocation

Reserved for more info

Another one reserved for future info.

I just posted something similar in the "general" section...(about Christmas, that is...)
http://forum.xda-developers.com/showthread.php?t=886630

Thanks you for your work and contributions to the eris community. This will be very helpful as im trying to learn my way up. My comp died last week so it'll be a few more weeks till I get another one,but im trying to start doing a lil rom making/codeing myself. Thanks and MERRY CHRISTMAS TO ALL!!¶

Awesome work Gnarly

Brilliant thread! Thanks buddy.
And happy whatever and thanks to all the devs and smart ass users that make this phone surpass expectations every day.

Wait, how do I do all this again? Can you help me?

workshed said:
Wait, how do I do all this again? Can you help me?
Click to expand...
Click to collapse
No. Use the search feature noob!

Thanks for all of the thanks folks. I'm just trying to make it easier for people to become devs. We need as many as we can get. It takes time to learn this stuff, and it's nice when you don't have to spend quite so much of your time searching for the info instead of spending your time learning about the Eris and Android.
To make it more difficult, there's this dev 'club', with their secret IRC channels and PMing all of their secrets back and forth instead of being open and honest. And the chest-hair burning initiation is really tough to get through. (That's why we don't have any female devs, you know.) I did though. And now, I've went all wikileaks on them and they are angry. The attacks have begun already. They are mostly from Delaware, Pittsburgh, and the Seattle area. But, there is a completely incompetent attack coming from Michigan too.

This will help me out a lot. There are a lot of barriers to getting started, and this breaks down many of them. Thanks.

gnarlyc said:
Thanks for all of the thanks folks. I'm just trying to make it easier for people to become devs. We need as many as we can get. It takes time to learn this stuff, and it's nice when you don't have to spend quite so much of your time searching for the info instead of spending your time learning about the Eris and Android.
To make it more difficult, there's this dev 'club', with their secret IRC channels and PMing all of their secrets back and forth instead of being open and honest. And the chest-hair burning initiation is really tough to get through. (That's why we don't have any female devs, you know.) I did though. And now, I've went all wikileaks on them and they are angry. The attacks have begun already. They are mostly from Delaware, Pittsburgh, and the Seattle area. But, there is a completely incompetent attack coming from Michigan too.
Click to expand...
Click to collapse
+1 Internetz to you sir, I lol'd!

Wait so where is the download link? How do I install this?

Hey gnarly I just now looked at this, as many times as I've probably looked at your links I didn't see it and it is perfect, short & sweet but to the point and very informative. I'm sorry for bringing up an old thread guys but I just had to get it out there how helpful this is. Thanks bro!

lemonoid said:
Hey gnarly I just now looked at this, as many times as I've probably looked at your links I didn't see it and it is perfect, short & sweet but to the point and very informative. I'm sorry for bringing up an old thread guys but I just had to get it out there how helpful this is. Thanks bro!
Click to expand...
Click to collapse
No problem. I'm glad you find it helpful. My intention was for other folks to contribute as they learned new things, but that didn't really happen. Oh well... (Hint, hint, hint).
And, I never got around to adding a section on 'ethics', so here you go...
1) ask permission before using other's work
2) give credit for using other's work
3) don't lie about what you did or what your ROM really is
4) #1-#3 are much easier and less stressful than the alternatives, and they're just plain nice

gnarlyc said:
No problem. I'm glad you find it helpful. My intention was for other folks to contribute as they learned new things, but that didn't really happen. Oh well... (Hint, hint, hint).
And, I never got around to adding a section on 'ethics', so here you go...
1) ask permission before using other's work
2) give credit for using other's work
3) don't lie about what you did or what your ROM really is
4) #1-#3 are much easier and less stressful than the alternatives, and they're just plain nice
Click to expand...
Click to collapse
Well as I pick up on a few more things, I have a few kinks in my brain to work out, I will definitely put whatever I can to help. As you know at least, I'm still very fresh at all of this, which makes this even better. Newer minds are constantly developing new knowledge and skills to improve their own efforts, and I personally think that many of the seasoned devs know so much and have had their hands in the pot so long, that they might not remember all of the little things that had to be overcome or learned at the beginning. So with good communication between beginners and experienced developers, I believe that is the only way an amazing guide can be released. And that has already begun here, and obviously countless other places. Thanks again gnarly

Nice write up! Thanks, the info is greatly appreciated.
Sent from my un-rootable Incredible 2 using XDA app

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.

[UPDATE 2/12/2010] Terminal IDE - Full 'on device' Java / Android IDE

[UPDATE]
BusyBox 1.19.2
Bash 4.2
Midnight Commander 4.8
TMUX 1.5 - That's right, full terminal multiplexer..
Vim 7.3
Terminal IDE ASCII Soft keyboard first round bug fixes complete.
It's the addition of TMUX and MC that really excites..
--------------------------
Well,
As the only people I know who might even be interested in this, I would like to announce the release of Terminal IDE v1.0.
A complete Java / Android Development Environment that runs on the device itself, with a nice telnetd / sshd feature.
For Android. Of course... Eat this you IPhone Hounds..
Woo HOO!!
The application is available on Android Market.
https://market.android.com/details?id=com.spartacusrex.spartacuside
As what I can only describe as 'dark days' finally draw to an end, I am very pleased with this first draft.
PLEASE give it a go, log in over telnet for a smoother ride, and let me know how it goes..
DO THE TUTORIAL! Does it work ?!
I have released the whole project GPLv2! Yeah, Who Knew!?
http://code.google.com/p/terminal-ide/
BOOOOOM!
Spartacus

a link to the app in the market would be usefull.

Interesting. Was just wondering about coding on my tablet.

Pretty freakin sweet
Thanks for putting this out!

Awesome
The full keyboard alone makes it worth downloading, but the IDE as well - wow!

this is best bro.

I randomly found this last night while looking for a decent mobile IDE for my tablet. I was looking for a simple text editor with syntax highlighting and you've taken that extra step to include other tools for ssh, telnet and compilers. Much appreciated.
One question, how do you start the ssh server? sshd doesn't seem to do it. I would like to scp files to my device from my desktop in order to work on my commute.
Thanks

The sshd app is actually called Dropbear.
You also have Dropbearkey.
You use Dropbearkey to generate the sshd certificates you need.
I really need to add a tutorial on setting the sshd keys up
For now Google has a couple of articles on it.
For file transfers you also have busybox FTP but I admit not terribley secure..
Allthough SSH is provided, and I wonder whether an SSH pipe can be created..?
And lastly you can just copy the files over to your sdcard via USB..
Will look into it & add tutorials asap.

Ok. So I now have SSHD working..
But there is a slight issue.. basically when you log in you have to start bash manually.. unless you have the file /etc/shell with the correct shell to use.. Which requires a rooted phone.
Since Terminal IDE is for non-ROOT users, I will have to recompile the code to allow a shell to be specified on the command line.. Soon..
FOR NOW - This is how to connect to the phone via SSH (There are other ways using public keys but this is one way)
So - Once in Terminal IDE
2) You need to create a couple of server ssh keys
Start in $HOME
Code:
cd ~
Create folder
Code:
mkdir .ssh
Give it some secure permissions
Code:
chmod 700 .ssh
Get in there
Code:
cd .ssh
Now create the keys
Code:
dropbearkey -t dss -f dropbear_dss_host_key
dropbearkey -t rsa -f dropbear_rsa_host_key
ok - That's almost it. Just need to start dropbear with the correct parameters now. [Probably want to keep this in a script]
Back HOME
Code:
cd ~
You need to know the UID of your app, which is different per phone - use 'id'
Code:
id
That will tell you your user ID / Group ID. Let's say its 10058.
Now to start DropBear
Code:
dropbear -A -N username -U 10058 -G 10058 -C password -d ~/.ssh/dropbear_dss_host_key -r ~/.ssh/dropbear_rsa_host_key -F -E -p 8090 -P PidFile
This will start it running in the foreground with password set to 'password' on port 8090.
Then you can connect, like telnet, and simply use 'password' for the password.
Now for the issue. It will start a simple shell session in / with no ENVIRONMENT variables or anything..
I'll fix it permanently in a future release, but for now it can be fixed with these 2 commands.
cd into your home dir - Check this is correct on your device
Code:
cd /data/data/com.spartacusrex.spartacuside/files
And start bash with an init file Terminal IDE auto-magically creates..
Code:
./system/bin/bash --init-file ./.init
Everything should now be setup as usual.
Good luck..

Very awesome and thank you sir. Works like a charm.
One thing to clarify for those "braving" this (not that it's all that insane to try)... the '-N' is setting the username (in the case of the example, setting it to 'username').
Also, it gives a permission denied for scp, I'm assuming since it doesn't init/run the shell. Should be fine since FTP is included. Haven't tried this option yet. Not too worried about security at the moment, since I'll only run it on a private network.
May I make a (maybe) small feature request? Is it possible to include a "keep screen awake" option in the options menu? I have my Xoom config'd to turn off the wifi when the screen is off for power saving (can go ~4 days on 1 charge), so it will kill my connections if I let this happen. I know not everyone has this config set, but it'd be a nice option.
NOW, if I wasn't lazy, I could probably add this myself and build since I've dl'd the source. But, lazy and working on a few projects already.
Again, much thanks.

And as if by magic..
Funnily enough I was having the exact same issue last night while using wget to transfer a big file to my device..
NEW VERSION UPLOADED v1.13
Now has 3 non-exclusive lock types available in the options :
- CPU Lock
- SCREEN Lock
- WIFI Lock
Set them as you wish...

Saw that this morning when I was on the bus (Thursday morning here in Hong Kong). Very awesome and much appreciated.
As well, thanks for open-sourcing it. +1 for you sir!

Very cool stuff
Thanks for creating this.

Great app! However I can't compile .java files. I always get an error that it can't unzip a file in /android.policy.jar. Any idea?
Sent from my GT-I9100 using XDA App

Do you think its possible to also support compiling C sources directly in your phone

I've been searching for this ever since I got an android.
THANK YOU.

Says that it's incompatible with my OG Droid. Any idea why?

shpen said:
Says that it's incompatible with my OG Droid. Any idea why?
Click to expand...
Click to collapse
Most likely seems to be due to the ROM you are using and/or the market version
can u post the build.prop here?
/system/build.prop
also, try going back to market 2.x, 3.x market(s) do loads of checks

Does anybody know why I can't compile java files? I always get the following error:
Error reading /system/framework/android_policy.jar cannot read zip file.
Any ideas? Could anyone upload there android_policy.jar because that might cause the error.
Sent from my GT-I9100 using XDA App

Hi Schindler33.
Can I ask, have you followed the tutorials, say the first helloworld example TO THE LETTER?
Does the helloworld example work?
The parameters have to be correct, and as always exact, and the BOOTCLASSPATH variable must be set.
If so, is it a custom ROM?
Does that policy jar file exist and is it readable by non root users?
As much info as possible good..