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.

The main things you'll want to back up are the contents of /etc, /var/lib/dpkg, /var/lib/apt/extended_states and the output of dpkg --get-selections "*" (the quotes are important). If you use aptitude to manage packages on your system, you will also want to back up /var/lib/aptitude/pkgstates.

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.

You will have to do a kernel upgrade when upgrading to squeeze, so a reboot will be necessary.

During the upgrade process, there might be services associated with packages that will be include in the upgrade. If this is the case, these services might be stopped while the packages that are going to be upgraded are being replaced and configured. During this time, these services will not be available.

The precise downtime for these service will vary depending on the number of packages being upgraded in the system, and it also includes the time the system administrator answers the configuration questions from different package upgrades (if any). Notice that if the upgrade process is left unattended and the system requests input throughout the upgrade there is a high possibility of services being unavailable^[4] for a significant period of time.

If the system being upgraded provides critical services for your users or network^[5], you can reduce the downtime if you do a minimal system upgrade, as described in Seksjon 4.4.4, “Minimal systemoppgradering”, followed by a kernel upgrade and reboot (see Seksjon 4.4.5, “Upgrading the kernel and udev”), and then upgrade the packages associated with your critical services. Upgrade these packages prior to doing the full upgrade described in Seksjon 4.4.6, “Upgrading the system”. This way you can ensure that these critical services are running and available through the full upgrade process, and their downtime is reduced.

På grunn av de mange endringene i kjernen mellom lenny og squeeze, 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 squeeze 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.

	Viktig
	If you are using some VPN services (such as tinc) they might not be available throughout the upgrade process. Please see Seksjon 4.1.3, “Prepare for downtime on services”.

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.

Due to bug #512951, the splashy package needs to be purged prior to the upgrade.

	# apt-get purge splashy

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 lenny; og ikke stable eller squeeze; 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.

The “hold” package state for apt-get can be changed using:

# echo package_name hold | dpkg --set-selections

Replace hold with install to unset the “hold” state.

Om det er noe du trenger å rette på, så lønner det seg å passe på at sources.list fortsatt refererer til lenny, 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 squeeze, og endre de respektive linjene.

Hvis du har uoffisielle backportede pakker installert på ditt lenny system som er “nyere” enn de som finnes i Debian, så vil disse trolig skape konflikter under en oppgradering^[7]. Seksjon 4.5, “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/squeeze/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/squeeze/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 squeeze 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/squeeze/main/binary-i386/...
/var/ftp/debian/dists/squeeze/contrib/binary-i386/...

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

deb file:/var/ftp/debian squeeze 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-squeeze.time -a ~/upgrade-squeeze.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)

The typescript will also allow you to review information that has scrolled off-screen. If you are at the system's console, just switch to VT2 (using Alt+F2) and, after logging in, use less -R ~root/upgrade-squeeze.script to view the file.

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-squeeze.time ~/upgrade-squeeze.script

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

# apt-get update

You have to make sure before upgrading your system that you have sufficient hard disk space when you start the full system upgrade described in Seksjon 4.4.6, “Upgrading the system”. First, any package needed for installation that is fetched from the network is stored in /var/cache/apt/archives (and the partial/ subdirectory, during download), so you must make sure you have enough space on the file system partition that holds /var/ to temporarily download the packages that will be installed in your system. After the download, you will probably need more space in other file system partitions in order to both install upgraded packages (which might contain bigger binaries or more data) and new packages that will be pulled in for the upgrade. If your system does not have sufficient space you might end up with an incomplete upgrade that might be difficult to recover from.

apt-get can show you detailed information of the disk space needed for the installation. Before executing the upgrade, you can see this estimate by running:

# apt-get -o APT::Get::Trivial-Only=true dist-upgrade
[ ... ]
XXX upgraded, XXX newly installed, XXX to remove and XXX not upgraded.
Need to get xx.xMB of archives. 
After this operation, AAAMB of additional disk space will be used.

	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.4.4, “Minimal systemoppgradering” og fått oppgradert kjernen.

If you do not have enough space for the upgrade, apt-get will warn you with a message like this:

E: You don't have enough free space in /var/cache/apt/archives/.

