Kapittel 4. Oppgradering fra tidligere versjoner

Innholdsfortegnelse

4.1. Forberedelser før selve oppgraderingen
4.1.1. Ta sikkerhetskopi av alle dine filer og konfigurasjoner
4.1.2. Gi dine bruker beskjed på forhånd
4.1.3. Forberedelse til oppgradering
4.1.4. Forbered et sikkert miljø for oppgradering
4.2. Kontroller systemets status
4.2.1. Kontroller handlinger som er satt på vent i pakkebehandleren
4.2.2. Skru av APT pinning
4.2.3. Kontroller pakkestatus
4.2.4. Avsnittet med proposed-updates
4.2.5. Uoffisielle kilder og backports
4.3. Manuell fjerning av pakker markert som auto pakker
4.4. Klargjør APT sine kilder
4.4.1. Legge til APT-kilder for installering fra Internet
4.4.2. Legge til APT-kilder for installering fra lokalt speil
4.4.3. Legge til APT-kilde for installering fra CD-ROM eller DVD
4.5. Oppgradering av pakker
4.5.1. Ta opp hele oppgraderingsrutinen
4.5.2. Oppdatering av pakkelisten
4.5.3. Pass på at du har nok plass til oppgraderingen
4.5.4. Oppgrader apt og/eller aptitude først
4.5.5. Hvordan bruke aptitude sin liste over automatiske installerte pakker sammen med apt
4.5.6. Minimal systemoppgradering
4.5.7. Oppgradering av resten av systemet
4.5.8. Mulige problem under oppgraderingen
4.6. Oppgrader din kjerne og tilhørende pakker
4.6.1. Installere en metapakke for kjernen
4.6.2. Nytt system for nummerering av enheter
4.6.3. Tidsmessige problem under oppstart
4.7. Ting å huske før omstart
4.7.1. Kjør lilo igjen
4.8. Systemet stopper under oppstart med Waiting for root file system
4.8.1. Hvordan man unngår problemet før oppgradering
4.8.2. Hvordan løse problemer etter oppgraderingen
4.9. Forberedelser for neste versjon
4.10. Avleggse pakker
4.10.1. Dummy-pakker

4.1. Forberedelser før selve oppgraderingen

Vi foreslår at du før du begynner oppgraderingen, leser informasjonen i Kapittel 5, Problemer du bør kjenne til vedrørende lenny. Det kapitelet dekker potensielle problemer som ikke er direkte tilknyttet selve oppgraderingen, men som det allikevel kan være lurt å kjenne til.

4.1.1. Ta sikkerhetskopi av alle dine filer og konfigurasjoner

Før du begynner på oppgraderingen så bør du ta en full sikkerhetskopi av alle dine filer, eller i det minste ta en sikkerhetskopi av alle filer du absolutt ikke kan miste. Oppgraderingsverktøyet og rutinen er til å stole på, men f.eks en hardware feil som oppstår midt i oppgraderingsrutinen kan etterlate systemet ditt i en ikke-fungerende tilstand.

De viktigste filene å ta sikkerhetskopi av er de som ligger i /etc, /var/lib/dpkg, /var/lib/aptitude/pkgstates og resultatet av kommandoen dpkg --get-selections "*" (hermetegnene er viktige)

Oppgraderingsrutinen endrer ikke noe på innholdet i katalogen /home. Men noen programmer (f.eks noen Mozilla-program og skrivebordsmiljøene KDE og GNOME) er kjent for å overskrive enkelte brukerinnstillinger når en ny versjon av disse programmene startes første gang. For sikkerhetskyld så bør du ta en sikkerhetskopi av alle skjulte filer og kataloger (såkalte “punktfiler”) i alle hjemmekataloger til dine brukere. Denne sikkerhetskopien kan du bruke for å gjenskape gamle innstillinger. Du vil kanskje også informere dine bruker om dette.

Om du ønsker å bruke pakkebehandleren, så må du gjøre dette med superbruker rettigheter, enten må du være logget på som root, eller så må du bruker kommandoen su eller sudo for å oppnå de nødvendige rettighetene.

Selve oppgraderingen har noen betingelser som må oppfylles, du bør se til at de faktisk er oppfylt før du begynner å oppgradere.

4.1.1.1. Pass på at du bruker korrekt kjerne

Versjonen av glibc som følger med lenny fungerer ikke sammen med kjerner eldre enn 2.6.8, uavhengig av hvilken prosessorvariant du bruker. Noen prosessorvarianter har til og med høyere krav. Vi anbefaler at du først oppgraderer kjernen med en kjerne som følger med etch, 2.6.18 eller 2.6.24. Eventuelt så kan du selv bygge din egen kjerne, men det må minst være versjon 2.6.18.

4.1.2. Gi dine bruker beskjed på forhånd

Det er lurt å informere dine bruker før du begynner på selve oppgraderingen, selv om brukere som er logget på via ssh oppkoblinger knapt kommer til å merke noe til at du oppgraderer, og burde kunne jobbe uavbrutt.

Hvis du vil være ekstra påpasselig, så kan du ta sikkerhetskopi av hjemmeområdet til dine brukere, eller avmontere partisjonen hvor de ligger (/home) før du oppgraderer.

Du må sannsynligvis også oppgradere kjernen din når du oppgraderer til lenny, da må du også ta en omstart på ditt system. Dette vil typisk skje helt til slutt når selve oppgraderingen er gjennomført.

4.1.3. Forberedelse til oppgradering

På grunn av de mange endringene i kjernen mellom etch og lenny, spesielt mht til drivere, gjenkjenning av hardware og navngiving, rekkefølgen på enhetsfiler, så finnes det en risiko for at du vil oppleve problemer når du starter opp ditt system første gang etter oppgraderingen. En del av disse problemene er kjent, og er dokumenter her i Utgivelsesnotatet.

Av den grunn er det lurt å forsikre seg om at du kan gjenopprette ditt system om det ikke klarer å starte opp, eller hvis ditt nettverk ikke virker etter oppstart og du er avhengig av nettverk for å komme inn på systemet.

Om du fjernoppgraderer via ssh så er det sterkt anbefalt at du har et opplegg på plass for å kunne komme inn på systemet via en fjernserielterminal. Det finnes en risiko for at du etter å ha oppgradert kjernen vil oppleve at noen enheter har byttet navn, som beskrevet her i Seksjon 4.6.2, “Nytt system for nummerering av enheter” , du vil da måtte bruke en lokal konsoll for å fikse dette. Om systemet plutselig omstartes midt i oppgraderingen, så må du kanskje også bruke lokal konsoll for å komme inn igjen.

Det første du bør gjøre er å forsøke å starte med din gamle kjerne. Men av ulike grunner dokumentert her i dette dokumentet, så er det ikke garantert å virke.

Hvis det ikke virker, så er et alternativ å starte systemet på en slik måte at du har en sjanse til å kunne reparerer det. En måte å gjøre det på er å starte systemet fra en spesiell CD, enten en rednings-cd eller en såkalt Linux Live CD. Etter at du har startet opp ditt system fra en slik CD, så bør du kunne montere ditt rot-filsystem og deretter benytte deg av chroot for å komme inn i det og undersøke og forhåpentligvis reparere det.

