Canonical Voices

Posts tagged with 'ubuntu'

Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer

Being a MOTU


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer

EDIT: As several people have pointed out, there is a script to already to this, pull-lp-source. Perfect! I’ve asked numerous people over the last year about whether there was a tool that could do this and nobody mentioned this one (even asked on AskUbuntu last week). So out of all this I end up with a link to a great new tool and got to write some python yesterday. pull-lp-source looks like it will meet all my needs.

During my work on bug triage and trying to become MOTU, I’ve found myself wanting to be able to pull source packages for a specified release, for example, download source for lxc on precise, even if I’m using raring. Although you can do this if you setup apt with all the releases and then use pinning, or doing a setup like this, I wanted an easier way. So I decided to glue together rmadison and dpkg-source and create a tool called “get_source”. This is how it works.

get_source.py -r <release> -p <package>

Pulling the source for bc on oneiric:

get_source.py -r oneiric -p bc

Grabbing lxc on precise:

get_source.py -r precise -p lxc

Seems pretty simple and it is!

The tool relies on outside helpers to do the hard work, namely rmadison and dpkg-source, so you’ll need those installed to use it. Please give it a try and send in feedback and fixes. If you’re a developer you’ll note that I even have unit-ish tests, please add more if you make some fixes for corner-cases.

bzr branch lp:~mfisch/+junk/get_source

How It Works

  1. Run rmadison and build a list of packages + versions per release
  2. Find the release we care about. We now know the package name, version, and release name.
  3. Using some hueristics, download the dsc file.
  4. Read and parse the dsc file to find the filenames for the orig file and diff and/or debdiff
  5. Download the orig and diff/debdiff files
  6. Use dpkg-source -x to extract it

Alternatives and Issues

When I started this, I figured it would be simple, but I was mistaken. There is lots of variation on filenames and locations in the archives, for example:

  1. I had originally planned to just go grab http://url/pool/main/<package first letter>/package/package_version.<extension>, but it’s not quite that simple. First, not all packages use standard names, some have a diff.gz, some a debian.tar.gz. Then some packages use xz and some use gz.  Native packages won’t have a diff at all (I think), and right now I know my code won’t support that.
  2. There’s also the question of package directory. alsa-base for example comes from the directory “alsa-driver”. I plan on grabbing this information from apt-cache show, but even that will not solve the issue if I’m on raring and the package was elsewhere in precise. This is also not yet supported in this version.
  3. Packages like angband have a version of 1:3.0.9-1, and the “1:” portion is not included in the filename. The code now supports this.

I found these cases by making this app work for a package and then randomly trying more and more packages to find and hopefully fix new cases. The worry I have is that there are hundreds more corner-cases that I don’t handle. Given all these issues, I’m still releasing this code for other people to test, but perhaps someone has simpler solutions to the problems above? Even better, maybe someone has already written a better tool, which I’ll gladly use!

Read more
Matt Fischer

Limiting LXC Memory Usage


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/mfischer/mattfischer.com/blog/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 68

Read more
Matt Fischer

Based on the questions I’ve seen on AskUbuntu, lightdm.conf is one of the most misunderstood files on your system. So, I decided I’d write a post on how you can easily modify this file and what the modification are useful for. I hope to show how to modify the most asked about settings.

Safely Modifying lightdm.conf

Before you do anything to your lightdm.conf file, you should make a backup, simply run:

sudo cp /etc/lightdm/lightdm.conf /etc/lightdm/lightdm.conf.old

Once you’ve made a backup, the simplest and safest way to modify lightdm.conf is to use lightdm-set-defaults. lightdm-set-defaults was written so that lightdm.conf could be modified via script, but you can also use it to easily make changes. I’ve made several changes to this tool to add new features that I needed, and best of all, I even wrote a manpage for it, which should show up in raring at some point. If you’re not using raring, then just run /usr/lib/lightdm/lightdm-set-defaults with no arguments and you’ll get a clear picture on what it can do.

Usage:
lightdm-set-defaults [OPTION...] - set lightdm default values

Help Options:
-h, --help Show help options

Application Options:
-d, --debug Enable debugging
-k, --keep-old Only update if no default already set
-r, --remove Remove default value if it's the current one
-s, --session Set default session
-g, --greeter Set default greeter
-a, --autologin Set autologin user
-i, --hide-users Set greeter-hide-users to true or false
-m, --show-manual-login Set show-manual-login to true or false
-R, --show-remote-login Set show-remote-login to true or false
-l, --allow-guest Set allow-guest to true or false

