Innan uppgradering av ditt system rekommenderas det starkt att du gör en fullständig säkerhetskopia, eller åtminstone en säkerhetskopia av data eller konfigurationsinformation som du inte vill riskera att förlora. Uppgraderingsverktygen och -processen är tillförlitlig men ett hårdvarufel mitt i en uppgradering kan resultera i ett allvarligt skadat system.

De huvudsakliga delar du vill säkerhetskopiera är innehållet i /etc, /var/lib/dpkg, /var/lib/aptitude/pkgstates och utdata från dpkg --get-selections "*" (citationstecknen är viktiga).

Själva uppgraderingsprocessen ändrar ingenting i katalogen /home. Dock är det känt att vissa program (exempelvis delar av Mozilla-sviten och skrivbordsmiljöerna GNOME och KDE) skriver över befintliga användarinställningar med nya standardvärden när en ny version av programmet startas för första gången av en användare. Som en försiktighetsåtgård bör du göra en säkerhetskopia av de dolda filerna och katalogerna (så kallade ”punktfiler”) i användarnas hemkataloger. Denna säkerhetskopia kan hjälpa till att återställa eller återskapa de gamla inställningarna. Du kanske även vill informera dina användare om det här.

Alla paketinstallationsåtgärder måste köras med superanvändarens rättigheter, logga in som root, använd su eller sudo för att få de nödvändiga åtkomsträttigheterna.

Uppgraderingen innebär att vissa förutsättningar måste mötas; du bör kontrollera dem innan den faktiska uppgraderingen påbörjas.

Det är klokt att informera alla användare i förväg angående de uppgraderingar som du planerar att göra, även om användarna som kommer åt ditt system via en ssh-anslutning knappt kommer att märka det under uppgraderingen, och bör kunna fortsätta att arbeta som vanligt.

Om du vill vidta extra försiktighetsåtgärder bör du säkerhetskopiera eller avmontera /home före uppgradering.

Du kommer antagligen behöva göra en kärnuppgradering vid uppgradering till lenny, så en omstart kommer troligen vara nödvändig. Vanligtvis kommer omstarten att göras efter att uppgraderingen är färdig.

På grund av många ändringar i kärnan mellan etch och lenny gällande drivrutiner, identifiering av hårdvara, namnstandarden och ordning på enhetsfiler, finns det en risk att du kan uppleva problem vid omstart av ditt system efter uppgraderingen. En del kända tänkbara problem finns dokumenterade i det här och de nästkommande kapitlen av Kommentarer till utgåvan.

Av den anledningen är det klokt att försäkra sig om att du kan återställa om ditt system skulle misslyckas att starta om eller, för fjärrhanterade system, misslyckas att komma åt nätverket.

Om du fjärruppgraderar via en ssh-länk är det starkt rekommenderat att du vidtar nödvändiga säkerhetsåtgärder för att kunna komma åt servern genom en fjärrserieterminal. Det finns en chans att, efter uppgraderingen av kärnan och omstart, vissa enheter kommer att få nya namn (som beskrivs i Avsnitt 4.6.2, ”Ny ordning för enhetsnumrering”) och du kommer att behöva rätta till systemkonfigurationen genom en lokal konsoll. Om systemet av misstag startas om mitt i en uppgradering finns det en chans att du behöver återställa systemet med hjälp av en lokal konsoll.

Det självklara är att först försöka starta om med din gamla kärna. Av olika anledningar, dokumenterade på annan plats i det här dokumentet, är det inte garanterat att det fungerar.

Om det misslyckas behöver du ett alternativt sätt att starta upp ditt system på så att du kan komma åt och reparera det. Ett alternativ är att använda en speciell räddningsavbild eller en cd-skiva med ett körbart Linuxsystem på. Efter att du har startat upp från en sådan skiva bör du kunna montera ditt rotfilsystem och använda chroot in i det för att undersöka och rätta till problemet.

Ett annat alternativ som vi rekommenderar är att använda räddningsläget i Debian-installeraren för lenny. Fördelen med att använda installeraren är att du kan välja bland dess många installationsmetoder för att hitta en som bäst passar din situation. För mer information, konsultera avsnittet ”Återställning av ett trasigt system” i kapitel 8 av Installationsguiden och Debian Installer FAQ.

