Database Develop

[MOD] Full Ubuntu on the Atrix (now fully automated: 4.1.26/4.1.52)

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

Webtop2sd

http://forum.xda-developers.com/showthread.php?t=1119555
Logically speaking, this application should also work with the Bionic correct?
Just wondering, if its deemed safe in this thread to attempt using, I will try it and post back with results.
---------- Post added at 12:30 AM ---------- Previous post was at 12:08 AM ----------
Okay, so I just backed up everything and tried the app, which won't work due to the fact that it checks the phone model number, Theres a manual guide to get ubuntu running on the atrix, and I'm going to start from scratch there. Probably going to be a couple of days before I do anything since I need a new microhdmi...

I tried the app that comes with it to partition the sdcard but it does a device check then it stops with an error message that the device is not an Olympus (Atrix). Maybe we can get the dev to check on the differences, albeit small, for the Atrix and the Bionic.
Worth a shot. I've been playing around with /osh for a few days but had to reflash to stock due to the lapdock staying on the screensaver.

Hey guys, I am working on the same thing at the moment trying to port over Sogarth's method of unlocking the 10.10 maverick build of Ubuntu on our phones.
http://forum.xda-developers.com/showthread.php?t=1000316
The link here is for his old automated .bat script he made for the Atrix that I believe will work for our phones with a little modification to it to reflect Maverick packages instead of the Jaunty packages for their phones.
Please jump into the irc in my sig because I would like to get this going as well.

