Posts Tagged ‘Karmic’
In the 9.10 release of Ubuntu Server Edition, we introduced something new for people who are exploring cloud computing using Amazon’s Elastic Compute Cloud (EC2).
If you haven’t tried it yet, EC2 is essentially an API for managing virtual servers. Using a command line tool or script, you request a new VM, and moments later, it is ready for you to ssh in, preconfigured with your ssh public key. When you’re finished, you shut it down, and receive a bill for only the time and Internet bandwidth you used (about $0.10 per hour and $0.10-$0.17 per gigabyte). There is no downloading, no installing, and no hardware required for you to set up a server. The first step is to boot it up.
Starting with release 9.10, every release of Ubuntu Server Edition is simultaneously available on EC2. This means you can have a new Ubuntu server up and running using your EC2 account with a single command. Ready-to-run Ubuntu machine images are published on EC2 whenever a new Ubuntu release or milestone is available. All you need to know is the AMI, a short string which uniquely identifies the image you want. The AMIs for the 9.10 release are on the download page, in 32- and 64-bit versions for US and Europe zones.
Similarly, all Server Edition development builds are available on EC2 as well. When the first builds of Lucid (Ubuntu 10.04) are created, there will be AMIs for those as well. If you want to test drive a new feature, or check compatibility with your application, just fire up a new instance on EC2, do your work, and then terminate it. The whole process can be completed in less than a minute. If you find a problem in our development builds, just run ubuntu-bug on the virtual machine as you normally would, and apport will automatically attach the relevant EC2 details to your bug report.
As I mentioned above, EC2 does charge for Internet bandwidth. It does not charge for local bandwidth within your EC2 zone. For this reason, Canonical has set up Ubuntu archive mirrors within EC2, so that you can download all Ubuntu packages and updates for free. Ubuntu virtual machines inside EC2 are automatically configured to use the appropriate mirror, so you don’t need to think about it.
This is an exciting step forward in making Ubuntu more convenient and powerful to use on EC2, and I encourage you to give it a try. If you’ve never used EC2 before, just follow our Starter’s Guide to get set up.
On a recent trip abroad, I brought my laptop and planned to work online at the airport while waiting for my flight. I found a power socket, opened my laptop, and got connected with no fuss at all. I was even able to connect my G1 phone at the same time, since the WiFi was free, and sync my calendar and RSS feeds.
After 15 minutes or so, my laptop fell off the network. I couldn’t even see the access point anymore. I spent the next few minutes grumbling and running terminal commands to try to understand what was wrong, and decided that the problem must be with the access point. Then I switched on my phone and noticed that it connected without a problem!
Grumbling louder, I spent quite some time trying to figure out the problem. The crucial clue was provided by Android, which provides a configuration setting for the number of WiFi channels to use. It can be set to 11, 13 or 14. I tried setting the phone to 11 channels, to match what was reported by my laptop:
iwlagn 0000:03:00.0: Tunable channels: 11 802.11bg, 13 802.11a channels
…and then the phone couldn’t connect either! I couldn’t get Android to show me the channel information for the access point, but by trying the settings, I could infer that it was using channel 12 or 13, and must have switched channels since I started working.
So, how to get my laptop to see these extra channels? I immediately suspected the regulatory settings, since a new regulatory framework had recently been developed and added to Ubuntu. I dug through man pages, I read database dumps, and I searched Google using my phone. Everything I found told me that I was doing the right thing already, and that channels 12-14 (which were perfectly legal in the country where I was) should be available.
Then I came across a few references which told me that my WiFi card (Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)) was believed to be hardware crippled to support only 11 channels. I had purchased this laptop in the US, but don’t live there anymore, and certainly didn’t want to concern myself with US regulations while outside of the US.
Tough luck for me, it seems. If I want to be able to get online in other countries reliably, it seems I’ll need to buy a new card.
I rebooted my laptop today, to effect the latest updates to Karmic. Well, actually, that was a side effect. I had to reboot because my Intel i965 hung (again). I’ve written a watchdog script which detects this condition and attempts to gather debug information, but it hung trying to read some files in /proc/dri.
After the reboot, new problems so far include:
- My keymap is set to USA at the gdm greeter (rather than USA/dvorak as was correctly done before): bug 401047 (hey, we’ve passed bug 400000 recently)
- I found myself unable to launch any X applications from a terminal, because I was unconditionally setting the XAUTHORITY environment variable in my ~/.zshenv, and apparently gdm is now putting it in /var/run/gdm (this one was my fault)
- I’ve ended up with two volume control applets with different behavior. One is gnome-volume-control-applet, and the other seems like it might be built into gnome-panel
- indicator-applet crashed: bug 401051
- Reporting the above bugs required several attempts, because Firefox 3.5 crashed intermittently trying to open a new tab:
Gdk-ERROR **: The program 'firefox-3.5' received an X Window System error: bug 401055
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
Things which have improved:
- My monitor’s graphics modes are now detected correctly
- 2.6.31 seems to be stable for me now
Problems which are still present:
Rebooting can be an exciting experience when tracking the bleeding edge of Ubuntu development. Today, after installing the latest round of updates (including a new kernel, the latest grub 2, and all sorts of other important things, I rebooted. A few things happened:
- My system failed to boot at first, because grub.cfg had been updated to use search --no-floppy, which wasn’t supported by the version of GRUB actually living in my MBR. I think it might be nicer if something as critical as a boot loader were more forgiving about this sort of thing, but at least GRUB’s interactive editor makes this easy to work around at boot time. A grub-install /dev/sda from single-user mode should fix it permanently.
- I noticed the console being set to graphics mode very early, signaling the arrival of kernel mode setting. When the X server started up, it did so without any flickering, creating a smooth transition from startup into the login screen.
- Presumably due to the above, my displays started to behave differently, with the external LCD set to its native mode (1920×1200) and the internal one set to its native mode (1680×1050), with the latter displaying an offset picture (much of the login screen was “off the edge” of the display)
I was hoping to see the lightning-fast resume times I’d observed in some KMS demos, but it still takes a few seconds on my system. At least it still works, with all this change. Onward and upward!
GRUB 2 is now the default for new installations of Ubuntu, but as explained in the announcement, existing GRUB 0.x systems won’t be automatically converted to GRUB 2. This is because switching to a new PC boot loader is tricky business, and it’s generally best to leave it alone if it’s working.
The main exception to this rule is, of course, the community of people who test the bleeding edge of Ubuntu development. Yes, perhaps even you! If you’re adventurous enough to be running Karmic in this early stage of its development, a little boot loader trouble wouldn’t kill you, would it? What’s the worst that could happen? You would have to boot from your handy Ubuntu USB drive, mount your root filesystem, and clean up the mess by hand. Maybe it’s been a while since you had to recover your system in this way, and it would be good practice!
Thus, I convinced myself to make the switch to GRUB 2. I wanted to be confident that Ubuntu 9.04 would continue to provide a great experience on my laptop for anyone installing it afresh.
It turns out, this is really easy to do, and not as risky as I thought:
sudo apt-get install grub-pc
This will remove the grub 0.x package from your system, but don’t worry. It stays installed in /boot/grub even though the package is removed. While it’s installing, the grub-pc package explains exactly what to expect, and gives you a choice of whether to preserve your existing setup by chain-loading GRUB 2 from the GRUB 0.x menu. This is the default, and is a good way to confirm that GRUB 2 works properly on your system before making the final leap.
It builds a new configuration for you in /boot/grub/grub.cfg, preserving a few key bits from the old /boot/grub/menu.lst. This takes a surprisingly long time (I suspect os-prober, which has always seemed curiously slow).
When it finished, I rebooted, let it start up with the defaults (not touching any keys), and everything came up fine. To seal the deal, I followed the instructions given earlier and ran:
sudo upgrade-from-grub-legacy to install GRUB 2 in the MBR, replacing GRUB 0.x and rebooted again to test that.
Everything just worked.
Refer to the testing instructions for more details, and add your system to the list if you test it.
We are a large community, but only a small number of people can travel to attend UDS in person. So, over the years, we’ve experimented with different approaches to enable remote participation in UDS. If you participated in UDS remotely (for example, using the audio feed, IRC, Gobby, etc.), please tell us about your experience by filling out this survey:
If you registered to attend in person in Barcelona, you’ll be receiving an email with a (different) link to the (same) survey. Please use that one instead, so that we can easily sort feedback from local and remote participants.