Related
----- Announcements -----
Closed in favour of this thread.
As noted in the poll, interest is high enough in a union filesystem that it will be the next thing investigated. Unfortunately, anybody who wants to move from any version 1.x or earlier of this script will probably need to re-install everything for version 2.x, as the way the target filesystem is designed is going to change dramatically. Sorry.
There's a typo that jdkramar found, but I expect that most of you won't hit it (unless you've modified your /etc/sudoers), and those that will know enough to fix the script.
----- Your regularly scheduled post below. -----
For those users who have requested a full Linux on their Android device, I now present a relatively easily upgradable Ubuntu on the Motorola Atrix. It's not perfect, but it's surprisingly good.
There are a number of problems we have with the webtop environment that we would like to address in order to have "proper" Ubuntu, including (additional explanation below about each of these points):
The restrictiveness of the environment Motorola's set up (easy to bypass).
A lack of disk space to do anything (only having ~80 MB free really hurts).
An unwillingness to create a third Linux-based environment.
A non-functional apt/aptitude (easy to fix).
Note: This is different than the "webtop over HDMI sans dock" effort. If you're looking for that, please look at this other thread instead. Although unrelated, they shouldn't conflict with each other.
Caveats:
You will be hacking your device. The base script that modifies your device has been reasonably well tested and operates with a decent level of paranoia, so it is highly unlikely that the script will break anything. However, any software you install after you have access to a full Ubuntu presents a very real chance that you will either soft-brick your device or get it into an infinite reboot loop, particularly if you don't know what you're doing. Having a decent knowledge of Unix/Linux is recommended if you wish to proceed. You take full responsibility for what may happen to your device if you execute this script.
You'll need a rooted Atrix in order to do this*, although I doubt anyone's surprised about that. The attached setup script takes care of the steps in post #4, but you should note a few things:
Before you execute the script:
In response to the request that threads indicate whether or not this will work on any Motorola Atrix, it should. If you'd like verification, send me the output of "/usr/bin/dpkg-query -l" on your Atrix's unmodified Ubuntu, and I can double-check. So far, this is verified to work on:
AT&T (me! )
Bell
The script will create a 1 GB filesystem file in /data, so you'll need to have at least that much free space there.
Before running the install script, you'll need to have seven or less apps in the Media area. You can check this by going to Settings → Applications → Manage applications, then checking the Media area tab. The number of apps there will need to be seven or less. If you have more than that, temporarily uninstall apps or move them back to the phone (you can move them back after the script runs and reboots).
While you execute the script:
When the script asks question, it offers reasonably "sane" options by default (although it does try to be safe).
Resetting a filesystem file means that it will use the file that's already there, but set it back to match your original /osh partition. It's generally quite a bit faster than deleting it and recreating it, but deleting it is sometimes the right decision (like if you want to change its size).
The script asks about your MAC (mandatory access control) files because it can't be sure that you haven't altered your original files to your taste. If you have no idea what that sentence just said, pick either the very permissive or somewhat permissive MAC configuration files (the former should cause you fewer headaches).
If you haven't altered your AWN configuration (the tray at the bottom), I suggest you install the modified app launcher configuration (which is the default). If you have altered the configuration, the script won't ask, assuming that you'd like to keep your current one.
Since the setup script downloads Ubuntu packages on the fly (it made more sense than trying to have a giant archive with all of the packages embedded in it), the quality of your connection may result in the script dying partway through. If this happens, you should just be able to restart the script; it'll start again from the beginning, but nothing bad should happen as a result. If enough people report problems with downloading packages, I'll look into a workaround.
After you execute the script:
I've seen a couple of instances where on the first reboot to the alternate /osh partition where MotoBlur thinks that the SIM card has changed. Another reboot fixes this.
For those users who have used a previous version of the script, an upgrade script(s) are included to bring you up to the current level of what's automated.
For those users who have used a previous version of the script and made changes after that, the upgrade script(s) should be able to handle those changes gracefully.
If you want to uninstall:
Using adb with root access:
adb shell
su
cd /system/bin
mv mountosh mountosh.new
mv mountosh.orig mountosh
cd /data
rm ubuntu.disk
cd /home/adas/.gconf/apps/avant-window-manager
rm -r window_navigator
reboot
Once installation is complete, you can start playing with synaptic to install packages. You may need to be careful upgrading any of the -mot/~mot versioned packages, as that can break functionality. I'm still compiling a list of which packages can be upgraded versus which can be left alone (listed below).
Here's a brief runthrough of the type of operations you can do afterwards. Upon rebooting, the webtop screen now looks like this (note the altered set of icons in the tray):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Running synaptic brings up a list of available packages:
If we're looking for a decent image viewer, eog should do the trick:
Once we install it, Nautilus (the file manager) now has an interesting option in the menu for pictures, Open with "Image Viewer":
Selecting that brings up what you would expect (moved off to the side so that it doesn't take up the entire desktop):
I haven't yet tested upgrading to Ubuntu 9.10 yet (let alone Ubuntu 10.x), but everything else looks to work fine, with the usual caveats. Further updates to come as they're available!
Changelog:
1.0.6: "By default, Wget will assume a value of 10 seconds." my foot!
1.0.5: More fixes:
Having a space in the directory structure should no longer be disruptive to the script's behaviour.
Questions are now case-insensitive.
More tweaks to the somewhat permissive TOMOYO configuration files.
If the LXTerminal binary has been deleted (as appears to be the case on Bell), it is now re-installed.
The built-in package tester is now more resilient. It supports 1.4.26 and 1.4.52 properly.
The script now asks whether the dock should just be blown away with the replacement, rather than trying to make assumptions.
1.0.4: Quite a few fixes:
Rename upgrade scripts, so that people get less confused (hopefully!).
Tweak the check for whether it's already running from the filesystem file, since the earlier check didn't actually work (doh!).
/osh/data doesn't exist by default, so have the script stop assuming that.
Tweak the pulseaudio re-install so that it's a bit more reliable.
The expected list of packages to manipulate doesn't work for 4.1.26. Set it to the 4.1.26 numbers for now, and re-factor for 4.1.52 with the next revision.
Reroute /bin/ps' stderr to /dev/null so that it doesn't pollute stdout.
The set of unmount instructions at the end need to be split up, since you can rightfully get to the end while skipping some of the mount instructions.
Prior to attempting to alter /system, ensure that it's mounted read/write.
1.0.3: Not everybody runs batch files from the command line, so add a "pause" at the end so that users can see what happened.
1.0.2: Apparently, relying on the score that aptitude returns as the check for whether or not it's okay to auto-fix things is too unreliable. So, instead, opt for the (somewhat riskier, but should be reasonable) check of the number of packages to remove/install/upgrade/downgrade. The check can be made package-specific if need be, but I'd rather have a script that I can re-use later for other upgrades if I need it.
1.0.1: If the package management auto-fix doesn't go through, it's not likely that the script will be able to install gksu or synaptic either, so those steps need to be fixed.
1.0: The "very permissive" MAC option was broken. That's now been fixed, along with completing the automation of the entire process.
0.7.2: Added a check for having a free loop device, and also re-added a "very permissive" MAC option.
0.7.1: Removing /sbin/tomoyo-init appears to cause the X environment not to load at all, so disallow that option for now.
0.7: In addition to making it slightly more user-friendly (by adding questions for when the script isn't sure how to handle a situation), it now handles through to the initial dpkg installation.
0.5.2: Dump rsync's output to /tmp/rsync.out since it takes a really long time, allowing for users to tail the output if they know how. Also, run adb kill-server at the end of the script so that the adb daemon doesn't continue to run (which makes it really annoying to try and delete the directory).
0.5.1: 0.5 had a bug where it tried to check for a return from psneuter, which kills the adb connection (so no return value could be obtained). Instead, use whoami to verify whether or not psneuter succeeded in running.
0.5: The attached script should handle up through to the rsync phase automatically. There's a considerable amount of error checking, so it should be safe to use (I've uploaded a version of the script that should take you as far as the mountosh swapping, which means that you'll now be using a different Ubuntu partition than the default).
* This is a technicality, since the script hacks your device to be able to run commands over ADB as root.
----- Donation notes -----
If you want to donate, rather than to me, why not donate to the Japanese earthquake/tsunami relief effort instead? Here are a couple of (non-attributed) pointers if you don't know where else to look:
International Federation of Red Cross and Red Crescent Societies: no minimum; USD, CHF, EUR; Visa/MC
American Red Cross: $10 minimum (ouch); USD; Visa/MC/AmEx/Discover/Amazon
Canadian Red Cross: no minimum (?); CAD; Visa/MC/AmEx/PayPal
In regards to the above list, a bit of explanation:
The restrictiveness of the environment Motorola's set up (easy to bypass).
As shown in the above steps, renaming and/or removing /sbin/tomoyo-init is all it takes to disable TOMOYO Linux. Leaving it in place isn't necessarily a bad idea, since it means that any of the standard entry points into an Atrix are reasonably locked down. The TOMOYO configuration file that I'll shortly be attaching leaves certain executables completely unlocked (those that need to be able to run anything), but finding out what's hitting up against the limits is a simple matter of setting everything to run_level 2 and checking dmesg.
A lack of disk space to do anything (only having ~80 MB free really hurts).
As I note above, 1 GB isn't much either. On the other hand, what I'm going to look into when I have that mythical thing called free time is to use my internal contacts to get a copy of the kernel source code and then see if I can build myself a FUSE module. At that point, I should be able to pull off a union mount, which should help dramatically.
We haven't figured out how to repartition the Atrix's partition scheme, so we don't have much flexibility on making the existing partition larger. Creating a filesystem file in the Internal Storage would be nice, but a) that partition (p18) isn't available when mountosh runs, and b) it'd make it difficult, if not impossible, to cleanly USB mount the partition. Creating a partition on the SD card would be nice, but a) mmcblk1 isn't available when mountosh runs either, and b) there would be similar constraints if a user ever wanted to pull the SD card.
An unwillingness to create a third Linux-based environment.
I respect what the people who are trying to create a "clean" chrooted environment are trying to do, but it feels to me that there's the whole "throwing the baby out with the bathwater" aspect here, since there really isn't that much more to do beyond what Motorola's provided. Besides of which, some of what Motorola has done with their environment isn't possible to duplicate without taking the files (like the aiw (Android In Window) package). So I would prefer to take the approach of taking the chains off the existing system.
A non-functional apt/aptitude (easy to fix).
Not much to say here, right?
The script builds a larger disk using /data as its home. The primary advantage is that we have access to it at the right point during boot. The primary disadvantage is that we don't have anywhere as much as we'd like to have (since /data is 2 GB total). But, you work with what you've got!
Known package issues:
Be careful upgrading any of the -mot/~mot packages, as that can break functionality. I'm still compiling a list of which packages can be upgraded versus which can be left alone.
Can be upgraded with loss of functionality:
libnautilus-extension1-1:2.26.2-0ubuntu1-mot1
nautilus-1:2.26.2-0ubuntu1-mot1
nautilus-data-1:2.26.2-0ubuntu1-mot1
Upgrading these packages plus at least one additional package I've not yet fully identified breaks viewing mountable storage and the ability to unmount it.
xserver-xorg-core-2:1.6.0-0ubuntu14
Using the stock xserver-xorg-core 2:1.6.0-0ubuntu14 that's already installed without recovering /usr/bin/Xorg appears to lead to a loss of the status bar at the top. This particular issue is now handled by the script.
Cannot be upgraded:
gtk2-engines-1:2.18.1-0ubuntu1~mot1
This breaks aiw (Android In Window) so that there's no frame around the window and it can no longer be manipulated in any way.
xscreensaver-5.10-6-motorola1?
xscreensaver-data-5.10-6-motorola1?
xscreensaver-data-extra-5.10-6-motorola1?
This will likely break displaying aiw (Android In Window) as the unlocking mechanism for the screensaver. Still needs to be tested.
Archived notes:
The below steps are performed by the script in the first post, but in case you really wanted to know what's going on behind the scenes....
----- The setup script takes care of steps starting here. -----
From here on until noted otherwise, all commands are assumed to be run as root (so you either are root, or you're calling every command via sudo).
First, we should make sure that there's enough free space on the device:
/bin/df -h /data
There should be at least 1.0G under the Used column. If not, you won't have enough to create a decent disk. If so, then you can keep going:
/bin/dd if=/dev/zero of=/data/ubuntu.disk bs=1024 count=1048576
/sbin/losetup /dev/block/loop7 /data/ubuntu.disk
/sbin/mkfs -t ext3 -m 1 -b 2048 /dev/block/loop7
mkdir /tmp/osh
/bin/mount -t ext3 /dev/block/loop7 /tmp/osh
At this point, we've created a 1 GB disk file (1,024×1,024=1,048,576), formatted it as ext3, and mounted it in /tmp/osh. The next step is that we need to grab a copy of rsync so that we can perform our copy. I'll assume that rync is in /mnt/sdcard-ext for now:
mkdir /tmp/deb
/usr/bin/dpkg-deb -x /mnt/sdcard-ext/rsync* /tmp/deb
/tmp/deb/usr/bin/rsync -avx /osh/ /tmp/osh/
And now we have a duplicate of our /osh partition, but with more space this time (1 GB instead of 756 MB, which isn't great, but is a hell of a lot better). And, we know how to intercept the point in init.rc where /osh is mounted so that we can redirect it. Put the following into a file named mountosh.new, then copy it to /mnt/sdcard-ext. Here's the file:
Code:
#!/system/bin/sh
# Run mountosh.orig
/system/bin/mountosh.orig "[email protected]"
# Then, mount the filesystem file over the existing /osh
# partition.
/sbin/losetup /dev/block/loop7 /data/ubuntu.disk
/system/bin/mount -t ext3 /dev/block/loop7 /osh
After that:
mv /system/bin/mountosh /system/bin/mountosh.orig
cp /mnt/sdcard-ext/mountosh.new /system/bin/mountosh
chmod 0755 /system/bin/mountosh
chown 0 /system/bin/mountosh
chgrp 2000 /system/bin/mountosh
You can now reboot your device, and you should now boot into the new partition we've just created.
----- The 0.5 version of the setup script performs up through here. -----
Here, an interesting question pops up: do you want mandatory access control (MAC) in place? In my case, I don't have a problem with it, so I can provide updated TOMOYO configuration files that reflect that. If you would prefer to disable it completely, run the following commands:
rm osh/etc/tomoyo/exception_policy.conf
touch osh/etc/tomoyo/exception_policy.conf
rm osh/etc/tomoyo/domain_policy.conf
touch osh/etc/tomoyo/domain_policy.conf
and then reboot your device again. This configures TOMOYO so that it monitors nothing.
Next, we go through and install a series of packages which are either loaded in a broken state (because Motorola force-installed conflicting packages afterward) or packages which are expected to be present. Some of these packages have specific paths listed afterward; if there are, then those files need to be backed up before package reinstallation, then restored afterward. This is important.
coreutils
cpio
dbus
/etc/init.d/dbus
dbus-x11
/etc/X11/Xsession.d/75dbus_dbus-launch
dhcp3-client
findutils
gpgv
pulseaudio
/etc/pulse/daemon.conf
/etc/pulse/default.pa
udev
/etc/init.d/udev
xserver-xorg-core
/usr/bin/Xorg
You'll need to install each package with:
dpkg -i --root=/osh --force-overwrite <package>
At this point, we can now update the list of APT sources so that we can start querying the public Ubuntu depots. Edit your /etc/apt/sources.list to have these entries:
Code:
deb http://ports.ubuntu.com jaunty main universe multiverse restricted
deb http://ports.ubuntu.com jaunty-security main universe multiverse restricted
deb http://ports.ubuntu.com jaunty-updates main universe multiverse restricted
I would also recommend that you add this line to the bottom of your /etc/apt/apt.conf.d/05aptitude file, since the reality of the situation is that we still don't have much space (it'll turn off auto-installing packages that aren't necessary but are recommended):
Code:
Apt::Install-Recommends "false";
At this point, you should be able to run the following with no problems:
apt-get update
----- The 0.7 version of the setup script performs up through here. -----
If this succeeds, we can move on to running aptitude:
aptitude
It will complain that a number of package installations are broken. This is expected, as that's how Motorola built out the distribution. The current script executes the "default" solution, which at the time of writing is four uninstallations, one downgrade, and ten installs. Also make sure that no "unnecessary" packages are uninstalled, since some of them are actually necessary.
We can then install gksu and aptitude so that we have graphical access to the package repositories from aptitude.
----- The 1.0 version of the setup script performs up through here. -----
You my friend are incredibly good. This is insane
Edit: removed huge quote...
Might be a good idea to not quote the entire massive post.
Looking forward to seeing where this goes... How well does it run?
This is great. Can't wait to try it monday. Keep up the good work.
Sent from my MB860 using XDA Premium App
how does this perform vs the included webtop mode?
CC Lemon said:
Looking forward to seeing where this goes... How well does it run?
Click to expand...
Click to collapse
lasersocks said:
how does this perform vs the included webtop mode?
Click to expand...
Click to collapse
It is the included webtop mode - it's just a matter of pulling off some of the restrictions that Motorola put on it. I should probably tweak it just a bit more to where I'm happy with it, and then I'll be able to start making suggestions on what to install. One of the things that people would probably want most is synaptic (graphical package manager), for example, and I should just have a script that installs it for people.
if you get this working, can you make a video please? would be nice to see how it is.
pure genius
can u post a video about your work ? =)
Very good work! You should join the irc sometime.
freenode
#moto-atrix
Now with more scripting!
I've added a version 0.5 of a setup script that automates some of what happens (I've denoted how far in the process it performs right now). It should print out a user-friendly version of what it's doing, in addition to what it's failing on if it fails. Appropriate notes added in the first post as well.
Sogarth said:
Now with more scripting!
I've added a version 0.5 of a setup script that automates some of what happens (I've denoted how far in the process it performs right now). It should print out a user-friendly version of what it's doing, in addition to what it's failing on if it fails. Appropriate notes added in the first post as well.
Click to expand...
Click to collapse
I'll try again. Got up until mounting new partition. Created mountosh.new copied over to phone rebooted. Didn't mount. Didn't have anything in /sbin dir. Like losetup.
Back to .sbf now. Going to try script and give it another go.
I cant wait for my Atrix I'm getting more and more excited every day seeing whats happening here
Thanks a lot for this, especially that I'm not very advanced linux user
Does the usb mice and keyboard work properly? Or other usb-stuff?
dicksteele said:
I'll try again. Got up until mounting new partition. Created mountosh.new copied over to phone rebooted. Didn't mount. Didn't have anything in /sbin dir. Like losetup.
Back to .sbf now. Going to try script and give it another go.
Click to expand...
Click to collapse
Hmm... that's really, really strange.
Edit ubuntu.bad and comment out the reboot line, then. Should just be a matter of adding rem at the beginning of that line.
Also, you shouldn't have to use the sbf. Using the soft brick recovery instructions should be enough, since all you would need to do would be to rename mountosh to mountosh.new, then rename mountosh.orig back to mountosh to get the original state back.
Sogarth said:
Now with more scripting!
I've added a version 0.5 of a setup script that automates some of what happens (I've denoted how far in the process it performs right now). It should print out a user-friendly version of what it's doing, in addition to what it's failing on if it fails. Appropriate notes added in the first post as well.
Click to expand...
Click to collapse
Shouldn't for /f "tokens=*" %%l in ('%~dp0adb.exe shell "chmod 6755 /tmp/psneuter > /dev/null 2>&1 && echo PASS"') do set retval=%%l
be chmod 0755 ? Getting error can't execute psneuter. First I thought it was because I already had one in tmp from AROOT. Trying again now.
Sogarth said:
Hmm... that's really, really strange.
Edit ubuntu.bad and comment out the reboot line, then. Should just be a matter of adding rem at the beginning of that line.
Also, you shouldn't have to use the sbf. Using the soft brick recovery instructions should be enough, since all you would need to do would be to rename mountosh to mountosh.new, then rename mountosh.orig back to mountosh to get the original state back.
Click to expand...
Click to collapse
I was running Gingerblur. Wanted to start fresh. And it wasn't from running batch file. It was before you creating batch. Tried from first post instructions. No biggie. I'm having fun !!!
dicksteele said:
Shouldn't for /f "tokens=*" %%l in ('%~dp0adb.exe shell "chmod 6755 /tmp/psneuter > /dev/null 2>&1 && echo PASS"') do set retval=%%l
be chmod 0755 ? Getting error can't execute psneuter. First I thought it was because I already had one in tmp from AROOT. Trying again now.
Click to expand...
Click to collapse
No, it's actually chmod 6755 since it's setting u+s. What's a bug in there (and I'm about to upload a fixed version) is that /tmp/psneuter actually kills the connection immediately, so it can never return "PASS". I added in a user check afterward instead.
A fixed 0.5.1 uploaded.
If you are looking for how to get back to stock Bell, go HERE.
Disclaimer: I have not tested this on anything but my phone. This is a development section of a hacking website. Make backups. Know what you are doing.
Credits:
Brut.all for apktool
edgan for 2nd-init
designgears for aroot inspiration.
xda for being a source of info.
Requirements:
Windows 7 or Ubuntu 10.10+ (10.10 and 11.04 tested)
Java installed. (For applymods, it uses apktool)
Running Phone, not in recovery mode, etc.
Tips:
Don't factory reset please if something goes wrong, it just erases your personal settings, it doesn't write to the system partition. It also deletes your data partition, making it harder to get back to stock.
Early usb mode, turn your phone on while holding down the lower volume button, when it says fastboot, release and press volume down repeatedly until it says early usb enumeration, then press up volume. It takes 30 seconds or so before adb is ready.
Version 9:
Download it here.
What's new:
Added support for 2nd-int (WIP, tested on stock Bell only)
shsu updated to allow a super user to become a super user, acts like sh in that case.
fixed linux install_recovery.sh and uninstall_recovery.sh scripts to use shsu instead of remaining using su. Ditto with ApplyMods.sh
Boot animation now smaller, using jpegs instead of png files, no difference in appearance.
Version 8:
Download it here.
What's new:
Added full phone backup and full restore phone options to the menu. It will download a backup if there is none found.
root script more universal, tries psneuter first, then gingerbreak.
Early usb recovery updated, now uses a tmpfs for system, also mounts /sdcard and /sdcard-ext.
Deodexed French 2.1.1 files incorporated.
Misc fixes
Version 7:
What's new:
New Menu script for windows and linux in the top folder, double click Menu and enter options.
ApplyMods and other scripts updated to use /data/local/tmp/system, this means I can update system.tar.gz and add folders to be copied into system.
Early USB enumeration recovery option. (experimental but useful as is)
Fixed bugs in windows scripts. Can't get user input from bat file while in a parenthesis block apparently.
Bloat backed up to sdcard now
root and unroot scripts updated with more prompts for rebooting phone.
Version 6:
What's new:
Support for Telstra 1.4.2.
ApplyMods can create signed update.zips now, Create_update.bat updated. both using basic ready made scripts in main bin folder instead of creating them on the fly, CR LF issues.
Updated root and unroot scripts, more fool proofing, has to be Bell stock firmware (psneuter doesn't work on telstra).
Includes basic boot animation, and mod for Bell apn on telstra firmware. (Have to reset to default under access point names in settings.)
transparent status bar, yellow tinted white for text color, matches front buttons somewhat.
Version 5.1:
Features:
Works under Linux and Windows 7
Includes root and no ads scripts
Patch system for applying modifications.
What's new:
New scripts for doing mods, fixes issues with patch 9 images.
Updated root and unroot scripts, more fool proofing.
New RestoreSystemPartition script
Custom apktool for more [hopefully] bug free installations.
How to use:
Extract archive, keeping folder structure intact.
run a command prompt/terminal (There is a link to one in the windows folder)
run root.bat or root.sh from the linux or windows folders, depending on which one you are using.
Turn the phone off after that is done and turn it back on again.
The rest of the scripts shouldn't be run with psneuter affecting the phone.
run ApplyMods.bat (.sh) [OPTIONAL] This applies webtop hack and translucent status bar, translucent notification drop down, etc. Select update system.tar.gz.
run install_bell_deodex.bat or .sh
System image of stock Bell.
Mirror of above
Cheers!
Very nice! Looks good!
Will try this when I get home
Sent from my Motorola Olympus
So what is the benefit of this? Will I be able to theme my device with some of the themes that are available? Or should I play it safe and wait for a bell. Sbf to leak before I try anything and brick my phone again lol thanks in advance
EDIT: i see that you have included soft_brick.bat is it the same as this one http://forum.xda-developers.com/showthread.php?t=982859 because that one did not work for me thanks again
Sent from my MB860 using XDA Premium App
cool, i'll try this tomorrow when i don't still have a ****load to do and only 5 hours to sleep
nice to see a Bell dev here!
Also I just wanted to say major props for the crazy awesome idea of doing over-the-air download and installation. Really smart and original.
Atrices, just so you know
NFHimself said:
Hi,
(What is the plural of Atrix?)
Click to expand...
Click to collapse
Can I run this on my mac? Sorry relatively new to adb
Sent from my Motorola Olympus
you could run it on a mac, just had to edit the script a bit.
Hi,
So what is the benefit of this? Will I be able to theme my device with some of the themes that are available? Or should I play it safe and wait for a bell. Sbf to leak before I try anything and brick my phone again lol thanks in advance
Click to expand...
Click to collapse
I wouldn't try theming with ATT files, I would take what was done to them and apply them myself to the deodexed files here. There may or may not be differences that are not obvious. I am never really sure if there is any benefit to this stuff, it's fun to do, about it.
EDIT: i see that you have included soft_brick.bat is it the same as this one http://forum.xda-developers.com/showthread.php?t=982859 because that one did not work for me thanks again
Click to expand...
Click to collapse
The soft_brick.bat script is specific to the folders I am using for transferring data to /system/app and /system/framework. It tries to get root via psneuter, mounts system read write, deletes dalvik-cache files, and tries to copy the files already on the phone to the right folders. It could be that just one file caused the phone to crash mid copy and copying it again will fix things. This avoids trying to do a usb data transfer of all the files which you don't have time to do otherwise. I was also thinking that install-recovery.sh would be a good place to do this, (and then clobber it later with the init.d hack) but I couldn't find setprop and I wasn't in need enough to select a file to use as a semaphore.
Can I run this on my mac? Sorry relatively new to adb
Click to expand...
Click to collapse
It would be easier to do it all from a sh script really, and that would likely be more compatible with a Mac.
Also I just wanted to say major props for the crazy awesome idea of doing over-the-air download and installation. Really smart and original.
Click to expand...
Click to collapse
Thanks!
Cheers!
maledyris said:
Atrices, just so you know
Click to expand...
Click to collapse
Thanks, a lot, really, 10 chars..
How do I recover from a softbrick from this? Thanks.
Before anything is done, all the files are extracted to /data/local/tmp/app and /data/local/tmp/framework. If you run into problems put the phone into fastboot/early usb enumeration mode (see here) and run soft_brick.bat (.sh for linux)
Quote:
A soft brick, in this case, is when you make a bad edit to your framework files and the phone won't fully boot and starts flashing a red LED at you.
There is one catch, you only get about 1-2min to do all of this before the phone reboots on its own. If that happens, do SuperOneClick steps again and continue where you left off. Better yet, build a script to do it all for you
Power off your device
Enter Fastboot:
Hold Volume down + power until you see Fastboot at the top left
Use volume down to scroll down to "Early USB Enumeration" (only shows one item at a time, if you pass it, keep going down, up selects)
Press Volume up to select
This is the message I get when i run the batch file.
This is of course when invoking Early USB Enumeration.
Wait for the count down to finish ...
'TIMEOUT' is not recognized as an internal or external command,
operable program or batch file.
clearing Dalvik cache..
rm failed for /data/dalvik-cache/[email protected]*.dex, No such file or directory
rm failed for /data/dalvik-cache/[email protected]*.dex, No such file or director
y
rm failed for /data/dalvik-cache/[email protected]*.odex, No such file or directory
rm failed for /data/dalvik-cache/[email protected]*.odex, No such file or directo
ry
reinstalling apps
cp: cannot stat '/data/local/tmp/app/*': No such file or directory
reinstalling framework..
cp: cannot stat '/data/local/tmp/framework/*': No such file or directory
done.
The timeout message means you are running a version of windows without timeout, see adeo thread.
The lines for rm just mean there are no files to delete in the Dalvik-cache, which is normal, you should see that the second time around.
The cp lines are saying that there are no files in /data/local/tmp/app (/framework).
So, that's unusual, in order to get soft bricked using my script you would to have copied files from /data/local/tmp to /system, and if you are bricked would be unable to delete the files afterword.
sequence:
cd /system
cp /data/local/tmp/app/* app/
sync
reboot now
**brick**
So, how are the /data/local/tmp/app files being deleted?
No clue. I'm not sure what to do here? Is my phone permanently bricked? Any other way to recover from this? The one thing that could have gone wrong is I tried installing from my behind my works firewall. Maybe I could not download the proper files.
No, you are soft bricked, you only made a change (that I know of) in system files.
Were you rooted before you tried this?
If you copy the soft_brick.bat files and change the last line to be adb.exe shell ls -R /data/local/tmp, what do you get?
Basically, it sounds like to need to get the files copied over to data/local/tmp, how they are missing/inaccessible is odd. So, create a script to copy the files over bit by bit, might take a while but it should be able to be done.
EDIT:
Do this:
from command prompt:
adb.exe shell ./data/local/tmp/psneuter
wait a few seconds
type this:
adb shell ls -l -R /data/local/tmp
if psneuter fails, it isn't in /data/local/tmp, which is also odd.
I was rooted before this. So I should attempt all these commands while Early USB Enumeration right? That doesn't give me much time Lol.
OK, here's the output.
C:\bell_deodex>adb.exe shell ./data/local/tmp/psneuter
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
property service neutered.
killing adbd. (should restart in a second or two)
C:\bell_deodex>adb shell ls -l -R /data/local/tmp
/data/local/tmp:
-rwxr-xr-x root root 585731 2011-01-09 02:02 psneuter
-rw-r--r-- mot_tcmd mot_tcmd 4 2011-03-30 21:00 ap_tcmd.pid
C:\bell_deodex>^A
And sorry to be a pain. How would I create the script? What are the files that need to be copied? Are they included in your script?
While the recovery we have at the moment, fruit of the hard work of xantaro, unclecracker and digitalfrost, is enough for most operations there are some things bugging me that is in our interest to fix with the ultimate aim of adding it to ROM Manager and thus get official support.
Current issues:
1. It isn't the latest version of CWM and isn't official.
2. It doesn't have USB mount working.
3. It doesn't have ADB working.
4. It doesn't support EXT4.
Now, I have tried to fix these but recoveries are a new domain for me and at a first attempt I couldn't bring some of these to work. Compiling the latest version was easy and an important first step towards official; however, all others I couldn't do it and I don't think we should talk with koush before fixing all this.
Here are my short attempts:
- For USB mount I defined on the BoardConfig the path for UMS lun0 file. The path seems to be correct and there's no other file in /platform/ as I've found out by running a ls -R. I have no idea why it's not working.
- For ADB, I made sure the persist.adb.service is set to 1 and the init.rc is starting it. This being said, I don't know what's missing. Perhaps this is of interest?
- For EXT4 support I thought it was just a matter of adding alternative FS to recovery.fstab. Seems I was wrong though.
So, does anyone want to join in and help?
This is really new territory to me and I have a quite faint idea of what I'm doing.
A few guidelines:
- Read this to get an idea.
- You'll need CM sources (repo init... repo sync...)
- The CWM recovery source is in /bootable/recovery
- Here is my device source and a patch file for some changes on recovery src *
- Run build commands (. build/envsetup.sh, lunch full_p970-eng, make -j4 recoveryimage)
* If you don't change what I did on the recovery source you won't have a key to select.
Also, I have CWM 4.x at the moment on my OB but since it does the same as the already posted 3.x I don't deem necessary to share it; but if anyone wants, I'll upload it.
I'll join the party when I come from the mini-vacations, hope there'll be some progress meanwhile!
Great
i'll try to do some help,maybe little
If anyone wants you can request a pull from my source.
Also, here's a flashing CWM 4.x. I renamed it Nova recovery for the lulz.
http://www.multiupload.com/R7WGNYTL7G
Changes on the Source to get selectbutton to work shouldn´t be necessary. Adding "BOARD_HAS_NO_SELECT_BUTTON := true" to boardconfig.mk suffices to get selectbutton to work.
EXT4 Backup and Restore worked for me after editing the fstab file.
For the ADB and USB mount problem i have no Idea what is missing. Like you said, adb daemon should get started througt the initscript.
BTW. seems like the Progressbar isn´t working on the newer Versions of CWM
xantaro said:
EXT4 Backup and Restore worked for me after editing the fstab file.
Click to expand...
Click to collapse
Could you release a new version or tell us how to do it? Thanks
To get EXT4 working in my O2X builds my /data line looks like this:
Code:
/data ext3 /dev/block/mmcblk0p9 NULL auto
xantaro said:
Changes on the Source to get selectbutton to work shouldn´t be necessary. Adding "BOARD_HAS_NO_SELECT_BUTTON := true" to boardconfig.mk suffices to get selectbutton to work.
Click to expand...
Click to collapse
I thought the flag wasn't suffice. Thanks.
Rusty! said:
To get EXT4 working in my O2X builds my /data line looks like this:
Code:
/data ext3 /dev/block/mmcblk0p9 NULL auto
Click to expand...
Click to collapse
Nice tip, I'll try.
knzo said:
While the recovery we have at the moment, fruit of the hard work of xantaro, unclecracker and digitalfrost, is enough for most operations there are some things bugging me that is in our interest to fix with the ultimate aim of adding it to ROM Manager and thus get official support.
Current issues:
1. It isn't the latest version of CWM and isn't official.
2. It doesn't have USB mount working.
3. It doesn't have ADB working.
4. It doesn't support EXT4.
Click to expand...
Click to collapse
Hey,
I know this is an old thread but still if u have not resolved the problem with ADB and USB follow these instruction:
Before we start:
My mobile is Spice Mi-410 (Qualcomm made), also known as Cherrymobile magnum, Wellcomm, Motorola triumph in different countries. So may be these tweak will not work with your device. (But you can give it a try )
I hope you know how to unpack recovery.img of your device (or boot.img if your recovery ramdisk is stored in boot.img like Xperia Arc) if not then follow this guide to unpack recovery.img and extract recovery ramdisk into a folder.
Tweak
For ADB: Open init.rc file from recovery ramdisk/initram using any editor of your choice
Put this line at the end of "on init" section
Code:
write /sys/module/g_android/parameters/product_id ####
where #### should be replaced by your device's product id.
(if you dont know what it is then connect your mobile to PC and issue "lsusb" command in ubuntu terminal, you should see something like this
Bus 001 Device 027: ID 0489:c000 Foxconn / Hon Hai
Here c000 is my devices product id and Foxconn is my device's manufacturer)
Though /sys/module/g_android is not present in our device but this worked for me.
Please note that the device id is case sensitive, so write what you see on PC
For USB: For this add following line at the end of "on boot" section in init.rc file
Code:
echo 1 > /sys/class/usb_composite/usb_mass_storage/enable
For your device first confirm the location of /sys/class/ ###### / ####/usb_mass_storage/enable
Since this location vary from device to device.
This should enable usb storage mounting from recovery.
Best of luck!!
One option for load rootfs image in native mode is necesary
enviado
In case someone would like to build an own image based on the stock firmware,
I wrote a script that performs the neccessary steps (which where mostly described at the xda-forums) automatically on a linux based system.
It is very raw, and is not well optimized. It also is using many sudo calls for creating and modifying the image. Maybe someone has another, better solution.
Usage:
Download and unpack the ExtractAOS archive:
Code:
tar xfj ExtractAOS.tar.bz2
At first you need to place a AOS update file (firmware_archos_it4.aos) into the "dl" folder.
Then copy a busybox.tar.bz2 file, which contains the statically linked binaries of busybox (no subdirectories) inside the archive:
Code:
ash
busybox
cat
chgrp
...
Also make sure that following tools are installed on your system:
unsquash
unzip
tar
Then start the main script:
Code:
./unpackAOS
You will see a menu like this:
Code:
---------- Unpack and Modify Archos image -----------
1 Cleanup: Umount all mounted devices and delete all created files.
2 Download needed packages
3 Setup build directory
4 Create new Ext4 loop image and mount it to MOUNT_DIR
5 Extract AOS image
6 Copy AOS image contens into /data/ExtractAOS/archos_update_folder
7 Modify image in /data/ExtractAOS/archos_update_folder
8 Finish image and unmount it
88 Perform step 3-8 automatically
99 Exit
Then download needed tools via menu item "2".
If the download are successfully done, then you can enter "88"
to build your own archos.ext4.update image file.
Notes:
I'm on a 64 bit system. Letama seems to provide binaries also for 32 bit sytems. In that case, you can modify and set the correct binary within the script file.
This script is intended to provide a base for developers which want their own customisations
Special thanks to:
letama
surdu_petru
Thanks i will try it next weekend
Gesendet von meinem HTC Desire mit Tapatalk 2
Quallenauge said:
Also make sure that following tools are installed on your system:
unsquash
unzip
tar
Click to expand...
Click to collapse
On which firmwares did you test this script?
There was an error in squashfs header in 4.0.5-4.0.6 FW (including test releases)- androidmerged.squashfs.secure could be mounted as loop but not extracted
Hi,
I builded my image based on the current 4.0.7 aos-update file.
I'm using archlinux 64 bit.
Which arch are you using? Can you please verify that the correct extractAOS binaries are downloaded within the script?
The script doesn't mount the androidmerged.squashfs.secure as loop device, but copies all the data from androidmerged.squashfs to a temporary folder named "output_folder".
Can you please provide a console output? Maybe there is some more information?...
Quallenauge said:
Hi,
I builded my image based on the current 4.0.7 aos-update file.
I'm using archlinux 64 bit.
Which arch are you using? Can you please verify that the correct extractAOS binaries are downloaded within the script?
The script doesn't mount the androidmerged.squashfs.secure as loop device, but copies all the data from androidmerged.squashfs to a temporary folder named "output_folder".
Can you please provide a console output? Maybe there is some more information?...
Click to expand...
Click to collapse
I didn't test the script (I stick to 3.2.80).
For modifying I use LeTamas' "manual" method- correct binaries are present (linux 32bit). Unpacking .aos file works fine but I had problems with unsquashfs (header error in =<4.0.6 fw) so the only option was mount -o loop.
If it works for 4.0.7= Archos corrected the error
Hi!
I've just downloaded the 4.0.6 version from archos servers.
Code:
h**p:// update.archos.com/9/gen9/gen9_4.0.6/firmware_archos_it4.aos
Unpacking of the squashfs still works here...
Maybe you missed the needed steps:
Code:
cd $BASEPATH/firmware_archos_it4/root/data
dd if=androidmerged.squashfs.secure of=androidmerged.squashfs bs=256 skip=1
if [ -d output_folder ]; then
rm -f output_folder
fi
unsquashfs -d output_folder androidmerged.squashfs
Maybe stupid question but why we need this busybox ( this archive actually is missing)? I think there is busybox already from the archive is that archive is rooted or give us something more?
Hi,
I saw that another customized roms contains an updated busybox, which can provide more features.
(Honestly, I don't know which feature is it worth to replace the builtin busybox... . :angel
If you want to build an image without this step, just comment out the busybox call.
The busybox archive is missing, because I don't know If I have the permission to include a compiled (from other people) busybox by default.
[Dev] CM9 Mod Extension
Help!
I can't wait to try out the final build from Anybody interested in testing a CM9 super-alpha build in a week or so?, so I decided to try out a modification of the stock rom with CM9 by myself. And yes, today zygote has startet and I got a screen =)
I would like to share with you, what I did and I hope that you can give some code extensions to build a better mod script.
So, let's go:
1) Compile cyanogen mod
Install prerequisites
(I used Ubuntu Precise 32bit in a chrooted environment)
Then perform like suggested a repo init/sync:
Code:
repo init -u git://github.com/CyanogenMod/android.git -b ics
repo sync
Then perform a compile action:
Code:
. build/envsetup.sh
lunch full_panda-eng
mka
PS: I had to modify the cyanogen_root/external/webkit/Android.mk
because there where build errors:
Code:
# Build the performance command line tool.
#include $(WEBKIT_PATH)/android/benchmark/Android.mk
Get some coffee I full build will take about an hour (on my system).
2) Unpack Archos stock image
You can use my tool at #1 of this thread!
PS: I used 407 stock image...
3) Create a loop image and mount it into a folder
You can use my script for that.
4) Get my new archive and unpack it.
Go into that folder and modify the bash script Porting.sh to match the folder paths:
Code:
export CYANOGEN=/cynogen_mod/out/target/product/panda
export STOCK=/ExtractAOS/firmware_archos_it4/root/data/output_folder/
export OUT=/Android/Development/mount
Run the script as root!
Code:
sudo ./Porting.sh
You get a file system contents in $OUT. Unmount the loop directory and
load it into the media update path as usual:
Code:
adb push archos.ext4.update /data/media/ && adb reboot
That's it! You should get a CM9 desktop.
------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
That was the good news! The bad:
The current state is a proof of concept.
I'm really hope that you can contribute to the modding script: I'm not an android expert!
Dirty technical details:
I had to use the existing vendor libraries especially the graphics drivers (I tried to use the panda binaries, with no luck :-/ ).
I moved them into the /system/vendor/lib folder and symlinked the libraries to /system/lib. This way it seems to much cleaner.
I modify the init.rc script to mount the data directory into /data2 to not interfere with existing archos installation. Later we should be able to point to that directory again. (Hint: to update the development you must use a adapted adb update command:
Code:
adb push archos.ext4.update /data2/media/ && adb reboot
From the first test, I saw that I have no real touchscreen, it worked like a "mouse" controlled environment. Maybe because the panda board has an mouse as input device.
Thanks.
PS: I'm curious how JackpotCalvin has solved the CM9 integration, It sounds way better than my solution...
Nice one
Some thoughts:
-why do you copy $STOCK/usr/bin/[binary name] when later all $STOCK/usr dir is copied?
-there should be no need to place PowerVR in /system/vendor/lib/[...], /system/lib/[...] should work fine
-check prelinks for existing libs and adjust prelink map for [repo path]/device/ (this may not be necessary, last system I compiled was Froyo)
I'm stopping my efford because I'm at a point, where I learned that just replacing the files between both sources (Panda Board CM9 builded binaries and Archos Stock ROM) is not a 100% solution.
I resolved my input devices setup, by copying the corresponding icd (and other) foles to the output folder. Then I had unresolved issues by getting WLAN to work. I found out, that in libandroid.so and libandroid_legacy.so are coded the modules which are needed for WIFI. Panda board is compiled w/o WIFI, so there are no
wifi modules loaded. (After I load wl12xx_sdio.ko manually by using insmod, the wlan was functional!).
The solution IMHO must be, to compile an adapted CM9 with all hardware specific settings. Maybe the customized files can also moved inside the device configuration directory so that the merge script is obsolete (my hope).
So I decided to either to wait until JackpotClavin is posting his CM9 configuration files
Code:
http://forum.xda-developers.com/showpost.php?p=28439197&postcount=80
or to learn how to make a new device on CM which maches our Archos device. (Maybe someone else can give me some archos specific instructions).
Update: Great! JackpoClavin has provided sources =)
Hey!
I found this thread with fully compile-able code for android on most hardware platforms, I see it uses system level modifications to do its business, and would love to see it rolled into a magisk module. I regularly use external hard drives on my Pixel 2 XL for a plethora of reasons and really need legit exFat and NTFS support as I use flash kernel and I cant merge the code myself (my only machine couldn't handle the compiling). Anyway, If possible, making a ZIP that is universal and has the binaries for arm, arm64, and all x86 variants would be pretty great!
GitHub: https://github.com/Lurker00/Android-fs
XDA: https://forum.xda-developers.com/android/development/exfat-ntfs-fuse-drivers-easy-build-t3126413
I am not magisk-ninja so anyone who can help make this happen OR educate me in the process of doing so (and who can compile the above Git files for arm64 and send them to me) would be very much appreciated! I am willing to learn to help the community!
Over and out
thomasamas said:
Hey!
I found this thread with fully compile-able code for android on most hardware platforms, I see it uses system level modifications to do its business, and would love to see it rolled into a magisk module. I regularly use external hard drives on my Pixel 2 XL for a plethora of reasons and really need legit exFat and NTFS support as I use flash kernel and I cant merge the code myself (my only machine couldn't handle the compiling). Anyway, If possible, making a ZIP that is universal and has the binaries for arm, arm64, and all x86 variants would be pretty great!
GitHub: https://github.com/Lurker00/Android-fs
XDA: https://forum.xda-developers.com/android/development/exfat-ntfs-fuse-drivers-easy-build-t3126413
I am not magisk-ninja so anyone who can help make this happen OR educate me in the process of doing so (and who can compile the above Git files for arm64 and send them to me) would be very much appreciated! I am willing to learn to help the community!
Over and out
Click to expand...
Click to collapse
Hi. I just started working on this yesterday.
It seems like the perfect method to install additional filesystem support.
I am currently able to manually mount exfat or ntfs sdcard images on my phone (LG Aristo 2, Android 7).
However, a great deal has changed in how filesystem support is added to an existing kernel. Lurker00's code is for Android 4.4.2.
If you want to work together on it, I would be more than happy to do so. I will try to get together what I have so far in a post later today.
FYI, this is a TWRP installable .zip that has Lurker00's compiled binaries for arm64-v8a, armeabi-v7a, x86 and x86_64.
It also installs init.d scripts that supposedly support auto mounting of exFat and NTFS partitions. That part is not working for me, as I think it is setup for Android 5 and before. However the mount binaries work for manually mounting exFat or NTFS partitions.
Just install the .zip from TWRP.
https://forum.xda-developers.com/attachment.php?attachmentid=4600419&stc=1&d=1537390717
Hey! I just saw this, I can try my best but I was assuming it wouldn't be an android thing but rather a Linux/android kernel thing. Is there a way we can Abstract the mounting from android, solely into the kernel, basically leaving Android unaware that the introduced file system is not "officially supported"? I'm assuming FUSE can do this.
Edit: spelling.
tecknight said:
Hi. I just started working on this yesterday.
It seems like the perfect method to install additional filesystem support.
I am currently able to manually mount exfat or ntfs sdcard images on my phone (LG Aristo 2, Android 7).
However, a great deal has changed in how filesystem support is added to an existing kernel. Lurker00's code is for Android 4.4.2.
If you want to work together on it, I would be more than happy to do so. I will try to get together what I have so far in a post later today.
FYI, this is a TWRP installable .zip that has Lurker00's compiled binaries for arm64-v8a, armeabi-v7a, x86 and x86_64.
It also installs init.d scripts that supposedly support auto mounting of exFat and NTFS partitions. That part is not working for me, as I think it is setup for Android 5 and before. However the mount binaries work for manually mounting exFat or NTFS partitions.
Just install the .zip from TWRP.
https://forum.xda-developers.com/attachment.php?attachmentid=4600419&stc=1&d=1537390717
Click to expand...
Click to collapse
How exactly do you manually mount them? (your method)
Edit: also! I was thinking maybe this could become a kernel patch that I could alert kernel devs to? (see my above comment)
And... Thanks for all the hard work to get this going. Tell me how I can help!
thomasamas said:
How exactly do you manually mount them? (your method)
Edit: also! I was thinking maybe this could become a kernel patch that I could alert kernel devs to? (see my above comment)
And... Thanks for all the hard work to get this going. Tell me how I can help!
Click to expand...
Click to collapse
I installed the .zip file that I posted earlier using TWRP.
This installs these binaries to /system/xbin:
mount.exfat
mkfs.exfat
fsck.exfat
dumpexfat
exfatfsck
exfatlabel
mkexfatfs
mount.exfat-fuse
ntfs-3g
ntfsfix
probe
I then inserted an exFat formatted SDCard into my phone and Android told me the device was corrupt.
That is due to the fact that Android no longer uses probe to determine the filesystem of a device, it now uses a program called blkid.
I would like to figure out how to add a new supported filesystem type to blkid
In any event, I mounted my exFat sdcard by launching a shell from adb, running su to get root and then I created a folder named exfatsd in the /mnt folder. I then ran this command:
mount.exfat /dev/block/mmcblk1 /mnt/exfatsd
The mount succeeded and I was able to browse the sdcard from /mnt/exfatsd
When I typed mount to enumerate the mounts, this is the entry I saw for my sdcard:
/dev/block/mmcblk1 on /mnt/exfatsd type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
By the way, even as i was browsing the exfat sdcard, Android still had a notification up telling me that my sdcard was corrupt
Is there any legit documentation on blkid?
I haven't found any, but I haven't given up on this project either. I have been busy on a couple of other things lately, but I still would like to see this work.
Making progress on this on my LG cv1 ROMs
I just wanted to let you know that I now have exFAT and NTFS support working on my phone, even though the kernel does not have support for either filesystem..
I am mounting the Micro SD using a script that runs under Magisk from the:
post.fs.data.d folder
This folder contains scripts that are to run immediately after the /data filesystem is mounted.
My script is checking the Micro SD device using the blkid command.
The blkid command will indicate the type of filesystem residing on the device, even if the kernel won't mount it.
So I use the results from the blkid command to issue mount commands myself using the binaries created by lurker00.
Here is the script I am using, it is really quite short:
Code:
#!/system/bin/sh
#
# mount NTFS / exFAT
# 06/07/2019 by TecKnight
# This script checks the inserted Micro SD--
# If Micro SD is formatted exFAT or NTFS, it mounts it
sdcard_device=`blkid /dev/block/mmcblk1`
sdcard_part1=`blkid /dev/block/mmcblk1p1`
# Uncomment next 2 lines to troubleshoot
# echo $sdcard_device > /cache/sdcard_device.txt
# echo $sdcard_part1 > /cache/sdcard_part1.txt
# output from blkid command looks like this:
# /dev/block/mmcblk1p1: LABEL="e" UUID="CEDC-3F3A" TYPE="exfat"
# create mount point
mkdir /mnt/media_rw/extsd
# mount approriate filesystem if it resides on device directly
case "$sdcard_device" in
*exfat*) mount.exfat /dev/block/mmcblk1 /mnt/media_rw/extsd ;;
*ntfs*) ntfs-3g /dev/block/mmcblk1 /mnt/media_rw/extsd ;;
esac
# mount approriate filesystem if it resides on first partition of device
case "$sdcard_part1" in
*exfat*) mount.exfat /dev/block/mmcblk1p1 /mnt/media_rw/extsd ;;
*ntfs*) ntfs-3g /dev/block/mmcblk1p1 /mnt/media_rw/extsd ;;
esac
FYI: The reason I am checking /dev/block/mmcblk1 (the actual SD card itself) and dev/block/mmcblk1p1 (the first partition on the sdcard) is that depending on where the sdcard is formatted exFAT or NTFS, it could be on the disk itself or within a parrition. This way, I will catch it either way and mount it correctly.
I was thinking of creating a subroutine to cycle through the block devices to determine the sdcard device.
This would make it compatible with practically every device.
Then I could turn the whole thing into a Magisk module.
There are still 2 minor issues that I am having:
1. The phone still displays a notification about the sdcard being corrupt. You just have to clear the notification and it never reappears.
2. The mounted card is not identified as an external SD by android.
However, the exFAT or NTFS filesystem is mounted at /mnt/media_rw/extsd and is browseable and the filesystem is readable and writable.
Tell me what you think.
TWRP installable .zip to install NTFS/exFAT suport
OK, this is a installable .ZIP that will copy the binaries to /system/xbin and copy the mounting script to:
/data/adb/post-fs-data.d.
This should enable NTFS/exFAT support to most phones.
Requirements:
1. You must have Magisk installed
2. Your Micro SD''s device address must be:
/dev/block/mmcblk1. This is the case on most devices running Android 6 or higher.
If your Micro SD's device address is different, you can fix it by modifying:
/data/adb/post-fs-data.d/mount_ntfs_exfat.sh
replacing /dev/block/mmcblk1 with the device address of your external Micro SD.
Download the installer here:
https://forum.xda-developers.com/attachment.php?attachmentid=4773292&stc=1&d=1559992139
tecknight said:
OK, this is a installable .ZIP that will copy the binaries to /system/xbin and copy the mounting script to:
/data/adb/post-fs-data.d.
This should enable NTFS/exFAT support to most phones.
Requirements:
1. You must have Magisk installed
2. Your Micro SD''s device address must be:
/dev/block/mmcblk1. This is the case on most devices running Android 6 or higher.
If your Micro SD's device address is different, you can fix it by modifying:
/data/adb/post-fs-data.d/mount_ntfs_exfat.sh
replacing /dev/block/mmcblk1 with the device address of your external Micro SD.
Download the installer here:
https://forum.xda-developers.com/attachment.php?attachmentid=4773292&stc=1&d=1559992139
Click to expand...
Click to collapse
Hi,
I know this post isn't new, but I tried installing this zip file and it tells me that my bootloader in't unlocked even though I'm pretty sure it's unlocked,
any way around this?
rachelld said:
Hi,
I know this post isn't new, but I tried installing this zip file and it tells me that my bootloader in't unlocked even though I'm pretty sure it's unlocked,
any way around this?
Click to expand...
Click to collapse
Same here. Maybe the template is to old? Also could use this module.
aCIDsLAM said:
Same here. Maybe the template is to old? Also could use this module.
Click to expand...
Click to collapse
Try this one:
https://www.androidfilehost.com/?fid=4349826312261782012I removed the check for
ro.boot.bl_unlock_complete = true
---------- Post added at 11:08 PM ---------- Previous post was at 11:06 PM ----------
rachelld said:
Hi,
I know this post isn't new, but I tried installing this zip file and it tells me that my bootloader in't unlocked even though I'm pretty sure it's unlocked,
any way around this?
Click to expand...
Click to collapse
Try this one:
https://www.androidfilehost.com/?fid...26312261782012
I removed the check for
ro.boot.bl_unlock_complete = true
I could flash it, using TWRP. In Magisk itself, it told me me, its no magisk module. Anyway. Thanks!
@thomasamas
@tecknight
Is this thread dead ?
Has these drivers been tested on Android 11 ?
I have a custom ROM and would like to use my SDCard with NTFS/exFAT but the ROM only supports FAT32.
KineSight said:
@thomasamas
@tecknight
Is this thread dead ?
Has these drivers been tested on Android 11 ?
I have a custom ROM and would like to use my SDCard with NTFS/exFAT but the ROM only supports FAT32.
Click to expand...
Click to collapse
+1
tecknight said:
TWRP installable .zip to install NTFS/exFAT suport
OK, this is a installable .ZIP that will copy the binaries to /system/xbin and copy the mounting script to:
/data/adb/post-fs-data.d.
This should enable NTFS/exFAT support to most phones.
Requirements:
1. You must have Magisk installed
2. Your Micro SD''s device address must be:
/dev/block/mmcblk1. This is the case on most devices running Android 6 or higher.
If your Micro SD's device address is different, you can fix it by modifying:
/data/adb/post-fs-data.d/mount_ntfs_exfat.sh
replacing /dev/block/mmcblk1 with the device address of your external Micro SD.
Download the installer here:
https://forum.xda-developers.com/attachment.php?attachmentid=4773292&stc=1&d=1559992139
Click to expand...
Click to collapse
Actually, this still works! Have tested this on A11 OctaviOS GSI. You still need to have Magisk installed, but you don't necessarily have to install this as a Magisk module.
Don't flash the .zip file from TWRP, it doesn't do anything (at least not for me). Just unzip everything in the .zip file into a folder. Then, take the files inside the xbin folder and put it into /system/xbin (as per instructions). Make sure those files have execute permissions. I just set the xbin folder with full execute permissions and apply to all child files in the folder, by using Root Explorer.
Next, do the same thing by taking the script and chuck that into /data/adb/post-fs-data.d. Again, give this script full execute permissions.
Reboot phone and voila, it should work! You should also see that the script is loaded and running in Magisk logs.
Oh and the reason why Magisk is required is because Magisk creates that "post-fs-data.d" folder after it is installed. If you put scripts into /data/adb/service.d or /data/adb/post-fs-data.d, they will automatically get executed by Magisk and run with superuser rights.
chaoscreater said:
Actually, this still works! Have tested this on A11 OctaviOS GSI. You still need to have Magisk installed, but you don't necessarily have to install this as a Magisk module.
Don't flash the .zip file from TWRP, it doesn't do anything (at least not for me). Just unzip everything in the .zip file into a folder. Then, take the files inside the xbin folder and put it into /system/xbin (as per instructions). Make sure those files have execute permissions. I just set the xbin folder with full execute permissions and apply to all child files in the folder, by using Root Explorer.
Next, do the same thing by taking the script and chuck that into /data/adb/post-fs-data.d. Again, give this script full execute permissions.
Reboot phone and voila, it should work! You should also see that the script is loaded and running in Magisk logs.
Oh and the reason why Magisk is required is because Magisk creates that "post-fs-data.d" folder after it is installed. If you put scripts into /data/adb/service.d or /data/adb/post-fs-data.d, they will automatically get executed by Magisk and run with superuser rights.
Click to expand...
Click to collapse
Hello, I did everything as you said and it worked normally, but now SELinux is turned off. This is normal?
i have same issue. But i cant find xbin folder
my device is Samsung M51 on custom os
I converted this twrp zip into a magisk module https://github.com/phhusson/treble_experimentations/files/8948418/ntfs-exfat-support.zip
Hi.
I'm using Ancient OS A13 and I can't access my SD Card.It asks for format and after formatting it still asks for format.
it still works on my pc and twrp recovery. Unfortunately, this fix isn't working. Also, there is not any xbin folder in system.
What should I Do?