In this situation, make sure you free up space beforehand. You can:

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

In some cases, doing the full upgrade (as described below) directly might remove large numbers of packages that you will want to keep. We therefore recommend a two-part upgrade process, first a minimal upgrade to overcome these conflicts, then a full upgrade as described in Seksjon 4.4.6, “Upgrading the system”.

To do this first, run:

# apt-get upgrade

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

The minimal system upgrade can also be useful when the system is tight on space and a full upgrade cannot be run due to space constrains.

The udev version in squeeze requires a kernel of version 2.6.26 or newer with the CONFIG_SYSFS_DEPRECATED option disabled and the CONFIG_INOTIFY_USER and CONFIG_SIGNALFD options enabled. Because the standard Debian kernels in lenny (version 2.6.26) have CONFIG_SYSFS_DEPRECATED enabled, and the udev version in lenny will not provide all the functionality expected by the latest kernels, special care must be taken when upgrading to avoid putting your system in an unbootable state.

Booting the 2.6.26 kernel from lenny with the udev from squeeze may result in a failure to correctly assign names to network devices, and will also fail to apply certain additional permissions to block devices (such as access by the disk group). The software itself will appear to be working, but some rules (for example, network-based rules) will not be loaded properly. It is therefore strongly recommended that you upgrade the kernel on its own at this point, to ensure a compatible kernel is available before upgrading udev.

For å fortsette med å oppgradere kjernen, så kjør:

# apt-get install linux-image-2.6-flavor

Les Seksjon 4.6.1, “Installere en metapakke for kjernen” for hjelp med å avgjøre hvilken variant av kjernepakken du bør installere.

Users of the grub bootloader should make sure that update-grub is run as part of the kernel upgrade, or run it manually.

Immediately after upgrading the kernel, you should also install the new udev to minimize the risk of other incompatibilities caused by using the old udev with a new kernel ^[8]. You can do this by running:

# apt-get install udev

Once you have upgraded both the kernel and udev the system should be rebooted.

Once you have taken the previous steps, you are now ready to continue with the main part of the upgrade. Execute:

# apt-get dist-upgrade

	Notat
	The upgrade process for other releases recommended the use of aptitude for the upgrade. This tool is not recommended for upgrades from lenny to squeeze.

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.

New versions of currently installed packages that cannot be upgraded without changing the install status of another package will be left at their current version (displayed as “held back”). This can be resolved by either using aptitude to choose these packages for installation or by trying apt-get -f install package.

Support for cryptoloop has been dropped from the Linux kernel packages included in Debian 6.0. Existing installations using cryptoloop need to be transitioned to dm-crypt before the upgrade.

The upgrade process to squeeze might ask for removal of packages in the system. The precise list of packages will vary depending on the set of packages that you have installed. These release notes give general advice on these removals, but if in doubt, it is recommended that you examine the package removals proposed by each method before proceeding.

Some common packages that are expected to be removed include: autofs (replaced by autofs5), dhcp3 (replaced by isc-dhcp), madwifi-source, python-setuptools and python2.4 (replaced by python2.6). For more information about packages obsoleted in squeeze, see Seksjon 4.10, “Avleggse pakker”.

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.

Sometimes it's necessary to enable the APT::Force-LoopBreak option in APT to be able to temporarily remove an essential package due to a Conflicts/Pre-Depends loop. apt-get will alert you of this and abort the upgrade. You can work around this by specifying the option -o APT::Force-LoopBreak=1 on the apt-get command line.

It is possible that a system's dependency structure can be so corrupt as to require manual intervention. Usually this means using apt-get or

# dpkg --remove pakkenavn

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

# apt-get -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” lenny 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

After fixing things up, you should be able to resume the upgrade by repeating the previously described apt-get commands.

