Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.
Sign up to join this community
How does Ubuntu upgrade seamlessly to a newer distribution, while the operating system is still running? I'm upgrading from 10.10 to 11.04, and I've upgraded several times before, and it's as simple as running update-manager -d and downloading and installing them, then rebooting.
How exactly does this work though? How is the upgrade manager able to update the operating system while it is still in use?
Here a more detailed description of the process. Sorry the text got so long.
My experience stems from Debian, for which the entire packaging and upgrade system used in Ubuntu was originally invented. The daily Ubuntu security upgrades correspond to running apt-get upgrade which normally doesn't remove any software. The big release upgrades correspond to a apt-get dist-upgrade during which software packages can be exchanged completely.
Actually the very low level components are normally not exchanged during a release upgrade. Immediately after the upgrade you should find two kernel and initrd images in your /boot directory. This is because unlike programs kernel components are not interchangable so well. If the need arises to load new device drivers during the upgrade, those must be compatible with the running kernel. After the system boots up with the new kernel, the old one can be removed. Last time I checked this one thing had to be done manually, I don't know how the current updater handles this. This is BTW. the main reason, why the kernel image bears its version number in the file name - so you can have different kernel versions installed at the same time. Same for the module path (/lib/modules/...)
Software packages are upgraded one by one, starting with the lowest packages in the dependency hirarchy. Those are normally program librarys like libc and other ones. The sequence in which packages are updated is however not hardcoded but dynamically calculated as package dependencies are resolved. In most cases old programs can function with new librarys, so it's not so problematic if those librarys get replaced first.
You have to understand here, that the system differentiates between manually installed packages (i.e. the packages which installation you directly requested yourself, i.e. chromium) and automatically installed packages, which where only installed to fulfill dependencies of manually installed packages (and dependencies of those dependencies).
For each manually installed program, the updater just looks for a newer version. Often those programs are just meta packages like "ubuntu-desktop", which contains no data, and just dependencies. New versions of dependent libraries will be pulled in, as they are requested by directly updated (manually requested) programs. The updater will always try to install the newest usable version of any dependent package (during any upgrdade not just release upgrades).
Programs which cannot function with the new library versions cannot be started during the time after the library is upgraded, and before the program itself is upgraded as well. If those programs should already be running before the library upgrade they will however continue to run, because the old library version remains in memory as long as it remains in use. Same goes for programs which were started before they get upgraded. Those will not provide new features until they are terminated and restarted.
After the update some libraries (or dependencies in general) will be orphaned. Those are libraries which were required by old program versions, but are no longer required by the new versions. Since these packages are marked as automatically installed, and since no manually installed prgram relates to them anymore these packages can easily be located and removed. You can even observe this as the last step of the update process (the updater sais "removing obsolete packages" or something similar).
Some packages will be installed, which where not installed before, those are simply new dependencies, which are marked as automatically installed, and can be removed, should the requirement for them vanish in the future.
This mechanism even allows the exchange of entire user programs. Like for example switching from Gnome2 to Unity. Since both are just automatic dependencies of ubuntu-desktop, which is one of the few packages, for which new versions are actually requested in the first place.
Programs do normally not depend on a specific version of the OS kernel, so they will normally work fine with the running kernel.
Apart from all this I suspect the Ubuntu updater throws some specific fixes and workarounds into the mix, to circumvent situations where this theory breaks.
As you can see during the update there are very well conditions in which the system is only usable to a limited part. Should something go wrong during the update you will most likely be left with a broken system. Often even one which cannot easily be repaired, since the upgrade program can be affected as well. Remember, programs with broken dependencies can continue to function, but not be restarted, as long as the dependencies are broken, this goes for the updater as well.
You can use the command line program apt-mark to find out which packages are marked as manually installed and which have been automatically installed. You can also switch those marks using the same program. This will directly affect the update process.
In a more complex software setup the Updater will sometimes ask you to resolve a dependency manually. I.e. when one manually installed program gets updated and requests a new version of a library while another manually installed program depends on the old version of the same library and cannot work with the new one. You will then have to make your choice, either to relinquish one of those programs or to refrain from upgrading both. Since dependencies are often complex this can get very messy very fast (you might have heard of the term "dependency hell").
Now to the specific questions:
Just ask me if you still have any more questions.
man apt-get. I find it is often useful to use the release specifying command syntax like apt-get -t intrepid install foo/jaunty bar/oneiric etc..., just examples. Actually this makes more sense with Debian where you sometimes mix releases, under Ubuntu this is less customary. Interesting topics could also be apt-pinning and setting packages on hold.
Nov 1, 2012 at 22:21
From my experience I would assume that while packages and modules are running they are held in memory and don't refer back to their copy on the hard drive much. You can see this if you run a program in ubuntu and then remove the related packages while its running. It will keep running, but if you close it, you can't restart it.
I would assume the same happens with a distribution upgrade. All of the packages related to the original version of ubuntu are still running even though they have been removed and replace with the new ones, so when they are finally stopped on a system restart, the new packages take over.
At the filesystem level, unlike Windows, on a Unix system you can delete files that are open. Deletion just removes the name of the file, not its contents, so any programs that still have the file open can still access it until they close the file, and only then is the data freed.
So the upgrade process simply removes the old files, replaces them with the new ones, and for certain system services, restarts them so the new version is running.
There are one or two components that can not be restarted without rebooting the whole computer, so after upgrading those, you get prompted to reboot so you will be using the new version.
How can Linux update itself while it's still in use?
Mainly because Linux (and with it, most distributions) is simply designed that way. Being able to upgrade a package on a running system is a goal for most Linux based distributions.
With Linux, there is nothing that would prevent the package manager process from writing to a file on disk, even if that file is currently open by an application or the file is an executable or shared library of code that is currently running. On a very low-level, there are locks that protect access to a file during a single write/read operation, but these are never designed to be held for more than a matter of milliseconds and any other application trying to write to the same file will simply wait those milliseconds.
You can replace an executable file while it's running and it won't actually do anything to the running process, because the process no longer needs the file on disk - all of its code has already been loaded into memory.
That is why on Linux, even though you can upgrade an application while it's running, the upgrade won't actually take effect until the application you upgraded is restarted. In the case of upgrading a background process such as a system service, that service would need to be restarted. In the case that you've upgraded the kernel, then this means a reboot.
Won't replacing a program's files while it's running break some programs?
Some of the packages in a Linux distribution will contain installation instructions instructing the package manager to stop certain system services while the package updates, and re-start those services after the update is complete. This prevents situations where, for example, the configuration files for a particular service are updated and the running version of the service may not be able to cope with the newer version of the configuration files.
In general, regular user applications require no configuration files to run, except for files it generates itself and places in locations such as the users' home directories. So these won't be touched by the package manager when updating.
apt, handles the certain packages and dependencies during the upgrade process.
This is similar to another feature. Hope this helps to understand the basic process.
I am referring to the capability to "switch root" when the operating system boots.
When the operating system is booting, the root filesystem (read: "/") is initially available only in RAM. While this boot process is running, it switches / from the RAM to the / filesystem on the hard disk.
