How to make rootfs / writable

[dwallersv]

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.

 

[SubnetMask]

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

 

[poit]

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

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.

 

[mkasick]

The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.

You can remount / as read-write with:

mount -wo remount rootfs /

and read-only again with:

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.

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.

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".

 

[DiGi760]

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.

 

[mkasick]

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.

That's for "/system", OP is asking about "/".

 

[Dameon87]

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.

 

[dwallersv]

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.

 

[dwallersv]

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

Spot-on, and very good point. However, there are ways around that:

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.

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.

 

[mkasick]

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.

How about setting BASH_ENV or HOME in telnetd's environment? Or is the environment not preserved?

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 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.

You are unique among the devs in my view, given the nature of what you have looked into and fixed.

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.

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.

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.

 

[dwallersv]

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.

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.