NetworklessInstallationFixes
|
Size: 4606
Comment:
|
Size: 4858
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 17: | Line 17: |
| a network connection to the package repository server can not be | a network connection to the package repository server cannot be |
| Line 28: | Line 28: |
| === Problem === So if I choose Russian as my native language and my internet connection is down and Ubuntu installs in English because it's the default language, how happy do you think I'd be? Do you think I'd be impressed with Ubuntu? |
|
| Line 31: | Line 34: |
| pkgAcquire::Item::StatTransientNetworkError if it encounters a "Timeout", "TmpResolveFailure" or "ConnectionRefused" error. |
pkgAcquire::Item::Stat``Transient``Network``Error if it encounters a "Timeout", "Tmp``Resolve``Failure" or "Connection``Refused" error. |
| Line 34: | Line 37: |
| On a TransientNetworkError, libapt will stop trying to download items | On a Transient``Network``Error, libapt will stop trying to download items |
| Line 40: | Line 43: |
| "ResolveFailure". On a system with working DNS but blocked access to the archive the acquire::http::timeout will be run for each |
"Resolve``Failure". On a system with working DNS but blocked access to the archive the Acquire::http::Timeout will be run for each |
| Line 48: | Line 51: |
| multiverse" line for each "archive, security, updates. | multiverse" line for each "archive, security, updates". |
| Line 103: | Line 106: |
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: networkless-installation-fixes
Packages affected: apt, apt-setup, ubiquity
Summary
A networkless installation in ubiquity is currently not as smooth as it could be. One of the issues is the apt network timeout.
Release Note
The package management system is now more robust against unusual network setups and will no longer take a long time to timeout when a network connection to the package repository server cannot be established during install.
Rationale
Installing without network is very common and should be as painless as possible. Nevertheless, when a network is available, the installer should take the opportunity to install language packs that are not available on the local installation medium.
Use Cases
- Bob installs Ubuntu in a language not available on the CD without a network connected. The installer pauses briefly while it tries to download language packs, but continues without undue delay.
Problem
So if I choose Russian as my native language and my internet connection is down and Ubuntu installs in English because it's the default language, how happy do you think I'd be? Do you think I'd be impressed with Ubuntu?
Current status in libapt
The current implementation in libapt will set the acquire state to pkgAcquire::Item::StatTransientNetworkError if it encounters a "Timeout", "TmpResolveFailure" or "ConnectionRefused" error.
On a TransientNetworkError, libapt will stop trying to download items for any sources.list deb/deb-src pair after trying to download the Release.gpg file. The connection timeout can be controlled via "Acquire::http::Timeout".
On a system with no network at all the resolver will exit quickly with "ResolveFailure". On a system with working DNS but blocked access to the archive the Acquire::http::Timeout will be run for each deb/deb-src pair.
That is currently 9 times because of the way the sources.list is written (lines for "main restricted","universe","multiverse" for each archive,security,gutsy-updates). It could be collapsed to 3 times if the sources.list would contain one "main restricted universe multiverse" line for each "archive, security, updates".
One problem currently is that translations are queued for download as well and timeout. This should be fixed for hardy. A workaround is to set APT::Acquire::Translation=none.
Design
libapt should be fixed to remember previous network failures on a given host (in the same apt-get call) and give up immediately.
apt-setup currently feeds a single source line to apt for each line it wants to add to the sources.list. Instead, if it is not going to comment out lines on failure, it should pass the entire output of each generator to apt in a single chunk.
This means, that in the worst case we timeout on 3 network sources (archive.ubuntu.com, security.ubuntu.com, archive.canonical.com). With a timeout of 10s per source this is 30s. To mitigate this further, apt-setup should use a cancellable debconf progress bar while running apt-get update (and map Cancel to SIGINT), in order that a user can explicitly cancel an update which will never complete.
ubiquity should fetch the network proxy from gconf immediately before running apt-setup, rather than relying on gksu to have passed it (which requires the user to have set the proxy before starting ubiquity). In addition, since in Hardy we will default to running ubiquity standalone, we will add an option to ubiquity's Advanced dialog to set the HTTP proxy.
Finally, we should return to ensuring that sources.list lines are never commented out on failure, which has been the intention in Ubuntu installations for some time but stymied by the lack of implementation of this specification.
Test/Demo Plan
The following network problems can occur:
- no network at all
- no working DNS
- DNS but no connection to the outside world
- firewall rules that reject packets
- firewall rules that drop packets
The first two (the most common cases) and the last case should result in really fast timeouts with the current code already (this needs to be verified). The remaining cases are problematic and need to be fixed.
We need to set up a test framework so that we can monitor how well we do (possibly use a VM/emulator). Both ubiquity and d-i should be tested for correct behavior. The SIGINT handler in apt also needs to be tested; all the tests need to go into the apt regression test suite.
NetworklessInstallationFixes (last edited 2008-08-06 16:41:32 by localhost)