En annen mulighet som vi anbefaler er å bruke det spesielle rescue mode valget som finnes i lenny Debian Installer. Fordelen med dette er at du her kan velge blant flere installasjonsmetoder, og lettere finne den som passer din situasjon best. For mer informasjon, se avsnittet “Recovering a Broken System” i kapitel 8 i Installation Guide og Debian Installer FAQ.

4.1.3.1. Feilsøkingsskall under oppstart ved hjelp av initrd

Pakken initramfs-tools inkluderer et feilsøkingsskall[2] i de initrd som den lager. Hvis f.eks din initrd ikke klarer å montere ditt rot-filsystem, så vil du bli tilbudt dette feilsøkingskallet, som har alle nødvendige kommandoer tilgjengelig for å hjelpe deg med å reparere feilen.

Det første du bør se på er: er de nødvendige enhetsfilene tilstede i /dev; hvilke kjernemoduler er lastet (cat /proc/modules); resultatet av kommandoen dmesg vil vise mulige feilmeldinger ved lasting av drivere. Resultatet av kommandoen dmesg vil også fortelle deg hvilke enhetsfiler som har blitt tildelt dine harddisker, dette bør du kontrollere opp mot resultatet av kommandoen echo $ROOT for å være sikker på at rot-filsystemet er på den riktige harddisken.

Om du klarer å løse dine problem, så skriver du exit for å komme ut av feilsøkingskallet og fortsette med oppstartsrutinen fra der hvor det feilet. Du må huske på å reparere problemet når du senere har fått startet opp ditt system, husk å lage ny initrd, ellers får du bare problemet igjen neste gang du starter systemet.

4.1.4. Forbered et sikkert miljø for oppgradering

Oppgraderingen av distribusjonen bør gjøres enten direkte fra en tekstbasert virtuell konsoll (eller en direkte tilkoblet seriell terminal), eller via fjernpålogging fra en ssh oppkobling.

Som en ekstra sikkerhet, så anbefaler vi at du benytter deg av programmet screen når du oppgraderer via fjernpålogging, da er du sikret at oppgraderingsrutinen ikke blir avbrutt selv om forbindelsen blir borte.

[Viktig]Viktig

Viktig! Du bør ikke oppgradere via telnet, rlogin, rsh, eller fra en X-sesjon som håndteres av xdm, gdm eller kdm på den maskinen du utfører oppgraderingen på. Dette er fordi prosessene som håndteres av disse tjenestene kan stoppe under selve oppgraderingen, noe som kan resultere i et utilgjengelig system som er bare halvveis oppgradert.

4.2. Kontroller systemets status

Oppgraderingsrutinen som er beskrevet her tar utgangspunkt i et “rent” etch system som ikke inneholder tredjepartspakker. For best resultat, så bør du vurdere å fjerne slike eventuelle tredjepartspakker før du begynner å oppgradere.

Prosessen forutsetter at du først har oppgradert til siste punktversjonen av etch. Hvis du ikke allerede har gjort det, eller om du er usikker, så følg instruksjonene i Seksjon A.1, “Oppgradering av ditt etch system”.

4.2.1. Kontroller handlinger som er satt på vent i pakkebehandleren

I noen tilfeller så vil bruken av apt-get istedenfor bruken av aptitude for å installere en pakke, føre til at aptitude anser denne pakken for å ikke være i bruk av systemet, og derfor foreslå at den skal fjernes. Pass på at ditt system er helt oppdatert og “rent” før du fortsetter med oppgraderingen.

Kontrollere om det finnes noen handlinger som er satt på vent i pakkebehandleren aptitude. Hvis en pakke er markert for å bli fjernet eller å oppdateres i pakkebehandleren, så kan dette ha negative konsekvenser for selve oppgraderingen av systemet. Merk at dette kun kan rettes på om din sources.list fremdeles forholder seg til etch; og ikke stable eller lenny; se Seksjon A.2, “Kontroller dine arkivlister”.

For å gjøre dette så må du kjøre aptitude i såkalt “visuelt modus” og der trykke på g (“Go”). Om det der finnes noen indikasjon på at noen handlinger ligger på vent, så bør du fikse dem, eller følge eventuelle anbefalinger. Hvis det ikke ligger noe på vent, så vil du få en beskjed som sier “No packages are scheduled to be installed, removed, or upgraded”.

4.2.2. Skru av APT pinning

Hvis du har konfigurert APT til å installere enkelte pakker fra en et annet arkiv enn stable (f.eks fra testing), så kan det hende at du må endre denne konfigurasjonen (se i /etc/apt/preferences) for å få disse pakkene oppgradert til den versjonen som finnes i den nye stabile distribusjonen. For mer informasjon om APT pinning, så kan du lese manualsiden til apt_preferences(5).

4.2.3. Kontroller pakkestatus

Uansett hvordan du planlegger å oppgradere, så lønner det seg å sjekke status på alle installerte pakker, og passer på at alle lar seg oppgradere. De følgende kommandoene vil finne pakker som har status som halvveis-installerte, eller som ikke er korrekt konfigurert.

# dpkg --audit

Du kan også sjekke status på alle installerte pakker på ditt system med kommandoene dselect, aptitude, eller kommandoer som

# dpkg -l | pager

eller

# dpkg --get-selections "*" > ~/curr-pkgs.txt

Det er lurt å ta bort eventuelle merknader om at en pakke skal være på vent før man begynner på oppgraderingen. Hvis en pakke som er viktig for selve oppgraderingen er satt på vent, så kan hele oppgraderingen stoppe opp.

Merk at aptitude bruker en annen metode for å registrere at en pakke er satt på vent enn apt-get og dselect. Du kan finne ut hvilke som er på vent med kommandoen aptitude med

# aptitude search "~ahold" | grep "^.h"

Om du med apt-get vil finne hvilke pakker som er satt på vent, så kan du bruke

# dpkg --get-selections | grep hold

Hvis du selv har bygd en pakke, og ikke gitt den et nytt navn, eller har lagt inn en dato i pakkenavnet, så må du sette den på vent for å forhindre at den blir oppgradert.

Pakkestatusen “hold” for en pakke kan med aptitude endres med:

# aptitude hold pakkenavn

Bytt ut hold med unhold for å endre “hold” status på en pakke.

Om det er noe du trenger å rette på, så lønner det seg å passe på at sources.list fortsatt refererer til etch, som forklart i Seksjon A.2, “Kontroller dine arkivlister”.

4.2.4. Avsnittet med proposed-updates

Hvis du har et avsnitt med proposed-updates i din/etc/apt/sources.list fil, så bør du for sikkerhets skyld fjerne disse før du begynner på oppgraderingen.

4.2.5. Uoffisielle kilder og backports

Om du har noen ikke-Debian pakker installert på ditt system, så bør du være klar over at disse kan komme til å bli fjernet under oppgraderingen pga mulige konflikter. Hvis du har installert disse pakkene via et tilhørende arkiv nevnt i /etc/apt/sources.list, så bør du sjekke om dette arkivet også tilbyr disse pakkene for lenny, og endre de respektive linjene.

Hvis du har uoffisielle backportede pakker installert på ditt etch system som er “nyere” enn de som finnes i Debian, så vil disse trolig skape konflikter under en oppgradering[3]. Seksjon 4.5.8, “Mulige problem under oppgraderingen” har mer informasjon om dette problemet skulle oppstå.