I would hop in IRC but I'm about to head out the door.
I'm currently approaching this situation from two directions:
1.) I'm dumping /osh/ (webtop partition) and uploading it to dropbox as soon as I can get a complete dump. (hopefully tonight) and providing it to the original Atrix dev to see if he can hook us up with an app to help do whats needed
2.) I'm also attempting the manual method as soon as I get a new microHDMI cable (I was using a cheap adapter).
You are 100% correct though, you should be able to get that install script working just by changing the packages to reflect the updated Ubuntu. MAKE SURE you backup ANY files before you change them (and preferably a complete backup of /osh/. Since we have SU on our phones we have free reign over the /osh partition, so be careful in there.
OT: I can't wait until we can get on-demand CPU overclocking for this thing... if it clocks as well as past mobile chips... Toggle 1.2-1.4ghz and plug it in the LapDock. You'd have a damned fine netbook...
(Not necessarily talking to any experienced users or noobs, the disclaimer about Linux & SU is for everyone reading this thread - I'm relatively experienced in the Linux world... and I need to be reminded of SU's power sometimes.)
I just realized that their phone's Ubuntu distribution is under the 9.x series versus the 10.x series. A lot of Major changes happened to Ubuntu between 9.x and 10.x that affected the way the operating system talked to devices and booted, they stopped using HAL and moved to a new boot method, I am uncertain whether or not the install script will work or not, though I'm somewhat confident it will, given the nature of webtop (Android does the hardware abstraction, and the booting, we just run a second set of executable's on a different X window session attached to a different display) This should mean that the portions that would normally prevent us from just duplicated the script are omitted from the Ubuntu distribution entirely. As long as we keep a backup we should still be fine.

No worries, just remember to keep FXZ and RSD handy. I've screwed up the /osh partition a couple times but that has saved me from complete disaster so far

Good call on bringing this up. Let me know if you need to test anything for this.

@xaero252
So I modified Sogarth's script to use Maverick build of all the tools it downloads and installs but the problem with the script is that it needs the phone to have the ro.secure=0 so that ADB always launches with root access without manually initiating su each line of code. I am not sure if there is a way around it or if we have to modify the script differently. Anywho, I've upload a copy of the work I've done to the script.

Is it just an sh script? If so and ut doesn't reboot the phone at all you could launch a SU terminal and do "su sh script.sh"
oh i see the issue now... we would have to be able to edit the boot loader for that method... if i'm correct though his android app doesnt use the pc for much... if you change that variable on boot do you think it woukd work?
Hmm, I have an idea, its not as polished as the pc based script, however it should still work presuming you can get a SU terminal to run on the phone ( I happen to have one running right now ) I'm going to see if I can't adapt that to a bash script. probably going to take a while.
Curiously we happen to have a 1.5gb partition for Ubuntu on built in memory, where as the atrix only had a 600 or so mb partition... This is great because we should likely be able to continue to install /, /boot and such to internal memory, and use the sd card (even left as ntfs) for /home...
Couple of things: reading through the script it looks like 100% of the commands he runs could be run on the phone via a bash script run as su. The idea is this: convert the entire script over to bash, copy the script, and the required files to the phone, and execute the script from the phone. The only other concern I can see is the wget package included with the script not being compatible with maverick, which doesn't seem likely.
I'm gonna start working on rewriting the script linux native. My idea is to use a terminal emulator (they are free on the market) and run su script.sh and pray. I need to get a new microHDMI before I do this though, so I can test my results reliably.

xaero252 said:
Is it just an sh script? If so and ut doesn't reboot the phone at all you could launch a SU terminal and do "su sh script.sh"
oh i see the issue now... we would have to be able to edit the boot loader for that method... if i'm correct though his android app doesnt use the pc for much... if you change that variable on boot do you think it woukd work?
Click to expand...
Click to collapse
As far as correcting that, no one has attempted doing custom kernels yet so to do the edit to get root access out of the gate is moot at this point.
Hmm, I have an idea, its not as polished as the pc based script, however it should still work presuming you can get a SU terminal to run on the phone ( I happen to have one running right now ) I'm going to see if I can't adapt that to a bash script. probably going to take a while.
Click to expand...
Click to collapse
Your linux skills are probably 10 folds better than mine but I believe if you convert my modified script, which has all the necessary links to the correct packages for our phone, then it might just work.
Curiously we happen to have a 1.5gb partition for Ubuntu on built in memory, where as the atrix only had a 600 or so mb partition... This is great because we should likely be able to continue to install /, /boot and such to internal memory, and use the sd card (even left as ntfs) for /home...
Couple of things: reading through the script it looks like 100% of the commands he runs could be run on the phone via a bash script run as su. The idea is this: convert the entire script over to bash, copy the script, and the required files to the phone, and execute the script from the phone. The only other concern I can see is the wget package included with the script not being compatible with maverick, which doesn't seem likely.
Click to expand...
Click to collapse
The WGET I packaged in the .zip is the correct for Maverick along with all the files in the \bin directory are corrected to match our phone. If you can convert all this to a bash script, that would be awesome instead having to do each command via ADB Shell. The only problem I had with this is every time I tried to run the DPKG command on the .deb I downloaded manually, it threw up an error saying it could not find the file or destination.
On a side note, you are correct that we have 1.5gb partition opposed to their 700mb so we could honestly forget the part about creating a ubuntu.disk on the /data partition and modify the /osh directly for now until the time we need more space. After that, we can see if Sogarth will incorporate your script into his Webtop2sd app or we could make a 3gb ubuntu.disk on the /data partition since we have plenty of space there.
I'm gonna start working on rewriting the script linux native. My idea is to use a terminal emulator (they are free on the market) and run su script.sh and pray. I need to get a new microHDMI before I do this though, so I can test my results reliably.
Click to expand...
Click to collapse
Make sure you get the adapter as well to trigger Webtop cause at the moment our phone wont do webtop directly over HDMI without the HD Dock, Webtop adapter or Laptop dock. If you want to test the script out for now, hit me with the script and I will test it for ya

[Q] Can I install ClockworkMod on the P970g without proprietary software?

I'm trying to help the Replicant project (see redmine[dot]replicant[dot]us for more information) by porting their system to the Optimus Black, and I've just secured myself a P970g, but I'm having trouble installing CyanogenMod 10.0 (a prerequisite). For example, fastboot and adb don't seem to detect the phone; ./fastboot devices doesn't show anything.
The Replicant project is rather picky about the flashing tools they use; they need to be executable on GNU/Linux (which I'm using) and they need to be free software (licensed under the GNU General Public License, or any license that gives the freedoms of use for any purpose, distribution, and/or modification). I have the SDK installed; that's free software. Any software I run on the phone is fine, as long as it's either free and open-source, or the phone can be changed without proprietary software once the process is complete.
So, is there a way to install ClockworkMod on the P970g from my GNU/Linux computer without running proprietary software on it? All of the installation instructions I've seen so far appear to require it.

first, p970 has not been designed to work with fasboot. it works only in flash mode. for adb side, it needs to boot. second, I don't really understand your request because both twrp and cwm are open source so you can compile them from source. from my side, I made a cwm and a twrp flasher package as well for installing one of them easily. The compiler I've used is NSIS (open source too).
my question is, what's the problem ?

I made a cwm and a twrp flasher package as well for installing one of them easily. The compiler I've used is NSIS (open source too).
Click to expand...
Click to collapse
This may be useful. But are the packages themselves free software? If you don't explicitly license them under a free software license (http colon slash slash www dot gnu dot org slash licenses slash license-list dot html) and release the source code, then the Replicant project can't use them. If you have done this, I would appreciate it if you could point me to the download link for these packages.

you know, I don't have much knowledge about licensing, but in that case I don't think it needs any license. What I've made are simple containers with basic instructions. There is no any commercial purpose, restriction or anything else like that, because it's all about contributing freely. I mean, without any kind of charge. You can use or redistribute them, rightly because it's totally free. The source code of my work will be useless here, except if you plan to recompile for your needs. Everything can be done manually or in other ways. Note that the packages are for Windows. 7zip can be used to explore their containing.
http://forum.xda-developers.com/showthread.php?t=1111771
if you want, I can provide you the commands for flashing correctly

I actually do hope to recompile this program for my needs and would very much like to see the source code. You see, the Replicant project prefers that flashing tools support GNU/Linux. If you released the source code under an appropriate license, we could perform the porting and work from there.
You say you don't know so much about licensing? It's actually rather simple: if you decide to release the source code, just put this text as a LICENSE.txt file into the top directory of the repository:
Code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

okay, I'll be glad to help your project, but know that NSIS is script based, it's not really coding so I'm not sure if simple script based instructions could be considered as a true source code... you won't be able to recompile as it simply won't work under any linux environment. Although NSIS can be compiled for POSIX platforms, it's still in order to build Windows packages. This is why I proposed to share the commands (they are available around internet though). The main tasks of my packages is to apply known Windows commands with just a few clicks. In other terms, these are setup packages (like Inno etc..).
Just extract an img recovery file and apply proper commands for flashing, simple as that.

Never mind that; our problem is actually semi-solved. Are you the developer of BlackJack? Because that's where we need the source code noq.

yes but the exploit isn't from me. blackjack is obsolete for gingerbread and over, and I'm not a developer
Made in ZR

You see, we've figured out a way to install ClockworkMod using only free and open-source tools. But the device needs to be rooted for it to work. Of course there's a rootkit available for Gingerbread, but our users may be running Froyo, as my phone is. So, we'd still be very happy to see its source code. But it complicates things if you're not the author of the exploit. Do you know who did create it, so we can contact them?

sure, it's written by Scott Wlaker. His twitter and mail (he doesn't seem being registered on xda so I couldn't find him here)

I'm confused. It seems if you install ClockworkMod on a stock phone that you'll get a security error. See thread number 2094640.
Anyways, let me rephrase: I'm looking for a way to install CyanogenMod on a P970g running Froyo that doesn't use proprietary software. (You said you were the developer of Blackjack; even if you could just point me to the front-end code that'd be great.)
Who is the creator of SmartFlash? That could be even more useful if we could obtain its source code.

Roller_REP said:
I'm confused. It seems if you install ClockworkMod on a stock phone that you'll get a security error. See thread number 2094640.
Anyways, let me rephrase: I'm looking for a way to install CyanogenMod on a P970g running Froyo that doesn't use proprietary software. (You said you were the developer of Blackjack; even if you could just point me to the front-end code that'd be great.)
Who is the creator of SmartFlash? That could be even more useful if we could obtain its source code.
Click to expand...
Click to collapse
You get a security error if you install CWM recovery over LG's official Ice Cream Sandwish ROM, as it has a locked bootloader. This is not a problem for both Froyo and Gingerbread stock ROMS, as they have unlocked bootloader.
About SmartFlash, I don't know. I always thought it was a LG tool.
For ICS (not for Froyo/Gingerbread), this might help:
http://forum.xda-developers.com/showthread.php?t=2160394

Roller_REP said:
I'm confused. It seems if you install ClockworkMod on a stock phone that you'll get a security error. See thread number 2094640.
Anyways, let me rephrase: I'm looking for a way to install CyanogenMod on a P970g running Froyo that doesn't use proprietary software. (You said you were the developer of Blackjack; even if you could just point me to the front-end code that'd be great.)
Who is the creator of SmartFlash? That could be even more useful if we could obtain its source code.
Click to expand...
Click to collapse
As said before, you probably bricked your device after having missed something.
And you're still wrong. I'm not a developer, and never claimed it anywhere. I repeat, my packages are script-based so useless for linux. Smartflash originally needs 3 files to run, but I packed it into an autonomous exe (this version is only available in UPK). This tool is a leak from LG and wasn't destined to the public. It's of course, copyrighted, and there si actually NO other way for unbricking a hard bricked device.
What's required for running the exploit :
ADB
Superuser.apk
su (binary)
bysybox (binary)
sqlite3 (binary)
psneuter exploit (binary)
Superuser from Clockworkmod is open source (not used in blackjack).
Here are the Windows batch cmds for running the exploit properly :
Code:
Reseting server
---------------
adb kill-server
adb start-server
Waiting for device
------------------
adb wait-for-device
Pushing files
-------------
adb push files\busybox /tmp/
adb push files\psneuter /tmp/
adb push files\sqlite3 /tmp/
adb push files\su /tmp/
adb push files\Superuser.apk /tmp/
Running exploit
---------------
adb shell "chmod 0755 /tmp/psneuter"
adb shell "chmod 4755 /tmp/psneuter"
adb shell "/tmp/./psneuter"
[COLOR="Red"]# AT THIS POINT AN EXTERNAL INTERVENTION IS NEEDED FOR RESTARTING ADB (IT'S BASICALLY DESIGNED FOR HTC DEVICES)[/COLOR]
Mounting system
---------------
adb shell "mount -orw,remount -t ext3 /dev/block/mmcblk0p8 /system"
Applying root privileges
------------------------
adb shell "cat /tmp/busybox > /system/bin/busybox"
adb shell "cat /tmp/sqlite3 > /system/bin/sqlite3"
adb shell "cat /tmp/su > /system/bin/su"
adb shell "cat /tmp/Superuser.apk > /system/app/Superuser.apk"
adb shell "chmod 4755 /system/bin/su"
adb shell "chmod 4755 /system/bin/busybox"
adb shell "chmod 4755 /system/bin/sqlite3"
Rebooting
---------
adb reboot
Killing server
--------------
adb kill-server
Remember that this works only for Froyo.

I asked you "Are you the developer of BlackJack?" And you said "yes but the exploit isn't from me."
But thank you very much! As soon as I can find those files, that solves my problem. However, I can't see them in your upgrade kit...

Ilko said:
yes but... I'm not a developer
Click to expand...
Click to collapse
good luck
Made in ZR

S-off with Firewater

Another S-Off script that was sent to me by coremark. Successfully s-off my device and supercid.
http://firewater-soff.com/
Thanks to @coremark.

After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?

edorner said:
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
Click to expand...
Click to collapse
I'm afraid you'll need a custom recovery for this. The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this. To work around it, you'd need a custom kernel (which is not feasible at the moment since HTC haven't released the full source tree yet, unfortunately) or the wp-mod hack (which I would be afraid of using, to be honest).
Also, why avoid custom recovery when you're already S-OFF and you can flash the stock recovey anytime?

koniiiik said:
The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this.
Click to expand...
Click to collapse
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?

edorner said:
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Click to expand...
Click to collapse
To be honest, no idea. All I do know is that on my phone the write protection works the way it does and I don't really see a feasible way around it. Also, I haven't tried these exact steps. It's possible that adb remount does some extra work or something. Moreover, I'm not sure about the adb shell chmod ... command – that would require root, wouldn't it? But since I haven't tried it, I can only guess.
If you don't mind trying it, I'd be interested in the results.
edorner said:
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
Click to expand...
Click to collapse
The way I understand wp_mod works is that it monkey-patches the running kernel's filesystem driver to skip the check for the /system partition. In other words, it rewrites the code of the running kernel in-memory. This by itself is reason enough to be extremely careful around such code as it has potential for a major disaster. Missing the right memory location by any nonzero number of bytes can result in the kernel doing practically anything (most likely a crash).
Now, to make matters worse, these seem to be only a few binary versions of the kernel module and people seem to just take a binary compiled for one kernel, modify the version information within the file to make it match other kernels and load it on a completely different kernel. This, to me, is borderline insane, considering that the kernel binaries depend on the version of the kernel, used compiler and even compiler flags used when building.
Again, though, I haven't actually looked at the module's source code; can't say I'm suffering from a surplus of free time and I'm also not *that* interested in it. Most likely it's written in a robust enough way to have a high chance of success. (This seems to be backed up by anecdotal evidence – the thing appears to work for people, which is a small wonder for me.) All of the above is actually just my interpretation of stuff I read in some threads here on XDA-developers and I haven't even tried to confirm it myself.
Still, for me, using the recovery for any such changes is a sufficient and acceptable workaround, since I don't need to modify /system that often.

Wow! Thanks for the exhaustive expanation about WP-mod!
If you don't mind trying it, I'd be interested in the results.
Click to expand...
Click to collapse
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.

edorner said:
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
Click to expand...
Click to collapse
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.

koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
Ah, I see. In that case I will definitely try it!
Truth is I am still an Android noob, I used ADB maybe on two occasions so far, and did not have the time yet to properly check out the documentation for these particular commands.
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?

edorner said:
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
Click to expand...
Click to collapse
No idea, I haven't used firewater, but my guess would be that it won't wipe anything…
As for backing up /data/preload, you can for example use temproot to get access to the directory, copy it somewhere on your sdcard and adb pull it. In case it gets wiped, you can just push it back again and voilà. It's going to require some shell-fu, however.
Alternately, you can just download my ZIP of the latest stock ROM and extract it, it contains the latest /data/preload.
And yes, just copying the APK files into /data/preload should suffice *– Dalvik and its package manager is intelligent enough to detect something has changed in there and perform any installation steps necessary. If it doesn't work right away, a reboot should fix things.

Edorner. It won't wipe. I tried it already.
Sent from my GT-I9305 using XDA Premium 4 mobile app

koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.

edorner said:
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
Click to expand...
Click to collapse
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.

koniiiik said:
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
Click to expand...
Click to collapse
Thanks
Hm... Strange...
Instead of manually remounting /system as "ro", I simply rebooted the device. (What can I say, I am hopelessly lazy ) After the reboot I checked the permissions of /system by issuing the "mount" command without any parameters. It showed that it was remounted using the original settings:
Code:
/dev/block/mmcblk0p38 /system ext4 ro,noatime,data=ordered 0 0
So in theory, rebooting instead of manually remounting as "ro" should not make any difference. But who knows
After the reboot, I checked the changes I made to /system previously, and fortunately they did not disappear. (su was still there, I could successfully copy it, and execute it.)
Since then, I've performed a couple more reboots and at least one full shutdown-startup cycle as well. And I still have not lost any changes.
Please let me know if you find something out! I am very interested.

A pure C implementation of 'cuber' using OpenSSL's BigNum library

In case anybody cares, here's a pure C reimplementation of 'cuber.py'
(my own earlier reimplementation of @vortox's signature.py).
This is what I'm using in my '1-Click' bootloader unlock VM...
See 'grep ^gcc' for "build instructions".
Hack, you can probably build this for ARM and run it right on your very HDX tablet... (-;
UPDATE (JanuaryFebruary 2017):
OK; so, @zivimo had built this for ARM, but people still haven't noticed.
I repacked his binary from a .tar.gz to a .zip archive and decided to spell out the instructions for use.
Perhaps, this helps... With the right bootloader in place, and adb/fastboot installed (and working),
the unlock is as easy as follows...
Download and extract unlock.zip (SHA256: e40e3010f8eccfa9cbd1e73eecac30cf799099d183de23b2d256fc3407f143f6e5db0b8d82c8fd2a25a22b0a598014d22a2ec33cef27a8d4b65a36acde08f27a)
to the same directory that holds the adb and fastboot executables (unless you have added them to your PATH)
Click on get_code.bat in the extracted folder
-- optional (but commonly required) step(s) --
fix root (roll back, if you need to), flash vulnerable bootloader
[you'll definitely need to perform at least some of these if the last step fails]
Click on unlock.bat in the extracted folder
The archive also includes .sh variants of the .bat files for convenience.
You could also just click to show the hidden section and cut&paste... (-;
Code:
[STRIKE]unzip cuber.zip[/STRIKE]
adb push cuber /data/local/tmp/
adb shell chmod 0755 /data/local/tmp/cuber
adb shell 'id=$(cat /sys/class/block/mmcblk0/device/{manfid,serial}); echo "$id"; echo 0x${id:6:2}${id:11:8} | /data/local/tmp/cuber > /sdcard/unlock.code'
adb pull /sdcard/unlock.code
adb shell rm /sdcard/unlock.code /data/local/tmp/cuber
adb reboot-bootloader
fastboot -i 0x1949 flash unlock unlock.code
NOTE: download and extract the attached 'cuberunlock.zip' and run the above commands
in the directory where 'cuber' got extracted to.

Nice job! Originally I wanted to use OpenSSL BigNum too, but I hadn't enough time and Python was easier to use

hey,
made a static compile with an arm debian (jessie). seemed the easiest solution to me. compile command:
Code:
# gcc -fPIE -static cuber.c -o cuber -lssl -lcrypto
# strip cuber
# ldd cuber
not a dynamic executable
# ./cuber
Usage: cuber [RSA-bytes] < data > sig
seems to work. arm(!) binary attached.

ok draxie, you pointed me here but something seems to be missing. i downloaded unlock.zip, put the files in my adb directory. when i run get_code.bat, it pushes cuber to the kindle in the right directory, changes permissions (dont see any errors there) but then stops saying the system can't find the specified path. Whats funny is i used es file explorer to check the paths in the script, and they are there so not sure where the hang up is.

chin_bone said:
ok draxie, you pointed me here but something seems to be missing. i downloaded unlock.zip, put the files in my adb directory. when i run get_code.bat, it pushes cuber to the kindle in the right directory, changes permissions (dont see any errors there) but then stops saying the system can't find the specified path. Whats funny is i used es file explorer to check the paths in the script, and they are there so not sure where the hang up is.
Click to expand...
Click to collapse
Did you check all three paths?
/data/local/tmp
/sdcard
/sys/class/block/mmcblk0
The 2nd one _may_ be problematic if you're on SafeStrap.
I don't know why. I'm yet to install that on one of my test
devices to investigate. (Or, was that the 1st... )
The 0 in the 3rd one may actually be a 1 on some systems.
I have a few extra lines in my VM script to work around
that, I can easily add that here as well, if that turns out
to be the issue.
BUT, to try and troubleshoot: how far does the script get?
If it didn't complain with the permissions, the 1st path is probably OK.
Does it print your manfid/serial?
If so, mmcblkX would be right as well.
Any chance that you're on SafeStrap?
Can you push/pull to/from /sdcard?
- - - - -
On a second thought: I've only ever tested this on Linux.
String quoting on Windows may work differently, and could *royally* mess up how that more complex command is interpreted.
I'll test tomorrow; it's like 20 past 1am here. I need to get some sleep.
In the meantime, as a workaround, you could just hard-code your manfid/serial, and replace this line:
Code:
adb shell 'id=$(cat /sys/class/block/mmcblk0/device/{manfid,serial}); echo "$id"; echo 0x${id:6:2}${id:11:8} | /data/local/tmp/cuber > /sdcard/unlock.code'
by the decidedly much simpler:
Code:
adb shell 'echo 0xmmssssssss | /data/local/tmp/cuber > /sdcard/unlock.code'

draxie said:
Did you check all three paths?
/data/local/tmp
/sdcard
/sys/class/block/mmcblk0
The 2nd one _may_ be problematic if you're on SafeStrap.
I don't know why. I'm yet to install that on one of my test
devices to investigate. (Or, was that the 1st... )
The 0 in the 3rd one may actually be a 1 on some systems.
I have a few extra lines in my VM script to work around
that, I can easily add that here as well, if that turns out
to be the issue.
BUT, to try and troubleshoot: how far does the script get?
If it didn't complain with the permissions, the 1st path is probably OK.
Does it print your manfid/serial?
If so, mmcblkX would be right as well.
Any chance that you're on SafeStrap?
Can you push/pull to/from /sdcard?
- - - - -
On a second thought: I've only ever tested this on Linux.
String quoting on Windows may work differently, and could *royally* mess up how that more complex command is interpreted.
I'll test tomorrow; it's like 20 past 1am here. I need to get some sleep.
Click to expand...
Click to collapse
It's all good draxie, i figured out what i was doing wrong with the other procedure, that damn STEP 2, once i did it, everything fell into place. Bootloader unlocked and now just trying to figure out which rom to try first. Thanks again, you guys are great and i know how valuable everyones time is. :good:

I keep hitting road blocks, I am rooted and on Fire OS 4.5.5.2 I click get code a screen flashes up then I click Unlock and my Kindle boots to the Grey Kindle screen with Fastboot underneath and nothing else happens. Same happens when I copy and past the code into ADB. What step am I failing at? Thanks for the help!

pdanforth said:
I keep hitting road blocks, I am rooted and on Fire OS 4.5.5.2 I click get code a screen flashes up then I click Unlock and my Kindle boots to the Grey Kindle screen with Fastboot underneath and nothing else happens. Same happens when I copy and past the code into ADB. What step am I failing at? Thanks for the help!
Click to expand...
Click to collapse
@draxie - I have no experience with this tool; python/gmpy2 works reliably for me. Sorry to pull you in ...

Davey126 said:
@draxie - I have no experience with this tool; python/gmpy2 works reliably for me. Sorry to pull you in ...
Click to expand...
Click to collapse
I am up and running now, unlocked and running kk-fire-nexus-rom-thor-20161017. Play store is also up and running.

pdanforth said:
I am up and running now, unlocked and running kk-fire-nexus-rom-thor-20161017. Play store is also up and running.
Click to expand...
Click to collapse
Did you end up using some other method, or did these scripts work for you in the end?
Either way, others may find useful if you could share whatever worked for you. (-;
Unfortunately, I still haven't had a chance to test these scripts in Windows;
so, I couldn't answer your first call for help in a good way. If there's something
wrong and there's enough interest, I'll be happy to fix it as soon as I can.

draxie said:
Did you end up using some other method, or did these scripts work for you in the end?
Either way, others may find useful if you could share whatever worked for you. (-;
Unfortunately, I still haven't had a chance to test these scripts in Windows;
so, I couldn't answer your first call for help in a good way. If there's something
wrong and there's enough interest, I'll be happy to fix it as soon as I can.
Click to expand...
Click to collapse
@stangri did my unlock file and I used this thread to unlock https://forum.xda-developers.com/kindle-fire-hdx/general/thor-unlocking-bootloader-firmware-t3463982
I had trouble making the Unlock file, once that was done and some help from other users I am now up and running!