You can also edit the file manually, but in either case, manual edit or set-defaults, you’ll need to use sudo. And now that you know how to modify the file, let’s cover what the most frequently asked about items are.

Disabling Guest Login

Some people really get annoyed by guest login, so if you want to disable it, simply use:

sudo /usr/lib/lightdm/lightdm-set-defaults --allow-guest false

Or, you can manually add the following line in the [SeatDefaults] section:

allow-guest=false

The default for this option is true, so if unset, the guest account will be enabled.  Note: See how great the command option for lightdm-set-defaults was named? Whoever added that was a genius.

Hiding the User List

If you don’t want a user list to be displayed by the greeter, you can enable this option. This should also be used with the enabling manual login (below) or logging in may be a challenge (actually I’ve never tried one without the other, I’m not sure what will happen).

sudo /usr/lib/lightdm/lightdm-set-defaults --hide-users true

Or, you can manually add the following line in the [SeatDefaults] section:

greeter-hide-users=true

The default for this option is false, so if unset, you will get a user list in the greeter.

Show Manual Login Box

If you previously hid your user list and would like a box where you can manually type in a user name then this option is for you.

sudo /usr/lib/lightdm/lightdm-set-defaults --show-manual-login true

Or, you can manually add the following line in the [SeatDefaults] section:

greeter-show-manual-login=true

The default for this option is false, so if unset, you won’t get a manual login box.

Autologin

You can enable autologin by specifying the autologin user.

sudo /usr/lib/lightdm/lightdm-set-defaults --autologin username

Or, you can manually add the following line in the [SeatDefaults] section:

autologin-user=username

There are other autologin related options which you may want to set, but none of these can be set using lightdm-set-defaults:

To change how long the greeter will delay before starting autologin.  If not set, the delay is 0, so if you want this to be 0, you don’t need to change it.  Note: the default for all unset integers in the [SeatDefaults] section is 0.

autologin-user-timeout=delay

To enable autologin of the guest account:

autologin-guest=true

Run a Command When X Starts, When The Greeter Starts, When the User Session Starts

When lightdm starts X you can run a command or script, like xset perhaps.

display-setup-script=[script|command]

You can do something similar when the greeter starts:

greeter-setup-script=[script|command]

or when the user session starts:

session-setup-script=[script|command]

Change the Default Session

If you want a different session for the default, you can modify this option. I think that the greeter will default to give you the last session you chose, so this option will only change the default session. Note: The session switcher will only show up if you have more than one VALID session; a valid session is one that points to a valid executable. By default in 12.10 you will have a session file for gnome-shell, but gnome-shell won’t be installed, so the session is invalid, leaving you with a single valid session (Ubuntu), and hence no session selector!

/usr/lib/lightdm/lightdm-set-defaults --session [session name]

Or, you can manually add the following line in the [SeatDefaults] section:

user-session=true

The list of user sessions is in /usr/share/xsessions, although even that location is configurable (see Advanced Options).

You can change the default greeter in the same manner, using –greeter for lightdm-set-defaults or greeter-session for the config file. The list of installed greeters is in /usr/share/xgreeters.

Advanced Options and All Other Options

There is no manpage for lighdm.conf, but there is an example that lists all the options and a bit about what they do, just look in /usr/share/doc/lightdm/lightdm.conf.gz.  If you use vim, you can just edit the file and it will be automagically ungzipped for you, users of other editors are on their own.

Read more
Matt Fischer

Several months ago, I wrote a stock quote lens using Michael Hall‘s Singlet. After installing Quantal in September, I started playing with the preview feature in lenses and I really liked it, so I got motivated to add it to my lens. Turns out, it’s super easy. During the process, I also added real charts for the preview icons and fixed a bug when displaying news stories (they were missing the publication date).

First a quick look at the new graphs and previews, then I’ll go over the code.

Real charts with the quotes

The preview mode offers two buttons for stock quotes, the first one “More Info” takes you to the standard stock quote page. The second one, Interactive Chart, takes you to a large interactive stock chart, both at Yahoo Finance.

Preview with two actions

 

If you want to install the new version with quotes, you need version 0.6 or later. You can get them from the Scopes Packagers PPA, I’ve uploaded versions for Precise, Quantal, and Raring.