4.2.5.1. Å bruker pakker fra backports.org

backports.org er et semi-offisielt arkiv som vedlikeholdes av Debian GNU/Linux-utviklere. Dette arkivet inneholder nyere pakker enn de som finnes i det stabile arkivet, disse pakkene er basert på versjoner som finnes i “testing”-arkivet.

Pakker i backports.org arkivet har pakker fra “testing” men med et lavere versjonsnummer for å sikre at oppgraderingen fra etch backports til lenny går greit. Det finnes også pakker i backports-arkivet som kommer fra unstable-arkivet (sikkerhetsoppgraderinger og følgende unntak; Firefox, Linux kjernen, OpenOffice.org og X.org)

If you do not use one of these exceptions, you can safely upgrade to lenny. If you use one of these exceptions, set the Pin-Priority (see apt_preferences(5)) temporarily to 1001 for all packages from lenny, and you should be able to do a safe dist-upgrade too.

4.3. Manuell fjerning av pakker markert som auto pakker

For å hindre aptitude fra å fjerne pakker som har blitt installert gjennom en avhengighet i en annen pakke, så må du manuelt fjerne merkingen de har som auto pakker. Dette inkluderer OpenOffice.org og Vim for Skrivebordssystemer:

# aptitude unmarkauto openoffice.org vim

Dette gjelder også 2.6 kjerner om de er installert via en kjerne metapakke:

# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6.*' | cut -f1)
[Notat]Notat

Du kan se hvilke pakker som er merket som auto pakker i aptitude ved å kjøre:

# aptitude search '~i~M'

4.4. Klargjør APT sine kilder

Før du starter på oppgraderingen, så må du konfigurere apt sin konfigurasjonsfil, /etc/apt/sources.list.

apt vil gå igjennom alle pakker som finnes via “deb” linjer i konfigurasjonsfilen, og installere de med høyest versjonsnummer, linjene gis prioritet etter rekkefølge (slik at om du har flere speil oppført, så vil du typisk først føre opp lokal harddisk, så CD-ROM , og deretter HTTP/FTP-speil)

[Tips]Tips

Det kan hende at du trenger å sette et GPG unntak for sjekking av DVD'er og CD-ROM'er. Legg til følgende linje i /etc/apt/apt.conf, hvis du ikke har en slik linje allerede i fila /etc/apt/apt.conf.d/00trustcdrom :

APT::Authentication::TrustCDROM "true";

Merk at dette vil ikke virke med DVD/CD-ROM avbildinger.

En utgivelse blir ofte referert til enten ved sitt kodenavn (f.eks etch, lenny), eller ved sitt statusnavn (f.eks oldstable, stable, testing, unstable). Hvis man holder seg til tradisjonen med å referere til kodenavn, så slipper man å bli overrasket når en ny versjon kommer, det er denne metoden vi bruker her. Det betyr at du selv må holde deg oppdatert på når det kommer en ny versjon. Om du bruker statusnavnet, så vil du kanskje først oppdage at det har kommet en ny versjon når alle pakker du har installert blir oppdaterte.

4.4.1. Legge til APT-kilder for installering fra Internet

Standardkonfigurasjonen er å laste ned pakker fra Debian sin hovedserver på Internet, men du vil kanskje endre /etc/apt/sources.list til å bruke en server som står nærmere deg, nettverksmessig.

Adressene til de forskjellige speilene til Debian HTTP eller FTP finner du på http://www.debian.org/distrib/ftplist (se på “list of Debian mirrors”). HTTP-speil er generelt raskere enn FTP-speilene.

For eksempel, la oss anta at det nærmeste Debian speilet er http://mirrors.kernel.org. Når du bruker en nettleser for å se på innholdet i dette speilet, så vil du se at katalogene er organisert slik:

http://mirrors.kernel.org/debian/dists/lenny/main/binary-powerpc/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-powerpc/...

Legg til denne linjen i din sources.list fil om du vil bruke dette speilet med apt:

deb http://mirrors.kernel.org/debian lenny main contrib

Merk at `dists' legges til automatisk, og at argumentet etter versjonens kodenavn brukes for å utvide til å inkludere flere kataloger

Etter at du har lagt til en ny kilde, så kan du gjøre de tidligere brukte kildene inaktive ved å plassere en skigard (#) foran de tilhørende “deb” linjene i sources.list

4.4.2. Legge til APT-kilder for installering fra lokalt speil

Istedenfor å bruke et HTTP- eller FTP-speil for å installere pakker, så kan du endre på /etc/apt/sources.list slik at det er et lokalt speil på din harddisk som brukes (eventuelt en nettverksdisk montert med NFS).

For eksempel, ditt lokale speil kan befinne seg på /var/ftp/debian/, og ha underkataloger som inneholder dette:

/var/ftp/debian/dists/lenny/main/binary-powerpc/...
/var/ftp/debian/dists/lenny/contrib/binary-powerpc/...

Legg til denne linjen i sources.list for å bruke den med apt:

deb file:/var/ftp/debian lenny main contrib

Merk at `dists' legges til automatisk, og at argumentet etter versjonens kodenavn brukes for å utvide til å inkludere flere kataloger

