Ubuntu
update-manager package

restricted component lost from sources.list during upgrade

Bug #68467 reported by Kai Schroeder
6
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

on one of my computers the xserver does not boot after an upgrade to edgy. after the upgrade main universe and multiverse are enabled for edgy-security and edgy-updates but only main is enabled for edgy.
because of that nvidia-glx has not been updated and therefore the xserver fails to start because the nvidia kernel module had been build for the dapper kernel.

my sources.list contained these line (well, not only):

deb ftp://ftp.stw-bonn.de/pub/ubuntu dapper main restricted multiverse universe
deb-src ftp://ftp.stw-bonn.de/pub/ubuntu dapper main restricted multiverse universe

that is a local mirror not available to the public.

those have been commented out by the upgrader.

now i only have (apart from edgy-security and edgy-updates lines)

deb http://archive.ubuntu.com/ubuntu/ edgy main
(and no deb-src line)

btw. i have used the graphical update-notifier and not apt-get dist-upgrade.
editing sources.list manually and invoking a dist-upgrade now fixed it for me.

See original description
Tags: edgy-upgrade
Kai Schroeder (kai-schroeder)
description: updated
Revision history for this message
Caroline Ford (secretlondon) wrote :

I think this is because you are using a local mirror for dapper main.

Revision history for this message
Kai Schroeder (kai-schroeder) wrote :

yes, me too. just for clarification: i am pretty confident the mirror itself works fine - only somehow the upgrader doesn't detect it. does the upgrader search for a list of known mirrors or is it in any way important that the mirror can't be reached from the general internet?

Revision history for this message
Matt Zimmerman (mdz) wrote :

This seems likely to be a problem with your mirror; please try to reproduce the problem using archive.ubuntu.com.

Revision history for this message
Kai Schroeder (kai-schroeder) wrote :

i had a quick look into the source code. The following line in DistUpgrade/DistUpgradeConfigParser.py:
    print c.getListFromFile("Sources","ValidMirrors")

suggests that my initial guess was right. (I have not verified the following carefully - it is just an assumption, but a very likely one) The update-manager searches in sources.list for a known mirror and then does not find one because my mirror is not listed in DistUpgrade/mirrors.cfg. Then it uses a default value (archive.ubuntu.com main). As it is a very common situation to have a local linux / ubuntu mirror at a university to limit the incoming traffic, this should probably be improved.

Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for your bugreport.

Your assumption is correct, the upgrader currently carries a list of valid mirrors and considers other sources as 3rd party sources and drops them. This is something we need to fix. Unfortunately its technically challenging because libapt does not export a way to map a sources.list entry to a VerFileIter to determine more about the archive.

Cheers,
 Michael

Changed in update-manager:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Revision history for this message
Kai Schroeder (kai-schroeder) wrote :

Hi,

two possible workarounds would be

a) if no valid mirror is found, check if nvidia-glx or the ati driver (and probably some other restricted driver) is installed and enable restricted. to lose some programs from multiverse or universe is not a big deal. An Xserver that refuses to boot is - for many people.

b) if no valid mirror is found, search sources.list for the words restricted, universe, multiverse and enable the corresponding repositories. probably with some message box - roughly: "No official Ubuntu mirror has been found. To perform the upgrade we have to switch to an official mirror. Your configuration suggests that you are using components from the Universe, Multiverse or Restricted repositories. Please note that these are not officially supported."

some combination - first a) then b) could also work.

Kai

Revision history for this message
Reinhard Tartler (siretart) wrote :

why do we need a whitelist for 'valid' mirrors anyway? I don't think that having a private mirror for e.g. university labs is an uncommon use-case

Revision history for this message
Joachim Sauer (saua) wrote :

I think the fix for bug #73463 fixed this one as well, at least it did for me.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Fixed by patch in bug 73463

  * DistUpgrade/DistUpgradeControler.py:
    - fix sources.list rewriting for people with internal or
      unofficial mirrors (LP#73463)

Changed in update-manager:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.