Uppgradering av distributionen bör göras antingen lokalt från en virtuell textkonsoll (eller en direktansluten serieterminal), eller från ett fjärrsystem via en ssh-anslutning.

För att öka säkerhetsmarginalen vid en fjärruppgradering föreslår vi att du kör uppgraderingsprocesser i den virtuella konsollen som tillhandahålls av programmet screen, vilket gör att man säkert kan återansluta till sessionen och försäkra sig om att uppgraderingsprocessen inte avbryts även om fjärranslutningen avbryts.

	Viktigt
	Viktigt! Du bör inte uppgradera via telnet, rlogin, rsh eller från en X-session som hanteras av xdm, gdm eller kdm etc på maskinen som du uppgraderar. Då processer som hanterar dessa tjänster kan avslutas under uppgraderingen vilket kan resultera i ett oåtkomligt system som endast är halvt uppgraderat.

Användare som använder uppstartshanteraren LILO bör känna till att standardinställningen för initramfs-tools skapar en initramfs som är för stor för LILO att ladda. Dessa användare ska antingen byta till grub eller redigera följande i filen /etc/initramfs-tools/initramfs.conf:

MODULES=most

så att det står

MODULES=dep

Observera att detta medför att initramfs-tools endast installerar de moduler som behövs för den typ av hårdvara som den körs på i initramfs. Om du vill skapa ett uppstartsmedium som ska fungera på olika typer av hårdvara och inte bara just den som skapar initramfs ska alternativet fortsatt vara

MODULES=most

och klargör att du inte använder LILO.

I vissa fall kan användandet av apt-get för installation av paket istället för aptitude orsaka att aptitude anser att ett paket är ”oanvänt” och markera det för radering. Tillse att ditt system är helt uppdaterat och ”rent” innan du fortsätter med uppgraderingen.

På grund av detta bör du kontrollera och det finns några kommande åtgärder i pakethanteraren aptitude. Om ett paket är markerat för radering eller uppdatering i pakethanteraren kan det innebära att uppgraderingen drabbas negativt. Kom ihåg att detta endast kan åtgärdas om din sources.list fortfarande pekar på etch och inte på stable eller lenny, läs mer i Avsnitt A.2, ”Kontrollera dina källistor”.

För att genomföra denna granskning ska du köra aptitude i ”visuellt läge” och trycka g (”Gå”). Om det indikerar att det finns åtgärder att utföra kontrollera vad det är och lös dem eller kör föreslagen åtgärd. Om inga åtgärder föreslås visas ett meddelande, ”Inga paket är schemalagda för installation, borttagning eller uppgradering”.

Om du har konfigurerat APT att installera vissa paket från en annan distribution än den stabila (exempelvis från testing), kan du ändra din konfiguration för paketnålning i APT (lagrad i /etc/apt/preferences) för att tillåta uppgraderingen av paket till versionerna i den nya stabila utgåvan. Ytterligare information om APT-nålning kan hittas i apt_preferences(5).

Oavsett vilken metod som används för uppgradering, rekommenderas det att du kontrollerar statusen på paketen först och verifierar att alla paket är möjliga att uppgradera. Följande kommando kommer att visa de paket som har statusen Half-Installed eller Failed-Config, och de som har någon form av felstatus.

# dpkg --audit

Du kan även inspektera tillståndet för alla paket på ditt system med dselect, aptitude, eller med kommandon som

# dpkg -l | pager

eller

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

Det är önskvärt att ta bort eventuella tillbakahållna paket innan uppgradering. Om något paket är systemkritiskt och hålls tillbaka för uppgraderingen, kommer uppgraderingen att misslyckas.

Observera att aptitude använder en annan metod för att registrera paket som hålls tillbaka än apt-get och dselect. Du kan identifiera paket som hålls tillbaka med aptitude med

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

Om du vill kontrollera vilka paket som hålls tillbaka vid användning av apt-get, ska du använda

# dpkg --get-selections | grep hold

Om du ändrat och byggt om ett paket lokalt, och inte bytte namn på det eller la in ett datum i versionen, måste du hålla tillbaka det för att förhindra att det uppgraderas.

Pakettillståndet ”hold” för aptitude kan ändras med:

# aptitude hold package_name

Ersätt hold med unhold för att ändra ”hold”-tillståndet.

Om det är någonting du behöver rätta till är det bäst att se till att din sources.list fortfarande refererar till etch vilket förklaras i Avsnitt A.2, ”Kontrollera dina källistor”.