Etter at du har lagt til en ny kilde, så kan du gjøre de tidligere brukte kildene inaktive ved å plassere en skigard (#) foran de tilhørende “deb” linjene i sources.list

4.4.3. Legge til APT-kilde for installering fra CD-ROM eller DVD

Hvis du kun vil bruke CD'er, så kommenter bort de eksisterende “deb” linjene i /etc/apt/sources.list ved å plassere en skigard (#) foran dem.

Pass på at det finnes en linje i /etc/fstab som muliggjør for montering av CD-ROM på monteringspunktet /cdrom (apt-cdrom trenger at CD-ROM er montert på /cdrom). Hvis /dev/hdc er der din CD-ROM er, så vil den tilhørende linja i /etc/fstab se slik ut:

/dev/hdc /cdrom auto defaults,noauto,ro 0 0

Merk at det ikke må være noen mellomrom mellom ordene defaults,noauto,ro i det fjerde feltet i denne linja.

For å sjekke om dette fungerer som det skal, så prøv

# mount /cdrom    # dette vil montere CD-ROM på monteringspunktet
# ls -alF /cdrom  # dette vil liste opp innholdet på roten til CD-ROM
# umount /cdrom   # dette vil avmontere CD-ROM

Så kan du kjøre:

# apt-cdrom add

for hver Debian Binær CD-ROM som du har, for å legge de inn i APT sin database over tilgjengelige pakker.

4.5. Oppgradering av pakker

Den anbefalte metoden for å oppgradere til en nyere Debian GNU/Linux versjonen er å bruke pakkebehandleren aptitude. Denne pakkebehandleren gjør sikrere valg angående installasjon av pakker enn å bruke apt-get direkte.

Ikke glem å montere alle partisjoner (spesielt rot- og /usr-partisjonen) som skrivbare med en kommando som f.eks dette:

# mount -o remount,rw /mountpoint

Deretter må du dobbeltsjekke at APT-kildene (i /etc/apt/sources.list) enten referer til “lenny” eller til “stable”. Det må ikke være noen referanser til etch.

[Notat]Notat

Merk at linjer for CD-ROM ofte referer til “unstable”, selv om dette tilsynelatende er feil, så er det faktisk oftest korrekt, du skal derfor ikke endre disse.

4.5.1. Ta opp hele oppgraderingsrutinen

Det anbefales på det sterkeste å lage et opptak av alt som skjer under oppgraderingen, bruk programmet /usr/bin/script for å gjøre dette. Så, om noe går galt under oppgraderingen, så har du en detaljer loggfil over hva som har hendt, og kan da gi eksakt informasjon i tilknytting til en feilrapport. For å starte opptaket, så skriv:

# script -t 2>~/upgrade-lenny.time -a ~/upgrade-lenny.script

eller noe lignende. Ikke plasser loggfila i en midlertidig katalog som /tmp eller /var/tmp (filer i disse katalogene blir ofte slettet ved en omstart eller ved oppgradering)

Loggfila lar deg også se det som har rullet forbi på skjermen. Bytt til VT2 (bruk Alt+F2) deretter kan du bruke less -R ~root/upgrade-lenny.script for å se på innholdet i fila.

Etter at du er ferdig med oppgraderingen, så kan du stoppe script ved å skrive exit ved prompten.

Hvis du brukte opsjonen -t sammen med script, så kan du bruke scriptreplay for å spille av hele sesjonen.

# scriptreplay ~/upgrade-lenny.time ~/upgrade-lenny.script

4.5.2. Oppdatering av pakkelisten

Først må du hente den nye oversikten over pakker som finnes i den nye versjonen. Dette gjør du med:

# aptitude update

Første gang du kjører denne kommandoen etter at du har lagt til nye kilder, så vil du se en del advarsler relatert til tilgjengeligheten til disse nye arkivene. Disse advarslene er harmløse, og vil ikke dukke opp neste gang du kjører kommandoen.

4.5.3. Pass på at du har nok plass til oppgraderingen

Du må sjekke at du har nok plass på din harddisk før du starter oppgraderingen som beskrevet i Seksjon 4.5.7, “Oppgradering av resten av systemet”. Alle pakker som skal installeres blir først lastet ned og plassert i /var/cache/apt/archives (under selve nedlastingen av pakken så blir de midlertidig plassert i partial/ katalogen), så du må passe på at du har nok plass på partisjonen som har /var/. Etter at pakkene er lastet ned, så vil du trenge plass andre steder for selve installasjonen av pakkene. Hvis systemet ditt ikke har nok plass , så kan du risikere å ende opp med et ødelagt system.

Både aptitude og apt vil vise deg detaljert hvor mye diskplass de trenger for installasjonen. Før du starter oppgraderingen, så kan du se estimatet for hvor mye diskplass du trenger ved å kjøre:

# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX pakker oppgradert, XXX nylig installert, XXX skal fjernes og XXX skal ikke oppgraderes.
 Trenger å hente XXXXMB i installasjonspakker. Etter utpakking vil XXXMB bli brukt.
 Vil laste ned, installere og/eller fjerne pakker.
[Notat]Notat

Hvis du forsøker å kjøre denne kommandoen på starten av oppgraderingsrutinen, så kan den gi mange feilmeldinger, av årsaker beskrevet i kommende avsnitt. I så fall så må du vente med denne kommandoen til du har fått unnagjort en minimal systemoppgradering som beskrevet i Seksjon 4.5.6, “Minimal systemoppgradering” og fått oppgradert kjernen.

Hvis du ikke har nok plass til å kunne oppgradere, så må du frigjøre plass. Du kan:

  • Fjerne pakker som tidligere har blitt lastet ned (til/var/cache/apt/archives) og installert. Disse pakkene slettes trygt med kommandoen apt-get clean eller aptitude clean.

  • Fjerne gamle pakker du ikke lenger bruker. Hvis du har popularity-contest installert, så kan du bruke kommandoen popcon-largest-unused for å få en liste over pakker som ikke er mye i bruk, rangert etter installert størrelse. Du kan også bruke deborphan eller debfoster for å finne pakker som ikke lenger trengs (se Seksjon 4.10, “Avleggse pakker” ). Alternativt så kan du starte aptitude i “visual mode” og der finne utgåtte pakker under “Obsolete and Locally Created Packages”.

  • Fjerne pakker som bruker for mye plass, og som ikke trengs akkurat nå (du kan installere dem igjen når du er ferdig med å oppgradere). Du kan finne de pakkene som tar størst plass med kommandoen dpigs (denne finner du i pakken debian-goodies ) eller du kan bruker kommandoen wajig (bruk da wajig size).

    You can list packages that take up most of the disk space with aptitude. Start aptitude into “visual mode”, select ViewsNew Flat Package List (this menu entry is available only after etch version), press l and enter ~i, press S and enter ~installsize, then it will give you nice list to work with. Doing this after upgrading aptitude should give you access to this new feature.

  • Ta bort oversettelser og språktilpassninger som du ikke trenger. Du kan installere pakken localepurge og sette den opp slik at bare et fåtall språk og språktilpassninger beholdes. Dette vil minske plassen som brukes på /usr/share/locale.

  • Flytt systemets loggfiler midlertidig til et annet system, eller slett dem, disse filene finner du under /var/log/.

  • Bruk en midlertidig /var/cache/apt/archives katalog: Du kan bruke en midlertidig cachekatalog på et annet filsystem (USB-enhet, midlertidig harddisk, et eksisterende filsystem, ...)

    [Notat]Notat

    Ikke bruk NFS-montering, ettersom nettverket kan bli forstyrret under oppgraderingen

    For eksempel, hvis du har en USB-diskenhet montert på /media/usbkey:

    1. Fjern pakker som har blitt lastet ned og allerede installert:

      # apt-get clean

    2. Kopier katalogen /var/cache/apt/archives over til USB-diskenheten

      # cp -ax /var/cache/apt/archives /media/usbkey/

    3. Monter den mildertidige cachekatalogen over den nåværende:

      # mount --bind /media/usbkey/archives /var/cache/apt/archives

    4. Etter at du er ferdig med oppgraderingen, så kan du legge tilbake den originale katalogen /var/cache/apt/archives:

      # umount /media/usbkey/archives

    5. Fjern gjenværende /media/usbkey/archives.

    Du kan lage midlertidige cachekataloger hvor du vil på ditt monterte filsystem.

Merk at for å fjerne pakker på en trygg måte, så bør du bruke referanser til etch i fila sources.list , som beskrevet i Seksjon A.2, “Kontroller dine arkivlister”.

4.5.4. Oppgrader apt og/eller aptitude først

Several bug reports have shown that the versions of the aptitude and apt packages in etch are often unable to handle the upgrade to lenny. In lenny, apt is better at dealing with complex chains of packages requiring immediate configuration and aptitude is smarter at searching for solutions to satisfy the dependencies. These two features are heavily involved during the dist-upgrade to lenny, so it is necessary to upgrade these two packages before upgrading anything else.

The following command will upgrade both aptitude and apt:

# aptitude install aptitude apt dpkg

This step will also automatically upgrade libc6 and locales. At this point, some running services will be restarted, including xdm, gdm and kdm. As a consequence, local X11 sessions might be disconnected.

[Notat]Upgrading with apt

Please note that using apt-get is not recommended for the upgrade from etch to lenny. If you do not have aptitude installed you are recommended to install it first.

If you want to perform the upgrade with apt or if the upgrade with aptitude failed and you want to try the upgrade with apt' dependency chain resolution algorithm, you should run:

# apt-get install apt

Note that you will have to adapt other aptitude commands to use apt-get instead.

4.5.5. Hvordan bruke aptitude sin liste over automatiske installerte pakker sammen med apt

aptitude vedlikeholder en liste med pakker som har blitt installert automatisk (for eksempel som en avhengighet til en annen pakke). I lenny så finnes denne funksjonen også i apt.

Når du bruker lenny versjonen av aptitude første gang, så vil den lese inn listen med automatiske installerte pakker, og konvertere den for bruk sammen med lenny versjonen av apt. Hvis du har aptitude installert, så bør du i det minste kjøre kommandoen aptitude en gang for å gjennomføre denne konverteringen, for eksempel så kan du søke etter en pakke som ikke finnes.

# aptitude search "?false"

4.5.6. Minimal systemoppgradering

På grunn av noen helt nødvendige konflikter mellom noen pakker som finnes i etch og lenny, så vil en direkte kjøring av kommandoen aptitude dist-upgrade ofte fjerne mange pakker som du helst vil ha installert. Vi anbefaler derfor en todelt oppgradering for å unngå dette problemet. Først foretaes en minimal oppgradering, deretter en full dist-upgrade.

Kjør først:

# aptitude safe-upgrade

Dette vil oppgradere de pakkene som kan oppgraderes uten at noen andre pakker blir fjernet eller installert.

Neste skritt avhenger av hvilke pakker du har installert på ditt system. Du finner råd og tips i Utgivelsesnotatet om hvilke løsning du burde bruke, hvis du er i tvil, så anbefaler vi at du nøye undersøker hvilke pakker som foreslås fjernet av hver metode før du fortsetter.

Pakker som du kan forvente vil bli fjernet inkluderer blant annet base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common og xserver-common. For en komplett liste over pakker som har blitt gjort avleggse i lenny, se Seksjon 4.10, “Avleggse pakker”.

4.5.7. Oppgradering av resten av systemet

Du er nå klar for å fortsette med hoveddelen av oppgraderingen. Kjør:

# aptitude dist-upgrade

Dette kommer til å utføre en fullstendig oppgradering av ditt system, altså kommer den nyeste versjonen av alle installerte pakker til å bli installert, samt løse alle avhengigheter mellom pakker i forskjellige versjoner. Om det er nødvendig, så kommer også nye pakker til å bli installert (vanligvis dreier det seg om nye versjoner av bibliotek eller pakker som har fått nytt navn), avleggse pakker som står i konflikt med nyere pakker vil bli fjernet.

Ved oppgradering fra et sett av cd'er (eller dvd'er), så vil du bli bedt om å sette inn spesifike cd'er flere ganger i løpet av oppgraderingen. Det kan hende at du blir bedt om å sette inn den samme cd'en flere ganger, dette er fordi en pakke kan ha avhengighet på en pakke som befinner seg på en annen cd.

