Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a cluster of about 50 ubuntu nodes which are currently running maverick release. I'd like to upgrade them to oneiric, but I'm having a difficulty choosing the right tools.

I know ubuntu has the 'unattended-upgrade' utility, but it's only meant for security upgrades and cannot switch the whole release. Is there anything similar that can?

For now it seems that the only choice is to use something like fabric/pssh/capistrano and make it run 'do-release-upgrade' on each of the servers. But 'do-release-upgrade' is interactive and requires some input from the user during the upgrade. There doesn't seem to be any --unattended parameter for the 'do-release-upgrade' tool.

What kind of tactics do you use in situations like this?


share|improve this question
What levels of downtime are acceptable? Are they providing some kind of external (web) service, or are they more of a computing cluster? – andol Jan 9 '12 at 21:07
They are physical kiosk computers with touchscreens providing some services to people. Downtime is acceptable for a few hours during nighttime. – Akarot Jan 9 '12 at 21:34
up vote 4 down vote accepted

I'm the one who wrote that guide about using apt-get dist-upgrade and yes it's certainly true that there are many differences between dist-upgrade and do-release-upgrade. I have now written a new guide on how to do the release upgrade automatically with the do-release-upgrade and it's actually very simple. You can find the new guide here:

Also in this one I'm answering yes to all questions during the upgrade but you can define the answers in the command if you know the exact order of the questions that require interaction. You should try it first in test environment as that way you could also find out the questions.

The guide includes a Fabric example as well.

share|improve this answer
Ha, this is funny. :) Although it's a bit error-prone it gets the job done. But I would still really like to see ubuntu implementing some kind of preseeding mechanism for the do-release-upgrade where I could be more specific about the behavior of the tool. – Akarot Jun 3 '12 at 12:51
With piped input, do-release-upgrade returns the error Must be connected to a terminal and refuse to do anything. Is it possible to get around that? – netvope Nov 6 '12 at 6:56

In situations like this, assuming all your machines are identical (or minimally different) I would suggest using a tool like Puppet, Chef, or radmind to manage your systems.

This requires more time investment up front, but as a long-term solution it will be tremendously beneficial for you.

Speaking chiefly from my experience with radmind the general principle is to upgrade a template machine, then make all your other hosts look like the template. The major advantages being consistency across hosts & automation of the actual upgrade steps.
Both puppet and chef offer many additional features compared to radmind, and have larger user communities.
Search around on ServerFault for additional information on these tools

share|improve this answer
An added bonus based on your comment about these being kiosks that can take some downtime: You can schedule a nightly check against the deployment server. This buys you a regular consistency check (and even a fixup of any variances in the event a machine is compromised) – voretaq7 Jan 9 '12 at 22:56
The servers are already using puppet for configuration and it's working great, but I have a feeling that puppet can only natively operate within a single release. If I'm to use puppet for performing the upgrade I'd have to do what @d34dh0r53 suggested (exec: apt-get dist-upgrade). Or maybe I'm missing something? – Akarot Jan 10 '12 at 1:27
For now it seems that the best option is an identical test environment which is used to test 'apt-get dist-upgrade' with all the --force-yes sillines. When I'm sure the update gets through, I can distribute it with puppet/fabric. I'll try to find out if puppet can be used more effectively to approach this problem, but so far my googling has been unsuccessful. – Akarot Jan 10 '12 at 1:38
@akarot Puppet (and Chef to an extent) is really more config-file-and-package-set oriented -- It can do an OS upgrade, but it's not great at it. This link has some info on their philosophy re: installing/upgrading. This is part of why I'm still using radmind (which is more file-oriented "Make the system look like this" -- Less efficient in many ways, but better at pushing OS upgrades down the pipe – voretaq7 Jan 10 '12 at 18:37

A little Googling brought me to this:

Should work from Maverick to Oneiric as well.

share|improve this answer
This will work, however you should mount a Scratch Monkey and make sure you have positive backups and a good backout plan -- The "say yes to all the prompts" approach can do some pretty nasty things to customized configurations (I had one that broke every time on the second reboot - never did figure out what caused the trouble, and had to re-image a bunch of machines as a result). – voretaq7 Jan 9 '12 at 23:00
I've looked up on differences between 'do-release-upgrade' and 'apt-get dist-upgrade' and there are quitea few! Ubuntu ships a whole set of patches, config files and other release specific fixes when doing an upgrade with 'do-release-upgrade'. So there indeed is a notable difference between the two approaches. But as I said before, 'do-release-upgrade' is interactive and therefore unsuitable for large scale upgrading. Is ubuntu really without any kind of official support for a job like this?! – Akarot Jan 10 '12 at 14:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.