Now, let’s look at the code, you can find it here, or just branch it with: bzr branch lp:~mfisch/onehundredscopes/unity-stock-ticker-lens.  The relevant changes are in revision 11, look at the preview function in the scope code (yahoostock-scope). I’ve simplified what’s in my code some to make it easier to follow:

def preview(self, result_item, result_model):
   preview = Unity.GenericPreview.new(result_item['title'], result_item['description'], None)
   preview.props.image_source_uri = 'http://chart.finance.yahoo.com/t?s=%s&amp;lang=en-US&amp;region=US&amp;width=380&amp;height=380' % result_item['title']
   open_chart = Unity.PreviewAction.new("open_chart", "Interactive Chart", None)
   open_chart.connect('activated', self.open_chart)
   preview.add_action(open_chart)
   return preview

The first two lines setup the preview, the first one sets the large font title and the smaller font text. The second line sets the large preview image. The open_chart lines define an action, which becomes a button in the UI. The button text is “Interactive Chart” and the button action is a function called open_chart. The open_chart function (not listed, but available in the bzr branch munges the inbound URL some and then opens a webbrowser to the Yahoo interactive chart page.

And that’s it!  Very simple! I had this up and running in about 30 minutes, while watching The Pacific on TV,

You can read more about previews in Singlet 0.3 in Michael Hall’s blog post about it. Special thanks to Chris Wayne for his git hub lens which was inspiration for these changes. You can look at Chris’s code for some other examples, his may be easier to follow than mine.

Read more
Matt Fischer

Getting Juju With It

At the UDS in Copenhagen I finally had time to attend a session on Juju Charms. I knew the theory of Juju, which is that allows you to easily deploy and link services on public clouds, locally, or even on bare metal, but I never had time to try it out. The Charm School (registration required) session in Copenhagen really showed me the power of what Juju can give you. For example, when I first setup my blog, I had to find a webhost, get an an ssh account, download WordPress, install it, and dependencies, setup mysql, configure WordPress, debug why they weren’t communicating, etc. It was super annoying and took way too long. Now, imagine you want to setup ten blogs, or ten instances of couchdb, or one hundred, or one thousand, and it quickly becomes untenable.  With juju, setting up a blog is as simple as:

  • juju deploy wordpress
  • juju deploy mysql
  • juju add-relation wordpress mysql
  • juju expose wordpress

A few minutes later, and I have a functioning WordPress install. For more complex setups and installs Juju helps to manage the relationships between charms and sends events that the charms react to. This makes it easy to add and remove services like haproxy and memcached to an existing webapp. This interaction between charms implies that the more charms that are available the more useful they all become; the network effect applies to charms!

So after I got home, Charm School had left me energized and ready to write a charm, but I didn’t have any great ideas, until I remembered an app that I’ve used before called Tracks. Tracks is a GTD app, in other words, a fancy todo list. I’d used it hosted before, but my free host went offline and I lost all my to do items. Hosting my own would be much safer. So I started working on a Tracks charm.

If you need an idea for a charm, think about what tools you use that you have to setup, what software have you installed and configured recently? If you need an idea and nothing stands out, you can check out the list of “Charm Needed” bugs. Actually you should check that list regardless to make sure nobody else is already writing the same one.

With an idea in hand, I sat down to write my Charm. Step one is the documentation, most of which was contained on this page “Writing a Charm“. I fully expected to spend three weeks learning a new programming language with arcane black magic commands, but I was pleasantly surprised to learn that you can write a charm in any language you want. Most charms seem to be shell scripts or Python and my charm was simple enough that I wrote it in bash.

During the process of charm writing you may have some questions, and there’s plenty of help to be had. First, the examples that are contained in the juju trunk are OLD and I wouldn’t recommend you follow them. They are missing things like README files and don’t expose http interfaces, which was requested for my charm. Instead I’d recommend you pull the wordpress, mysql, and drupal charms from the charm store. If the examples aren’t enough, you can always ask in #juju on freenode or use askubuntu.com. Once your charm works, you can submit it for review. You’ll probably learn a lot during the review, every person I’ve talked to has.

Finally after a bit of work off and on, my charm was done! I submitted it for review, made a few fixes and it made it into the store.

I can now have a Tracks instance up and running in just a few minutes

I’ve barely scratched the surface here with this post, but I hope someone will be energized to go investigate charms and write one. Charms do not use black magic and you don’t need to learn a new language to write one. Help is available if you need it and we’d love to have your contributions.
If you go write a charm please comment here and let me know!

Read more
Matt Fischer

This is a a brief post to alert everyone that the 32Gb Nexus7 with 3g cannot currently install Ubuntu.  The problems have been fixed, but we’re not going to re-roll a Quantal based image for this. You’ll get a fix when the Raring builds are ready, which should be soon, hopefully this week. The issue, if you’re curious, is that the new radio changed the device ID where we write the rootfs into. The new code will not make assumptions about the layout and will determine it dynamically.

Read more
Matt Fischer

I was asked last Friday about what type of bugs we see the most on Nexus7.  Right now we have about 75 unfixed bugs, and from having walked through that bugs list about twenty times, I know that we can break the bugs down into some categories. These are arbitrary categories and subject to debate, but they show the patterns I see in the bug list:

Kernel/Kernel Config/Drivers: 9 bugs

The initial kernel we used was the Android 3.1 kernel, which included binary drivers. This kernel has configuration and code differences from the standard Ubuntu kernel. The kernel team at Canonical is working on trying to get the kernel we’re using as close to Ubuntu as possible. This includes things as simple as enabling more modules and as complex as merging in patches so we can support things like overlayfs.

Onboard Related Issues: 9 bugs

For mobility impaired users, Onboard is a part of daily life. For most of us, we only have to use it when we’re playing with a tablet device, so I think it’s great that these bugs are getting some attention. One bug that was recently fixed by marmuta that should lead to Onboard launching 7x faster with certain themes, including the default theme. Some of the bugs in this category are not issues with Onboard itself, but impact Onboard specifically.

Unity/Nux: 6 bugs

Unity and nux have some bugs that impair the usability of the device and a couple bugs that lead to crashes or lock-ups. This is the area I know the least about. Many of the bugs here are sitting in the upstream project as “New”, if you can help confirm them upstream or even find an older dupe, please do.

Tegra3/nVidia: 6 bugs

We found several bugs that seem to be Tegra3 related, Tegra drivers related, or bugs that we need some input from nVidia on, for example, the sound only works after suspend/resume issue.  Not all of these may really be tegra related issues in the end, many require more investigation.

—–

So these are my top four categories, but that still leaves over half the bugs out. There are some smaller categories, which I’d list as Touch, Performance, and Bluetooth, and then there is Misc aka Everything Else.

Categories aside, another interesting thing I’ve noticed that aside from bugs that are specific to the kernel, drivers, or chipset, almost all the bugs we’ve found were confirmed on other platforms; usually they’re confirmed on a someone’s amd64/i386 laptop. Finding, bringing attention to, and fixing these bugs means shows that we’re achieving one of our goals, which is to fix issues in Ubuntu Core. These fixes will benefit all platforms. There are only a small number of bugs that we have not been able to confirm on other platforms yet, can any of my readers do so?  Here are the ones that stand-out in my mind:

Also I’d like to thank all the new contributors we’ve had in the past couple of weeks, we’re glad for all your help on bugs in any form you can provide it.

Below are the full bug lists for my generated categories:

Kernel:

  • 1068672 webcam support
  • 1072320 please consider adding OTG charging support to kernel
  • 1075549 please include fw_bcmdhd.bin and bcm4330.hcd in linux-firmware for support of the nexus7
  • 1076317 overlayfs support
  • 1070770 bluetoothd dies with glibc malloc memory corruption when used with brcm_patchram
  • 1071259 Setting brightness all the way down actually switches off the display completely
  • 1073499 please consider turning on all possible modules for external USB devices
  • 1073840 Sync kernel configuration with the one from the Ubuntu kernel
  • 1074673 JACK server fails to start

OnBoard:

  • 960537 Dash search box doesn’t unhide Onboard on-screen keyboard
  • 1078554 Onboard doesn’t respect launcher icon size
  • 1081227 onboard should optionally stay hidden if a keyboard is present
  • 1075326 On screen keyboard doesn’t re-position in order to see input
  • 421660 gksu’s and gksudo’s modal password prompt prevents OnBoard’s virtual keyboard input, causing accessibility issues
  • 1079591 onboard can be made thin to the point of unusable
  • 1071508 Onboard onscreen keyboard isn’t always shown when text input selected
  • 1077260 When using software center search, onboard goes away until text box is reslected after entering 2 chars
  • 1077277 Keyboard can’t type into Firefox bookmark dialog

Unity/Nux:

  • 1065638 Unity panels don’t display visuals
  • 1072249 Using desktop switcher via touchscreen causes Unity launcher to stop working
  • 1045256 Dash – It should be possible to vertically scroll the Dash left clicking and dragging
  • 1055949 Unity panel shadow appears as solid black bar on GLES/ARM (Pandaboard, Nexus 7)
  • 1075417 Unity panel/launcher width don’t scale with system DPI/font settings
  • 1070374 unity cannot be cleanly restarted from the command-line on Nexus7

Tegra3/nVidia:

  • 1065644 plymouth causes a hard reset of the nexus
  • 1068804 sound only works after suspend/resume cycle
  • 1070283 after reboot, framebuffer of previous boot appears on screen
  • 1073096 Screen is corrupted between rotations
  • 1067954 control-alt-f1 to bring up a VT shows a blank (black) screen
  • 1070755 screen rotates to portrait sometimes

PS – Thanks to Chris Wayne for vetting my bug category list.

Read more
Matt Fischer

There are dozens of ways that the rest of the community can participate in the Nexus7 project, but I’d like to call out one facet that I’ve been working hard on since I got back from Copenhagen. Chris Wayne and I spend a large portion of our day going through the Nexus7 bug list doing bug triage. In brief, what we do is:

  1. If the bug is unclear, ask the submitter for more info in a comment
  2. Checking for duplicate bug reports inside the Nexus7 project
  3. Confirm that the bug really happens on the Nexus7 device
  4. See if the bug occurs on our laptops/dev boxes (x86 running Quantal)
  5. Search the upstream launchpad projects to see if the bug is known already, and mark the Nexus7 one as a duplicate if so
  6. Search gnome bug reports to see if we can link to one
  7. File upstream LP and gnome bug reports if none exist
  8. Testing fixes from upstream
  9. Set bug priority
All of these are standard Ubuntu Bug Triage tasks that anyone from the community can do. Better yet, all of these except for #3 and maybe #8 can be done without even owning a Nexus7.

So today, I’m officially asking the community to help, if you’re interested in helping with the Nexus7 work and don’t know where to start, bug triage is a great place and we could use your help.

So how do you start?  A good place to start is by reviewing the New bug queue and then following the Triaging guide and try to get enough information so that a developer can get started on it. You should also join the #ubuntu-arm channel on freenode, where we can discuss bug status and priority. Feel free to ping me (mfisch) or Chris (cwayne) if you have questions about a bug or how to help.

You may also consider joining the Ubuntu Bug Squad, and later Ubuntu Bug Control if you want to keep doing this work generally in Ubuntu.

On a personal note: when I first started working on Ubuntu, I joined the Ubuntu Bug Squad because there’s really no better way to learn about the components of Ubuntu than to dive into a bunch of bug reports. After a while doing Bug triage work, I was very comfortable with launchpad and bug triage procedures. I also had a better feel for how the components of the system worked together, it’s amazing how much you can learn from digging into bug reports!

Read more
Matt Fischer

A new Nexus7 image just posted and can installed using the standard installer and install process. However before you rush out and re-install you should note the changes, only one of which requires you to do a full re-install.

The only fix you need to really reinstall for is this hostname fix:

The other changes are all in the kernel. These changes below can be installed by doing sudo apt-get update && sudo apt-get install linux-nexus7. This will upgrade you to version 3.1.10-7.11 of the kernel:

  • Enable ISO support
  • Enable NFS support
  • Add battery information (upower –dump now works)
  • Enable LXC support
  • Enable SND_USB_AUDIO, disable SND_HDA_INTEL

Over the next few weeks you should expect more changes to come through the standard apt-get upgrade process. These will include syncing the kernel config with the standard Ubuntu one and bug fixes in non-kernel packages.
We may not release a new image again until we have nightlies working. Please note that you should NOT enable any of the standard quantal archives and upgrade things from there. That will supercede some of our fixes like the ones in Nux and you will likely end up with an unusable system.

Read more
Matt Fischer

WARNING: This process has changed since the switch to Raring. I don’t yet have a new update for the process.

EDIT: I just added some notes about extracting files from the boot.img in the post.

Several people asked me some questions last week abut how the Nexus7 image is built and how they can hack it. Hopefully this post will help to answer some of those questions. Note that nothing described here is supported, it is just presented here to enable people interested in hacking the image to get going. This process requires the tools simg2img and make_ext4fs which you can download pre-compiled binaries for from here.

Hacking a pre-built image rootfs.img

    1. Take the rootfs.img file as input and use the tool simg2img to unpack it. It will be a large file when unpacked, 28G for the 32GB tablet, 13G for the 16GB tablet, and 6G for the 8GB tablet.

mfisch@caprica:~/build$ ./simg2img rootfs.img rootfs.ext4

    1. Mount the rootfs.ext4 file

mfisch@caprica:~/build$ sudo mount -o loop rootfs.ext4 tmpmnt/

    1. Inside tmpmnt, you’ll find the original rootfs.tar.gz. Copy this file out and unmount the directory. You can also remove the rootfs.ext4 file.


mfisch@caprica:~/build/tmpmnt$ cp rootfs.tar.gz ..
mfisch@caprica:~/build/tmpmnt$ cd ..
mfisch@caprica:~/build$ sudo umount tmpmnt/
mfisch@caprica:~/build$ rm rootfs.ext4

    1. Extract the rootfs.tar.gz


mfisch@caprica:~/build$ tar -xvzf rootfs.tar.gz

    1. The extracted filesystem is in ./binary/casper/filesystem.dir. You can copy files into and out of here or modify files.

Once you’re done with the changes, you need to rebuild the rootfs.img file. The first step is to re-tar and recompress the unpacked files.

mfisch@caprica:~/build$ tar -cvzf rebuilt.tar.gz binary/

From this point you can use the same process we use to build images and then flash them, following the process below.

Building or rebuilding a rootfs.img file

Given a tarball image, our image building script basically does a couple things:

  1. Extract the kernel and initrd from the rootfs.tar.gz
  2. Write a bootimg.cfg file out using the right values for the Nexus 7.
  3. Create a boot.img file using abootimg using the inputs of the kernel, the initrd, the bootimg.cfg. Note: We had to do some work here to make sure that the initrd was small. I think the limit was 2MB.
  4. Take the rootfs.tar.gz, and using the tool make_ext4fs, create a sparse ext4 filesystem and call the output rootfs.img.

We wrote a script to do all this which makes life easier. This process may change as we implement these image builds on cdimage.ubuntu.com and this script may not be updated, but it should be enough to get people hacking. If you do anything cool with this or have fixes for Ubuntu, please let me know or send a patch to one of our bugs.

Hacking/Rebuilding boot.img

After a few questions I decided to add a brief note about how to hack and rebuild the boot.img. It’s pretty simple and uses the abootimg tool which is in universe for quantal.

To extract the files, use abootimg -x

mfisch@caprica:~/upload-scripts$ abootimg -x boot.img
writing boot image config in bootimg.cfg
extracting kernel in zImage
extracting ramdisk in initrd.img

To rebuild, you see see the script I referenced above, or just run abootimg –create:

mfisch@caprica:~/upload-scripts$ abootimg --create newboot.img -k zImage -f ./bootimg.cfg -r initrd.img
reading config file ./bootimg.cfg
reading kernel from zImage
reading ramdisk from initrd.img
Writing Boot Image newboot.img

Read more
Matt Fischer

12 Months at Canonical

Last fall, I gave notice at my old job, my last day was to be October 28, and on November first, I started at Canonical.

My first day at Canonical was interesting, it began early with a drive to the airport and a flight to Orlando for UDS-P. It was a great way to start a new job, I left the early 10″ (250mm) Colorado snow behind for palm trees and meeting my new team. I met most of them while enjoying dinner and beers in the evening breeze of Orlando by the pool at the Caribe Royale.

I had to shovel my deck so I could grill when I had some of my family visit

My wife, left behind in Colorado with my parents and our kid who had just contracted Chicken Pox was less than pleased with these photos taken by the pool at the Caribe Royale

Once I returned to Colorado, I soon discovered my job at Canonical was one of a radical generalist. There had not been a single week that went by where I didn’t do something new or work on something new. Our team’s mission is to take Ubuntu and make it work great for customers on various ARM-based platforms. “Make it work great” means that almost anything you’ve ever used in Ubuntu, we’ve had to fix or tweak during one of our projects. In addition to hardware, we’ve also been able to work on some cool features, like remote login and improving test automation in checkbox, and too many more to mention here.

It’s been a fun, educational, and challenging twelve months and I hope the next twelve continue the trend.

Read more