[ föregående ] [ Innehåll ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ nästa ]
Vi föreslår att du läser informationen i Eventuella problemsituationer för etch, Kapitel 5 innan du uppgraderar. Det kapitlet täcker in möjliga problem som inte direkt relaterar till uppgraderingsprocessen men som fortfarande kan vara viktigt att känna till innan du påbörjar arbetet.
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 ganska tillförlitliga 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 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. Den säkerhetskopian 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,
så logga antingen in som root eller 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 användarnas partitioner (/home) före uppgradering.
Du kommer antagligen behöva göra en kärnuppgradering vid uppgradering till etch, så en omstart kommer vanligtvis vara nödvändig. Vanligtvis kommer den att göras efter att uppgraderingen är färdig.
På grund av många ändringar i kärnan mellan sarge och etch gällande drivrutiner, identifiering av hårdvara och 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 dessa 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 Ny ordning för enhetsnumrering, Avsnitt 4.6.4) 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. Dock, av olika anledningar dokumenterade någon annanstans 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 levande Linux-skiva. Efter att du har startat upp från en sådan skicka 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 etch. Fördelen av 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.
Paketet initramfs-tools inkluderar ett felsökningsskal[6] i de initrd-filer som den
genererar. Om, till exempel, initrd-filen inte kan montera ditt rotfilsystem,
kommer du att bli förflyttad in i det här felsökningsskalet vilket har
grundläggande kommandon tillgängliga för att hjälpa att spåra problemet och
möjligen rätta till det.
Grundläggande saker att kontrollera är: närvaron av korrekta enhetsfiler i
/dev; vilka moduler som läses in (cat /proc/modules);
utdata för dmesg efter fel vid inläsning av drivrutiner. Utdata
för dmesg kommer även att visa vilka enhetsfiler som har
tilldelats till vilka diskar; du bör kontrollera det här mot utdata för
echo $ROOT för att försäkra dig om att rotfilsystemet finns på den
förväntade enheten.
Om du lyckas rätta till problemet, skriv exit för att avsluta felsökningsskalet och fortsätta uppstartsprocessen där felet inträffade. Så klart behöver du även rätta till det underliggande problemet och generera om initrd-filen så att nästa uppstart inte misslyckas igen.
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! 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. Det är på grund av att
de processer som hanterar dessa tjänster kan avslutas under uppgraderingen,
vilket kan resultera i ett oåtkomligt system som endast är halvt
uppgraderat.
Om du kör en kärnversion lägre än 2.4.1 behöver du uppgradera till (åtminstone)
2.4-serien innan uppgradering av glibc. Det bör helst göras innan
uppgraderingen påbörjas. Det rekommenderas att du uppgraderar direkt till
2.6.8-kärnan tillgänglig i sarge, istället för att uppgradera till en
2.4-kärna.
Uppgraderingsprocessen som beskrivs i det här kapitlet har designats för
uppgraderingar från "rena" sarge-system utan tredjepartspaket.
Speciellt finns det kända problem med tredjepartspaket som installerar program
under /usr/X11R6/bin/ och orsakar problem med uppgraderingar på
grund av övergången till X.org (Övergång från XFree86 till X.Org, Avsnitt
5.3). För största möjliga tillförlitlighet för uppgraderingsprocessen bör
du ta bort tredjepartspaket från ditt system innan du påbörjar uppgraderingen.
Den här proceduren antar även att ditt system har uppdaterats till den senaste punktutgåvan av sarge. Om du inte har gjort det här eller är osäker, följ instruktionerna i Uppgradering av ditt sarge-system, Avsnitt A.1.
I vissa fall kan användningen av apt-get för installation av paket
istället för med aptitude kan göra att aptitude anser
ett paket som "unused" och schemalägga det för borttagning. I
allmänhet bör du se till att systemet är fullständigt uppdaterat och
"rent" innan du fortsätter med uppgraderingen.
På grund av det här bör du granska om det finns några väntande åtgärder i
pakethanteraren aptitude. Om ett paket är schemalagt för
borttagning eller uppdatering i pakethanteraren kan det påverka
uppgraderingsprocessen negativt. Observera att det endast är möjligt att rätta
till det här om din sources.list fortfarande pekar på
sarge; och inte till stable eller etch; se Kontrollera dina källistor, Avsnitt
A.2.
För att göra det här måste du köra aptitude och trycka på
"g" ("Gå"). Om det visar några åtgärder bör du granska dem
och antingen rätta till dem eller implementera de föreslagna åtgärderna. Om
inga åtgärder föreslås kommer du att se ett meddelande som säger "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 "*" > ~/nuvarande-paket.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 du hade hållt tillbaka för
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 paketnamn
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 sarge vilket förklaras i
Kontrollera dina källistor,
Avsnitt A.2.
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 etch 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 sarge-system. Sådana paket kommer med stor sannolikhet att orsaka problem under en uppgradering eftersom de kan resultera i filkonflikter[7]. Avsnittet Möjliga problem under uppgraderingen, Avsnitt 4.5.8 innehåller information om hur man hanterar filkonflikter om de skulle inträffa.
För att förhindra att aptitude tar bort vissa paket som
installerades som beroenden för andra paket behöver du manuellt avmarkera dem
som auto-paket. Det inkluderar OpenOffice och Vim för
skrivbordsinstallationer:
# aptitude unmarkauto openoffice.org vim
Och 2.6-kärnavbilder om du har installerat dem med ett kärnmetapaket:
# aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)
Observera: Du kan granska vilka paket som är markerade som auto i aptitude genom att köra:
# aptitude search 'i~M <paketnamn>'
Innan du påbörjar uppgraderingen måste du redigera konfigurationsfilen för
paketlistor i apt, /etc/apt/sources.list.
Apt kommer att anse att alla paket som kan hittas via någon
"deb"-rad, och installera paketet med högsta
versionsnumret, där prioritet ges till de förstnämnda raderna (på så sätt, om
det är så att flera speglar, skulle du vanligtvis först namnge en lokal
hårddisk, sedan cd-skivor, och sedan HTTP/FTP-speglar).
En utgåva kan ofta refereras till av både dess kodnamn (t.ex. sarge, etch) och efter dess statusnamn (alltså oldstable, stable, testing, unstable). Att referera till en utgåva efter dess kodnamn har fördelen att du aldrig blir överraskad av en ny utgåva och av den anledningen används den här metoden här. Det kan naturligtvis betyda att du själv måste hålla utkik efter nya utgåvor. Om du istället använder statusnamnet, kommer du bara att se massor av uppdateringar för paket som finns tillgängliga så snart en utgivning har skett.
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/debian/. 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/etch/main/binary-s390/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-s390/...
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 etch 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ålla huvudkataloger som dessa:
/var/ftp/debian/dists/etch/main/binary-s390/...
/var/ftp/debian/dists/etch/contrib/binary-s390/...
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 etch 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 Binary cd-rom som du har, för att lägga till data om varje cd till APT:s databas.
Det rekommenderade sättet att uppgradera mellan utgåvor av Debian GNU/Linux är
att använda pakethanteringsverktyget aptitude. Det här programmet
gör säkrare val angående paketinstallationer än att köra apt-get
direkt.
Glöm inte att montera alla nödvändiga partitioner (speciellt rot- och
/usr-partitionerna) läs- och skrivbara, med ett kommando som det
här:
# mount -o remount,rw /monteringspunkt
Efter det ska du dubbelkontrollera att källraderna för APT (i
/etc/apt/sources.list) refererar antingen till
"etch" eller till "stable". Det
ska inte finnas några källrader som pekar till sarge. Observera: källrader för
en cd-skiva kommer ofta att referera till "unstable",
även om det här är konstigt ska du inte ändra dem.
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>~/uppgradering-till-etch.time -a ~/uppgradering-till-etch.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-etch.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 ~/uppgradering-till-etch.time ~/uppgradering-till-etch.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 Uppgradering av resten av systemet,
Avsnitt 4.5.6. 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 paket 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.
Om du inte har tillräckligt med utrymme kan du se till att frigöra utrymme innan uppgraderingen. Du kan till exempel:
Ta bort paket som tidigare har hämtats ner för installation (i
/var/cache/apt/archive). Rensa upp paketcachen genom att köra
apt-get clean eller aptitude clean vilket kommer att
ta bort alla tidigare hämtade paketfiler.
Ta bort gamla paket som du inte längre använder. Om du har paketet
popularity-contest installerat kan du använda
popcon-largest-unused för att lista de paket som du inte använder
i systemet och som tar upp mest utrymme. Du kan även använda
deborphan eller debfoster för att hitta föråldrade
paket (se Föråldrade paket, Avsnitt 4.9).
Alternativt kan du starta aptitude i "visuellt läge" och
hitta föråldrade paket under "Föråldrade och lokalt skapade paket".
Ta bort paket som tar upp för mycket utrymme och som du inte har ett omedelbart
behov av (du kan alltid installera om dem efter uppgraderingen). Du kan lista
paketen som tar upp mest utrymme genom att köra dpigs
(tillgängligt i paketet debian-goodies) eller med
wajig (kör wajig size).
Flytta systemloggar från /var/log/ till ett annat system, eller ta
bort permanent.
Observera att för att ta bort paket på ett säkert sätt, rekommenderas det att
växla tillbaka din sources.list till sarge vilket förklaras i Kontrollera dina källistor, Avsnitt
A.2.
På grund av vissa nödvändiga paketkonflikter mellan sarge och etch 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 upgrade
Det här har effekten av att uppgradera de paket som kan uppgraderas utan att kräva att några andra paket tas bort eller installeras.
Följ upp den minimala uppgraderingen med:
# aptitude install initrd-tools
Det här steget kommer automatiskt att uppgradera libc6 och
locales och kommer att dra in stödbibliotek för SELinux
(libselinux1). Vid det här tillfället kommer vissa körande
tjänster att startas om, inklusive xdm, gdm och
kdm. Ett resultat av detta är att lokala X11-sessioner kommer att
brytas.
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 att 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 etch, se Föråldrade paket, Avsnitt 4.9.
Dessa uppgraderingssteg har verifierats att fungera på sarge-system med funktionen desktop installerad. Det är antagligen den metod som kommer att ge bäst resultat på system med funktionen desktop installerad, eller med paketen gnome eller kde installerade.
Det är antagligen inte den korrekta metoden att använda om du inte
redan har paketen libfam0c102 och xlibmesa-glu
installerade:
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Om du har ett fullständigt skrivbordssystem installerat kan du köra:
# aptitude install libfam0 xlibmesa-glu
System med vissa X-paket installerade, men inte den fullständiga funktionen
desktop, kräver en annan metod. Den här metoden gäller i
allmänhet för system med xfree86-common installerat, inklusive
vissa serversystem som har serverfunktioner i tasksel installerade
eftersom några av dessa funktioner inkluderar grafiska hanteringsverktyg. Det
är antagligen den rätta metoden att använda för system som kör X, men som inte
har den fullständiga funktionen desktop installerad.
# dpkg -l xfree86-common | grep ^ii
Kontrollera först om du har paketen libfam0c102 och
xlibmesa-glu installerade.
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Om du inte har libfam0c102 installerat, ska du inte inkludera
libfam0 i följande kommandorad. Om du inte har
xlibmesa-glu installerat, ska du inte inkludera det i följande
kommandorad. [8]
# aptitude install x11-common libfam0 xlibmesa-glu
Observera att om du installerar libfam0 kommer det även att
installera File Alteration Monitor (fam) såväl som RPC portmapper
(portmap) om de inte redan finns tillgängliga i ditt system. Båda
paketen kommer att aktivera nya nätverkstjänster i systemet även om de båda kan
konfigureras till att bindas till det (interna) vändslingegränssnittet.
På ett system utan X behövs inga extra installationskommandon för aptitude och du kan hoppa till nästa steg.
Versionen för udev i etch saknar stöd för kärnversioner tidigare
än 2.6.15 (som inkluderar sarge 2.6.8-kärnor), och udev-versionen
i sarge kommer inte att fungera korrekt med de senaste kärnorna. I tillägg
till det kommer en installation av etch-versionen av udev att
tvinga igenom en borttagning av hotplug som används av Linux
2.4-kärnor.
Som en konsekvens av detta kommer antagligen det tidigare kärnpaketen inte att
starta upp korrekt efter den här uppgraderingen. Det finns även ett
tidsfönster under uppgraderingen i vilket udev har blivit
uppgraderat men den senaste kärnan har inte blivit installerad. Om systemet
blev omstartat vid den här tidspunkten, mitt i uppgraderingen, kan det orsaka
att systemet inte kan starta upp på grund av att drivrutinerna inte
identifieras och läses in korrekt. (Se Förbered en säker miljö för uppgraderingen,
Avsnitt 4.1.4 för rekommendationer för att förbereda sig för den här
tänkbara situationen om du uppgraderar från ett fjärrsystem.)
SÅvida inte ditt system har funktionen desktop installerad, eller andra paket som skulle orsaka ett inte accepterbart antal paketborttagningar, är det därför rekommenderat att du uppgraderar kärnan för sig själv.
För att fortsätta med den här kärnuppgraderingen ska du köra:
# aptitude install linux-image-2.6-variant
Se Installera metapaketet för kärnan, Avsnitt 4.6.1 för hjälp med att fastställa vilken variant av kärnpaketen som du ska installera.
I skrivbordsfallet är det tyvärr inte möjligt att försäkra sig om att det nya
kärnpaketet installeras omedelbart efter det nya udev installeras,
så därför finns det ett tidsfönster när ditt system inte kommer att ha någon
kärna med fullständigt stöd för hotplug installerad. Se Uppgradering av din kärna och relaterade paket, Avsnitt
4.6 för information om hur man konfigurerar systemet till att inte vara
beroende av hotplug vid uppstart.
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, 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; det här är på grund av sammankopplade paket som 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 "held back"). 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.
Efter uppgraderingen, med den nya versionen av apt, kan du nu
uppdatera din paketinformation som kommer att inkludera den nya
kontrollmekanismen för paketsignaturer:
# aptitude update
Uppgraderingen har redan hämtat och aktiverat signeringsnycklarna för Debians
paketarkiv. Om du lägger till andra (inofficiella) paketkällor kommer
apt att skriva ut varningar relaterade till dess oförmåga att
bekräfta att paketen som hämtas från dem är legitima och har inte ändrats av
någon. För mer information, se Pakethantering, Avsnitt 2.1.1.
Du kommer att märka det, eftersom du använder den nya versionen av
apt, att den hämtar paketskillnadsfiler (pdiff)
istället för den fullständiga paketindexlistan. För mer information om den här
funktionen kan du läsa Långsammare
uppdatering av APT:s paketindexfiler, Avsnitt 5.1.4.
Om en åtgärd med aptitude, apt-get eller
dpkg misslyckas med felet
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 Conflicts/Pre-Depends-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 paketnamn
för att plocka bort några av de störande paketen, eller
# aptitude --fix-broken 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" sarge-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 <paketfil-foo>) ...
dpkg: fel vid hantering av <paket-foo> (--install):
försöker skriva över "<något-filnamn>",
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.
Det här avsnittet förklarar hur man uppgraderar sin kärna och identifierar
tänkbara problem relaterade till den här uppgraderingen. Du kan antingen
installera ett av paketen linux-image-* som tillhandahålls av
Debian, eller bygga en anpassad kärna från källkod.
Observera att en hel del information i det här avsnittet är baserad på
antagelsen att du kommer att använda en av de modulära Debian-kärnorna
tillsammans med initramfs-tools och udev. Om du har
valt att använda en anpassad kärna som inte kräver en initrd eller om du
använder en annan initrd-generator kan delar av den här informationen vara
irrelevant för dig.
Observera också att om udev inte är installerat på ditt
system är det fortfarande möjligt att använda hotplug för att
identifiera hårdvara.
Om du för närvarande använder en 2.4-kärna bör du även läsa Uppgradering till en 2.6-kärna, Avsnitt 5.2 noggrant.
När du kör dist-upgrade från sarge till etch, 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.4.27-3-686" rekommenderas det att du installerar
linux-image-2.6-686. 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 din egna anpassade
kärna på Debian GNU/Linux. Installera verktyget kernel-package
och läs dokumentationen i /usr/share/doc/kernel-package.
Om du för närvarande kör en kärna ur 2.6-serien från sarge kommer den här uppgraderingen att ske automatiskt efter att du kör en fullständig uppgradering av systempaketen (som beskrivs i Uppgradering av paket, Avsnitt 4.5).
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. Se Uppgradering av kärnan, Avsnitt 4.5.5 för en beskrivning av den här processen. Observera att det här bör endast göras efter den minimala uppgraderingsprocessen, beskriven i Minimal systemuppgradering, Avsnitt 4.5.4.
Du kan också göra det här steget om du använder din egna anpassade kärna och
vill använda kärnan som finns tillgänglig i etch. Om din kärnversion inte
stöds av udev är det rekommenderat att du uppgraderar efter den
minimala uppgraderingen. Om din version stöds av udev kan du med
säkerhet vänta tills efter den fullständiga systemuppgraderingen.
Om du har en 2.4-kärna installerad och ditt system förlitar sig på
hotplug för att identifiera sin hårdvara bör du först uppgradera
till en 2.6-kärna från sarge innan du försöker med uppgraderingen. Försäkra
dig om att 2.6-kärnan startar upp ditt system och att all din hårdvara
identifieras korrekt innan du genomför uppgraderingen. Paketet
hotplug tas bort från systemet (och ersätts av udev)
när du kör en fullständig systemuppgradering. Om du inte gör
kärnuppgraderingen innan det här kanske ditt system inte kan starta upp korrekt
från och med nu. När du har gjort en uppgraderinge till en 2.6-kärna i sarge
kan du göra en kärnuppgradering som beskrivs i Uppgradering från en 2.6-kärna, Avsnitt 4.6.2.
Om ditt system inte förlitar sig på hotplug[9] kan du fördröja
kärnuppgraderingen till efter att du har gjort en fullständig
systemuppgradering, som beskrivs i Uppgradering av
resten av systemet, Avsnitt 4.5.6. När ditt system har blivit uppgraderat
kan du sedan göra följande (ändra kärnpaketets namn till det som mest passar
ditt system genom att ersätta <variant>):
# aptitude install linux-image-2.6-<variant>
etch 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 etch-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/z25_persistent-net.rules[10]. 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
för det här, 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 sarge och etch. 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 etch-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 vanliga symptomerna är att uppstarten misslyckas på grund av att
rotfilsystemet inte kan monteras och du försätts i ett felsökningsskal, men att
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.
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.
När aptitude dist-upgrade har kört färdigt är den "formella" uppgraderingen färdig, men det finns vissa andra saker som bör tas om hand före nästa omstart.
Debian-kärnor inkluderar inte längre stöd för devfs. Därför behöver användare med devfs manuellt konvertera sina system före uppstart med en etch-kärna.
Om du ser strängen "devfs" i /proc/mounts så använder du
säkerligen devfs. De konfigurationsfiler som refererar till
devfs-liknande namn kommer att behöva justeras till att använda
udev-liknande namn. Filer som säkerligen refererar till
devfs-liknande enhetsnamn inkluderar /etc/fstab,
/etc/lilo.conf, /boot/grub/menu.lst och
/etc/inittab.
Mer information om tänkbara problem finns tillgängligt i felrapporten #341152.
Inte all S/390-hårdvara kan konfigureras automatiskt. För kärnorna i etch
används ett nytt verktyg kallat sysconfig-hardware för att
konfigurera dessa enheter. Tyvärr finns ingen dokumentation för det här
verktyg eller dess konfigurationsfiler ännu. Konfigurationsfilerna för
sysconfig-hardware kan hittas under /etc/sysconfig/.
Speciellt om ditt system för närvarande kör en 2.4-kärna, kan det vara svårt
att få konfigurationen rätt. Om du behöver hjälp, kontakta gärna sändlistan
Debian S/390.
Installera först verktyget och generera om initrd eftersom verktyget tillhandahåller ett antal skript som behöver inkluderas i initrd-filen:
# aptitude install sysconfig-hardware
# update-initramfs -u -k all
Det här görs genom att ändra /etc/zipl.conf. Sysconfig-verktyget
kan använda enhetssökvägen till rotenheten för att aktivera den, vilket betyder
att den här sökvägen behöver skickas med i kärnans uppstartsparametrar. För en
vanlig dasd anges sökvägen som följer:
<bus>-<device>
Fö parametern root behöver partitionen läggas till i sökvägen. Så
om din dasda är 0.0.0122, istället för
root=/dev/dasda1 skulle du inkludera följande på
parameters-raden i /etc/zipl.conf:
root=/dev/disks/by-path/ccw-0.0.0122-part1
Eller så kan du alternativt använda parametern enable för att ange enheten som ska aktiveras; partitionen i det fallet:
root=/dev/dasda1 enable=ccw-0.0.0122
Sökvägarna kan skilja sig för olika enheter. Till exempel för diskar på en zFCP-fiberkanalsadapter innehåller sökvägen bussen, enheten, drivrutinen, wwpn och lun. Parametrar för en RAID1 skulle se ut ungefär som denna (på en enda rad):
root=/dev/md0 enable=ccw-0.0.2900-zfcp-0x21000020371c93a5:0
enable=ccw-0.0.2900-zfcp-0x21000020371d8f94:0
Andra dasd-enheter (dasds behövs inte för att ta fram rotfilsystemet) aktiveras
genom konfigurationsfiler i /etc/sysconfig/hardware/. För en
vanlig dasd behöver du bara skapa en fil med enhetssökvägen i dess namn:
# cd /etc/sysconfig/hardware
# touch config-ccw-0.0.0122
För diskar på en zFCP-fiberkanaladapter listas de individuella enheter inne i
filen. Med hjälp av exemplet ovanför, skapa filen
config-ccw-0.0.2900 som innehåller (andra enheten utelämnad för
läsbarhet):
ZFCP_DEVICES=(0x21000020371c93a5:0x0000000000000000 0x2100...:0x...)
Nätverksenheter aktiveras genom konfigurationsfiler i
/etc/sysconfig/hardware/. För en ctc-nätverksenhet med läskanalen
0.0.0a00 och skrivkanalen 0.0.0a01 och som använder
S/390-protokollet, skulle du skapa filen config-ccw-0.0.0a00 som
innehåller:
CCWGROUP_CHANS=(0.0.0a00 0.0.0a01)
CTC_PROTOCOL=0
För nätverksenheten qeth med layer2 aktiverat kan det här vara filen
config-ccw-0.0.0600:
CCWGROUP_CHANS=(0.0.0600 0.0.0601 0.0.0602)
QETH_OPTIONS=(layer2)
Alternativ som stöds för ctc är: CTC_PROTOCOL och CTC_BUFFER; och för qeth: QETH_PORTNAME, QETH_PORTNO och QETH_OPTIONS.
Eftersom nätverksenheter på S/390 inte har en fast MAC-adress är det inte
möjligt att använda enhetsnamn via udev. Istället kan du lägga
till alternativet INTERFACE_NAME i konfigurationsfilen för att
byta namn på ett nätverksgränssnitt.
mdadm behöver nu en konfigurationsfil för att sätta samman MD-kedjor (RAID)
från den initiala ramdisken och under systemets initieringssekvens. Se till
att läsa och agera efter de instruktioner som finns i
/usr/share/doc/mdadm/README.upgrading-2.5.3.gz efter att paketet
har uppgraderats och innan du startar om. Den senaste
versionen av den här filen finns tillgänglig på http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file;
läs den om du får problem.
Efter uppgraderingen finns det flera saker som du kan göra för att förbereda inför nästa utgåva.
Om du använder grub, redigera /etc/kernel-img.conf
och justera platsen för programmet update-grub genom att ändra
/sbin/update-grub till /usr/sbin/update-grub.
Om den nya kärnavbildens metapaket drogs in som ett beroende till den gamla, kommer det att markeras som automatiskt installerat, vilket bör korrigeras:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
Ta bort sarge-kärnans metapaket genom att köra:
# aptitude purge kernel-image-2.6-<variant>
Flytta eventuella konfigurationsvärden för kärnan i
/etc/network/options till /etc/sysctl.conf.
Ta bort föråldrade och oanvända paket som beskrivs i Föråldrade paket, Avsnitt 4.9. Du bör granska vilka konfigurationsfiler som de använder och överväga att avinstallera paketen fullständigt för att ta bort deras konfigurationsfiler
etch introducerar tusentals nya paket men pensionerar och utelämnar mer än två tusen gamla paket som fanns i sarge. Den tillhandahåller inget uppgraderingssätt för dessa föråldrade paket. Då ingenting hindrar dig från att fortsätta att använda ett föråldrat paket om så önskas, kommer Debian-projektet vanligtvis att sluta ge säkerhetsstöd för det ett år efter utgivningen av etch[11], och kommer normalt sett inte att tillhandahålla annat stöd under den tiden. Att ersätta dem med tillgängliga alternativ, om det finns några, rekommenderas.
Det finns många anledningar till varför paket kan ha tagits bort från distributionen: de underhålls inte längre av upphovsmännen; det finns inte längre någon Debian-utvecklare som är intresserad i att underhålla paketen; funktionaliteten de tillhandahåller har ersatts av en annan programvara (eller en ny version); eller så anses de inte längre vara lämpliga för etch på grund av fel i dem. I det senare fallet kan paket fortfarande finnas i "unstable"-distributionen.
Att identifiera vilka paket på ett uppdaterat system som är
"föråldrade" är enkelt eftersom pakethanteringsvertygen markerar dem
så. Om du använder aptitude, kommer du att se en lista över dessa
paket under "Föråldrade och lokalt skapade paket".
dselect tillhandahåller en liknande sektion men listning som visas
kan skilja sig. Dessutom, om du har använt aptitude för att
manuellt installera paket i sarge kommer den att hålla kontroll på de paket som
du manuellt installerat och kommer att kunna markera de paket som själva har
hämtats in av beroenden, vilka inte längre behövs om ett paket har tagits bort.
Dessutom, aptitude, till skillnad från deborphan
kommer inte markera de manuellt installerade som föråldrade paket, i motsats
till de som blev automatiskt installerade genom beroenden.
Det finns ytterligare verktyg som du kan använda för att hitta föråldrade
paket, såsom deborphan, debfoster eller
cruft. deborphan rekommenderas starkt, även om det
endast kommer (i standardläget) rapportera om föråldrade bibliotek: paket i
sektionerna "libs" eller "oldlibs" som inte används av
några andra paket. Ta inte helt blint bort de paket som dessa verktyg
presenterar, speciellt om du använder aggressiva ickestandardalternativ som är
benägna att producera felaktigheter. Det rekommenderas starkt att du manuellt
granskar paketen som föreslås för borttagning (alltså deras innehåll, storlek
och beskrivning) innan du tar bort dem.
Debians felhanteringssystem
tillhandahåller ofta ytterligare information om varför paketet blev borttaget.
Du bör granska både de arkiverade felrapporterna för själva paketet och de
arkiverade felrapporterna för pseudopaketet på ftp.debian.org.
Vissa paket från sarge har delats upp i flera paket i etch, ofta för att förbättra systemunderhållet. För att göra uppgraderingssättet enklare i sådana fall, tillhandahåller etch ofta så kallade "dummy"-paket: tomma paket som har samma namn som det gamla paketet i sarge 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.
[ föregående ] [ Innehåll ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ nästa ]
Kommentarer till utgåvan Debian GNU/Linux 4.0 ("etch"), S/390
$Id: release-notes.sv.sgml,v 1.283 2007/04/07 06:59:57 dnylander Exp $debian-doc@lists.debian.org