versehentliches dist-upgrade von lenny-backports

[DocJunioR]

hab neulich versehentlich (cmd history und schreiende kinder) ein dist-upgrade von den lenny-backports gefahren (und mich gewundert, warum das so viel ist) und seitdem ständig probleme mit meinem lenny-laptop.

gibts ne sinnhafte möglichkeit, das wieder runter zu kratzen?

[debianoli]

Welche Probleme hast du denn? Hast du den Kernel aktualisiert? Evtl reicht es schon, wenn du mit einem anderen Kernel startest.

Ansonsten: Schau ins log von apt bzw aptitude unter /var/log

Dort findest du die Pakete, die aktualisiert wurden. Dann die sources.list vom backport-Eintrag befreien, update fahren und die entsprechenden Pakete per remove entfernen und dann wiederinstallieren.

[Saxman]

Dort findest du die Pakete, die aktualisiert wurden. Dann die sources.list vom backport-Eintrag befreien, update fahren und die entsprechenden Pakete per remove entfernen und dann wiederinstallieren.

Beser ist ein

Code: Alles auswählen

aptitude install Paketname/stable

[ThorstenS]

Das hier listet dir die bpo Pakete:

Code: Alles auswählen

apt-show-versions | grep ~bpo | awk '{ print $1}'

Ich hatte letzten Februar auch so einen Unfall unter etch. Davon stammt das Script hier, welches du dir noch anpassen musst:

Code: Alles auswählen

1#	!/bin/sh
2	
3	# Alle Pakete holen, die noch von bpo stammen. Ausgenommen cfengine und incronn.
4	# vim wird ausgenommen, weil es über security.debian.org schon zur Verfügung
5	# gestellt wird und dieses Script das nicht berücksichtigt.
6	#                                      Thorsten Strusch <t@strus.ch> 2009-03-04 #
7	#################################################################################
8	
9
10	export http_proxy="http://proxy:8080/"
11	
12	mkdir -p debs && cd debs
13	
14	LIST=$(apt-show-versions | grep ~bpo | awk '{ print $1}' | egrep -v 'cfengine|incron|vim')
15	
16	for P in $LIST; do
17	        # VERSION=$(apt-cache policy $P | grep -B1 "500 " | awk '!/http/ { print $1 }' | tail -1)
18	        # aptitude download ${P}=${VERSION#* -- }
19	        VERSION=$(apt-cache policy $P | grep -B1 "500 " | awk '!/http/ { print $1 }' )
20	        aptitude download ${P}=${VERSION}
21	done
22	
23	# Jetzt die mir bekannten Pakete, die schon in security sind: (Stand 2009-03-04)
24	aptitude download  vim-common=1:7.0-122+1etch5 vim-runtime=1:7.0-122+1etch5 vim=1:7.0-122+1etch5
25	
26	# wirklich downgraden?
27	a=""
28	echo -e "Die Pakete werden jetzt installiert.\nWenn du das nicht möchtest -> STRG+C"
29	read a
30	
31	#echo "force-confold" >>  /etc/dpkg/dpkg.cfg
32	export DEBIAN_FRONTEND=noninteractive
33	dpkg -i *deb
34	
35	#echo -e "fertig. Evtl. nimmst du noch die letzte Zeile in der /etc/dpkg/dpkg.cfg wieder heraus"

[DocJunioR]

@ThorstenS: also ich hab gerade das Script zum Laufen gebracht, jetzt lädt es fröhlich Pakete runter.
Es gibt allerdings Pakete, die er nicht finden kann. Die Fehlermeldung sieht dann so aus:
E: Konnte kein Paket namens »2:3.2.5-4lenny8« finden

hab nen cut eingebaut, weil er mir sonst immer lenny-backports für das paket [paketname] herunterladen wollte:
LIST=$(apt-show-versions | grep ~bpo | awk '{ print $1}' | cut -d'/' -f1 | egrep -v 'cfengine|incron|vim|openoffice.org.*|wicd|flashplugin-nonfree|geany')

