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.

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.

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.

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! 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.

Brukere av oppstartslasteren LILO bør legge merke til at standardinnstillingene for initramfs-tools nå lager en initramfs som er for stor for LILO. Dere bør enten bytte til å bruke oppstartslasteren grub, eller redigere fila /etc/initramfs-tools/initramfs.conf, der endrer dere linja

MODULES=most

til å bli

MODULES=dep

Merk at dette gjør at pakken initramfs-tools kun vil installere de helt nødvendige moduler som trengs på ditt system. Om du vil lage et oppstartsmedium som skal fungere også på andre annerledes systemer, så bør du la det stå

MODULES=most

og passe på at du ikke bruker LILO.

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”.

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).

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”.

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.

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å.

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-i386/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-i386/...

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

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-i386/...
/var/ftp/debian/dists/lenny/contrib/binary-i386/...

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

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.

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

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.

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
	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:

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”.

Mange feilrapporter indikerer at pakkene aptitude og apt i etch versjonen mange ganger feiler ved oppgraderingen til lenny. I lenny så håndterer apt best kompliserte situasjoner hvor mange pakker trenger å konfigureres samtidig, mens aptitude er best på å finne løsninger på pakkeavhengigheter. Ettersom disse to pakkene er helt sentrale ved en dist-upgrade til lenny så må disse pakkene oppgraderes før noe annet. For å oppgradere apt så gjør dette:

# apt-get install apt

og for å oppgradere aptitude (hvis du har den installert), så gjør du:

# aptitude install aptitude

Dette vil automatisk oppgradere libc6 og locales, og vil også installere støttebibliotekene til SELinux (libselinux1). Deretter kommer en del tjenester til på å bli restartet, blant annet xdm, gdm og kdm, dette medfører at lokale X-sesjoner kan komme til å bli avbrutt.

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"

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”.

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.

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.

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”.

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.

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.

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.

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:

For å bruke UUID-metoden:

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.