Om du har proposed-updates i din /etc/apt/sources.list ska du ta bort det innan du försöker uppdatera ditt system. Detta är en försiktighetsåtgärd för att minska risken att konflikter uppstår.

Om du har några icke-Debianpaket på ditt system, bör du tänka på att dessa kan tas bort under uppgraderingen på grund av beroendekonflikter. Om dessa paket blev installerade genom att lägga till extra paketarkiv i din /etc/apt/sources.list, bör du kontrollera om det arkivet även erbjuder paket som är byggda för lenny och ändra källraden på lämpligt sätt samtidigt som dina källrader för Debian-paket.

Vissa användare kan ha inofficiella bakåtporterade versioner av paket, som är ”nyare” än de som finns i Debian, installerade på sina etch-system. Sådana paket kommer med stor sannolikhet att orsaka problem under en uppgradering eftersom de kan resultera i filkonflikter^[3]. Avsnitt 4.5.8, ”Möjliga problem under uppgraderingen” innehåller information om hur man hanterar filkonflikter om de skulle inträffa.

Standardkonfigurationen är inställd för installation från Debians huvudservrar på Internet, men du kanske önskar ändra /etc/apt/sources.list till att använda andra speglar, föredragsvis en spegel som är nätverksmässigt närmare dig.

Adresserna till Debians HTTP- eller FTP-speglar kan hittas på http://www.debian.org/distrib/ftplist (se avsnittet ”Listan över Debianspeglingar”). HTTP-speglar är vanligtvis snabbare än FTP-speglar.

Till exempel, anta att din närmaste Debian-spegel är http://mirrors.kernel.org. När den spegeln inspekteras med en webbläsare eller FTP-program, kommer du att märka att huvudkatalogerna är organiserade så här:

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

Lägg till den här raden till din sources.list för att använda den här spegelservern med apt:

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

Observera att ”dists” läggs till automatiskt och argumenten efter utgåvans namn används för att utöka sökvägen till flera kataloger.