Ooder war des falsch? Möchte nicht nen noch größeres Kuddelmuddel haben als es so schon eines ist..

[ThorstenS]

Und, hats geklappt - ich schätze du hast die bpo-Einträge noch in der source.list stehen gehabt, oder?
Der Vorschlag von saxmann aptitude install Paketname/stable zu nutzen wäre die einfacherer Variante, die kannte ich letzes Jahr noch nicht. -t stable geht IMHO auch.

[DocJunioR]

das werd ich mal ausprobieren. hab das script noch nicht zuende ausgeführt. will erst mal meine daten sichern..

[KBDCALLS]

Im Prinzip kann man doch garnicht ein versehentliches full-upgrade oder dist-upgrade mit den Backports machen. Wenn man nichts an den Preferences dreht , das muß man sich sogar um das Upgrade der Backportpakete selbst kümmern. Die Release Datei von den Backports ist so ausgelegt, das diese automatisch eine 1 erhalten.

http://debiananwenderhandbuch.de/apt-ge ... orit%E4ten

[rendegast]

Im Prinzip kann man doch garnicht ein versehentliches full-upgrade oder dist-upgrade mit den Backports machen. Wenn man nichts an den Preferences dreht , das muß man sich sogar um das Upgrade der Backportpakete selbst kümmern. Die Release Datei von den Backports ist so ausgelegt, das diese automatisch eine 1 erhalten.

backports-Release

Origin: Backports.org archive
Label: Backports.org archive
Suite: lenny-backports
Version: None
Codename: lenny-backports
...

lenny-Release

Origin: Debian
Label: Debian
Suite: stable
Version: 5.0.4
Codename: lenny
...

Ich lese die man-page und den Link so (ist auch meine Erfahrung)

Priorität 100
Wenn das Paket bereits installiert ist.
Priorität 500
Wenn das Paket nicht installiert ist und auch nicht zum Ziel-Release gehört.