Nye versjoner av installerte pakker som ikke kan oppgraderes uten å endre installasjonsstatus på andre pakker, vil ikke bli oppgradert (de vises som “held back”). Disse kan man tvinge gjennom en oppgradering ved å bruke aptitude for å installere disse enkeltvis, eller ved å bruke aptitude -f install pakkenavn.

4.5.8. Mulige problem under oppgraderingen

Hvis du ser denne feilen når du bruker aptitude, apt-get eller dpkg:

E: Dynamic MMap ran out of room

så skyldes det at standard størrelsen på cachen er for liten. Du kan løse dette problemet ved å enten fjerne unødvendige linjer i /etc/apt/sources.list, eller ved å øke størrelsen på cachen. Størrelsen på cachen kan du øke med APT::Cache-Limit i /etc/apt/apt.conf. Denne kommandoen burde øke størrelsen til noe som er stort nok for oppgraderingen:

# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

Dette forutsetter at du ikke allerede har denne variabelen i fila.

Noen ganger kan det være nødvendig å aktivere alternativet APT::Force-LoopBreak i APT for å kunne midlertidig fjerne en systemkritisk pakke på grunn av en Conflicts/Pre-Depends-løkke. aptitude vil advare deg om dette, og avbryte oppgraderingen. Du kan komme rundt dette ved å angi alternativet -o APT::Force-LoopBreak=1 sammen med kommandoen aptitude.

Det er mulig at avhengigsstrukturen for et system kan være så ødelagt at det krever manuell inngripen. Vanligvis betyr dette at du må bruke aptitude eller

# dpkg --remove pakkenavn

for å fjerne noen av de pakkene som er i veien, eller

# aptitude -f install
# dpkg --configure --pending

I helt ekstreme tilfeller så kan det hende at du må reinstallere pakken med en kommando som

# dpkg --install /sti/til/pakkenavn.deb

Filkonflikter bør ikke oppstå om du forsøker å oppgradere fra et “rent” etch system, men kan skje om du har uoffisielle backports installert. En filkonflikt kan resultere i en feilmelding som dette:

