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

Status
Not open for further replies.
Search This thread
By:
Advanced…
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
----- 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. :D 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! :D)
    • 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):

1.jpg

Running synaptic brings up a list of available packages:

2.jpg

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

3.jpg

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

4.jpg

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

5.jpg

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

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

 

Attachments

  • ubuntu-1.0.6.zip
    763.8 KB · Views: 8,336
Last edited:
  • Like
Reactions: petesimon, madefree, laconeo and 23 others
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
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? :D

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:
  • Like
Reactions: darebear802, eval-, dubyajaysmith and 2 others
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
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:
  • Like
Reactions: darebear802, eval- and edounn
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
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,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:
  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:
  • Like
Reactions: Viamonte, eval- and edounn
Vigneshd

Vigneshd

Senior Member
Mar 14, 2011
127
23
Tampa
You my friend are incredibly good. This is insane

Edit: removed huge quote...
 
Last edited:
C

CC Lemon

Senior Member
Feb 17, 2011
282
14
Might be a good idea to not quote the entire massive post.

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

hotrod2067

Member
Aug 12, 2008
11
1
This is great. Can't wait to try it monday. Keep up the good work.

Sent from my MB860 using XDA Premium App
 
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
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.
 
  • Like
Reactions: atlana and edounn
dasmoover

dasmoover

Inactive Recognized Developer
Nov 29, 2010
229
128
Very good work! You should join the irc sometime.

freenode
#moto-atrix
 
Last edited:
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
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.
 
dicksteele

dicksteele

Inactive Recognized Contributor
Sep 4, 2010
3,807
2,740
California
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.
 
M

metk@

Senior Member
Apr 18, 2009
99
7
Warsaw
I cant wait for my Atrix :) I'm getting more and more excited every day seeing whats happening here :D
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?
 
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
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.
 
dicksteele

dicksteele

Inactive Recognized Contributor
Sep 4, 2010
3,807
2,740
California
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.
 
dicksteele

dicksteele

Inactive Recognized Contributor
Sep 4, 2010
3,807
2,740
California
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 !!!
 
Last edited:
S

Sogarth

Retired Recognized Developer
Jan 14, 2006
503
361
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.
 
Last edited:
Status
Not open for further replies.

Similar threads

epinter
[ROM] CM10 (JellyBean) for Atrix
Replies
6K
Views
2M
D
DuyguSeli
epinter
[ROM] CM 10.1(Android 4.2) for Atrix
Replies
4K
Views
1M
W
williamfrench
t0dbld
  • Locked
* Official CM7 for Atrix Stable only (No Nightly )* Atrix CM Ba2tF RELEASED!!
Replies
4K
Views
1M
_Alex_
_Alex_
mmontuori
[KERNEL] [3.1.10] Olympus (Atrix 4G) Kernel Project
Replies
2K
Views
1M
P
palmbeach05
T
[ROM] Atrix CM9 [ADT's SelfKANGish builds - 20120715]
Replies
2K
Views
818K
W
williamfrench

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 26
    S
    Sogarth
    ----- 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. :D 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! :D)
      • 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):

    1.jpg

    Running synaptic brings up a list of available packages:

    2.jpg

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

    3.jpg

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

    4.jpg

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

    5.jpg

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

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

    View
    5
    S
    Sogarth
    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? :D

    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!
    View
    3
    S
    Sogarth
    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.
    View
    3
    S
    Sogarth
    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,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:
    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. -----
    View
    2
    S
    Sogarth
    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.
    View

New posts