During the upgrade, you will be asked questions regarding the configuration or re-configuration of several packages. When you are asked if any file in the /etc/init.d directory, or the /etc/manpath.config file should be replaced by the package maintainer's version, it's usually necessary to answer `yes' to ensure system consistency. You can always revert to the old versions, since they will be saved with a .dpkg-old extension.

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.

If you are running the upgrade using the system's local console you might find that at some points during the upgrade the console is shifted over to a different view and you lose visibility of the upgrade process. For example, this will happen in desktop systems when gdm is restarted.

To recover the console where the upgrade was running you will have to use Ctrl+Alt+F1 to switch back to the virtual terminal 1 if in the graphical startup screen or use Alt+F1 if in the local text-mode console. Replace F1 with the function key with the same number of the virtual terminal the upgrade was running in. You can also use Alt+Left Arrow or Alt+Right Arrow to switch between the different text-mode terminals.

In most cases, packages should upgrade smoothly between lenny and squeeze. There are a small number of cases where some intervention may be required, either before or during the upgrade; these are detailed below on a per-package basis.

Når du kjører dist-upgrade fra lenny til squeeze, 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

If you are unsure about which package to select, run uname -r and look for a package with a similar name. For example, if you see '2.6.26-2-686', it is recommended that you install linux-image-2.6-686. You may also use apt-cache to see a long description of each package in order to help choose the best one available. For example:

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

You should then use apt-get install to install it. Once this new kernel is installed you should reboot at the next available opportunity to get the benefits provided by the new kernel version.

For the more adventurous there is an easy way to compile your own custom kernel on Debian GNU/Linux. Install the kernel-package tool and read the documentation in /usr/share/doc/kernel-package. Alternatively, you can also use the kernel sources, provided in the linux-source-2.6 package. You can make use of the deb-pkg target available in the sources' makefile for building a binary package. There are some differences in these two approaches, please consult the respective package's documentation.

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.4.4, “Minimal systemoppgradering”.

In lenny and later, a new kernel mechanism for hardware discovery may change the order in which devices are discovered on your system on each boot, affecting the device names assigned to them. For example, if you have two network adapters that are associated with two different drivers, the devices eth0 and eth1 refer to may be swapped.

For network devices, this reordering is normally avoided by the definitions at /etc/udev/rules.d/70-persistent-net.rules for udev. Since these rules were already in place in lenny, no additional action should be required when upgrading to squeeze to get the benefit of stable network device names. Please note, however, that this udev mechanism means that a given network device name is tied to a particular piece of hardware; if you, for instance, exchange ethernet adapters in a deployed squeeze system, the new adapter will get a new interface name instead of using the existing one. To reuse an existing device name for new hardware, you will need to delete the associated entry from /etc/udev/rules.d/70-persistent-net.rules.

For storage devices, you may be able to avoid this reordering by using initramfs-tools and configuring it to load storage device driver modules in the same order they are currently loaded. However, in light of other changes to the storage subsystem of the Linux kernel as described at Seksjon 5.1.1, “Migration of disk drivers from IDE to PATA subsystem”, this is usually not worth the effort and it is recommended instead to use device names that are guaranteed to be stable over time, such as the UUID aliases ^[9] in the /dev/disk/by-uuid/ directory or LVM device names in /dev/mapper/.

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.

One can avoid this problem entirely by using an identifier for the root filesystem that does not change from one boot to the next. There are two possible methods for doing this - labeling the filesystem, or using the filesystem's universally unique identifier (UUID). These methods are supported in Debian since the etch release.

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:

During the upgrade, you will normally have been offered the option to "chainload" GRUB 2: that is, to keep GRUB Legacy as the primary boot loader but to add an option to it to load GRUB 2 and then start your Debian GNU/Linux system from that. This allows you to verify that GRUB 2 works on your system before committing to use it permanently.

Once you have confirmed that GRUB 2 works, you should switch to using it properly: the chainloading setup is only intended to be used temporarily. You can do this by running upgrade-from-grub-legacy.

The GRUB Manual has more information on the changes between GRUB Legacy and GRUB 2, some of which may require changes to complex configurations. If you have not modified your boot loader configuration, you should not need to do anything further.

Noen pakker fra lenny har blitt delt opp i flere pakker i squeeze, 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 lenny 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.

Most (but not all) dummy packages' descriptions indicate their purpose. Package descriptions for dummy packages are not uniform, however, so you might also find deborphan with the --guess-* options (e.g. --guess-dummy) useful to detect them in your system. Note that some dummy packages are not intended to be removed after an upgrade but are, instead, used to keep track of the current available version of a program over time.