Related
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
bowtieduece said:
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
Click to expand...
Click to collapse
Even though I didn't really think it would work, I gave it a shot anyway. Naturally, it was unsuccessful. The Eris take FOREVER to load that website, and it never triggers the shell script to ask for a reload, therefore permission is denied for the second part when you reboot with adb shell.
Interesting exploit, though. I wonder if there is some way to modify it for the Eris. Maybe you could contact the devs.
Really, nobody else is interested in this?
MyFixofAndroid said:
Yep that's what I expected. Yea there's gotta be someone here that can do the changes to the EVO files so they work with Eris, and upload the proper files to file sites and have us downloading in no time, so we can get root finally. Yes please anyone here up and willing
Click to expand...
Click to collapse
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
sickbox said:
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
Click to expand...
Click to collapse
Thanks for the tip. I sent him a PM. Will report back when I find something.
Anyone with an Eris can help out - rooted or unrooted.
I looked at those scripts last night - what seems like the necessary conditions for the beginning of the exploit (part1) are:
(1) there is a directory read/write/traversal permission security flaw in the data area for flash-lite;
(2) apparently, when flash-lite is running it must have root privilege at a moment when it performs a file "chmod" operation
So, an unprivileged user goes in, and makes a symlink (at the correct moment in time) in flash-lite's data area that points to a mtd partition - moments later, flash-lite "chmods" what it thinks is a file in it's data area, but instead, it is chmod'ing the target of a symlink - the normally protected mtd partition.
This allows use of flash_image to write whatever is wanted to that partition - even as an unprivileged user.
It should be easy enough for someone with Linux/Unix command line scripting experience to test to see if these conditions prevail on the Eris. You don't even need to be root - make your symlink point to something in /data/local if you are worried about something bad happening to a mtd partition. Chmod it initially to 600, and see if it get's changed by flash-lite when (and if) you drop the symlink into place.
I would do it, but I've got to go buy all the parts for ( & build) a new computer (no dev station as of last night ).
bftb0
bftb0 said:
Anyone with an Eris can help out - rooted or unrooted.
bftb0
Click to expand...
Click to collapse
Thank you for the detailed explanation. I'll have a look at the scripts, though it's more about learning new things for me, as this exceeds the current state of my unix knowledge. Hope others with more immediate knowledge of the subject will take a crack at it.
The shell script points to sharedobjects within /data/data/com.android.browser/flashlite, but sharedobjects, nor any folder for that matter, exists within that directory on the Eris. Is there a different place this could point; does the Eris have the same objects stored in a different location?
UPDATE: I'm searching my filesystem on my Eris right now to find it. I will report back later with results.
Also If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
MyFixofAndroid said:
Maybe the "sharedobjects" folder and other missing folders are really on the Eris, one of you should look for them. Use ASTRO or a different file manager and search most of the whole filesystem and see if you can find "sharedobjects" on your Erises.
In the meantime I'll try the same thing. Maybe there's a search engine for the file system of the Eris that you can get in the Android Market, that would do the trick. A file and/or folder search engine.
If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
Click to expand...
Click to collapse
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
I checked on my other Eris which is rooted. It seems that these may be the directories that we are looking for. However I don't find anything in an app-cache directory.
# find / -name *flashlite
find / -name *flashlite
/data/data/com.android.browser/flashlite
find: /proc/851: No such file or directory
# find / -name com.android.browser
find / -name com.android.browser
/data/data/com.android.browser
Well this appears to be the deal breaker then. Because non-root users of Eris cannot access /data as non-root, they cannot see anything in app-cache, and therefore cannot root yet, at least with this particular method unless there's another way to do it.
We should think of a way to still exploit Flash Lite on Eris, but use a different folder/folders in the Part? scripts that they point to for the operations of the script. This may be possible to do, however, still unlikely to work, and it is still going to be hard at this point.
But does anyone want to give my modified EVO method but for Eris a try? One of you should, so that we can root this thing and get it over with.
jimbonj said:
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
Click to expand...
Click to collapse
I dont think we would need read write permissions to begin with to use this root, if we had them to start we would be rooted
Because is he using a exploit in flash lite to write to a restricted folder, hes not just found a folder where the permissions aren't set correctly.
If flash lite can invoke admin access and we can exploit it there should be a way to root this.
I am going to the bar going to get some beers for my friends birthday, when I get home I am going to see if I can modify this into an eris root
Yeah JVWARD!
On your rooting effort, all the better, try modifying it for Eris and let all of us know if you succeed, hope you can, so we can get root too. Keep trying it with different changes until you get it to work.
Thanks.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
Click to expand...
Click to collapse
Yes sickbox, by all means, keep trying stuff, and finding that "flashlite" directory etc. till you get it to root. Hope your touchscreen returns to normal, and that you can create the directory that you mentioned in your previous post by using a flash site.
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
hey can someone with a rooted Eris using a an almost 100% stock Rom setup dump there file system and post it. Anyone using a highly customized Rom don't bother.
Sent from my Eris using Tapatalk
lostpilot28 said:
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
Click to expand...
Click to collapse
Link to the Evo instructions is in the OP. Currently working to see if it's possible on the Eris, so that's a no-go for now.
Stay tuned.
Team,
I've been working with the scripts with the awesome folks on IRC and have currently gotten thus far:
Part1 - http://pastebin.com/FUJWM3zW
Part2 - http://pastebin.com/6h07zrdm
I believe at this point I've screwed up my FlashLite plugin with my testing, so I'm going to try to recover that and keep moving along.
LR
supercurio has reported:
SpeedMod based (Doc's ROM and others) and every other Universal Lagfix corrupt badly /system
It means that as long as they don't restore a /system with Odin, they're stuck on kernels using broken mount options.
If you want to verify, try to boot a stock Samsung kernel. Depends on how much it is corrupt it will boot, or not, or with unexpected errors
Want proof?
http://bit.ly/bq2oXg
Highlighted line is using wrong and corruption mount points
lack of check=no which causes corruption. Every Samsung mount uses check=no
Second Issue:
Even with NO RFS Config selected... RFS is still used in /system mounts... means phone are slowly Dying of corruption..
please fix linky - I want to know more about this:
That page doesn't exist!
Click to expand...
Click to collapse
thanks !
zacharias.maladroit said:
please fix linky - I want to know more about this:
thanks !
Click to expand...
Click to collapse
Fixed XD Sorry for that
Not 100% sure on this, since I have not used or looked at sztupy's lagfix very much, but that line you are pointing out is not a problem.
If /system is EXT4, then calling mount -t rfs on it will simply return an error message, and not mount it. It will do exactly nothing.
The following line would then mount it correctly.
Basically, this seems to be totally false. More evidence please.
EDIT: Okay, OP was updated with better information. Lack of check=no means that the FAT32 check *may* be running on the /system, which would cause corruption.
Probably a good idea to confirm if the filesystem check is actually happening though!
In case that supercurio is right (I hope he’s not for obvious reasons), I guess that it wont affect to users that are running harcore kernel without any lagfix applied, right?
RyanZA said:
If /system is EXT4, then calling mount -t rfs on it will simply return an error message, and not mount it. It will do exactly nothing.
The following line would then mount it correctly.
Click to expand...
Click to collapse
That is correct, however /system is not EXT4, but RFS.
good catch.
but im sure sztupy can fix this with a small patch, although i agree the priority should be flagged 'critical'...
as always, good work supercurio
NetCopAD said:
That is correct, however /system is not EXT4, but RFS.
Click to expand...
Click to collapse
Thanks, I thought this was referring to a problem when /system is converted, rather than when it isn't. Which means that if you are running sztupy's kernel with one of the settings that convert /system then it should be fine.
In case that supercurio is right (I hope he’s not for obvious reasons), I guess that it wont affect to users that are running harcore kernel without any lagfix applied, right?
Click to expand...
Click to collapse
It would actually affect you in this case, as the problem occurs when the lagfix is NOT applied, rather than when it is applied!
If it even is a problem, and the fat32 check runs rather than the system trying to do fsck.rfs and failing.
RyanZA said:
Thanks, I thought this was referring to a problem when /system is converted, rather than when it isn't. Which means that if you are running sztupy's kernel with one of the settings that convert /system then it should be fine.
It would actually affect you in this case, as the problem occurs when the lagfix is NOT applied, rather than when it is applied!
If it even is a problem, and the fat32 check runs rather than the system trying to do fsck.rfs and failing.
Click to expand...
Click to collapse
Maybe I am wrong but there is no settings in sztupy's kernel which convert /system
Lagfix only convert /data, /cache and /dbdata
Mopral said:
Maybe I am wrong but there is no settings in sztupy's kernel which convert /system
Lagfix only convert /data, /cache and /dbdata
Click to expand...
Click to collapse
Yeah i just looking further system is still mounted as
/sbin/busybox mount -t rfs /dev/block/stl9 /system - Possible corruption happens here without check=no
RyanZA said:
Thanks, I thought this was referring to a problem when /system is converted, rather than when it isn't. Which means that if you are running sztupy's kernel with one of the settings that convert /system then it should be fine.
It would actually affect you in this case, as the problem occurs when the lagfix is NOT applied, rather than when it is applied!
If it even is a problem, and the fat32 check runs rather than the system trying to do fsck.rfs and failing.
Click to expand...
Click to collapse
Yes this would affect the speedmod kernel as well, if it indeed is a problem. ULFK does not change /system in any lagfix scheme. So, its always mounted as rfs, apparently "wrongly".
I am testing an updated speedmod (shall we say, K9-pre) with the changed mount option. At the very least it should do no harm. And trying to get in touch with curio but over at IRC they say he's probably sleeping now after a coding binge!
Hmm and I found a minor 'bug' in the post-init.sh that was not properly setting /system to read-only after its done.... mainly because the logfile is being written to /system!
Method to test if this is a problem:
Replace your fsck_msdos (this is the only fat32 fsck in the filesystem) with a script file. Inside the script put the following:
Code:
echo "$?" > /somewhere
Then reboot your phone a lot of times. If the check is being called, then you will now get a log message instead of the check happening.
Will also affect checking of /sdcard though.
As far as I know though, fsck_msdos is only ever called by vold, and therefore check=no in /system may not have any effect, and this could be a false alarm. Anyway as hardcore says, can't hurt to fix it!
EDIT: Just wanted to add that running fsck_msdos even once on my /system (using the awesome pre-init scripts from z4mod!) made my phone immediately unbootable (damnit!). Not a big sample size, but I believe that if this was really a problem, we would be seeing many many reports of the sztupy kernel breaking devices! Since we don't have these reports, I'm gonna put this myth down as 'likely to be busted soon!'
RyanZA said:
Method to test if this is a problem:
Replace your fsck_msdos (this is the only fat32 fsck in the filesystem) with a script file. Inside the script put the following:
Code:
echo "$?" > /somewhere
Then reboot your phone a lot of times. If the check is being called, then you will now get a log message instead of the check happening.
Will also affect checking of /sdcard though.
As far as I know though, fsck_msdos is only ever called by vold, and therefore check=no in /system may not have any effect, and this could be a false alarm. Anyway as hardcore says, can't hurt to fix it!
Click to expand...
Click to collapse
Well the intention of this post is to show the issue for it to be fixed So let hope it does not do too much damage :S
deathst said:
Well the intention of this post is to show the issue for it to be fixed So let hope it does not do too much damage :S
Click to expand...
Click to collapse
Looks like this may have been a bit too sensationalist!
More checking, less guessing is always good! (And I could learn a lot from that motto myself!! )
RyanZA said:
Looks like this may have been a bit too sensationalist!
More checking, less guessing is always good! (And I could learn a lot from that motto myself!! )
Click to expand...
Click to collapse
Well we could check it by running it on RFS and reboot alot of time and then flashing a original Kernel
RyanZA said:
Looks like this may have been a bit too sensationalist!
More checking, less guessing is always good! (And I could learn a lot from that motto myself!! )
Click to expand...
Click to collapse
yeah when i saw that post my balls shrank.. thinking that by precious phone may be 'slowly dying of corruption'
not like there is a repair file system tool to use
Code:
/dev/block/stl9 /system rfs ro,noatime,vfat,log_off,check=no,gid/uid/rwx,iocharset=utf8 0 0
K8, u had a short life... looks like its time for K9
Important thing to note is that this is the way stock kernels mount /system: read-only, and we see the option log_off too.
The thing I noticed this way is that if u do a mount -o remount,rw /system and modify stuff... it may corrupt /system. All modifications to /system should then ideally be done via CWM or update.zip only.
deathst said:
Well we could check it by running it on RFS and reboot alot of time and then flashing a original Kernel
Click to expand...
Click to collapse
Why would flashing an original kernel make a difference? Original kernel will mount /system in exactly the same way, so any corruption in /system would be seen on both the original kernel and on the sztupy kernel before the reflash.
Reflash or not has nothing to do with it.
Only method would be to reboot (or remount) enough times to hit the unclean filesystem check parameter (which rfs might not even have?), or wait long enough for the unclean check time to elapse. Not really sure how you would check what this parameter is - maybe tune2fs could be used? RFS is a bit of a black box!
RyanZA said:
Why would flashing an original kernel make a difference? Original kernel will mount /system in exactly the same way, so any corruption in /system would be seen on both the original kernel and on the sztupy kernel before the reflash.
Reflash or not has nothing to do with it.
Only method would be to reboot (or remount) enough times to hit the unclean filesystem check parameter (which rfs might not even have?), or wait long enough for the unclean check time to elapse. Not really sure how you would check what this parameter is - maybe tune2fs could be used? RFS is a bit of a black box!
Click to expand...
Click to collapse
It may mount correctly with Original Kernel..If it does quite a damage to the /system the phone might report errors even it is will not be able to boot.
deathst said:
It may mount correctly with Original Kernel..If it does quite a damage to the /system the phone might report errors even it is will not be able to boot.
Click to expand...
Click to collapse
No, that doesn't make sense. The difference between stock and sztupy is that sztupy's mount is telling the system to try and check the drive. If /system works fine in the sztupy kernel, it will still work fine in the stock kernel, because the only difference is that the stock kernel DOESN'T check. Well, testing so far seems to be showing that neither check, and the check option does nothing at all.
Hello to all in comunity.
Galaxy s has only 30MB of cache size. And this is bad because some apps on the market can't be installed, since market uses this cache partition for the downloads. Is there a way to increase this size or to symlink it on some bigger partition like /data or somewhere else?
Sent from my GT-I9000 using XDA App
Anybody? I heard that's a way to symlink cache anywhere else, but i can't do it, everytime i try a message saying "resource busy" or something like this appears on Terminal Emulator. I'm trying to symlink cache to /data.
Do you have ext4 lagfix enabled?
Sent from my GT-I9000 using XDA App
No. Do i need to enable it?
Sent from my GT-I9000 using XDA App
Using speedmod kernel with lagfix enabled on cache (ext4) gave me 100 MB.
Sent from my Galaxy S/CM7 using XDA App
avary said:
Using speedmod kernel with lagfix enabled on cache (ext4) gave me 100 MB.
Click to expand...
Click to collapse
And what version of speedmod are you using? I'm on K12-T 500Hz....if i enable ext4 lagfix on cache, will i get the 100MB too?
And also, were you using CM7 already?
Thanks!!
I tried to symlink the cache to a folder i created ala hardcore's suggestion (Thanks again hardcore!), but unfortunately I got the same sized partition as the original cache folder, which kinda makes sense. Hopefully Samsung or one of the guys on XDA (yeah, they'll probably get a fix out before Sammy does) will have a solution.
avary said:
Using speedmod kernel with lagfix enabled on cache (ext4) gave me 100 MB.
Sent from my Galaxy S/CM7 using XDA App
Click to expand...
Click to collapse
I call bull****.
So there isn't a way to do it right now? I guess we need supercurio's or hardcore's help. Please people, help to contact them. Thx!!
Sent from my GT-I9000 using XDA App
I agree
snapper.fishes said:
I call bull****.
Click to expand...
Click to collapse
So do I. I tried using the latest speedmod, and no change. Think the only solution would be to have the cache size changed in the internals. Definitely out of my league; I don't want to try changing a setting and lose the use of my phone. Hopefully someone gets a fix in; battle bears is calling...
Definitely we need to move this thread to android development and see if someone there with enough skills can help us. I think it's an urgent problem. What about battle bears? And what if gameloft start to sell their games on android market now?
Sent from my GT-I9000 using XDA App
Thanks!!!!
gangpe said:
I tried to symlink the cache to a folder i created ala hardcore's suggestion (Thanks again hardcore!), but unfortunately I got the same sized partition as the original cache folder, which kinda makes sense. Hopefully Samsung or one of the guys on XDA (yeah, they'll probably get a fix out before Sammy does) will have a solution.
Click to expand...
Click to collapse
lucbl1 said:
Anybody? I heard that's a way to symlink cache anywhere else, but i can't do it, everytime i try a message saying "resource busy" or something like this appears on Terminal Emulator. I'm trying to symlink cache to /data.
Click to expand...
Click to collapse
How do you guys exactly try to symlink it? I guess more people could help out if they knew exactly what you are doing and what the error messages exactly say.
I'm not really interested in getting a bigger cache partition since I don't use really big apps, but this would probably be thay way I'd do it:
(you could type these command either through adb shell or directly on the device using a terminal emulator -- WARNING: these commands are not tested and may horribly break something)
Code:
mkdir /data/cache
busybox rm -rf /cache
busybox ln -s /data/cache /cache
shantzu said:
How do you guys exactly try to symlink it? I guess more people could help out if they knew exactly what you are doing and what the error messages exactly say.
I'm not really interested in getting a bigger cache partition since I don't use really big apps, but this would probably be thay way I'd do it:
(you could type these command either through adb shell or directly on the device using a terminal emulator -- WARNING: these commands are not tested and may horribly break something)
Code:
mkdir /data/cache
busybox rm -rf /cache
busybox ln -s /data/cache /cache
Click to expand...
Click to collapse
I was just using the same code you posted. But i think that for symlinking, /system and /data must be in Ext2/3 or 4 format, am i right? I'll be testing it in the weekend!
I mentioned this issue to supercurio who is looking into it.
Sent from my GT-I9000 using XDA App
lucbl1 said:
I was just using the same code you posted. But i think that for symlinking, /system and /data must be in Ext2/3 or 4 format, am i right? I'll be testing it in the weekend!
Click to expand...
Click to collapse
well, tbqh I didn't work much with RFS, so I am not sure if it supports symlinks, I guess it can't hurt to try though...
If it doesn't work on RFS you'd have to try some ext FS (ext2, ext4, whatever you prefer).
rlorange said:
I mentioned this issue to supercurio who is looking into it.
Click to expand...
Click to collapse
So maybe supercurio can fix it. Let's hope! Any news please report here.
Sent from my GT-I9000 using XDA App
Problem fixed on last speedmod kernel!
Sent from my GT-I9000 using XDA App
can someone plz help me? i got the problem and its rly annoying..i have 2.3.3 xxjvo with cf_root how do i fix this ****?!
romdroid. said:
can someone plz help me? i got the problem and its rly annoying..i have 2.3.3 xxjvo with cf_root how do i fix this ****?!
Click to expand...
Click to collapse
If rou are rooted just folow this commands in terminal...
su
mkdir /sdcard/tempcache
mount -o bind /sdcard/tempcache /cache
This is temporary, after reboot cache will return normal and you can delete tempcache in sdcard...
Cheers
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.
Hello there!
I'm not sure wether this is the right Forum thread, nor if it's even possible.
English is not my first language, but i hope i can make myself clear and explain my problem.
As in the title mentioned I just want to mount a nfs share into my filesystem so that i can access my media through a vpn whereever I go.
I'm using a Synology Diskstation as NAS and created some NFS-shares (tried version 3 and 4) which are accessable in my Network. It's working flawless with my raspberry pi and with my debian system. I don't want to use smb (cfis).
I want to use my favorit musicplayer to listen to my music, mounted via fstab in the musicfolder for example.
Right now i'm using the yatse app, works fine - but it's just a workaround....
I tried FreedomOS(stock kernel and elementalx)+busybox and Resurrection Remix(stockkernel and lightningkernel)+ busybox. All i get is Invalid argument or error messages. I just can't get it to work. It's a linux system, why can't i use a simple nfs share?
Any help would be apreciated.
Thanks in advance!
I used to mount a nfs share with busybox so be sure to have that installed.
next be sure to have a working VPN connection to your home network.
One more thing to check is that VPN connections are allowed to access the nfs shares. Dont know if you need to set this up with synology or that it's enabled by default.
Thanks for the response.
I have all permissions set to get access to the nfs-share, tried it without vpn aswell. The vpn itself is working like a charm.
I have access to my NAS via webinterface and sftp, i can control and stream from my raspberry pi aswell. No problems with the vpn for sure.
I'm using busybox aswell. Can you post me your mount command or your fstab line for the mount?
the1weasel said:
Thanks for the response.
I have all permissions set to get access to the nfs-share, tried it without vpn aswell. The vpn itself is working like a charm.
I have access to my NAS via webinterface and sftp, i can control and stream from my raspberry pi aswell. No problems with the vpn for sure.
I'm using busybox aswell. Can you post me your mount command or your fstab line for the mount?
Click to expand...
Click to collapse
I used this i believe.
Your kernel needs to support it.
https://gist.github.com/aldur/4a3f90a111b71662f056
maikvitesse said:
I used this i believe.
Your kernel needs to support it.
https://gist.github.com/aldur/4a3f90a111b71662f056
Click to expand...
Click to collapse
Thats exactly what i was told over here https://forum.xda-developers.com/oneplus-5/development/kernel-elementalx-op3-1-00-t3626808/post73156290#post73156290
I will follow up on that, thanks for pointing me in the right direction aswell.
Ok, i was able to mount the share.
Now that it's getting a general question i will follow up here. I posted what i did over here aswell and got it solved to this state.
I can see the files in the Terminal, but not in any App (explorer, musicplayer etc.).
As i already wrote here: https://forum.xda-developers.com/showpost.php?p=73161675&postcount=437 I'm guessing it's because i mounted as root so normal users can't use it. Or at least thats what I'm thinking.
I searched the forum already and just found a thread with someone having the same problem without solution.
Is there a way that i can use the mounted share with any app I want?
Just for the roundup.
Here is whats working:
mount a nfs-share through an terminal app. => Files are visible/browsable
whats not working:
Use the mounted nfs-share systemwide with any other app.
What i tried (used Termux):
mount into /mnt/remotenfs => files show up in terminal, just there.
mount into /storage/emulated/0/Music/remote => files show up in terminal, just there.
mounted the share and then started an explorer (solidexplorer) from terminal - same result. No fileaccess through explorer.
the1weasel said:
Just for the roundup.
Here is whats working:
mount a nfs-share through an terminal app. => Files are visible/browsable
whats not working:
Use the mounted nfs-share systemwide with any other app.
What i tried (used Termux):
mount into /mnt/remotenfs => files show up in terminal, just there.
mount into /storage/emulated/0/Music/remote => files show up in terminal, just there.
mounted the share and then started an explorer (solidexplorer) from terminal - same result. No fileaccess through explorer.
Click to expand...
Click to collapse
I think I suggested something like this as a way to glean some information about this problem in the other thread, but don't recall for certain what the outcome if any was:
At least since V5 and above of Android OS, there's been some sort of thread insularity that keeps another thread from seeing what some of the first one sees. (moreso than before V5). I figured that since fstab.qcom (or whatever the name of the actual startup file where "mount -a" is pointed) must contain the mounted partitions that are visible to all. If that's the case, it's either the startup mount daemon, or it is in one of the columns of each "mount" entry in fstab.*.
I think I suggested adding a mount entry without the "automount at start" parameter for your remote music. Just curious if that was tried? Also, I thought the file where these were entries were kept in M & N (6 & 7) had "*vold*" in the title.
I'm also curious about this and will look around for some better answer because it seems very non-linux / android that only the thread performing the action can see the result (although that is how local actions / variables act).
After some poking around: I think this link explains some possible reasons for this behavior, not that there isn't some way around it. Probably there is no way around it without some compromise of whatever privacy additions android OS is after. It sounds a lot like an SELinux & /proc FS change. https://stackoverflow.com/questions/38590140/file-system-changes-in-android-nougat
hachamacha said:
I think I suggested something like this as a way to glean some information about this problem in the other thread, but don't recall for certain what the outcome if any was:
At least since V5 and above of Android OS, there's been some sort of thread insularity that keeps another thread from seeing what some of the first one sees. (moreso than before V5). I figured that since fstab.qcom (or whatever the name of the actual startup file where "mount -a" is pointed) must contain the mounted partitions that are visible to all. If that's the case, it's either the startup mount daemon, or it is in one of the columns of each "mount" entry in fstab.*.
I think I suggested adding a mount entry without the "automount at start" parameter for your remote music. Just curious if that was tried? Also, I thought the file where these were entries were kept in M & N (6 & 7) had "*vold*" in the title.
I'm also curious about this and will look around for some better answer because it seems very non-linux / android that only the thread performing the action can see the result (although that is how local actions / variables act).
After some poking around: I think this link explains some possible reasons for this behavior, not that there isn't some way around it. Probably there is no way around it without some compromise of whatever privacy additions android OS is after. It sounds a lot like an SELinux & /proc FS change. https://stackoverflow.com/questions/38590140/file-system-changes-in-android-nougat
Click to expand...
Click to collapse
Thanks for the response, looks like you are much more into that android thing....
I just added
"10.11.12.10:/volume1/Audio /storage/emulated/0/Music/remote nfs nolock,ro defaults"
to the fstab.qcom . Doesn't mount at startup.
I realized some inconsitency in the ssh thing, sometimes it works mounting via ssh, sometimes not....strange. (mount: applet not found)
To be sure i'm doing all that stuff without ssh.
Edit:
For everyone else reading this. It's not about music, the musicfolder is just a random folder to see if it's working.
the1weasel said:
Thanks for the response, looks like you are much more into that android thing....
I just added
"10.11.12.10:/volume1/Audio /storage/emulated/0/Music/remote nfs nolock,ro defaults"
to the fstab.qcom . Doesn't mount at startup.
I realized some inconsitency in the ssh thing, sometimes it works mounting via ssh, sometimes not....strange. (mount: applet not found)
To be sure i'm doing all that stuff without ssh.
Edit:
For everyone else reading this. It's not about music, the musicfolder is just a random folder to see if it's working.
Click to expand...
Click to collapse
To add to that: It doesn't seem like any surprise that just putting an entry in the fstab.qcom doesn't work the same as the others. As I search around for a way to do this it becomes apparent that even a Synology app designed to do this (DS File) (Mounts a NFS share on Synology box and allows file transfers) isn't able to allow others to see it's mounted share.
Before I mounted a Synology folder using Synology DS File, I created a tmp folder and cd there and then did a mount > mountbefore.log. After the mount of the share while still running DS File pointing to my Synology folder, I did a mount > ./mountafter.log. I then did a diff -urN (and just a diff) ./mountbefore.log ./mountafter.log that showed no differences. That seems telling.
Also, I did the same with /proc/mounts /proc/mountinfo /proc/mountstatus before and after, and nothing showed up as different. Also I did a ps | grep DS to see whether the ps output gave me any clue as to what local mount point was used, but though I could see the DS process, I couldn't see it's mountpoints.
I'm pretty sure there's an SELINUX (or many) entrie(s) for the mounted share that prevent the usual visibility. I recall reading that "fixing" the /proc exploits was a big priority with the advent of SElinux so I'll look at that angle too. I don't think that the fact that DLNA works is of much use in this problem. It's really a solution to a different and specific problem.
hachamacha said:
To add to that: It doesn't seem like any surprise that just putting an entry in the fstab.qcom doesn't work the same as the others. As I search around for a way to do this it becomes apparent that even a Synology app designed to do this (DS File) (Mounts a NFS share on Synology box and allows file transfers) isn't able to allow others to see it's mounted share.
Before I mounted a Synology folder using Synology DS File, I created a tmp folder and cd there and then did a mount > mountbefore.log. After the mount of the share while still running DS File pointing to my Synology folder, I did a mount > ./mountafter.log. I then did a diff -urN (and just a diff) ./mountbefore.log ./mountafter.log that showed no differences. That seems telling.
Also, I did the same with /proc/mounts /proc/mountinfo /proc/mountstatus before and after, and nothing showed up as different. Also I did a ps | grep DS to see whether the ps output gave me any clue as to what local mount point was used, but though I could see the DS process, I couldn't see it's mountpoints.
I'm pretty sure there's an SELINUX (or many) entrie(s) for the mounted share that prevent the usual visibility. I recall reading that "fixing" the /proc exploits was a big priority with the advent of SElinux so I'll look at that angle too. I don't think that the fact that DLNA works is of much use in this problem. It's really a solution to a different and specific problem.
Click to expand...
Click to collapse
Hmm I just found this: https://forum.xda-developers.com/showthread.php?t=2106480 and will have a closer look into it later, I'm running out of time right now and have to leave.
But what I've read so far looks similar to the problem we are facing right now. Maye thats the way to go. I'll try it, as I said, later.
At this point i don't even care if it's smb or nfs as long as i can mount my stuff into the filesystem.
One other thing I noticed but haven't messed around with yet is that I was looking at the various mount commands for different implementations (not that any will just work like 2 versions ago), and noticed that only /system/xbin/mount is a soft link to /system/xbin/busybox (standard busybox link to allow using it various look-alike-to-linux commands.
But then I realized that /system/bin/mount is also there, also a soft-link to /system/bin/toybox (another busybox clone) and am wondering if it behaves any differently. Might be worth a look (but I doubt it). /system/bin/toybox is at least a different version of busybox and not linked to it.
Just looked at your last reply and realized that unfortunately the two links of interest are at the now nonexistant domain cyanogenmod.org. Maybe the diffs are worthwhile. Gotta work, Later.
hachamacha said:
One other thing I noticed but haven't messed around with yet is that I was looking at the various mount commands for different implementations (not that any will just work like 2 versions ago), and noticed that only /system/xbin/mount is a soft link to /system/xbin/busybox (standard busybox link to allow using it various look-alike-to-linux commands.
But then I realized that /system/bin/mount is also there, also a soft-link to /system/bin/toybox (another busybox clone) and am wondering if it behaves any differently. Might be worth a look (but I doubt it). /system/bin/toybox is at least a different version of busybox and not linked to it.
Just looked at your last reply and realized that unfortunately the two links of interest are at the now nonexistant domain cyanogenmod.org. Maybe the diffs are worthwhile. Gotta work, Later.
Click to expand...
Click to collapse
I'm back home already a little late but enaugh time for more researches.
This link:
https://github.com/mkasick/android_...mmit/b358bf82c079a577f011c167da8b65faef73a06e
is working. And really worth reading it and explains the visibility problem.
mkasick said:
Android 4.2 breaks Dalvik-apps that mount file systems to be shared with other apps. This includes CifsManager, Mount Manager, essentially anything that mounts cifs shares, FUSE file sytems, etc. The symptom is that the mounted contents appear fine to app that peforms the mount operation (assuming the app itself provides the ability to browse the contents), but every other app only sees an empty directory at the mount point.
It turns out that this problem is a side-effect of the approach used to implement multi-user storage in Android 4.2. I've explained the problem in detail in the commit log for a Gerrit issue we're reviewing for CyanogenMod 10.1 that addresses the problem:
Ideally, any 4.2 ROM can provide support for CifsManager by applying a change to Dalvik, and a second change to the boot ramdisk's init.rc:
Dalvik change: Zygote: Restrict slave mountspace so Dalvik apps can mount system-wide volumes
init.rc change: init.rc: Create /storage mountpoint so Dalvik can mark as slave in zygotes
Alternatively, ROMs that can't/prefer not to use a source-build Dalvik (libdvm), I've also provided a kernel patch that implements a similar workaround within the kernel. It also requires the above init.rc modification:
Kernel commit: Restrict slave mountspace so Dalvik apps can mount system-wide volumes
init.rc change: init.rc: Create /storage mountpoint so Dalvik can mark as slave in zygotes
With either of the above two fixes, CifsManager et al. should work when using a mountpoint outside /storage (and /mnt/shell/emulated). I'd recommend using "/mnt/cifs" or something similar. Attempting to mount inside /storage retains the previous behavior where the mount can not be seen by other apps.
Note that ROMs only need one of the above two fixes, although they are compatible with each other and will function correctly if both are present. The Dalvik approach is preferred over the kernel workaround where feasible. Attached are the three patches referenced in the issues/commits.
Attachments: (sry for editing the quote)
dalvik.diff: https://forum.xda-developers.com/attachment.php?attachmentid=1656555&d=1358548352
nitrc.diff: https://forum.xda-developers.com/attachment.php?attachmentid=1656556&d=1358548352
kernel.diff: https://forum.xda-developers.com/attachment.php?attachmentid=1656557&d=1358548352
Click to expand...
Click to collapse
Look at the attached files, the answer is in there, but i don't know what to do with it
Thanks. I've got to do some work from home before I go back to messing around with this. I read the zygote/Dalvik page. I'm sure I've read it before but had the impression that the information was obsolete, but maybe not!
I guess there a couple of problems for me with that information.
1) It is pretty old (2013 or so): I can't even find the pertinent file in my source tree anymore.
2) dalvik has undergone a lot of revisions since this was tried. I'm not at all sure the change looks very different from the way tmpfs is /storage mounted already.
(but I could try this one. I figure in real time, if it'd let me remount it with the changes, the worst it could do is lock me up).
3) the kernel I'm using doesn't appear to have that line in it, besides, I'd have to rebuild the kernel.
I guess I'd much rather find a userspace way around this problem if possible. I seems almost unthinkable that there'd be no other way (via the mount cmd for example and careful choice of mount folder) to mount something that could be seen by any process. I'll keep trying from that angle.
Regrouping: I was ssh'd into the synology server poking around when I noticed that the running nfs daemon (as shown by ps -ef | grep nfs) was nfs4. I didn't see that Android supported that so I decided to just move the entire exercise of mount.nfs4 over to Ubuntu 16.04 box.
I made sure I had all the NFS stuff installed and pretty much did these statement:
mount -t nfs -o ro x.x.x.x/share /mnt/remote # failed with bad argument
mount -t nfs4 -o ro x.x.x.x/share /mnt/remote # failed with bad argument
mount.nfs4 x.x.x.x/share /mnt/remote #failed with bad argument.
At that point I decided that android didn't matter if I couldn't figure out how to mount NFS shares from linux.
I then tried mount -t cifs -o ro,user=me,pass=pwd //server/share /mnt/remote
It mounted up immediately. I need to look up some working examples of someone using mount.nfs / 4 from anywhere to synology. While I'm sure I've used it before, I'm also pretty sure I don't recall how exactly the setup and syntax works.