Related
Hi,
Usually on linux, there is a kernel loading modules at boot-time framework, cf. modules.conf.
No longer present in android.
When typing lsmod, there is two modules loaded by default : tntfs, and bcm4329 (and voodoo_sound
if you have it).
I'm trying to figure out what is the standard procedure on android : I've noticed on the
init.rc that the tntfs.ko is loaded, but can't figure out when bcm4329.ko is loaded.
Any idea ?
Moreover, I know that voodoo controller is able to load his own kernel module (voodoo-sound)
at boot-time. Anyone knows how the voodoo dev did that ?
My current idea is to modify init.rc to source a new file - let's say init.rc.local - to keep my custom mod. It'll
allow minimal changes when updating+root : just copy the init.rc.local and change the init.rc...
Sounds like we're recreating linux boot framework. lol.
This is something I've done on the HTC Incredible and the Droid 1 in the past, but in honeycomb, this is different, not very obvious yet:
Rather than try to emulate whatever Redhat or Ubuntu has done, which usually doesn't work, I either would use the line where tntfs.ko is insmod'd in /init.ventana.rc (sorry, think that's the filename), and add in the modules you want to add right there. Make sure to save the original file so you'll have a shot at fixing it if you make a mess.
The other thing is just to find some developer that appears to know what they're doing, and download their ROM, like Roach. I just downloaded his prime 1.6 ROM and unpacked it, then noticed immediately that he's got this in there:
/system/etc/init.d/01init{stuff},
Well that seems pretty important, so I did a grep 'init.d' * -R from the / level, and could only see little of importance, not any shell file like initrc pointing to it, just that busybox is linked to it, etc.
I figured it's worth a shot to create the same file structure on the stock ROM (/system/etc/init.d/0X{name} and see if it executes :: Start it with the usual #!/system/bin/sh
# load some modules
/system/bin/inmod /system/lib/modules/cifs.ko (or whatever)
and see what happened, if anything.
Better yet, I'd just send a message to Roach or some other ROM developer and ask.
Good luck -
altsyst said:
Hi,
Usually on linux, there is a kernel loading modules at boot-time framework, cf. modules.conf.
No longer present in android.
When typing lsmod, there is two modules loaded by default : tntfs, and bcm4329 (and voodoo_sound
if you have it).
I'm trying to figure out what is the standard procedure on android : I've noticed on the
init.rc that the tntfs.ko is loaded, but can't figure out when bcm4329.ko is loaded.
Any idea ?
Moreover, I know that voodoo controller is able to load his own kernel module (voodoo-sound)
at boot-time. Anyone knows how the voodoo dev did that ?
My current idea is to modify init.rc to source a new file - let's say init.rc.local - to keep my custom mod. It'll
allow minimal changes when updating+root : just copy the init.rc.local and change the init.rc...
Sounds like we're recreating linux boot framework. lol.
Click to expand...
Click to collapse
Tested.
Does not work, because modified room probably calling busybox run-parts.
Anyway I've found a hack, I'm posting it on general section.
Warning/disclaimer: This thread is intended for those who already know how to compile a kernel and have a working knowledge of Linux and its derivatives. There shouldn't be a great deal of risk involved, but you are responsible for what happens if you decide to follow these instructions.
Polite request: Please don't post replies to this thread that aren't of a technical nature directly related to compiling, modifying, or testing the kernel.
Introduction:
It appears as if Lenovo have released a buildable and bootable kernel source. I've done some preliminary testing with it. However, it would be better if we could get lots of people building and running the kernel, so that we can spot any remaining problems. This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Kernel source:
Get it from the Github repository at: https://github.com/gmarkall/lenovo_a1_07_kernel
Toolchain:
The Makefile seems to suggest that Codesourcery 2010q1 has been used by Lenovo to compile the kernel. Get it from https://sourcery.mentor.com/sgpp/lite/arm/portal/release1293, and make sure that the arm-none-linux-gnueabi-* binaries are on your path.
Building the source:
You may wish to edit the Makefile around line 192 to set CROSS_COMPILE=arm-none-linux-gnueabi- instead of the hardcoded path that is the default.
Then, to build the kernel:
Code:
make distclean
make a1_07_defconfig
make uImage
Booting the kernel
Normally, Android devices have two boot images that consist of a kernel and a ramdisk. One boot image is for the recovery, and the other is for the Android system. This makes it safe to flash a new boot image containing an untested kernel for the Android system, since the recovery can always boot up using the other boot image. However, the A1, by some bad design decision, only has one kernel - the bootloader always loads the same kernel, and just loads a different ramdisk depending whether it is to boot into recovery or system. As a result, it is not safe to flash a kernel to your A1 unless it's already been tested, since a bad kernel will make it impossible to boot from the internal memory, and you'll need a bootable SD card.
The solution to this problem is to make a bootable SD card for loading the kernel and ramdisk from. A bootable SD card consists of two partitions:
* A small bootable VFAT partition, that holds the X-Loader (MLO), U-Boot (u-boot.bin) and the kernel (uImage).
* An ext2 partition that holds the root filesystem.
In order to create a bootable SD card, use the omap3-mkcard.sh script that is attached below. To invoke it for making /dev/mmcblk0 a bootable SD card:
Code:
sudo omap3-mkcard.sh /dev/mmcblk0
You may need to hack the script if your SD card device isn't a /dev/mmcblk* one, since the script searches for partitions denoted "p1" and "p2" - this may need changing to just "1" and "2" respectively (thanks Xbdesign and Brancaleone for this).
This will create the necessary partitions, set the bootable flag, and format them. You will then need to mount the first partition (e.g. /dev/mmcblk0p1), and copy MLO and u-boot.bin to it (also linked below). Then, copy the uImage that you built from your kernel tree, which will be located in /arch/arm/boot. You can now unmount this partition.
Next, mount the second partition (e.g. /dev/mmcblk0p2). This will need to contain the same set of files that the initial ramdisk contains. There are two different ramdisks that you might want to use - one is from the Cyanogenmod 7 build, and the other one is from the stock system. Download links for these are also below. To extract the ramdisk, copy it onto the SD card second partition, then run the following commands (assuming the ramdisk is called ramdisk.ub):
Code:
dd if=ramdisk.ub of=ramdisk.img.gz bs=64 skip=1 # Strip off the U-Boot header
gunzip ramdisk.img.gz # Unzip
sudo cpio -idmv < ramdisk.img # Extract the cpio archive
Then, unmount the second partition of the SD card.
You should now be able to remove the SD card and insert it into your A1. Power down the A1 and power up again, and it should hopefully boot from the SD card and load your kernel. If it's booted from the SD card and loaded your kernel, you should be able to see that it was compiled on your host by looking in Settings -> About Phone -> Kernel Version.
Troubleshooting:
This is not a comprehensive guide, just a few pointers to where a problem might be - please post replies to the thread to get troubleshooting suggestions.
System boots up, but is not running my kernel - it didn't boot from the SD card. If the A1 is plugged into the charger/USB, you sometimes need to reboot multiple times before it boots off the SD card (I think it doesn't always turn off fully when the charger is plugged in).
The static Lenovo logo flashes up over and over again - it's booted from the SD card, but didn't manage to load your kernel
The static Lenovo logo comes up and stays there/goes to a black screen - it's probably loaded your kernel and mounted the root file system, but failed to mount /system. Try running adb shell to see what happens. If you get something like
Code:
/system/bin/sh: no such file or directory
then your kernel is running but /system isn't mounted.
IRC Channel
Join #ideapad-a1 on irc.freenode.net to discuss the kernel and other A1 development-related topics!
Download Links:
MLO
u-boot.bin
omap3-mkcard.sh
Ramdisk for Cyanogenmod 7
Ramdisk for ROW 2643 stock release
I've added the two ramdisks that I suspect will be most common - if you need another ramdisk, you'll have to extract it from an OTA.
Also, I compiled a tun.ko - www.doc.ic.ac.uk/~grm08/ideapad/tun.ko
Here's a cifs.ko - http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
EDIT: AutobahnA1 and infraredevans have confirmed that tun.ko works on ROW_2643.
EDIT 2/3: Please test out cifs.ko! (It doesn't work - it needs slow-work.ko. Will get that done when I can. Thanks to Ilikecokethree on the Lenovo forums for pointing that one out).
你懂中文吗，大神！
我是中国人 关注你的帖子很久了，我不懂英文，用翻译软件看的大概，我们这里很多人支持你，都在用你的rom 很棒！比联想官方的好多了，谢谢！
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong? Thank you very much.
PS: I'm a chinese too, and my English is not good either
gmarkall said:
This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Click to expand...
Click to collapse
Please do not forget to try the WiFi-based geolocation, which is also missing!
I wish I had the knowledge to work on it myself but I am far from taking over such tasks...do not have the slightest idea about how these things work.
Good luck and please keep us informed!
geoponer said:
Please do not forget to try the WiFi-based geolocation, which is also missing!
Click to expand...
Click to collapse
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Also, it's working in CM7.
hohoxu_hao115 said:
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong?
Click to expand...
Click to collapse
Sounds like it's booting from eMMC instead.
Can you post the partition table of the SD card as listed by fdisk, and also a directory listing of each of the two partitions? I ask this to confirm what's happened - seems like you're the first person to follow these instructions, and it's quite possible I made a mistake somewhere.
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
@Graham: I plan to install the CM7 that you have been working on (with the feedback from other users - I keep an eye on that thread!) but since I use my A1 for professional purposes as well, I would like to make sure that everything is working fine before moving to CM7. Apologies for not being able to contribute to the beta testing of CM7 but I am really looking forward to seeing a version based on the source code provided by Lenovo, which I think will lead to a more stable version of your CM7. I cannot thank you enough for taking the time to work on this, really!
geoponer said:
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
Click to expand...
Click to collapse
I think that whether it works in CM7 or not, it almost certainly isn't a kernel issue. I'll test it by signing up for Foursquare and give it a try out on CM7 to see if it works later on. Will post my findings in the CM7 thread.
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
dusko_m said:
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
Click to expand...
Click to collapse
I do want to implement something that's pretty much as you describe. My biggest motivation is that it's currently not safe to flash a kernel since you can break both system and recovery that way in one go - I really want to make the boot process more robust.
gmarkall said:
Also, I compiled a tun.ko - tun.ko
I haven't tested it yet - is anyone able to try it please?
Click to expand...
Click to collapse
The module loaded without a problem on my 2643_ROW Kernel. Installed "Rooted AnyConnect" from the "Play Place". Now I can connect to my company VPN.
gmarkall: YOU ROCK! THANK YOU!!!
tun.ko
Graham
The tun.ko module works perfectly with openvpn on 2643_ROW.
I can now access my Amahi home server,awsome.
Thanks a lot you are doing a great job.
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Cheers
Infraredevans said:
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Click to expand...
Click to collapse
I'll give it a whirl... give me a few minutes.
gmarkall said:
I'll give it a whirl... give me a few minutes.
Click to expand...
Click to collapse
Here it is: http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
To compile it I had to copy md5.h from another kernel source to fs/cifs in the kernel tree. I also had to edit init/Kconfig so that CONFIG_SLOW_WORK defaulted to yes. I configured the module with the options:
Support Legacy LANMAN servers which use weaker security
CIFS Extended attributes
CIFS POSIX attributes
and without statistics, debugging, or experimental features. Let me know if this is a suitable config - I could always tweak it and build another one.
arm-2010q1-202-arm-none-linux-gnueabi.bin
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
xbdesign said:
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
Click to expand...
Click to collapse
I did - I didn't have any problems, but my random guess about how to solve it could be to install ia32-libs. If installing that doesn't solve it, can you post a bit more detail about the problem?
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
xbdesign said:
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
Click to expand...
Click to collapse
Do you need that to run the installer? I just downloaded the tar version instead and extracted it. I saw there was an installer as well, but I thought it would be more hassle than using the tarball so I just ignored it.
Introduction
The DreamServer ROM makes the T-Mobile G1 (HTC Dream) a low-powered headless Linux server. The DreamServer ROM provides only the essential services and libraries required in order to start ADB and Wi-Fi. There is no Dalvik (and thus no Android user interface), which maximizes the resources available for server use.
WARNING
The DreamServer ROM is only intended for use by those comfortable with Linux. Once the DreamServer ROM is installed you will no longer have an Android GUI or user interface of any kind, and you will not be able to run standard Android applications or even USB-mount the SD card. The only device interaction you'll get is via ADB (and of course your custom recovery image).
Download
dreamserver-1.0.0-build.tar.gz (11.6 MB)
Revision History
1.0.0, 2013-02-02, dreamserver-1.0.0-build.tar.gz (11.6 MB), http://kidsquid.com/files/dream/dreamserver-1.0.0-build.tar.gz
Initial release
Prerequisites
Rooted T-Mobile G1 (HTC Dream) with custom recovery image that has the ability to restore nandroid backups.
Verified working adb connection via USB cable.
SD with a FAT file system (not ext2). The DreamServer ROM uses fsck_msdos to check the SD card before mounting it.
Wi-Fi access point.
Familiarity with Linux and shell scripts.
Installation
Meet all the prerequisites in the previous section.
Perform a nandroid backup and make sure you also have an update.zip on the SD card for whatever boot ROM you are currently using. Due to the extremely limited nature of the DreamServer ROM (see the WARNING above), you'll want to formulate your escape route now.
Under your existing rom, go to the Wi-Fi settings and forget any networks that you will not be using. Verify that Wi-Fi connects to your desired network.
Copy /data/misc/wifi/wpa_supplicant.conf from the phone to the root of the SD card as wpa_supplicant.conf. You'll need this in order to connect to Wi-Fi.
Copy the dreamserver-x.x.x.zip to an SD card, and install the ROM via your custom recovery as normal. No wiping of the internal DATA or CACHE partitions are necessary, as these are not mounted by the DreamServer ROM.
Reboot the phone.
When the device boots, it will turn off the backlight during init so you know that it did not hang. Wait for a while (around 30 seconds) and access the device with adb shell.
Customize the installation by adding init.sh and cleanup.sh scripts to the root of the SD card. See the "Run-time Configuration Files" section in the README file.
When you want to reboot, use the reboot command. Note that /system/bin/reboot is a shell script that runs cleanup tasks prior to rebooting. If fifosh is running, you can also reboot cleanly from within a chroot jail: killall -USR1 fifosh
Please see the README included in the tarball for additional information (key locations and files, how-to's, rebuilding the ROM, etc).
The tarball also contains example configuration files for a Debian chroot environment that sets the time with NTP and starts sshd and lighttpd.
Credits and Copyright
DreamServer was created by Jeffry Johnston, 2012.
This ROM was originally based on a 1.6 (Donut) ROM by dwang that I found to be reliable. My filesystem modifications are extensive, but the
kernel and busybox from that ROM are used unmodified. Source:
Thread: http://forum.xda-developers.com/showthread.php?t=567023
Title: [ROM][32B/Dream][Dec23][Dwang][Donut][Speed and Stability][v1.17.1]
Filename: dwang-v1.17.1.zip
Download: http://files.androidspin.com/downloads.php?dir=dwang/ROM/
Existing programs and files are copyright their respective owners. Any customizations that I have made are released to the public domain, except for the tools programs I wrote, which are released under GPLv2.
Hey cool! I doubt I wold use this, just currently don't have a reason, but its awesome to know its here! I'll test it out though as I'm curious what all could be done here, thanks!
Sent from my Nexus 7 using xda premium
demkantor said:
Hey cool! I doubt I wold use this, just currently don't have a reason, but its awesome to know its here! I'll test it out though as I'm curious what all could be done here, thanks!
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Thanks for trying it out! I expected the audience might be pretty small for this, but it gave my old phone a new lease on life, and I decided it was worth sharing. I often do a lot of small-time serving of web pages, IRC bots, and such. Nothing that requires a powerful machine or much bandwidth, so I didn't want to leave my main system on all the time. With this I have a completely silent server that uses a minimum of power. And of course it was fun learning more about my favorite Android device.
Thank! I was looking for something like your rom for my little log-what-and-where-my-car-does-with-obd2-and-gps-project Downloading right now You've just made my day
How was this done?
This is a very interesting project, how would one go about making this? like what files to mess with to remove JIT and other things?
Good Job @calamari
Wow. I just have to tear this thing apart and examine its innards.
I've used a HTC mytouch as a server before, but didn't take the time to rip dalvik out. Seemed like too much work that would lead to replacing a lot of functionality with shell scripts, and saying my coding skills are sub-par is an extreme understatement
Sent from my Evo V 4G using Tapatalk 2
Wow this sounds pretty awesome. Would you by chance be able to make a guide so I can do this with my heroc?
Sent from my HTC One V using xda app-developers app
Really great thing!
Just one questions:
Is it possible to access the camera?
I think about setting up a little wireless ip cam.
dadoc
KShion619 said:
This is a very interesting project, how would one go about making this? like what files to mess with to remove JIT and other things?
Good Job @calamari
Click to expand...
Click to collapse
whoshotjr2006 said:
Wow this sounds pretty awesome. Would you by chance be able to make a guide so I can do this with my heroc?
Sent from my HTC One V using xda app-developers app
Click to expand...
Click to collapse
I don't remember the full process (lots of trial and error and learning). However, you can download dwang's original ROM and compare his files against mine to determine the changes made. Full sources are included for any of my custom additions.
dadoc said:
Really great thing!
Just one questions:
Is it possible to access the camera?
I think about setting up a little wireless ip cam.
dadoc
Click to expand...
Click to collapse
I would assume so, but I haven't attempted it. There are several files in /dev that seem camera related: /dev/pmem_camera and /dev/msm_camera/*. Under Dalvik, you could try writing a program that replaces those and saves the I/O to files for analysis.
Hi all
This post will hopefully serve two purposes, one to help me find what Im looking for and the second to help other find similar.
Im looking for an N5 kernel that supports both CIFS and NFS, either built in or in the form of loadable modules. I have so far tried Faux and Franco, latest versions of both. I cant mount CIFS or NFS using the mount command with either of them. Are there any kernels on the N5 that support this properly?
If anyone knows any perhaps we can compile a list here so its clear which kernels support which features, searching high and low and trawling through kernel changelogs to find what I need is becoming quite laborious. Kind of makes me wonder why most kernel devs dont seem to want to publish a comprehensive feature list for their kernels, some do but most unfortunately dont.
Thanks in advance.
From what I can see there are kernels that support cifs - look in /system/lib/modules/ for cifs.ko.
[
I have not yet found a viable nfs module for the stock nexus, nor have I found a way to get the mount command to work.
It looks as if CM based roms may be able to deal with this, though.
Could you compile your own? If you want just to be able to simply transfer files ES File Explorer supports at least CIFS.
Sent from my Nexus 5 using xda app-developers app
Thus far I've found that Faux supports NFS, I'm able to mount directly via the busybox mount command, it just required a slight modification to the syntax. Unfortunately I've still not found any that support CIFS not even one that has the loadable modules for it. And I need these for shell scripts I'm using, which operate independently of apps so the usual file manager apps are of no use.
Sent from my Nexus 5 using Tapatalk
phobox360 said:
Thus far I've found that Faux supports NFS, I'm able to mount directly via the busybox mount command, it just required a slight modification to the syntax.
Click to expand...
Click to collapse
@phobox360 could you please post your command for NFS mount? I installed hammerhead-lp-faux123-024u kernel, tried both 'mount' and 'busybox mount' , with and w/o su, but still not able to mount NFS exports. Thanks in advance.
Disclaymer: I am not responsible by what this binary can cause to your phone.
In the past month I have been struggling with getting "rclone mount" working on my phone, and after not finding anyway to have fuse working on my phone I decided to compile the fusermount.
Yoy should copy the binary to /system/bin or add to your path "export PATH=$PATH:/path_to_fusermount"
I use the source code from: https://github.com/LineageOS/android_external_fuse/tree/cm-14.1
and https://github.com/kirbyfan64/zdata/blob/master/fs/jni/fusermount.mk to compile the binary
In my case I can now use rclone in the following way (you still need to have root access), on a terminal (termux) for android:
Code:
su
rclone mount Box:/ /storage/cloud --vfs-cache-mode minimal --allow-other --gid 1015
Tested on:
Mi4c cm14.1 (android 7.1)
Huawei Mediapad M5 (android 8)
na
Thank you very much. It's so nice that ican mount gdrive on my old phone. Helped me a lot.
Can see my mount point on termux but not see on file manager, please help??
boyrobbie said:
Can see my mount point on termux but not see on file manager, please help??
Click to expand...
Click to collapse
Are you using magisk module based rclone-mount?
darfri said:
Are you using magisk module based rclone-mount?
Click to expand...
Click to collapse
Same with me, I am using magisk module based rclone-mount.
I'm also using magisk module on android 6.0, but I get
Code:
cannot locate symbol "__aeabi_memcpy"
, because of this I can't use this module at all as intended.
Mount folders are created, but are empty. I am able to manually send files to cloud strorage, but they don't show up locally. Also, I can see the mounted folders in bot ES file explorer and Termux.
Edit: Tried it on my other phone running CarbonRom 6.1 (android 8.1.0), and I face the same issue described before me. Termux can list files when cloud storage is mounted, but file explorers show empty folders.
Edit2: Google drive seems to be working on 8.1.0 with Solid Explorer File Manager, mega folder still shows up empty :/
Has anyone got afwall? What to unblock? I'd hate to unblock multicomponent system apps.
Maybe a custom iptables script?
For people who are getting empty folders outside termux, is most likely because mount namespace seperation is enabled in their supersu or magisk. I don't use magisk so don't know the exact option but for supersu, just uncheck "Mount namespace seperation" in its settings and reboot and try after that.
I have successfully done a 64-bit on-device build inside termux for fusermount with the relevant patches. Its working fine for now and most likely will work better for people. I plan to release the binaries, the source code and tasker projects related to it hopefully in the next few days, but if someone needs the binaries earlier, let me know.
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux's. Would it be possible to include arm as well?
Click to expand...
Click to collapse
I initially was attempting a static compile within a ubuntu chroot in my phone but the static flags wouldn't work and it still linked to the "lib/arm-linux-gnueabihf/libc.so" and "/lib/ld-linux-armhf.so.3", which are glibc libs... i then decided to compile within termux itself since people would be using rclone with that anyways and dynamic linkage would hopefully not be a problem. For a 32bit compilation, i would have to look more into it cause that would require 32 libs/compiler dependencies. I tried in the morning but it failed as expected.
i have attached the termux patched source and 64bit fusermount. Instructions for termux compilation are inside the source zip... the source is the same as the OP... If someone could attempt compilation on a 32 bit phone, that would be quicker.
Edit: made some patches and improvements, use new binary.
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Click to expand...
Click to collapse
btw why do u need it outside termux, just curious... if u have root, u could call termux binaries from outside anyways, depending on selinux of course...
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Ah, check it out, looks pretty cool. yeah fixing bugs before bug reports arrive is always appreciated, but if there a no bugs reports that you are fixing with time, then it may look like you are not doing any work
yeah exporting LD_LIBRARY_PATH would work and other than during compilation for makeconf.sh, termux $PREFIX patches are not needed in the source code. The hardcoded binaries are never called if mtab is disabled or platform is not BSD. Also configure.ac does need the $PREFIX patch for setting paths which are read by util/Makefile.am for installing mount.fuse, udev and init.d scripts but those are only needed when "make install" is run and we don't need to run it just to get fusermount. So basically a static compile is possible which does not have hardcoded dependencies on termux binary path, provided that a static compile actually works. You could probabky copy the libs from termux too like you said. I'll have to first have to revert the prefix patches again though.
Few questions, do u sometimes get "transport end point not connected" error while unmounting?
and any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
@agnostic-apollo
do u sometimes get "transport end point not connected" error while unmounting?
Click to expand...
Click to collapse
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
Click to expand...
Click to collapse
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
Click to expand...
Click to collapse
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Geofferey said:
@agnostic-apollo
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Click to expand...
Click to collapse
I'll leave a detailed reply later, its 9 in the morning, i have to sleep now
fyi you can use "ldd util/fusermount" to find the libraries its linking against... and can run "export LD_LIBRARY_PATH=/system/lib64:/system/lib" before running a binary in termux...if it fails with library errors, it requires termux libraries... restart termux or restore LD_LIBRARY_PATH afterwards or other termux stuff wont work...
anyways i did an on-device build of fusermount binary that does not depend on termux/libandroid-support... reverted most of the previous patches and added a few more with new build instructions.... the fusermount binary still depends on /system/lib* libc.so and libdl.so but those are provided by every phone and would run fine on most phones, its basically like the OP one but symbol errors could be there in some devices... truly static might be possible but on device build might not be possible and will probably require cross-compile if even possible... will look into it later
check out the new binary on both devices and let me know...
I am using rclone mount magisk module
It cannot reach the host (its written in the log) when I have "apps running as root" blocked in Afwall
I really hate to allow all root apps to access inet. I would like to allow only rclone access only single local ip
What custom script would help?
It is ordinary iptables script
noob here. but i can follow. how to mount my google drive to my phone alongside to my sdcard i just want to use this as a failsafe to my files, so far i followed the step from rclone using google drive. since some apps has auto backup on phone only and thinking this is the best way to sync my phone and app settings without manually checking and uploading those files. but the problem is im stuck on this error. (screenshot) hope someone can help me. ty
im using magisk rclone module
@Geofferey
Well i managed to cross compile for all archs using NDK targeting API 21. Cannot target an API older than that due to missing function implementation in Android bionic older than that. But binaries will need to be tested on different archs and android versions/devices. You can download the binaries from my github release here. You or others can compile them yourself if they want, instructions are here.
Moreover I still couldn't manage to do a static compile. I doubt it is gonna be possible, atleast easily since Android bionic is probably not meant for that. mucl is the best hope i think, since it fully supports static linking.
However the binaries compiled by me have less library dependencies than the ones OP posted so it could be better for some, even though in OP's case, the binaries are linking to android system libraries so shouldn't be a problem in most cases. FYI I found that "ldd" command is not reliable for finding dynamic linking. Use "readelf -d "fusermount" | grep NEEDED"
The OP binary dynamic linking:
Code:
ARCH=arm64-v8a
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
ARCH=armeabi-v7a
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
The binary dynamic linking compiled by me:
Code:
Build Info:
NDK_FULL_VERSION=20.0.5594570
C_COMPILER=clang
HOST_TAG=linux-x86_64
BUILD_TIMESTAMP=2019-07-31 08.20.46
ARCH_SRC=arm64-v8a
API_LEVEL=21
FUSERMOUNT=fusermount-arm64-v8a
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi-v7a
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi-v7a
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86
API_LEVEL=21
FUSERMOUNT=fusermount-x86
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86-64
API_LEVEL=21
FUSERMOUNT=fusermount-x86-64
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
Alas, the things that need to be done just get binaries to run on our phones properly. If it were only me that had to use fusermount, it wouldn't be a problem at all, i would have just run one my scripts to merge my chroot ubuntu distro's rootfs with my android's rootfs and just run the ubuntu's fusermount and it would have worked fine for me. The ubuntu's libraries would have been dynamically linked to the binary since the ubuntu libraries would be linked to /lib and I wouldn't have to do any compilation at all. Now if it were only this simple for everybody...
Btw i read your previous comments, will try replying to them once i wake up, been too busy with this stuff.
Geofferey said:
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
Click to expand...
Click to collapse
Interesting, I use rclone supplied by termux apt repository. I get the errors if the mount point is busy like root explorer has opened up a directory inside the mount point and I stop the rclone mount command. The rclone mount command exits with resource is busy errors as expected and if i try to unmount the mount point manually i get "transport endpoint" errors, i have run a lazy unmount to get the mount point to unmount.
Geofferey said:
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
Click to expand...
Click to collapse
lolz no apologies needed, I ramble a lot too, not that anybody listens or understands
1. People in most cases are going to put the rclone file once, so going to the magisk module directory should not be a problem.
2. Most apps are granted storage permissions by users in recent android versions, and they are granted without explicit grants in old versions.... /sdcard is basically fuse/sdcardfs mounted to /storage/emulated/0, so all apps having storage permissions would have access to /storage/emulated/0/.rclone and any other directory except the /storage/emulated/0/Android of course... These popular apps are the main security risk tbh, who most likely monitor everything on the sdcard... and selinux wouldn't do anything for sdcard if storage permissions are granted.
And if a person has physical access the then it probably doesn't matter where its stored, but storing it in a root accessible would most likely still be better...
3. You could use the mount command or /proc/mounts to see active mounts to detect what has been mounted till now...
4. Yeah if your threat is a physical access than just keep your bootloader locked and encryption enabled and live a miserable life without all the benefits of rooting. I don't want to live that life, at all... I would be more worried about apps than physical access. And mostly encryption is not supported by twrp so if your device is lost, consider all the data gone if u r using a decrypted device flr using update/backup. Leaving adb enabled normally shouldn't be a problem unless you lose your authorized PC as well, then u probably have much bigger things to worry about
5. I am not familiar with magisk module access but /data/.rclone should be fine to use instead... Only root apps would have access. I'm not sure what selinux contexts magisk module directory has, it might be safer against root apps who have not been granted root access through magisk.
Geofferey said:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Click to expand...
Click to collapse
yeah caching could be hard for the device and will need to be looked over more. Wakelocks would be an issue too. I tried using minimal mode but i need to do more testing. I was getting some lags, might be related. Mobile data issues could be there too, my tasker based projects can most likely handle those by remounting. rclone remote control commands can only drop caches currently, not change their modes. Will need to ask the dev to add it if needed.
Geofferey said:
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
Click to expand...
Click to collapse
yeah I'm up for contributing to the project but only after I have completed and released my projects, gonna take a few days atleast. And yeah i have got github as u already know by now...
lolz C is not for everybody, but thats how I started programming with so I can understand it at most times, understanding the purpose of the code is another issue