----- 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.
Related
So you've rooted your phone, hacked your webtop, but then you realize that your Ubuntu doesn't have ssh. Wait, what? What the hell is *nix for if you don't have ssh?!
Time to fix that.
Based upon the existing packages, the Ubuntu installation is Jaunty/9.04. In this case, the packages to install for clean dependencies are these:
libedit2
openssh-client
passwd
For each package, you want to download the package that's listed as Published to /mnt/sdcard-ext (before you complain that I'm using old packages, when starting up, I prefer to have a consistent OS, rather than picking and choosing packages from several different versions).
Installation ended up being simpler than I expected, although I ended up remounting /mnt/sdcard-ext as /osh/mnt/sdcard-ext so that I could have a decent work area in my chroot. Here were the commands I used (including the remount) after downloading the three .deb files into /mnt/sdcard-ext:
Settings→SD card & phone storage→Unmount SD card
From the Android terminal:
su
mkdir /osh/mnt/sdcard-ext
mount -t vfat /dev/block/vold/179:33 /osh/mnt/sdcard-ext
From LXTerminal:
sudo chroot /osh
dpkg -i *.deb
exit
Settings→SD card & phone storage→Mount SD card (this will forcibly unmount the SD card from the other directory and mount it in the normal directory)
Congratulations! ssh has just been installed.
Is this the process people are using to install other. deb packages? Apt-get isn't working for me.
Sent from my MB860 using XDA App
edounn said:
Is this the process people are using to install other. deb packages? Apt-get isn't working for me.
Click to expand...
Click to collapse
I'm actually not sure what other people are doing.
Personally, I'm reluctant at the moment to use the second-layer package management tools, since there really isn't much free space in /osh, and I'd rather not trigger a domino effect of package installation by accident. As such, I'd prefer to be a lot more precise in what packages I'm installing.
Besides of which, the custom Motorola Ubuntu packages do cause some issues. For example, they shipped a version of Awn that normally ships with Ubuntu 9.10, so it's difficult to touch (if you want to go back to that version but stock, it starts an upgrade loop that becomes difficult to manage). But, you can try setting your depot to launchpad.net, which might work out for you.
some static linked binaries i built
I built a few static binaries today as I too don't really want to screw with trying to force some packages in alongside the base system.
I included a tarball (seems like the forums won't take a tar.gz) with scp, sftp, ssh, and wget in it. They are all static linked arm binaries so you shouldn't have any dependency issues. They're not built with anything special, I just grabbed the latest openssh and wget and built them.
I've only tested the ssh and wget, but I would assume that both scp and sftp also work. If there is enough interest I can post the rest of the openssh suite, I got the entire suite to build (didn't test it though).
Let me know if things work, I may build other things as a bunch of static linked binaries, or just setup a chroot to run more stuff from the webtop.
If anyone is looking for an SSH daemon on the android side of the device, this is an excellent guide to do it:
http://teslacoilsw.com/dropbear
Also, I've uploaded the compiled binaries for 2.2.1 (Dropbear Telsa v0.52) and the stock ssh client that comes with the android 2.2.1 SDK (Dropbear v0.49)
would this help with xsession i.e. ssh -X [email protected]
I believe xauth is all you need for X11 forwarding via SSH, and that's included in the webtop os.
Hi all -
I wrote a script and created a CWM update-flashable to perform a one-line install of the CM7 GPS Fix, documented here by jwleonhart. There were some complaints about jwleonhart's install instructions; it's a bit cumbersome and not trouble-free, especially for noobs. Please read the original thread for detailed instructions on what my script does; the script exactly does jwleonhart's instructions.
NOTE: EVERY VERSION OF THIS FIX MAKES SUBTLE BUT IMPORTANT CHANGES THAT MAY IMPROVE OR DEPRESS YOUR GPS FUNCTIONALITY. UNTIL A TRUE GPS DRIVER DROPS FOR THE VIBRANT (which at this point seems very unlikely) ALL WE CAN DO IS HACK AND TWEAK. NEWER VERSIONS MAY WORK BETTER OR WORSE THAN OLDER ONES! PLEASE POST WITH YOUR EXPERIENCE USING THE VARIOUS VERSIONS OF THE FIX, AND PLEASE BE CONSTRUCTIVE/HELPFUL WITH YOUR FINDINGS!
There are three separate ways to install: CWM, CWM with no gpsd, and via shell script.
CWM Installation
The easiest way to install the GPSFix files is to download and flash Vibrant_CM7_GPSFix_V1.4-CWM-signed.zip. All files will be copied over and read/execute permissions will be properly set.
NOTE: Flashable does NOT contain AngryGPS. There are some people who have better results without it, so I'll let you install that one on your own. You can find the APK at jwleonhart's CM7 Install Guide.
OPTIONAL: There's a no-gpsd version of the CWM flashable as well - if you want to use the gpsd from your current nightly, or mix and match. The GPS driver might get better in time, and who knows if down the line the gpsd bundled with the latest nightly is better than this one, pulled from Trigger Redux#13 (CM7 Nightly#54).
Script Installation
The script is available for users who want to customize their own GPS fix. It requires an extra reboot (since you can't just run the script after installing a new nightly), but you can easily add/remove files to the script to suit your own needs. Personally, I use the script to test new versions before they go into the CWM flashable.
Attached is the zip file with all the files and the shell script you need. Just extract the folder to your SD card; then in a terminal (ADB or terminal emulator with root), run these commands:
Code:
su # if you're not already dropped into superuser status
cd /sdcard/GPSFix
bash GPSFix.sh
It will automatically copy all the files (gpsd, secgps.conf, gps.conf, 90getgps_lto) to the right places, then set permissions those files, then reboot. AngryGPSmod.apk is in there but is not installed; I suggest try the GPS fix without AngryGPS first, then install it after if you don't get good results.
Script Contents
For those interested, here's the contents of the script..
Code:
#!/system/xbin/bash
FIXFILES="/system/etc/gps.conf
/etc/init.d/90getgps_lto
/system/vendor/bin/gpsd"
REMOVEONLY="/data/gps/lto.dat
/data/gps/lto2.dat
/data/gps/svstatus.txt
/data/gps/ltoStatus.txt
/data/gps/secgps.conf
/system/bin/agpsd"
mount -o rw,remount /system
echo "==================================================="
echo "======Vibrant CM7 GPS Fix One-Command Install======"
echo "=================by strictlyrude27================="
echo ""
# Delete previous fix files
echo "Deleting previous fix files..."
for file in $FIXFILES $REMOVEONLY
do
if [ -f $file ]; then
rm $file
fi
done
# Copy new files and set permissions
echo "Copying new files over..."
for file in $FIXFILES
do
fname=$(basename $file)
cp $fname $file
chmod 0755 $file
if [ $file == "/system/vendor/bin/gpsd" ]; then
chgrp shell $file
fi
done
echo "Rebooting device.. Enjoy GPS!"
echo "Install AngryGPSmod.apk manually if you want to."
echo ""
reboot
Credits
jwleonhart - writing up the CM7 install guide
roffee - finding the original GPS Fix for CM7
jad3675 - providing original Long Term Orbital download script
PLEASE go to their threads and hit their Thanks button. They did all the heavy lifting, I just packaged up their findings and work into a simple-to-use flashable.
"If I have seen far, it is because I have stood on the shoulders of giants."
--Isaac Newton
Changelog:
Code:
V1.5.1
-- renamed init-script to overwrite CM7's implementation of V3 of this fix
-- now offering "newgpsd" variant - contains gpsd from latest CM7 nightly
-- standard zip: faster locks, but more prone to randomly quitting working
-- newgpsd variant: slower locks, but more resilient GPS indicator [color="red"] still needs testing[/color]
V1.5
-- cleaned up script
-- now keeping LTO data named lto2.dat (used to rename to lto.dat)
-- lowering threshold for lto2 refresh to 3 days
V1.4 (all variants)
-- replaced lto.dat with lto2.dat - preliminary testing indicates survival after reboot and better TTFF
-- now using us.pool.ntp.org for the time server - if you're not in the US, please adjust your gps.conf accordingly
-- gps.conf tweaks - trading accuracy for TTFF for now..
V1.3.1 (all variants)
--set permissions on downloaded lto.dat to 755 (was 644) - i couldn't get
any birds in view before, now i can lock. give this a try if 1.3 doesn't work.
V1.3 (all variants)
--removed agpsd
--added 90getgps_lto - will fetch latest long term orbit data on boot
--hopefully these changes help get REPEAT locks faster - please let us know!
V1.2CWM-nogpsd
--same as V1.2CWM, but with no gpsd. This way you can use gpsd from
the latest CM7 nightlies, or whatever nightly gpsd worked best for you.
I will start collecting gpsd files and posting them for your convenience soon!
V1.2CWM
--created CWM flashable for your convenience! performs the EXACT SAME
as the script, so if you've already run V1.2, no need to flash V1.2CWM.
But, it could be useful if you tend to flash nightlies all the time.
V1.2
--changed all file permissions to 0755 - not sure how reading .conf files
worked if there wasn't any read permission. gets me a faster lock after
applying the script.
V1.1
--fixed typo - "chmod shell" should have been "chgrp"
--removed \t, \n - was not being interpreted by shell correctly
V1
--initial release
If I helped you with your CM7 experience, please hit the Thanks Button
im about to try this
Dear all -
Script was updated to V1.2. I noticed that no read permissions were set to the .conf files; my thinking is there's no way Android could read those config files without read permissions, so they weren't even doing anything.
That said, the latest script now gives permission 0755 (rwxr-xr-x) to all files. After running the script now, I get a lock after first reboot in about 25 seconds.
You can download V1.2 and start from scratch, or just copy/paste the latest script contents into your GPSFix.sh. Or, run the following commands at a terminal (ADB or terminal emulator with root):
Code:
su
mount -o rw,remount /system
chmod 0755 /data/gps/secgps.conf
chmod 0755 /system/etc/gps.conf
chmod 0755 /system/bin/agpsd
mount -o ro,remount /system
reboot
Also, I noticed 31 downloads (and there were 20-some in the original post) but only a total of 3 Thanks.. I'm kind of addicted to the Thanks button and don't ask for donations otherwise, please push it if I help make a better CM7 experience for you
do they work with MIUI ?
chuotcontodung said:
do they work with MIUI ?
Click to expand...
Click to collapse
Should work with any CM7-based ROM; I hope someone else can confirm, though; I only run vanilla CM7 and occasionally Trigger Redux.
Any chance to make it CWM-based ?
It'd be so much nicer to drop the zip into a SD root and just run it after every nighty installation.
strictlyrude27 said:
Dear all -
Script was updated to V1.2. I noticed that no read permissions were set to the .conf files; my thinking is there's no way Android could read those config files without read permissions, so they weren't even doing anything.
That said, the latest script now gives permission 0755 (rwxr-xr-x) to all files. After running the script now, I get a lock after first reboot in about 25 seconds.
You can download V1.2 and start from scratch, or just copy/paste the latest script contents into your GPSFix.sh. Or, run the following commands at a terminal (ADB or terminal emulator with root):
Code:
mount -o rw,remount /system
chmod 0755 /data/gps/secgps.conf
chmod 0755 /system/etc/gps.conf
chmod 0755 /system/bin/agpsd
mount -o ro,remount /system
reboot
Also, I noticed 31 downloads (and there were 20-some in the original post) but only a total of 3 Thanks.. I'm kind of addicted to the Thanks button and don't ask for donations otherwise, please push it if I help make a better CM7 experience for you
Click to expand...
Click to collapse
You need to add "su" to the first line of your installation instructions
ferhanmm said:
You need to add "su" to the first line of your installation instructions
Click to expand...
Click to collapse
I assumed you would be entering the terminal with root. I'll update that in the OP though, thanks.
svladimir said:
Any chance to make it CWM-based ?
It'd be so much nicer to drop the zip into a SD root and just run it after every nighty installation.
Click to expand...
Click to collapse
I don't know how to make an update.zip, but perhaps this will be a good time to learn! I'm way better at shell scripting which is why I went this route. I'll see what I can do, hopefully I can have a CWM flashable soon.. if anyone else can help me I would much appreciate it.
That said, note that you can still open an adb shell in recovery mode, so you could run the script after you flash the nightly. I haven't tried that, but I will soon.
strictlyrude27 said:
I assumed you would be entering the terminal with root. I'll update that in the OP though, thanks.
Click to expand...
Click to collapse
Lol yea but I guarantee you that if you didn't add it more than 20 people would ask
It turns out making an update.zip isn't so hard after all testing it now, if it works out I'll upload to OP. I'll keep the original scripts and stuff for posterity's sake.
Great efforts, wow
This is just great piece of development, a sure and simple cure for the GPS and the CM 7+ roms.
Now that you have created this script, one so simple, there will be leages of Vibrant Users who will be able to take advantage of your generousity and put this puppy to work.
Kudos and once again, great work.... W.0.W.
I can confirm, with the AngryGPS I was able to lock in with fast lock in up to Accuracy of 20 feet, picked up 8 of the 12 satellites in view.
Thank you very, very much....
Dear all -
V1.2CWM released! As requested, a CWM flashable zip has been created. It does literally the exact same thing as V1.2 (copies over the GPS files to the right locations, sets 0755 permissions on all files). You don't need to flash if you've already installed V1.2, but I would keep the zip on hand for when you decide to flash a new nightly.
As always, the Thanks button lets me know I'm loved
I plan on starting a gpsd database, seems that while all gpsd's are created equal, some are more equal than others so you can mix and match the gpsd from a previous nightly, rather than referring to the supermassive black hole that is the official CM7 Nightly thread.
And finally, I must point out that I did NOT create these fixes. All the credit and praise belongs to jwleonhart and roffee. I just packaged up their work into an easy-to-install package, those guys did the real work! Please find their threads in the Credits section of my OP and hit the Thanks button!
My phone refuses to download these. Annoying.
^ try getting astro, go to preferences and allow internet downloads.
Also, chrome to phone is amazing
s15274n said:
^ try getting astro, go to preferences and allow internet downloads.
Also, chrome to phone is amazing
Click to expand...
Click to collapse
I already did the astro thing.
Turned it on and off several times.
And I used chrome to phone to send the link, with the same result.
I swtiched over to Opera, and that eventually agreed to download it.
OP updated. I now offer a no-gpsd version of the CWM flashable, in case you want to keep your gpsd or mix and match with other nightlys. I'll put up a link to a Dropbox to store GPS drivers from every nightly.
Ironically, the fix used to work for me 100% of the time, but not anymore. I'm going to start experimenting with new gpsd's from CM7 nightlies; please also let me know of your own results!
EDIT: I wasn't getting locks, or was getting and losing locks with my fix. Tried #72 gpsd and the nogpsd flash.. 0/8 birds after 5 minutes. Reflashed my own fix. TTFF [time to first fix] 17 seconds, 7/10 satellites, 150 ft accuracy. After 1 minute, 20 foot accuracy. Rebooted. 0/10 after 5 minutes.
I wish I understood you, GPS. I wish I understood you.
very nice.. i tried right now..
before this, its takes serveral minutes to get a lock.
after this patch.
first 30 secs, In View 12 satts.
1 min, get in USE 4 satts, 25 meters accuracy.
2 min, get 6 satts, 7 meters accuracy.
Very fast!
Thanks!
Nice!!! It will be much much easier now to get GPS working after nightlies. Awesome!
Sent from my SGH-T959 using XDA App
This works but great the first day but
GPS seems to not even lock in the next day.
Dattack said:
This works but great the first day but
GPS seems to not even lock in the next day.
Click to expand...
Click to collapse
tell me about it. i put the damn thing together and i'm in the same boat. It's really hit or miss for me.
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
First of all, I need to acknowledge that I'm standing on the shoulders of giants, in composing this post. Mad props have to go to Rob Clark, for writing Freedreno and the Fedora installer I used. I also have to give credit to the people who made Ubuntu possible on the Touchpad (jshafer817, BodemM, castrwilliam, jcsullins, Calc1Programmer, Mystikal57, and lots of other people...I couldn't possibly post them all here, but that in no way diminishes my gratitude to them for all their hard work!)
Second of all, this is rough. Like "only shows kernel messages, good for nothing as it is" rough. I'm posting this to help spur on more work, so we can get things up and running faster.
Thirdly, you must have Ubuntu already installed to use this process, and it WILL destroy your Ubuntu install. I repeat, this WILL destroy your Ubuntu install. Only do this if you want to play with something that doesn't work right yet, and are willing to sacrifice something that does work to get it. You also need moboot 0.3.8 (which you already probably have if you have a working Ubuntu install).
Finally, no warranties. This will probably not work very well for you. I can't guarantee that bad things won't happen, and I will not be responsible if they do. I'm also LAUGHABLY FAR from being an expert, so look critically at these instructions before you go ahead, I can't guarantee I didn't miss anything. This is also probably not the most optimal method...the best method is probably what Rob posted in the readme, but that assumes you don't already have a Linux installed, which won't work so well for those of us with 16GB Touchpads.
Ok, having said all that, here's the good stuff.
Go to https://github.com/freedreno/touchpad-fedora and download the zip file.
Unzip it somewhere. There will be a bunch of scripts, a boot folder and a rootfs folder.
On your Touchpad, either in Android via a root terminal, or in WebOS with a root terminal, mount your /boot as read-write "sudo mount -o rw,remount /boot"
Go into the newly writable /boot, and delete uImage.Ubuntu (you'll need the free space...you can copy it to your computer or the SD Card if you want to reinstall it later). Copy uImage.Fedora to /boot. When you're done this, you should probably remount /boot as read-only "sudo mount -o ro,remount /boot"
Create a folder on your SD Card. Doesn't matter what you call it, but copy all the files from the rootfs folder there. There should be 11 of them, numbered 00 to 10.
Boot into WebOS, if you're not there already, and make sure you have WTerm installed and set up for root access.
Erase your Ubuntu partition, but don't destroy it. "mke2fs -F -T ext3 /dev/store/ubuntu-root" in WTerm. ***THIS IS DESTRUCTIVE***DANGER WILL ROBINSON***BE SURE BEFORE YOU DO THIS***
Make a temporary directory to mount your ubuntu partition on. "mkdir -p /tmp/linux"
Mount your newly formatted ubuntu partition. "mount /dev/store/ubuntu-root /tmp/linux"
CD into the folder you created that has the 00 through 10 files in it, and untar each one of them into /tmp/linux. The way I did this was to simply type "tar -C /tmp/linux -xvzf 00" and hit Tab. When it finished, I hit the up arrow, backspaced over the filename, then typed 01 and hit Tab, and so on for all eleven files.
When the files are all untarred, I typed "sync" (not sure why, it's in the script), and unmounted the temporary directory "umount /tmp/linux"
Last but not least, we have to rename the volume from ubuntu-root to fedora-root. "lvrename store ubuntu-root fedora-root"
That's it. You can close WTerm and reboot. When the moboot menu comes up, you'll see that Ubuntu is gone and Fedora is there, select it to boot. According to Rob's blog post, adb and rndis are working, so you can get access to a shell using adb, when it finishes booting.
Let me know how it works out for you, and please reply if you can improve my method (or if I screwed something up!).
I got rndis working...all I had to do was do it on my linux laptop, it didn't seem to work in Windows (surprise, surprise). With that running, I was able to get to yum via the adb shell. I yummed up gnome-shell, and it seemed to install OK, but I got an error when I tried to startx. It said there were no screens available, and it failed. I googled around a bit on that error, and it suggested I check into systemctl, where I noticed that "systemd-modules-load.service" had failed, and I saw module loading failure messages in dmesg, makes me think freedreno isn't loading right. I'll work on it some more after breakfast.
Turns out Rob forgot to add libdrm to the rootfs downloads. He added it last night to the git, and I've updated this guide to reflect that. Still doesn't boot to a GUI, but I'm closer than I was. startx throws an error about "no screens found", must need to be configured. I'll work on it later this evening and see what I can come up with.
Got it (sorta)! The libdrm version Rob supplied didn't quite match the Xorg version. A simple 'sudo yum update' and a reboot, and I have a GUI. Now to figure out how to add a user without a keyboard...
If this gets working I'm deff going to install. I'm dying for gnome 3 on a tablet.
Sent from my Nexus 7 using xda app-developers app
Head to your local Walmart (I think every town has one lol ) and buy the Bluetooth crapple keyboard....assuming it will work..but you might want to look it up...I just seen one there the other day.
Sent from my Galaxy Nexus using xda app-developers app
---------- Post added at 01:45 AM ---------- Previous post was at 01:41 AM ----------
OK quick search says yes it will pair...also if on the cheap..... http://dx.com/p/mini-bluetooth-keyboard-for-android-wince-nokia-symbian-s60-cellphones-black-37863 was successful under webos....so probably under android or Linux assuming your Bluetooth works.
Sent from my Galaxy Nexus using xda app-developers app
Great guide, can't wait to try this on my TP! It's been a while since I last messed around with it and this seems quite useful, as Gnome 3 is kinda optimized for touchscreens.
I was wondering though, does it matter which version of Ubuntu is installed or does it overwrite everything anyway?
https://github.com/freedreno/touchpad-fedora
Appears to have been a small update 4 days ago.
Sent from my Nexus 7 using xda app-developers app
This guide is intend to help you with "installing" Ubuntu 14.04 (12.04 also works) on the Amazon Fire TV 2 after @rbox recovery has been setup. Only headless mode is possible, similar to Ubuntu Server, but it still makes a nice little ARMv8 development box. Starting X.org or running systemd based Linux distributions will likely never be possible due to features missing from the Amazon kernel. Creative use of the framebuffer is possible if desired, maybe eventually a terminal emulator could be started. As long as you don't mount and modify mmcblk0pX there should be no possible way to mess up Android or brick the device. It's 100% reversible by just removing the SD card. You accept all responsibility for what you do with this work should something go wrong and the device becomes inoperable. With disclaimers and precursor knowledge out of the way let's get started.
To follow this guide you will need:
A micro SD card (2 GB+ recommended)
A Linux system
To login into Ubuntu you will need either:
A 1.8 V TTY USB serial device connected to the UART
A pair of USB serial devices and a null modem cable
I actually used a pair of Xbee's for testing the ttyUSB0 stuff, so hence a pair of FTDI chips would also work.
Preparing the SD Card
To get started you need to first partition the micro SD card:
Type = MBR
Part 1 = 100 MB, Fat32 (vfat)
Part 2 = Remainder, Ext4
Extract the attached zip file to the root of the first partition (extracted filename must be "ramdisk-recovery.cpio.lzma"). This is an alternative initramfs that simply uses busybox to clean up from the partial Android boot and prepare the filesystem for regular Linux. Extract an Ubuntu core root filesystem archive, ubuntu-core-14.04.4-core-arm64.tar.gz, to the root of the second partition as the root user (to preserve ownership/permissions). Make sure you sync or eject the device when done with this work so the data gets flushed to the SD card.
Now we need to make a few changes to the root filesystem to avoid usability issues and allow logins.
Replace /etc/fstab with the following contents to correct some mount options. This "disables" SELinux which fixes dpkg errors and some other login annoyances.
Code:
/dev/mmcblk1p2 / ext4 defaults,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs ro,relatime 0 0
Replace /etc/init/console.conf with the following contents to allow logins from the UART. Once the root password has been set (root is disabled by default) you can remove "-a root" if desired.
Code:
# console - getty
#
# This service maintains a getty on console from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/getty -s -a root console
Create /etc/init/ttyUSB0.conf with the following contents to allow logins from an attached USB serial device. This should help people who don't want to take apart their device to solder wires onto the UART test points. SSH would of course be an alternative but it's not installed by default in Ubuntu core and this guide is about the building blocks not providing pre-made images (yet). Since udev doesn't work due to devtmpfs not being enabled in the kernel you will need to attach the USB serial device before booting for this to work. As before you can remove "-a root" later if desired once the root password is set. Also you should change the baud rate if needed.
Code:
start on (tty-device-added ttyUSB0)
stop on (runlevel [!2345] or tty-device-removed ttyUSB0)
respawn
exec /sbin/getty -L -a root 115200 ttyUSB0 vt102
Preparing the Fire TV
Until the search order for the initramfs file is changed by @rbox you will need to rename the initramfs on the system partition so it will continue to search for one on the SD card or USB stick. You need to connect to the device using adb either over USB or the network to execute the following commands.
Code:
adb$ su
adb# mount -o remount,rw /system
adb# mv /system/recovery/ramdisk-recovery.cpio.lzma /system/recovery/ramdisk-recovery.cpio.lzma.bak
adb# mount -o remount,ro /system
Right now this prevents "su" from working, which should be fixed by @rbox in due time. To get "su" working again you should extract the original recovery initramfs file to a USB stick and boot the device with that USB stick inserted instead of the previously created SD card. Then to restore "su" you can repeat the above steps just swapping the order of the files in the "mv" command.
Booting Ubuntu
After connecting your serial device of choice simply insert the SD card and power on the device. It's that easy! With luck you should get a shell prompt that is already logged in as root. It's a good idea to set the root password before going much further. The device isn't too useful without networking, so you can install more packages. To solve that connect an ethernet cable (since it's simpler) and type "dhclient eth0" to get online. At this point you can install openssh-server using apt-get or do anything else you'd normally do on an Ubuntu VM or headless Ubuntu system. I'm interested in hearing what people plan to do with a more-or-less high-end ARM development system.
Tips and Tricks
NOTE: These changes, unless otherwise noted, are performed while logged into the target Ubuntu system.
Setting the Hostname
You can change the hostname using the following command:
Code:
echo sloane > /etc/hostname
You should also create a simple /etc/hosts file that matches the chosen hostname.
Code:
127.0.0.1 localhost
127.0.1.1 sloane
Enable Ethernet at Boot
Create the file /etc/network/interfaces.d/eth0 with the following contents:
Code:
auto eth0
iface eth0 inet dhcp
Allow Users Network Access
Since we are stuck running an Android kernel you need to create the following group and add users who need network access (such as ping) to this special group.
Code:
groupadd -g 3003 aid_inet
usermod -G aid_inet -a root
usermod -G aid_inet -a <username>
Removing Failed Services
There are a few services that fail to start due to hardware limitations. We should just prevent them from starting in the first place. We have no VT support enabled in the kernel (boo) so we can just remove the ttyX login prompt services. Also the console setup doesn't work since our console is a serial device not a virtual terminal or other "graphical" type terminal emulator.
Code:
rm /etc/init/tty?.conf
echo manual > /etc/init/console-font.override
echo manual > /etc/init/console-setup.override
Fix /dev Hotplug
As stated before udev doesn't work due to missing kernel features. The busybox applet mdev is a simple replacement for most users. After installing the "busybox-static" package run the following command:
Code:
ln -s /bin/busybox /sbin/mdev
Now add the following line to /etc/rc.local before "exit 0".
Code:
echo /sbin/mdev > /proc/sys/kernel/hotplug
Pre-installing SSH
See: http://forum.xda-developers.com/showpost.php?p=65595013&postcount=13 (thanks @segfault1978)
Thanks a lot, that was exactly the thing I was searching for. Since before today the Raspi3 came out, this box is the cheapest ARMv8 development machine available. With your instruction I was able to login via SSH and install all required software for my development environment. No GUI needed for that, I'm doing all remotely via SSH. Again, thank you!
segfault1978 said:
Thanks a lot, that was exactly the thing I was searching for. Since before today the Raspi3 came out, this box is the cheapest ARMv8 development machine available. With your instruction I was able to login via SSH and install all required software for my development environment. No GUI needed for that, I'm doing all remotely via SSH. Again, thank you!
Click to expand...
Click to collapse
Awesome to hear that it worked for you. Just curious if you went the USB serial route or soldered to the UART pins.
There is also the Dragonboard 410c which is a quad core A53 but has a bit more than the raspberry pi. The price is higher though but it has been out probably a year or so. Just FYI. The raspberry pi 3 is a good deal.
zeroepoch said:
Awesome to hear that it worked for you. Just curious if you went the USB serial route or soldered to the UART pins.
Click to expand...
Click to collapse
None of these methods (since I was in my weekend and all cables and adapters reside in my office)
I placed all .deb-files for openssh-server including all requiremens onto the microSD card, and placed a call "dpkg -i /*.deb" with logging options in /etc/rc.local. I also configured network by mounting the sd card, editing /etc/network/interfaces, and last changed /etc/shadow to have a valid root account for login. It took my some try-and-error loops, but finally it worked as expected. Call me crazy, but I succeeded without any hardware.
---------- Post added at 09:09 PM ---------- Previous post was at 09:03 PM ----------
zeroepoch said:
There is also the Dragonboard 410c which is a quad core A53 but has a bit more than the raspberry pi. The price is higher though but it has been out probably a year or so. Just FYI. The raspberry pi 3 is a good deal.
Click to expand...
Click to collapse
Thank you for the hint, I'll have a look for the availability of this board in germany.
I'm facing a memory problem, resulting in a reboot of the device when all RAM is being used. My compile session takes more than 1.x GB of RAM for the quite complex compilation of all required packages. I can reproduce the situation where all memory is consumed and the device instantly reboots when hitting "no memory left" situation. Since "swapon" is not supported by the kernel (really?): is there any way to enable swap functionality, i.e. via a kernel module? How to overcome this situation where more memory is needed?
segfault1978 said:
None of these methods (since I was in my weekend and all cables and adapters reside in my office)
I placed all .deb-files for openssh-server including all requiremens onto the microSD card, and placed a call "dpkg -i /*.deb" with logging options in /etc/rc.local. I also configured network by mounting the sd card, editing /etc/network/interfaces, and last changed /etc/shadow to have a valid root account for login. It took my some try-and-error loops, but finally it worked as expected. Call me crazy, but I succeeded without any hardware.
Click to expand...
Click to collapse
That is pretty crazy, but since you knew the changes required it worked Not everyone I expected to have such experience. I figured someone might even try to do a qemu chroot or debbootstrap to preinstall openssh. Multiple ways to solve the same problem I guess.
segfault1978 said:
I'm facing a memory problem, resulting in a reboot of the device when all RAM is being used. My compile session takes more than 1.x GB of RAM for the quite complex compilation of all required packages. I can reproduce the situation where all memory is consumed and the device instantly reboots when hitting "no memory left" situation. Since "swapon" is not supported by the kernel (really?): is there any way to enable swap functionality, i.e. via a kernel module? How to overcome this situation where more memory is needed?
Click to expand...
Click to collapse
Looking at the default kernel config from the source code drop from Amazon I see:
Code:
# CONFIG_SWAP is not set
Swap can not be compiled as a module. Even if you chose to use a USB stick or something as the swap device It wouldn't work. Given that we can't change the kernel we can't try stuff like zram or zswap either. The only other suggestion I might have is if you're using "-j4" or something while compiling just remove that so it does a single threaded compile. I'm sure you already tried that. Beyond that you could look at using the Linaro AArch64 toolchain and cross compile. Since we're running Ubuntu you shouldn't need to worry about static binaries.
zeroepoch said:
Looking at the default kernel config from the source code drop from Amazon I see:
Code:
# CONFIG_SWAP is not set
Swap can not be compiled as a module. Even if you chose to use a USB stick or something as the swap device It wouldn't work. Given that we can't change the kernel we can't try stuff like zram or zswap either. The only other suggestion I might have is if you're using "-j4" or something while compiling just remove that so it does a single threaded compile. I'm sure you already tried that. Beyond that you could look at using the Linaro AArch64 toolchain and cross compile. Since we're running Ubuntu you shouldn't need to worry about static binaries.
Click to expand...
Click to collapse
Unfortunately, I'm not compiling with parallel processes (I'm compilig Icinga2 for arm64), I'm running
Code:
dpkg-buildpackage -us -uc
within the source package. One single cpp call consumes so much memory (which is crazy in my eyes, never seen such a big compiler process until today), so I'll investigate the option of cross compiling and afterwards creating the deb file outside of the machine.
Code:
cd /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base && /usr/bin/aarch64-linux-gnu-g++ -DI2_BASE_BUILD -Doverride="" -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g -pthread -std=c++11 -Wno-inconsistent-missing-override -fPIC -I/root/icinga2-2.4.3 -I/root/icinga2-2.4.3/lib -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib -I/root/icinga2-2.4.3/third-party/execvpe -I/root/icinga2-2.4.3/third-party/mmatch -I/root/icinga2-2.4.3/third-party/socketpair -o CMakeFiles/base.dir/base_unity.cpp.o -c /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base/base_unity.cpp
I'm a novice in android devices: What would be required to use a custom kernel? A hacked boot loader, which is not available for the AFTV2?
segfault1978 said:
I'm a novice in android devices: What would be required to use a custom kernel? A hacked boot loader, which is not available for the AFTV2?
Click to expand...
Click to collapse
Yep... we need to be able to use fastboot to boot an unsigned kernel and initramfs (boot.img). I tried at one point to overwrite the boot partition with own image and it failed to boot. Since I had the preloader stuff worked out already I was able to restore the original boot image and get it working again.
On a side note, if you don't mind could you post the list of packages needed to install SSH server from rc.local? Others might find that useful. To get around the unset password issue you could have also saved a public key in /root/.ssh/authorized_keys which would also avoid you needing to change /etc/ssh/sshd_config to allow password logins as root.
segfault1978 said:
within the source package. One single cpp call consumes so much memory (which is crazy in my eyes, never seen such a big compiler process until today), so I'll investigate the option of cross compiling and afterwards creating the deb file outside of the machine.
Code:
cd /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base && /usr/bin/aarch64-linux-gnu-g++ -DI2_BASE_BUILD -Doverride="" -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g -pthread -std=c++11 -Wno-inconsistent-missing-override -fPIC -I/root/icinga2-2.4.3 -I/root/icinga2-2.4.3/lib -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib -I/root/icinga2-2.4.3/third-party/execvpe -I/root/icinga2-2.4.3/third-party/mmatch -I/root/icinga2-2.4.3/third-party/socketpair -o CMakeFiles/base.dir/base_unity.cpp.o -c /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base/base_unity.cpp
Click to expand...
Click to collapse
I see you are not using -pipe which is good, but a quick search suggested something that might not be simple since this package has it's own build system but changing from -O2 to -O1 might help.
I noticed that Debian has the package available for the same version and already built for arm64.
https://packages.debian.org/sid/icinga2
Maybe you already tried that. You could try going back to jessie which is probably an older version but I think most jessie packages work with Ubuntu 14.04.
zeroepoch said:
Yep... we need to be able to use fastboot to boot an unsigned kernel and initramfs (boot.img). I tried at one point to overwrite the boot partition with own image and it failed to boot. Since I had the preloader stuff worked out already I was able to restore the original boot image and get it working again.
On a side note, if you don't mind could you post the list of packages needed to install SSH server from rc.local? Others might find that useful. To get around the unset password issue you could have also saved a public key in /root/.ssh/authorized_keys which would also avoid you needing to change /etc/ssh/sshd_config to allow password logins as root.
Click to expand...
Click to collapse
This is the list of packages I manually downloaded for ARM64 (unfortunately I used Debian packages which worked first, but leads to a hell situation afterwards when dealing with other dependencies; be sure to use Ubuntu packages in order to avoid problems afterwards):
Code:
busybox_1.22.0
libedit2_3.1
libgssapi-krb5
libk5crypto3
libkeyutils1
libkrb5
libkrb5support0
libwrap0
openssh-client
openssh-server
openssh-sftp-server
This is the piece of calls in /etc/rc.local, right before the exit:
Code:
dpkg --force-all -i /*.deb > /install.log 2>/install.err
echo $? >> /install.log
echo "installation finished" >> /install.log
It took about 1-2 minutes before SSH started to work automatically, you can mount the SD card afterwards in another system in order to check the written logfiles.
Here are some notes for getting wireless working. In addition to the normal OS steps (installing wpasupplicant or wireless-tools and editing /etc/network/interfaces or using wicd) you will need some firmware files from /system (/dev/mmcblk0p13).
Code:
mount -o ro /dev/mmcblk0p13 /mnt
cp -r /mnt/etc/firmware/ /lib/
cp -r /mnt/etc/Wireless /etc/
umount /mnt
segfault1978 said:
None of these methods (since I was in my weekend and all cables and adapters reside in my office)
I placed all .deb-files for openssh-server including all requiremens onto the microSD card, and placed a call "dpkg -i /*.deb" with logging options in /etc/rc.local. I also configured network by mounting the sd card, editing /etc/network/interfaces, and last changed /etc/shadow to have a valid root account for login. It took my some try-and-error loops, but finally it worked as expected. Call me crazy, but I succeeded without any hardware.
Thank you for the the fire tv guide.
Click to expand...
Click to collapse
So, what's the verdict on this? I want to use my firetv 2 as an emby server. Is it worth it trying to get Ubuntu to run?
Sent from my Mi A1 using Tapatalk
mrchrister said:
So, what's the verdict on this? I want to use my firetv 2 as an emby server. Is it worth it trying to get Ubuntu to run?
Click to expand...
Click to collapse
If it has arm64 packages and headless you can give it a try. If you don't like it you can just revert the ramdisk and go back to Android.
Ok sweet, thanks for the reply
Sent from my Mi A1 using Tapatalk
Just curious if anyone's tried running Plex server on this?
I've been looking for a better solution without shelling out $500+ for a dedicated NAS. AFTV is tiny so I could hardwire it and hide it away.
Thanks
I got the same idea. Right now the firetv is still being used as a media streamer but I'm thinking of doing this soon