Efter att du har lagt till dina nya källor ska du inaktivera de tidigare befintliga ”deb”-raderna i sources.list genom att placera ett hash-tecken (#) framför dem.

Istället för att använda HTTP- eller FTP-paketspeglar, kanske du önskar ändra /etc/apt/sources.list till att använda en spegel på en lokal hårddisk (möjligen monterad över NFS).

Till exempel, din paketspegel kan finnas under /var/ftp/debian/ och innehåller huvudkataloger som dessa:

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

Lägg till den här raden till din sources.list för att använda den här med apt:

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

Observera att ”dists” läggs till automatiskt och argumenten efter utgåvans namn används för att utöka sökvägen till flera kataloger.

Efter att du har lagt till dina nya källor ska du inaktivera de tidigare befintliga ”deb”-raderna i sources.list genom att placera ett hash-tecken (#) framför dem.

Om du endast vill använda cd-skivor, kommentera ut de befintliga ”deb”-raderna i /etc/apt/sources.list genom att placera ett hash-tecken (#) framför dem.

Se till att det finns en rad i /etc/fstab som aktiverar montering av din cd-rom-enhet på monteringspunkten /cdrom (den exakta monteringspunkten /cdrom krävs för apt-cdrom). Till exempel, om /dev/hdc är din cd-rom-enhet, ska /etc/fstab innehålla en rad som denna:

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

Observera att det inte får finnas några blanksteg mellan orden defaults,noauto,ro i det fjärde fältet.

För att verifiera att det fungerar, mata in en cd och försök köra

# mount /cdrom    # det här monterar cd-skivan på monteringspunkten
# ls -alF /cdrom     # det här ska visa cd-skivans rotkatalog
# umount /cdrom  # det här kommer att avmontera cd-skivan

Kör sedan:

# apt-cdrom add

för varje Debian cd-rom med binärer som du har tillgång till för att lägga till data om varje cd till APT:s databas.

Det rekommenderas starkt att du använder programmet /usr/bin/script för att spela in en utskrift av uppgraderingssessionen. Om problem uppstår har du en logg på vad som hände och, om det behövs, kan tillhandahålla exakt information i en felrapport. För att påbörja inspelningen, kör:

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

eller liknande. Lägg inte typescript-filen i en temporär katalog såsom/tmp eller /var/tmp (filer i dessa kataloger kan tas bort under uppgraderingen eller under en omstart).

Typescript kommer även att låta dig granska informationen som har rullat ut från skärmen. Växla helt enkelt till VT2 (med Alt+F2) och, efter inloggning, använd less -R ~root/uppgradering-till-lenny.script för att visa filen.

Efter att du har färdigställt uppgraderingen, kan du stoppa script genom att ange exit vid prompten.

Om du har använt flaggan -t för script kan du använda programmet scriptreplay för att spela upp hela sessionen:

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

Först behöver listan över tillgängliga paket för den nya utgåvan hämtas. Det görs genom att köra:

# aptitude update

Körning av det här första gången nya källor uppdateras kommer att skriva ut några varningar som relaterar till tillgängligheten för källorna. Dessa varningar är harmlösa och kommer inte att visas om du kör kommandot igen.

Du måste kontrollera att ditt system har tillräckligt mycket ledigt hårddiskutrymme innan du påbörjar en fullständig systemuppgradering, som beskrivs i Avsnitt 4.5.7, ”Uppgradering av resten av systemet”. Alla paket som behöver hämtas för installation kommer att hämtas från nätverket och lagras i /var/cache/apt/archives (och underkatalogen partial/ under hämtningen) så du måste se till att du har tillräckligt utrymme på filsystemspartitionen som innehåller /var/ för temporär hämtning av paketen som ska installeras på ditt system. Efter hämtningen kommer du antagligen behöva mer utrymme på de andra filsystemspartitionerna för att både installera de uppgraderade paketen (som kan innehålla större binärfiler eller mer data) och de nya paketen som kommer att inkluderas i uppgraderingen. Om ditt system inte har tillräckligt med utrymme kan det resultera i en ofullständig uppgradering som kan vara svår att rätta till.

Både aptitude och apt kommer att visa dig detaljerad information om det diskutrymme som behövs för installationen. Du kan se det här estimatet innan den faktiska uppgraderingen påbörjas genom att köra:

# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX uppgraderade, XXX nyinstallerade, XXX att ta bort och XXX inte uppgraderade.
Behöver hämta xx.xMB/yyyMB arkiv. Efter uppackning kommer AAAMB diskplats att användas.
Kommer att hämta/installera/ta bort paket.

Notera

Körning av det här kommandot i början av uppgraderingsprocessen kan ge felaktigheter. Anledningarna beskrivs i nästkommande avsnitt. I det fallet behöver du vänta tills du har gjort en minimal systemuppgradering enligt Avsnitt 4.5.6, ”Minimal systemuppgradering” och uppgraderat din kärna enligt Avsnitt 4.1.1.1, ”Kontrollera att du har korrekt kärna” innan du kör det här kommandot för att uppskatta diskutrymmet.

Om du inte har tillräckligt med utrymme kan du se till att frigöra utrymme innan uppgraderingen. Du kan till exempel:

Observera att för att ta bort paket på ett säkert sätt, rekommenderas det att växla tillbaka din sources.list till etch vilket förklaras i Avsnitt A.2, ”Kontrollera dina källistor”.

Många felrapporter har indikerat att paketen aptitude och apt i etch ofta misslyckas med att hantera uppgraderingen till lenny. Apt i lenny är bättre på att hantera komplexa kedjor av paket som omedelbart behöver ställas in och aptitude hittar smartare lösningar för att uppfylla beroenden. I och med att dessa funktioner används oerhört mycket vid dist-upgrade till lenny måste dessa paket först uppgraderas före allting annat. För apt kör:

# apt-get install apt

och för aptitude (om du har det installerat) kör:

# aptitude install aptitude

Detta steg kommer automatiskt att uppgradera libc6 och locales samt lägga till stödbibliotek för SELinux (libselinux1). Därefter kommer några tjänster att startas om, ex. xdm, gdm och kdm vilket medför att lokaka X11-sessioner kommer att avslutas.

Aptitude underhåller en lista med paket som installerats automatiskt (exempelvis som beroenden av ett annat paket). I lenny finns denna funktion även i apt.

När lenny-versionen av aptitude körs kommer den att läsa in listan med automatiskt installerade paket och konvertera den så att den kan användas tillsammans med lenny-versionen av apt. Om du har aptitude installerat ska du åtminstone köra ett av aptitudes kommandon för att genomföra konverteringen av listan, exempelvis kan du söka efter ett paket som inte finns.

# aptitude search "?false"

På grund av vissa nödvändiga paketkonflikter mellan etch och lenny kommer en direkt körning av aptitude dist-upgrade ofta att ta bort ett stort antal paket som du vill behålla. Vi rekommenderar därför en tvådelad uppgraderingsprocess, först en minimal uppgradering för att komma runt dessa konflikter och sedan en fullständig dist-upgrade.

Kör först:

# aptitude safe-upgrade

Det här innebär att endast de paket som kan uppgraderas utan att kräva att några andra paket tas bort eller installeras uppgraderas.

Nästa steg beror på uppsättningen paket som du har installerade. Dessa Kommentarer till utgåvan ger allmänna råd om vilken metod som ska användas, men om du är osäker är det rekommenderat att du undersöker de paketborttagningar som föreslås av varje metod innan du fortsätter.

Några vanliga paket som förväntas bli borttagna är bland annat base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common och xserver-common. För en mer komplett lista över föråldrade paket i lenny, se Avsnitt 4.10, ”Föråldrade paket”.

Du är nu redo att fortsätta med huvuddelen av uppgraderingen. Kör:

# aptitude dist-upgrade

Det här kommer att genomföra en fullständig uppgradering av systemet, alltså installera de senaste tillgängliga versionerna av samtliga paket och lösa alla tänkbara beroendeändringar mellan paketen i olika utgåvor. Om det är nödvändigt kommer det även att installera några nya paket (vanligtvis nya versioner av bibliotek eller paket som fått nya namn) samt ta bort eventuella föråldrade paket som står i konflikt med varandra.

Vid uppgradering från en uppsättning cd-skivor (eller dvd-skivor), kommer du att bli uppmanad att mata in specifika cd-skivor vid olika tillfällen under uppgraderingen. Du kanske måste mata in samma cd-skiva flera gånger; detta beror på att sammankopplade paket har blivit utspridda över cd-skivorna.

Nya versioner av installerade paket, som inte kan uppgraderas utan att ändra installationsstatus för ett annat paket, kommer att lämnas kvar vid deras nuvarande version (visas som ”återhållna”). Det kan lösas genom att antingen använda aptitude för att välja dessa paket för installation eller genom att prova aptitude -f install paket.

Om en åtgärd med aptitude, apt-get eller dpkg misslyckas med felet

F: Dynamisk MMap fick slut på utrymme
E: Dynamic MMap ran out of room

räcker inte standardutrymmet för cachen till. Du kan lösa det här genom att antingen ta bort eller kommentera rader som du inte behöver i /etc/apt/sources.list eller genom att öka storleken på cachen. Storleken på cachen kan ökas genom att ställa in APT::Cache-Limit i /etc/apt/apt.conf. Följande kommando kommer att ställa in den till ett värde som ska vara tillräckligt för uppgraderingen:

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

Det här förutsätter att du inte redan har ställt in variabeln i den filen.

Ibland är det nödvändigt att aktivera alternativet APT::Force-LoopBreak i APT för att temporärt ta bort ett systemkritiskt paket på grund av en Konflikt/Förberoende-slinga. Aptitude kommer att varna dig om det här och avbryta uppgraderingen. Du kan lösa det genom att ange alternativet -o APT::Force-LoopBreak=1 på kommandoraden för aptitude.

Det är möjligt att beroendestrukturen för ett system kan vara så skadat att det kräver handpåläggning. Vanligtvis innebär det att använda aptitude eller

# dpkg --remove package_name

för att plocka bort några av de störande paketen, eller

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

I extrema fall kan du behöva tvinga fram en ominstallation med ett kommando som detta

# dpkg --install /sökväg/till/paketnamn.deb

Filkonflikter bör inte inträffa om du uppgraderar från ett ”rent” etch-system, men kan inträffa om du har inofficiella bakåtporteringar installerade. En filkonflikt resulterar i ett fel som:

Packar upp <paket-foo> (från <paket-fil-foo>) ...
dpkg: fel vid hantering av <paket-foo> (--install):
 försöker skriva över "<något-fil-namn>",
 som också finns i paketet <paket-bar>
dpkg-deb: underprocessen paste dödad av signal (Brutet rör)
 Fel uppstod vid hantering:
 <paket-foo>

Du kan försöka lösa en filkonflikt genom att tvinga igenom borttagning av paketet som nämns på sista raden i felmeddelandet:

# dpkg -r --force-depends paketnamn

Efter att problemen har lösts, bör du kunna återuppta uppgraderingen genom att upprepa tidigare beskrivna aptitude-kommandon.

Under uppgraderingen kommer det att ställas frågor om konfiguration eller omkonfigurationen av flera paket. När du blir tillfrågad om någon fil i katalogerna /etc/init.d eller /etc/terminfo, eller filen /etc/manpath.config ska ersättas av paketansvariges version, är det oftast nödvändigt att svara ”ja” för att upprätthålla systemets tillstånd. Du kan alltid återgå till de gamla versionerna, eftersom de kommer att sparas med en .dpkg-old-ändelse.

Om du inte är säker på vad som behöver göras, skriv ner namnet på paketet eller filen och red ut saker och ting senare. Du kan söka i typescript-filen för att granska informationen som visades på skärmen under uppgraderingen.

När du kör dist-upgrade från etch till lenny, rekommenderas det starkt att du installerar ett nytt linux-image-2.6-*-metapaket. Det här paketet kan installeras automatiskt av dist-upgrade-processen. Du kan verifiera det genom att köra:

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

Om du inte ser något utdata, behöver du installera ett nytt linux-image-paket för hand. Kör följande kommando för att se en lista över tillgängliga linux-image-2.6-metapaket:

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

Om du är osäker på vilket paket du ska välja, kör uname -r och leta efter ett paket med liknande namn. Om du till exempel ser ”2.6.18-6-686” rekommenderas det att du installerar linux-image-2.6-686 (observera att varianten k7 inte längre finns, om du för tillfället kör en kärna av k7-variant bör du installera varianten 686 istället.). Du kan även använda apt-cache för att se en lång beskrivning för varje paket för att hjälpa dig att välja den bästa möjliga. Till exempel:

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

Du bör sedan använda aptitude install för att installera den. När den här nya kärnan har installerats bör du starta om vid nästa möjliga tillfälle för att dra nytta av den nya kärnversionen.

För den mer äventyrlige finns det ett enkelt sätt att bygga sin egna, anpassade, kärna på Debian GNU/Linux. Installera verktyget kernel-package och läs dokumentationen i /usr/share/doc/kernel-package.

Om möjligt är det till din fördel att uppgradera kärnpaketet separat från själva dist-upgrade för att minska chanserna för ett temporärt icke-startbart system. Observera att det här bör endast göras efter den minimala uppgraderingsprocessen, beskriven i Avsnitt 4.5.6, ”Minimal systemuppgradering”.

lenny har en mer robust mekanism för att identifiera hårdvara än tidigare utgåvor. Dock kan den här orsaka ändringar på den ordning som enheter identifieras på ditt system vilket påverkar ordningen i vilken enhetsnamnen tilldelas. Om du till exempel har två nätverkskort som associeras med två olika drivrutiner, kan de enheter som eth0 och eth1 refererar till ändras. Observera att den nya mekanismen betyder att om du till exempel byter Ethernet-kort på ett körande lenny-system, kommer det nya kortet även att få ett nytt gränssnittsnamn.

För nätverksenheter kan du undvika den här omnumreringen genom att använda regler i udev, mer specifikt genom definitionerna i /etc/udev/rules.d/70_persistent-net.rules^[4]. Alternativt kan du använda verktyget ifrename för att binda fysiska enheter till specifika namn vid uppstarten. Se ifrename(8) och iftab(5) för mer information. De två alternativen (udev och ifrename) bör inte användas samtidigt.

För lagringsenheter kan du undvika den här omsorteringen genom att använda initramfs-tools och konfigurera det att läsa in drivrutinsmoduler för lagringsenheter i samma ordning som de för närvarande läses in i. För att göra detta, identifiera ordningen på lagringsmodulerna på ditt system genom att se på utdatat från lsmod. Lsmod listar moduler i omvänd ordning än den de lästes in i, alltså den första modulen i listan är den som sist lästes in. Observera att det här endast fungerar för enheter som kärnan numrerar i en stabil ordning (som PCI-enheter).

Dock kommer borttagning och omläsning av moduler efter initial uppstart att påverka ordningen. Din kärna kan även ha några drivrutiner som är statiskt länkade, och dessa namn kommer inte att visas i utdatat från lsmod. Du kan möjligen läsa ut dessa drivrutinsnamn och inläsningsordning genom att se i /var/log/kern.log, eller utdatat från dmesg.

Lägg till dessa modulnamn till /etc/initramfs-tools/modules i den ordning som de ska läsas in i vid uppstarten. Vissa modulnamn kan ha ändrats mellan etch och lenny. Till exempel har sym53c8xx_2 blivit sym53c8xx.

Du kommer att behöva generera om dina initramfs-avbild(er) genom att köra update-initramfs -u -k all.

När du väl kör en lenny-kärna tillsammans med udev kan du konfigurera om ditt system till att komma åt diskarna genom ett alias som inte är beroende av inläsningsordningen. Dessa alias finns under /dev/disk/-hierarkin.

Om en initrd som skapats med initramfs-tools används för att starta upp systemet, kan i vissa fall skapandet av enhetsfiler av udev ske för sent för uppstartsskripten att agera på.

De vanligaste symptomerna är att uppstarten misslyckas på grund av att rotfilsystemet inte kan monteras och du hamnar i ett felsökningsskal, men när du kontrollerar senare så finns alla nödvändiga enheter i /dev. Det har observerats i fall där rotfilsystemet finns på en USB-disk eller på RAID, speciellt om LILO används.

Ett sätt att komma runt det här problemet på är att använda uppstartsparametern rootdelay=9. Värdet för tidsgränsen (i sekunder) kan behöva justeras.

Om du använder lilo som uppstartshanterare (det är standardvalet för uppstartshantering i vissa installationer av etch) rekomenderas det starkt att du åter kör lilo efter uppdateringarna.

# /sbin/lilo

Observer att dett är ett nödvändigt steg även om du inte har uppdaterat din kärna i och med att andra steget av lilo har förändrats i och med uppdateringen av paket.

Kontrollera även innehållet i din /etc/kernel-img.conf och säkerställ att du har do_bootloader = Yes i den. På det viset kommer uppstartshanteraren alltid att köras efter en uppgradering av kärnan.

Skulle några problem uppstår när du kör lilo kontrollera de symboliska länkarna i / till vmlinuz och initrd samt att innehållet i /etc/lilo.conf inte avviker från detta.

Om du glömmer att köra lilo innan omstart av systemet eller om systemet startas om av misstag innan du gjort detta manuellt kan det innebära att systemet inte kan startas normalt. Isätllet för den vanliga lilo-bilden kommer endast LI visas när systemet ska startas^[5]. Se även Avsnitt 4.1.3, ”Förbered för återställning” för mer information om att återhämta sig från detta.

Problemet kan undvikas helt genom att använda en idetitet för rotfilsystemet som inte förändras mellan olika uppstarter. Det finns två möjliga metoder för att uppnå detta. Att sätta ettiketter på filsystem eller genom att använda ett filsystems universella unika identitet (UUID). Dessa metoder har funnits i Debian sedan utgåvan ”etch”.

Metoderna har fördelar och nackdelar. Etikett-metoden är mer läsbar men det kan finnas problem med den om ett annat filsystem på din maskin har samma ettikett. UUID-metoden är fulare men att det skulle skapas två filsystem med samma UUID är mycket osannolikt.

I exemplet nedan antas att rotfilsystemet finns på /dev/hda6. Vi antar dessutom att systemet har en fungernade udev-installation och ett ext2- eller ext3-filsystem.

För att använda ettikettmetoden:

För att använda UUID-metoden:

Vissa paket från etch har delats upp i flera paket i lenny, ofta för att förbättra systemunderhållet. För att göra uppgraderingssättet enklare i sådana fall, tillhandahåller lenny ofta så kallade ”dummy”-paket: tomma paket som har samma namn som det gamla paketet i etch med beroenden som gör att de nya paketen blir installerade. Dessa ”dummy”-paket anses som föråldrade paket efter uppgraderingen och kan med säkerhet tas bort.

Beskrivningarna för de flesta (men inte alla) dummy-paket indikerar deras syfte. Paketbeskrivningar för dummy-paket är inte enhetliga, dock kan deborphan med flaggan --guess vara användbar för att identifiera dem på ditt system. Observera att vissa dummy-paket inte är tänkta att tas bort efter en uppgradering men används istället för att hålla kontroll på den för närvarande tillgängliga versionen av ett program över tid.