Thread Closed

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

OP Sogarth

20th March 2011, 06:56 AM   |  #1  
OP Retired Recognized Developer
Thanks Meter: 362
 
503 posts
Join Date:Joined: Jan 2006
----- 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):

Click image for larger version

Name:	1.jpg
Views:	16622
Size:	85.9 KB
ID:	551321

Running synaptic brings up a list of available packages:

Click image for larger version

Name:	2.jpg
Views:	10623
Size:	89.2 KB
ID:	551322

If we're looking for a decent image viewer, eog should do the trick:

Click image for larger version

Name:	3.jpg
Views:	8076
Size:	96.2 KB
ID:	551323

Once we install it, Nautilus (the file manager) now has an interesting option in the menu for pictures, Open with "Image Viewer":

Click image for larger version

Name:	4.jpg
Views:	8394
Size:	97.3 KB
ID:	551324

Selecting that brings up what you would expect (moved off to the side so that it doesn't take up the entire desktop):

Click image for larger version

Name:	5.jpg
Views:	9776
Size:	100.8 KB
ID:	551325

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:
Attached Files
File Type: zip ubuntu-1.0.6.zip - [Click for QR Code] (763.8 KB, 7147 views)
Last edited by Sogarth; 11th June 2011 at 10:36 AM. Reason: Back from "vacation."
The Following 25 Users Say Thank You to Sogarth For This Useful Post: [ View ]
20th March 2011, 06:57 AM   |  #2  
OP Retired Recognized Developer
Thanks Meter: 362
 
503 posts
Join Date:Joined: Jan 2006
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!
Last edited by Sogarth; 22nd March 2011 at 05:11 AM.
The Following 5 Users Say Thank You to Sogarth For This Useful Post: [ View ]
20th March 2011, 06:57 AM   |  #3  
OP Retired Recognized Developer
Thanks Meter: 362
 
503 posts
Join Date:Joined: Jan 2006
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.
Last edited by Sogarth; 25th March 2011 at 06:43 AM.
The Following 3 Users Say Thank You to Sogarth For This Useful Post: [ View ]
20th March 2011, 06:58 AM   |  #4  
OP Retired Recognized Developer
Thanks Meter: 362
 
503 posts
Join Date:Joined: Jan 2006
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:
  1. /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:
  1. /bin/dd if=/dev/zero of=/data/ubuntu.disk bs=1024 count=1048576
  2. /sbin/losetup /dev/block/loop7 /data/ubuntu.disk
  3. /sbin/mkfs -t ext3 -m 1 -b 2048 /dev/block/loop7
  4. mkdir /tmp/osh
  5. /bin/mount -t ext3 /dev/block/loop7 /tmp/osh

At this point, we've created a 1 GB disk file (1,0241,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:
  1. mkdir /tmp/deb
  2. /usr/bin/dpkg-deb -x /mnt/sdcard-ext/rsync* /tmp/deb
  3. /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 "$@"

# 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:
  1. mv /system/bin/mountosh /system/bin/mountosh.orig
  2. cp /mnt/sdcard-ext/mountosh.new /system/bin/mountosh
  3. chmod 0755 /system/bin/mountosh
  4. chown 0 /system/bin/mountosh
  5. 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:
  1. rm osh/etc/tomoyo/exception_policy.conf
  2. touch osh/etc/tomoyo/exception_policy.conf
  3. rm osh/etc/tomoyo/domain_policy.conf
  4. 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.
  1. coreutils
  2. cpio
  3. dbus
    • /etc/init.d/dbus
  4. dbus-x11
    • /etc/X11/Xsession.d/75dbus_dbus-launch
  5. dhcp3-client
  6. findutils
  7. gpgv
  8. pulseaudio
    • /etc/pulse/daemon.conf
    • /etc/pulse/default.pa
  9. udev
    • /etc/init.d/udev
  10. xserver-xorg-core
    • /usr/bin/Xorg
You'll need to install each package with:
  1. 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:
  1. 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:
  1. 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. -----
Last edited by Sogarth; 25th March 2011 at 07:55 AM. Reason: Background notes for up through version 1.0 of the setup script.
The Following 3 Users Say Thank You to Sogarth For This Useful Post: [ View ]
20th March 2011, 07:48 AM   |  #5  
Vigneshd's Avatar
Senior Member
Tampa
Thanks Meter: 23
 
127 posts
Join Date:Joined: Mar 2011
More
You my friend are incredibly good. This is insane

Edit: removed huge quote...
Last edited by Vigneshd; 23rd March 2011 at 09:24 AM.
20th March 2011, 08:41 AM   |  #6  
Senior Member
Thanks Meter: 15
 
273 posts
Join Date:Joined: Feb 2011
Might be a good idea to not quote the entire massive post.

Looking forward to seeing where this goes... How well does it run?
20th March 2011, 12:22 PM   |  #7  
Junior Member
Thanks Meter: 1
 
11 posts
Join Date:Joined: Aug 2008
This is great. Can't wait to try it monday. Keep up the good work.

Sent from my MB860 using XDA Premium App
20th March 2011, 05:02 PM   |  #8  
Member
Flag Guelph
Thanks Meter: 1
 
84 posts
Join Date:Joined: Oct 2010
More
how does this perform vs the included webtop mode?
20th March 2011, 07:37 PM   |  #9  
OP Retired Recognized Developer
Thanks Meter: 362
 
503 posts
Join Date:Joined: Jan 2006
Quote:
Originally Posted by CC Lemon

Looking forward to seeing where this goes... How well does it run?

Quote:
Originally Posted by lasersocks

how does this perform vs the included webtop mode?

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.
The Following 2 Users Say Thank You to Sogarth For This Useful Post: [ View ]
20th March 2011, 09:21 PM   |  #10  
Senior Member
Flag London
Thanks Meter: 103
 
1,029 posts
Join Date:Joined: May 2010
if you get this working, can you make a video please? would be nice to see how it is.

Thread Closed Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Top Threads in Atrix 4G Android Development by ThreadRank