ist der Standard für irgendwie erreichbare Pakete, für die keine weiteres Pinning gemacht wird,
Von allen passenden Paketen wird das mit der höchsten Versionsnummer genommen
(da vorangestellt nochmal die "generation"(?) '1:' '2:' usw., Bsp.:
"Version: 3:4.7.0.1-1
...
Filename: pool/main/m/mc/mc_4.7.0.1-1_i386.deb")

Damit backports bei einem dist-upgrade nicht berücksichtigt wird, müßte also explizit die Target-Release angegeben werden für

Priorität 990
Wenn das Paket nicht installiert ist und zum Ziel-Release gehört.

sonst würde zBsp. von den beiden
exim4 (4.71-2~bpo50+1)
exim4 (4.69-9)
die backports-Version eingespielt.



Der Vorteil ist aber, die Version von backports-Paketen hat immer das "bpo",
wonach sich leicht suchen läßt:

Code: Alles auswählen

dpkg -l  |  grep bpo  [|  awk  '{print $2}']

und mit

Code: Alles auswählen

Aptitude::Purge-Unused "true";

in /etc/apt.conf lassen sich mittels 'aptitude purge' Pakete und Abhängigkeiten recht rückstandslos entfernen.

Hint: Bei den Kernelpaketen 2.6.3* werden bei Installation *.bin-Dateien erstellt,
die bei Deinstallation nicht berücksichtigt werden, diese aber zum Stolpern bringen.
/lib/modules/KERNEL/ und /var/lib/dpkg/info/linux-image-KERNEL.* müssen dann von Hand gelöscht werden.

[KBDCALLS]

backports-Release

Origin: Backports.org archive
Label: Backports.org archive
Suite: lenny-backports
Version: None
Codename: lenny-backports
...

Da hast du das wichtigste vergessen.

1 Origin: Backports.org archive
2 Label: Backports.org archive
3 Suite: lenny-backports
4 Version: None
5 Codename: lenny-backports
6 Date: Wed, 07 Apr 2010 08:37:37 UTC
7 NotAutomatic: yes
8 Architectures: alpha amd64 arm armel hppa i386 ia64 mips mipsel powerpc s390 sparc
9 Components: main contrib non-free
10 Description: Backports for the Lenny Distribution
11 MD5Sum:

Auf dieser Seite steht was man für Prioritys wählen muß damit ein installiertes Paket aus den Backports automatisch geupgradet wird. (Mindestestns Priority 101reicht aber dafür) Die generelle Installationsprozedur bleibt ansonten die gleiche

Und das passiert wenn man ohne Priority Datei für apt/aptitude arbeitet. Damit es nicht zu lang wird habe ich die Ausgabe von apt-cache policy gekürzt. Und damit funktionieren dann die automatischen Upgrades nicht mehr.

matthias@svetlana:~$ apt-cache policy
Paketdateien:
100 /var/lib/dpkg/status
release a=now
1 ftp://svetlana lenny-backports/non-free Packages
release v=None,o=Backports.org archive,a=lenny-backports,l=Backports.org archive,c=non-free
origin svetlana
1 ftp://svetlana lenny-backports/main Packages
release v=None,o=Backports.org archive,a=lenny-backports,l=Backports.org archive,c=main
origin svetlana
1 ftp://svetlana lenny-backports/contrib Packages
release v=None,o=Backports.org archive,a=lenny-backports,l=Backports.org archive,c=contrib
origin svetlana
500 ftp://svetlana lenny/updates/non-free Packages
release v=5.0,o=Debian,a=stable,l=Debian-Security,c=non-free
origin svetlana

PS: Mit experimental Pakten würde das gleiche passieren.

[rendegast]

@KBDCALLS
Yepp, hätte nicht gedacht, daß da ein Archiv sonderbehandelt wird, finde ich auch nicht gut.

Code: Alles auswählen

# apt-cache policy acpid firmware-linux-nonfree
acpid:
  Installed: 1:2.0.3-1
  Candidate: 1:2.0.3-1
  Version table:
 *** 1:2.0.3-1 0
        500 http://ftp2.de.debian.org testing/main Packages
        -50 http://ftp2.de.debian.org unstable/main Packages
        100 /var/lib/dpkg/status
     1.0.10-5~bpo50+1 0
          1 http://ftp.de.debian.org lenny-backports/main Packages
     1.0.8-1lenny2 0
        500 http://security.debian.org stable/updates/main Packages
         -5 http://ftp2.de.debian.org stable/main Packages
firmware-linux-nonfree:
  Installed: (none)
  Candidate: 0.23
  Version table:
     0.23 0
        500 http://ftp2.de.debian.org testing/non-free Packages
        -50 http://ftp2.de.debian.org unstable/non-free Packages
     0.23~bpo50+1 0
          1 http://ftp.de.debian.org lenny-backports/non-free Packages

Und damit hast Du Recht, daß dist-upgrade / full-upgrade die backports nicht anrührt.

Aber ein schon installiertes backports würde dann aber auch nicht "mitgezogen",
und würde ob seiner höheren Versionsnummer auch das Einspielen eines korrigierten regulären Paketes verhindern.
(Für ein 'dist-upgrade' innerhalb einer Distribution,
nicht beim Distributionswechsel stable->testing, denn die backports-Versionen liegen scheinbar meist zwischen stable und testing.)
-> Potentielles Osterei.

[KBDCALLS]

Aber ein schon installiertes backports würde dann aber auch nicht "mitgezogen",
und würde ob seiner höheren Versionsnummer auch das Einspielen eines korrigierten regulären Paketes verhindern.

Das war ja auch der Auslöser das ich da genauer hingesehen habe. Bei 1 oder 2 Paketen ist das nich weiter Tragisch wenn die bei einem dist-upgrade nicht berücksichtigt werden. Wenn das dann Opennoffice.org betrifft verhält sich die Sache etwas anders, und wird dann etwas mühsam.