Unpacking <package-foo> (from <package-foo-file>) ...
dpkg: error processing <package-foo> (--install):
 trying to overwrite `<some-file-name>',
 which is also in package <package-bar>
dpkg-deb: subprocess paste killed by signal (Broken pipe)
 Errors were encountered while processing:
 <package-foo>

Du kan forsøke å løse denne filkonflikten ved å tvinge igjennom fjerningen av pakken som nevnes på den siste linjen i feilmeldingen:

# dpkg -r --force-depends pakkenavn

Etter at dette problemet er løst, så burde du kunne forsette med oppgraderingen ved å fortsette med aptitude kommandoene som tidligere nevnt.

Under oppgraderingen så kan du komme til å bli stilt en rekke spørsmål om hvordan du vil at en pakke skal konfigureres, eller omkonfigureres. Når du blir spurt om hva som skal gjøres med en fil som befinner seg i enten /etc/init.d eller /etc/terminfo katalogene, eller /etc/manpath.config fila, om du vil bytte ut en fil med pakkevedlikeholderens nye versjon, så er vanligvis det nødvendige svaret "ja", for å beholde et korrekt fungerende system. Du kan alltids angre dette valget, ettersom de gamle versjonene blir tatt vare på med en .dpkg-old filendelse.

Hvis du er usikker på hva du burde gjøre, så skriv ned navnet på den aktuelle fila, eller pakken, så kan du ordne opp i det senere. Du kan se i typeskript-fila for å nærmere undersøke informasjonen som ble vist på skjermen.

4.6. Oppgrader din kjerne og tilhørende pakker

Dette avsnittet forklarer hvordan du oppgraderer kjernen, og tar for seg mulige problem som kan oppstå når du oppgraderer kjernen. Du kan enten installere en av linux-image-* pakkene som følger med Debian, eller lage dine egne kjerner direkte fra kildekoden.

Merk at mye av informasjonen i dette avsnittet tar utgangspunkt i at du bruker en av kjernepakkene som følger med Debian, sammen med initramfs-tools og udev. Hvis du bygger dine egne kjerner som ikke trenger en initrd, eller om du bruker en annen initrd-generator, så kan det hende at informasjonen her ikke gjelder deg.

4.6.1. Installere en metapakke for kjernen

Når du kjører dist-upgrade fra etch til lenny, så anbefales det på det sterkeste at du installerer en ny linux-image-2.6-* metapakke. Denne pakken kan installeres automatisk av dist-upgrade prosessen. Du kan kontrollere dette ved å kjøre:

# dpkg -l "linux-image*" | grep ^ii

Om du ikke får noe svar, så må du installere en ny linux-image metapakke manuelt. Kjør denne kommandoen for å få en oversikt over tilgjengelige linux-image-2.6 metapakker:

# apt-cache search linux-image-2.6- | grep -v transition

Om du er usikker på hvilken pakke du skal velge, så kjør uname -r og let etter en pakke med et lignende navn. For eksempel, hvis du ser '2.6.18-6-686', så anbefalses det at du installerer linux-image-2.6-686. (Merk at varianten k7 ikke lenger finnes, hvis du bruker k7, så skal du nå velge 686 istedenfor). Du kan også bruke apt-cache for å se en lengre beskrivelse for hver pakke, slik at du lettere kan velge riktig pakke. For eksempel:

# apt-cache show linux-image-2.6-686

Du bør så bruke aptitude install for å installere den. Så snart den nye kjernen er installert, så bør du ved første anledning starte systemet pånytt, slik at du kan begynne å bruke den nye forbedrede kjernen.

For de mer eventyrlystne så finnes det en enkel måte å bygge dine egne spesialtilpassede kjerner i Debian GNU/Linux. Installer pakken kernel-package og les dokumentasjonen i /usr/share/doc/kernel-package.

Hvis det er mulig, så er det i til din fordel om du kan oppgradere kjernen separat fra selve hoved dist-upgrade prosessen, da reduserer du sjansen for at du ender opp med et system som ikke vil starte. Merk at dette ikke bør forsøkes før du har utført en minimal oppgradering, som beskrevet i Seksjon 4.5.6, “Minimal systemoppgradering”.

4.6.2. Nytt system for nummerering av enheter

lenny har en mer robust mekanisme for å identifisere hardware enn tidligere versjoner hadde. Men, det kan hende at denne nye mere robuste mekanismen vil påvirke rekkefølgen på hvordan enhetsnavn tildeles. Om du f.eks har to nettverkskort som bruker forskjellige drivere, så kan de enheter som eth0 og eth1 referer til endres. Merk at om du bytter ut et nettverkskort på et lenny system, så vil det nye nettverkskortet få et nytt navn.

For nettverksenheter, så kan du unngå dette ved å bruke regler i udev, mer spesifikt gjennom definisjoner i /etc/udev/rules.d/70-persistent-net.rules[4]. Alternativt så kan du bruke kommandoen ifrename for å sette opp en bestemt sammenheng mellom en fysik enhet og et spesifikt navn. Seifrename(8) og iftab(5) for mer informasjon. De to alternativene (udev og ifrename) bør ikke brukes samtidig.

For lagringsenheter, så kan du unngå dette ved å bruke initramfs-tools, og konfigurere den slik at den laster drivermoduler i samme rekkefølge som de nå blir lastet. For å finne ut i hvilken rekkefølge dine nåværende drivermoduler har blitt lastet, så kan du se på resultatet fra kommandoen lsmod. lsmod. lister opp drivermoduler i omvendt rekkefølge av når de ble lastet, dvs at den første drivermodulen som listes er den siste som ble lastet. Merk at dette kun gjelder for enheter som kjernen nummerer på en fast måte (som PCI enheter).

Merk at om moduler fjernes og lastes pånytt etter oppstart, så vil dette påvirke rekkefølgen. Merk også at din kjerne kan ha moduler statisk lenket, og disse vil da ikke dukke opp på listen fra lsmod. Du kan kanskje klare å finne ut av dette ved å inspisere fila /var/log/kern.log, eller ved å se på kommandoen dmesg.

Legg til modulene i /etc/initramfs-tools/modules i den rekkefølgen de skal lastes automatisk ved oppstart. Noen moduler har byttet navn mellom versjonene etch og lenny. Feks så har sym53c8xx_2 byttet navn til sym53c8xx.

Du blir nødt til å lage dine initramfs-avbildninger på nytt ved å kjøre update-initramfs -u -k all.

Når du har begynt å bruke kjerne og udev fra lenny så kan du konfigurere systemet ditt til å aksessere diskene gjennom et alias på en slik måte at rekkefølgen de oppdages i ikke betyr noe. Disse aliasene finner du under /dev/disk/ strukturen.

4.6.3. Tidsmessige problem under oppstart

Hvis en initrd som er lagd med initramfs-tools brukes for å starte systemet, så kan det i noen tilfeller hende at opprettingen av enhetsfiler av udev skjer for sent for noen oppstartsskripts.

De vanlige symptom på dette er at oppstarten misslykkes fordi rotfilsystemet ikke kan monteres, og du kommer bare til et feilsøkingsskall. Når du senere sjekker om de nødvendige enhetsfilenen er på plass i /dev, så er de der alle sammen. Dette har blitt observert på systemer hvor rotfilsystemet ligger på en USB-enhet, eller på et RAID, spesielt hvis LILO brukes.

En måte å komme rundt dette problemet på er å bruke oppstartsparameteren rootdelay=9. Verdien for tidsgrensen (i sekunder) kan behøves å endres.

4.7. Ting å huske før omstart

Når aptitude dist-upgrade er ferdig med å kjøre, så er den “formelle” oppgraderingen ferdig, men det er visse andre ting som bør taes hånd om før neste omstart.

4.7.1. Kjør lilo igjen

Hvis du bruker lilo som din oppstartslaster (den var brukt som standard oppstartslaster på enkelte installasjoner av etch) så anbefales det at du kjører lilo etter oppgraderingen:

# /sbin/lilo

Merk at dette er nødvendig selv om du ikke har oppgradert kjernen, ettersom oppgraderingen av lilo i seg selv har endret andre steget i lilo.

Husk også å kontrollere innholdet i /etc/kernel-img.conf, pass på at du der har do_bootloader = Yes, da vil oppstartslasteren alltid bli kjørt etter en oppgradering av kjernen.

Hvis det oppstår problemer når du kjørere lilo, så kontrollert symlinkene fra / til vmlinuz og initrd, og kontroller at innholdet i /etc/lilo.conf stemmer.

Hvis du glemmer å kjøre lilo før du restarter, eller hvis systemet ved et uhell restarter, så kan det hende at ditt system ikke starter. Isteden for å se det vanlige lilo-bildet, så ser du bare LI når du forsøker å starte systemet[5]. Se Seksjon 4.1.3, “Forberedelse til oppgradering” for hvordan du løser dette problemet.

4.8. Systemet stopper under oppstart med Waiting for root file system

Prosedyre for å rette opp problem hvor /dev/hda ble til /dev/sda

Noen brukere har rapportert at oppgraderingen har ført til at kjernen ikke har klart å finne systemets rofilsystem etter opprtart.

I slike tilfeller så kommer systemet til å stoppe opp med feilmeldingen:

Venter på rotfilsystem... (engelsk: Waiting for root file system ...)

og etter noen sekunder så dukker en enkel busybox terminalprompt opp.

Dette problemet kan oppstå når en oppgradering av kjernen medfører at en ny type IDE drivere. Konvensjonen for navngivning med de gamle driverene var å bruke hda, hdb, hdc, hdd. De nye driverene vil kalle de samme diskene for sda, sdb, sdc, sdd. Problemet oppstår når disse nye navnene ikke blir inkludert i /boot/grub/menu.lst. Under oppstart så vil Grub gi kjernen utdatert informasjon om hvor rotfilsystemet befinner seg.

Hvis du har støtt på dette problemet etter oppgraderingen, så les Seksjon 4.8.2, “Hvordan løse problemer etter oppgraderingen”. Hvis du ønsker å unngå dette problemet, så les videre.

4.8.1. Hvordan man unngår problemet før oppgradering

Problemet kan unngåes ved å bruke en identitet for rotfilsystemet som ikke forander seg mellom de forskjellige oppstartene. Det finnes to mulige metoder for å oppnå dette. En måte er å sette en slags etikett på filsystemet, eller ved å bruke en såkalt universiell unik identitet (UUID). Begge disse metodenen har vært støttet i Debian siden 'etch' utgaven.

Disse metodene har fordeler og ulemper. Metoden med etiketter er lettere å lese, men sjansen er tilstede for at et annet filsystemt kan ha samme etikett. Metoden med UUID er ikke fult så enkel å lese, men det er veldig lite sannsynlig at to filsystem kan ha samme UUID.

I dette eksempelet så antar vi at rotfilsystemet ligger på /dev/hda6. Vi antar også at systemet har fungerende udev, og er et ext2 eller ext3 filsystem.

For å bruke etikettmetoden:

  1. Sett en etikett på filsystemet (navnet må være på (mindre) < 16 tegn) ved å bruke kommandoen: e2label /dev/hda6 rootfilesys

  2. Rediger /boot/grub/menu.lst og endre linjen:

    # kopt=root=/dev/hda6 ro

    til

    # kopt=root=LABEL=rootfilesys ro

    [Notat]Notat

    Ikke ta bort # fra begynnelsen av linja, den må være der.

  3. Oppdatert kernel-linjene i fila menu.lst ved å bruke kommandoen update-grub.

  4. Rediger fila /etc/fstab og endre linja som er ansvarlig for montering av / (rootfilsystemet), for eksempel:

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    til

    LABEL=rootfilesys     /     ext3  defaults,errors=remount-ro 0 1

    Endringen som betyr noe her er den som utføres i første kolonne, du trenger ikke å endre på noe annet på linja.

For å bruke UUID-metoden:

  1. Find out the universally unique identifier of your filesystem by issuing: ls -l /dev/disk/by-uuid | grep hda6. You can also use vol_id --uuid /dev/hda6 (in etch) or blkid /dev/hda6 (if already upgraded to lenny).

    Din linje bør se ut som dette:

    lrwxrwxrwx 1 root root 24 2008-09-25 08:16 d0dfcc8a-417a-41e3-ad2e-9736317f2d8a -> ../../hda6

    UUID er navnet på den symbolske lenken som peker til/dev/hda6 for eksempel: d0dfcc8a-417a-41e3-ad2e-9736317f2d8a.

    [Notat]Notat

    Ditt filsystem komme til å ha en annen UUID-streng.

  2. Rediger /boot/grub/menu.lst og endre linjen:

    # kopt=root=/dev/hda6 ro

    til

    # kopt=root=UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8 ro

    [Notat]Notat

    Ikke ta bort # fra begynnelsen av linja, den må være der.

  3. Oppdatert kernel-linjene i fila menu.lst ved å bruke kommandoen update-grub.

  4. Rediger fila /etc/fstab og endre linja som er ansvarlig for montering av / (rootfilsystemet), for eksempel:

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    til

    UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8  /  ext3  defaults,errors=remount-ro 0 1

    Endringen som betyr noe her er den som utføres i første kolonne, du trenger ikke å endre på noe annet på linja.

4.8.2. Hvordan løse problemer etter oppgraderingen

4.8.2.1. Løsning 1

Dette fungerer om Grub viser sin grafiske meny der du kan velge hvilke valg du vil starte opp fra. Hvis du ikke ser denne menyen, så prøv å trykke på Esc før kjernen starter for å vise menyen. Hvis du ikke kommer inn i menyen, så forsøk Seksjon 4.8.2.2, “Løsning 2” eller Seksjon 4.8.2.3, “Løsning 3”.

  1. Når du er inne i Grub menyen, så marker alternativet du vil starte. Trykk e (e for engelsk edit) for å redigere dette alternativet. Da vil du se noe slikt som dette:

    root (hd0,0)
    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd /initrd.img-2.6.26-1-686

  2. Marker linjen

    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro

    trykk e og bytt ut hdX med sdX (der X er bokstaven a, b, c or d avhengig av ditt system). I dette eksempelet blir linjen:

    kernel /vmlinuz-2.6.26-1-686 root=/dev/sda6 ro

    Trykk så Enter for å lagre endringene. Om andre linjer inneholder hdX, så endrer du disse også. Ikke rediger den linja som inneholder root (hd0,0). Når du er ferdig med alle dine endringer, så trykk b (b for engelsk boot), og ditt system burde starte som normalt.

  3. Når ditt system har startet opp, så må du løse problemet permanent. Gå til Seksjon 4.8.1, “Hvordan man unngår problemet før oppgradering”, og velg en av de to foreslåtte løsningene.

4.8.2.2. Løsning 2

Start systemet fra et Debian GNU/Linux installasjonsmedium (CD/DVD) og velg rescue for å starte opp i redningsmodus. Velg språk, sted og tastaturoppsett og la systemet selv sette opp nettverket (det spiller ingen rolle om det klarer det eller ikke). Etter en stund blir du spurt om hvilken partisjon du ønsker å bruke som rotfilsystem. De forskjellige alternativene burde se om som dette:

/dev/ide/host0/bus0/target0/lun0/part1
/dev/ide/host0/bus0/target0/lun0/part2
/dev/ide/host0/bus0/target0/lun0/part5
/dev/ide/host0/bus0/target0/lun0/part6

Hvis du vet hvilken partisjon som er ditt rotfilsystem, så velg den. Hvis du ikke vet hvilken som er ditt rotfilsystem, så prøver du den første på lista, om den ikke fungerer, så går du til neste på lista, helt til du finner den riktige. Det skader ikke å prøve seg fram på denne måten, og om du bare har et rotfilsystem, så burde dette gå raskt. Om du har flere rotfilsystem installert på dine harddisker, så er det nok best å vite nøyaktig hvilken partisjon som er korrekt.

Når du har valgt korrekt partisjon så får du valget mellom en del alternativ. Velg det alternativet som innebærer å starte et skall på den valgte partisjonen, hvis dette ikke går, så velg en annen partisjon.

Nå bør du ha fått opp et skall som brukeren root på ditt rotfilsystem montert på /target. Du trenger tilgang til innholdet i /boot, /sbin og /usr, som nå burde befinne seg montert under /target/boot, /target/sbin og /target/usr. Hvis disse katalogene trenger å bli montert fra andre partisjoner, så gjør det (hvis du ikke vet hvilke partisjoner det er snakk om, så ta en titt i /etc/fstab).

Gå til avsnittet Seksjon 4.8.1, “Hvordan man unngår problemet før oppgradering” og bruk en av de to foreslåtte løsningene for å fikse problemet permanent. Når du er ferdig, så skriver du exit for å kommet ut av skallet, deretter velger du Start systemet på nytt for å starte opp på vanlig måte (ikke glem å fjerne cd'en).

4.8.2.3. Løsning 3

  1. Start opp ditt system med din favoritt Live-cd distribusjon, slik som Debian Live, Knoppix eller Ubuntu Live.

  2. Monter partisjonen der /boot katalogen finnes. Hvis du ikke vet hvilken det er, så bruk kommandoen dmesg for å finne ut om disken din heter hda, hdb, hdc, hdd eller sda, sdb, sdc, sdd. Når du vet hva disken din heter, for eksempel sdb, så kan du bruke denne kommandoen for å finne ut hva slags partisjoner som er på den, og finne den riktige partisjonen: fdisk -l /dev/sdb

  3. Hvis du har montert riktig partisjon på /mnt, og denne partisjonen faktisk inneholder /boot katalogen, så skal du redigere filen /mnt/boot/grub/menu.lst.

    Finn avsnittet som ligner på dette:

    ## ## End Default Options ##
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd          /initrd.img-2.6.26-1-686
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686 (single-user mode)
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro single
    initrd          /initrd.img-2.6.26-1-686
    
    ### END DEBIAN AUTOMAGIC KERNELS LIST

    og bytt ut alle hda, hdb, hdc, hdd med sda, sdb, sdc, sdd, der det passer seg. Ikke bytt ut linjer som ligner på:

    root            (hd0,0)

  4. Start systemet omigjen, ta ut den kjørklare Live-cd'en, og ditt system burde starte opp på normal måte.

  5. Når systemet ditt har startet opp, så gjennomfører du en av de foreslåtte metodene på Seksjon 4.8.1, “Hvordan man unngår problemet før oppgradering” for å løse problemet permanent.

4.9. Forberedelser for neste versjon

Etter oppgraderingen er det flere ting du kan gjøre for å forberede deg for neste versjon, den etter lenny.

  • Om den nye kjernepakkens metapakke ble dratt inn som en avhengighet på den gamle, så vil den bli markert som automatisk installert, dette bør fikses med:

    # aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
    
  • Fjern avleggse og ubrukte pakker, som beskrevet i Seksjon 4.10, “Avleggse pakker”. Du bør granske hvilke konfigurasjonsfiler de bruker, og vurderer å fjerne pakken fullstendig for å også fjerne konfigurasjonsfilene

4.10. Avleggse pakker

lenny introduserer flere tusen nye pakker, men over to tusen pakker som var med i etch har blitt pensjonert eller gjort avleggs og har blitt fjernet. Det finnes ingen støtte for å oppgradere disse pakkene. Selv om ingenting hindrer deg i å bruke pakker som har bitt gjort avleggs, så kommer Debian til å slutte med å tilby sikkerhetsoppgraderinger av disse pakkene normalt et år etter utgivelsen av lenny [6], og vil normalt ikke tilby annen støtte i denne tiden. Å erstatte dem med tilgjengelige alternativ, om det finnes, anbefales på det sterkeste.

Det finnes mange grunner for at en pakke har blitt fjernet fra distribusjonen: de vedlikeholdes ikke lenger av original utvikleren; det finnes ingen Debian-utvikler som er interessert i å vedlikeholde pakken; funksjonaliteten de tilbyr har blitt erstattet av en annen pakke (eller en nyere versjon); eller pakken ansees ikke for å være passende for lenny. I det siste tilfellet, så kan den fremdeles finnes i distribusjonen, i “unstable”-distribusjonen.

Det er lett å identifisere hvilke pakker som er “avleggse” ettersom pakkebehandlerene vil merke dem som nettopp det. Hvis du bruker aptitude, så ser du disse pakkene under “Foreldede pakker og pakker som er laget lokalt”. dselect tilbyr en lignende seksjon, men listen som vises kan være annerledes.

Om du har brukt aptitude for å manuelt installere pakker i etch, så vil den holde orden på disse pakkene og markere de som blir avleggse når en pakker som trengte dem blir fjernet. aptitude, til forskjell fra deborphan, vil ikke markere manuelt installerte pakker som avleggse, i motsetning til de pakker som ble installert gjennom en avhengighet.

Det finnes flere verktøy for å finne avleggse pakker, noen av dem er deborphan, debfoster eller cruft. deborphan anbefales, selv om den (som standard) bare rapporterer avleggse biblioteker: pakker i “libs” eller“oldlibs” som ikke lenger brukes av noen pakker. Ikke stol blindt på resultatet fra disse vertøyene, spesielt hvis du benytter deg av mye ikke-standard valg. Det anbefales sterkt at du manuelt går igjennom listen med pakker som foreslås fjernet.

Debian Bug Tracking System inneholder ofte mer informasjon om hvorfor en pakke har blitt fjernet. Du bør lese de arkiverte feilrapportene for selve pakken, samt de for pseudopakken på ftp.debian.org pseudo-package.

The list of obsolete packages includes:

  • apache (1.x), etterfølgeren er apache2

  • bind (8), successor is bind9

  • php4, successor is php5

  • postgresql-7.4, successor is postgresql-8.1

  • exim (3), successor is exim4

4.10.1. Dummy-pakker

Noen pakker fra etch har blitt delt opp i flere pakker i lenny, ofte har det blitt gjort for å gjøre vedlikeholdet av dem lettere. For å gjøre oppgraderingen lettere for slike tilfeller, så brukers det såkalte “dummy”-pakker: tomme pakker som har samme navn som pakken i etch hadde, men med de riktige avhengighetene slik at de nye pakkene blir installert. Disse “dummy”-pakkene kan ansees som overflødige, og kan etter oppgraderingen trygt fjernes.

Beskrivelsen for de fleste (men ikke alle) dummy-pakkene inneholder deres formål. Pakkebeskrivelsene for dummy-pakker er ikke enhetlige, du kan bruke deborphan med --guess valget for å finne slike pakker på ditt system. Merk at noen dummy-pakker ikke skal fjernes etter oppgraderingen, men at de har som funksjon å holde orden på versjonsnummerene på pakker over tid.



[2] Denne funksjonen kan skrus av med parameteren panic=0 til dine oppstartsparametere.

[3] Debian sitt pakkesystem tillater normalt ikke en pakke å fjerne eller overskrive en fil som tilhører en annen pakke, med mindre den er satt til på bytte ut denne pakken.

[4] Reglene der genereres automatisk av skriptet /etc/udev/rules.d/75-persistent-net-generator.rules for å ha statiske navn på nettverksenhetene. Slett den symbolske lenken for å gjøre den statiske enhetsnavngivningen via NIC via udev inaktiv.

[5] For mer informasjon om lilo sine feilkoder, se The Linux Bootdisk HOWTO.

[6] Eller så lenge det ikke kommer noen ny utgivelse i den tidsperioden. Normalt så støttes bare to stabile versjoner samtidig.