Nutzung von squeeze-proposed-updates in Produktivsystemen
> -----Ursprüngliche Nachricht-----
> Von: Sven Hoexter [mailto:sven@timegate.de]
> Gesendet: Mittwoch, 11. Mai 2011 01:07
> An: debian-user-german@lists.debian.org
> Betreff: Re: Nutzung von squeeze-proposed-updates in Produktivsystemen
>
> On Tue, May 10, 2011 at 10:19:50PM +0200, Guido Hecken wrote:
>
> Hi,
>
> > Was mir aber (noch) nicht wirklich einleuchtet, ist die Frage, ob man denn wieder
> "geordnet" auf den Ursprungszustand zurückkommt, wenn man die Einträge in der
> sources.list wieder zurücksetzt, also ohne die proposed-updates.
> > Also etwa so:
> > - proposed-updates eintragen
> > - apt-get update
> > - apt-get upgrade
> > - reboot
> > - testen
> > - bei fehler proposed-updates auskommentieren
> > - apt-get update
> > - apt-get upgrade
> > - reboot
> > - alles ist wieder so wie vorher
> >
> > Wunschdenken oder besser doch eine Testmaschine aufsetzen?
>
> Wunschdenken. Das geht so nicht und downgrades werden nicht unterstuetzt.
> Wenn Du aber entweder entsprechendes pinning verwendest, oder einfach
> manuell nur das Kernel image, headers, base und was ggf. sonst noch dran haengt
> verwendest, kannst Du eben dies nach einem reboot mit altem Kernel, natuerlich
> wieder deinstallieren.
>
> > Ich verstehe da aber noch nicht ganz die Abhängigkeiten, die das mit sich bringen
> wird.
>
> In diesem Fall duerften das nicht all zu viele sein, zumal das Update ja
> grundsaetzlich fuer das naechste point release vorgesehen ist.
> Neben den oben genannten ggf. noch firmware und doc. Wenn das nur fuer ein
> System ist kann man das auch mal zu Fuss machen.
Prima, vielen Dank für die Infos.
Zusammen mit Andrei's Vorschlag in diesem Thread, sollte das ja eigentlich umzusetzen sein. Aus der xen-user Liste hörte ich, dass jemand die proposed-updates, so wie hier besprochen, erfolgreich eingesetzt und damit den vorhandenen Bug im Kernel eliminiert hat.
Gruß
Guido
Reply to: