[ zurück ]
[ Inhalt ]
[ 1 ]
[ 2 ]
[ 3 ]
[ 4 ]
[ 5 ]
[ 6 ]
[ 7 ]
[ 8 ]
[ 9 ]
[ 10 ]
[ weiter ]
#debian.de - Frequently Asked Questions
Kapitel 2 - Paketsystem, Paketmanagement, Installation
2.1 Welche Vorteile bietet aptitude gegenüber apt-get?
Aptitude ist nicht nur ein weiteres Frontend für apt und dpkg, wie es apt-get
und dselect es sind. Es wurde zwar ursprünglich als direkter Nachfolger zu
dselect entwickelt, besitzt mittlerweile aber einen größeren Funktionsumfang
als dieses. Allerdings speichert aptitude die Informationen, die es für den
größeren Funktionsumfang braucht, in einer eigenen Datei, die von apt nicht
genutzt wird - d.h. um in den vollen Umfang der Vorteile zu kommen, sollte man
nicht zwischen den verschiedenen Frontends wechseln, sondern sich für eines
entscheiden und dann auch dabei bleiben. Die vollständige Dokumentation zu
aptitude findet sich hier: http://people.debian.org/~dburrows/aptitude-doc/en/
Aber warum denn nun aptitude?
2.1.1 aptitude kann sich so wie apt-get verhalten
Die Befehle aptitude update, aptitude upgrade und
aptitude install sehen so aus und verhalten sich fast genauso wie
apt-get. Zusätzlich gibt es noch einige Funktionen, die dabei helfen die
Übersicht über Abhängigkeiten und unnötige Pakete zu behalten.
2.1.2 aptitude kann von einem regulärem User benutzt werden
Es mag unbekannt sein, aber aptitude lässt sich von einem normalen User im
GUI-Modus bedienen. Da es als normaler User läuft, ist es unmöglich, das
System zu zerstören. Erst wenn aptitude gesagt bekommt, dass es die Änderungen
ausführen soll, erscheint ein Dialog, der zur Eingabe des root-Passworts
auffordert. Bis zu diesem Punkt sind alle Änderungen nicht wirksam und man
kann diese immer zurücksetzen, indem man aptitude beendet. (Es ist auch
möglich, vorherige Veränderungen durch drücken von Strg+u rückgängig zu
machen.)
2.1.3 aptitude hat eine leistungsfähige Benutzeroberfläche
Die grafische Oberfläche von aptitude erlaubt eine einfache Verwaltung der
installierten Pakete. Auch hilft aptitude, durch die Einordnung aller
Programme in Kategorien, leichter interessante und nützliche Programme zu
finden. Die Suchmaske erlaubt es direkt nach Name, Beschreibung, Maintainer,
Abhängigkeiten, usw. zu suchen.
2.1.4 aptitude kommt mit verschiedenen Quellen klar
Es dürfte bekannt sein, dass es möglich ist, viele Einträge in der Datei
/etc/apt/sources.list zu haben. Somit kann es sein, dass mehrere
Versionen eines Programms auf verschiedenen Servern existieren. Aptitude
erleichtert es eine Version zu installieren, die nicht dem Standard entspricht.
Und sollte einmal unstable ein Paket aus unstable nicht installierbar sein,
vereinfacht aptitude es die Version des Paket aus dem testing-Zweig zu
installieren.
2.1.5 aptitude erstellt Log-Dateien über alle seine Aktivitäten
Aptitude erstellt Logs in /var/log/aptitude über die Installation
bzw. Entfernung von Paketen, sowie über Upgrades. Das macht es einfach,
herauszufinden, was schief gelaufen ist, sollte das System nachher nicht mehr
richtig funktionieren. Mittlerweile bietet dpkg selbst auch ein eigenes
Logging.
2.2 In welchem Paket ist die Datei foobar?
-
Wenn man den exakten Dateinamen hat, findet man es am einfachsten mit apt-file
(aus dem gleichnamigen Paket). Einmal apt-file update aufrufen,
um die Dateilisten zu installieren, danach kann man mit apt-file search
DATEI suchen.
-
Auch mit dpkg -Sfoobar bekommt man heraus, zu welchem
installierten Paket eine Datei gehört, sofern das betreffende Paket
installiert ist. Umgekehrt listet dpkg -Lfoobar auf,
welche Dateien zu einem installierten Paket gehören.
-
Die manuelle Variante von apt-file für solche, die es sich nicht installieren
wollen oder können, ist das manuelle (zgrep) Durchsuchen der Contents-Dateien:
Sucht man eine Datei, die noch nicht installiert ist, holt man sich am besten
die Datei debian/dists/$(DIST)/Contents-$(ARCH).gz vom nächsten
Debian-Mirror und zgrept nach dem Dateinamen.
$ zgrep foobar Contents-$(ARCH).gz
$(DIST) steht hierbei für den Codenamen der Debian-Version (z.B. etch (4.0),
lenny oder sid). Alternativ kann man auch den momentanen Zustand der
gewünschten Version nehmen (stable, testing oder unstable). $(ARCH) steht für
die Architektur (i386, amd64, powerpc, etc.).
-
Man kann aber auch das Paket auto-apt installieren (aptitude
install auto-apt) und dann mit auto-apt search
foobar nach den Paketen suchen, die die Datei foobar
enthalten. Man sollte aber die dazugehörige Datenbank vor dem ersten Aufruf
anlegen und in regelmäßigen Abständen aktualisieren (auto-apt
update). Im Prinzip werden damit die Content-Dateien automatisch
heruntergeladen und nach der Zeichenkette foobar durchsucht, was den
meisten notorisch faulen Benutzern unter uns einiges an Handarbeit abnehmen
sollte.
-
Eine weitere Möglichkeit besteht in der Verwendung von findpkg
von Joey, das im Prinzip nur ein Wrapper für grep ist und eine
interne Datenbank verwendet, die regelmäßig mit findpkg -u
aktualisiert werden muss. Öfter als wöchentlich ist nicht nötig, da das
Original auch nicht häufiger aktualisiert wird.
2.2.1 Aber in welchem Paket ist die Datei -ldb, -lperl oder -ljpeg, o.ä.?
Das sieht nach der typischen Fehlermeldung des Compilers aus, etwas in der Art
von:
/usr/bin/ld: cannot find -lgnomevfs
collect2: ld returned 1 exit status
make[3]: *** [galeon-bin] Fehler 1
make[3]: Leaving directory `/tst/debian_tmp/galeon-0.12.1/src'
Die gesuchte Datei heißt nicht -lgnomevfs (-l... ist eine Abkürzung des
Linkers), sondern libgnomevfs.a.
2.2.2 Der Kernel sucht aber nach etwas mit Ncurses, wo finde ich das?
Siehe Kernel selbst kompilieren - nach Debian-Art,
Abschnitt 2.11.
2.3 Kernel-Panik: "unable to mount rootfs" mit dem Debian-Kernel.
F: Ich habe ein Linux-Image von Debian installiert (linux-image-foo-bar), beim
Booten kriege ich nur Kernel-Panik: "unable to mount rootfs".
A: Selbst schuld. Das Kernel-Setup schreibt klar und deutlich, was man in
/etc/lilo.conf (bzw. die Konfigurationsdatei deines Boot-Loaders) eintragen
soll und fragt DICH, ob DU es getan hast. Wer nicht liest, muss leiden.
Abhilfe: Das System mit dem alten Kernel booten (sofern der im Lilo-Menü noch
vorhanden ist) oder mit der Installationsdiskette/CD durch Angabe von
"rescue root=/dev/meine_partition". Dann /etc/lilo.conf editieren,
in die ersten Zeilen "initrd=/initrd.img" eintragen, "lilo"
aufrufen und neu booten.
2.4 Kernel-Panik: "unable to mount rootfs" mit einem selbst kompilierten Kernel.
F: Ich habe mir ein eigenes Linux-Image erstellt, beim Booten kriege ich nur
Kernel-Panik: "unable to mount rootfs".
A: Selbst schuld. Entweder hast du den Treiber für dein Festplatten-Subsystem
vergessen einzubauen, oder der Treiber konnte nicht geladen werden (z.B. wenn
der Treiber modular gewählt wurde, aber keine initrd erstellt oder in der
Bootloader-Konfiguration nicht angegeben wurde).
2.5 dpkg -l zeigt die Spalten nur abgeschnitten an
bash$ COLUMNS=200 dpkg -l | less
Damit wird dpkg eine Terminalbreite von 200 Zeichen vorgegeben, und
dementsprechend breit stellt dpkg die Spalten dar.
2.6 Wie setze ich noch mal ein Paket auf hold?
Da aptitude-holds durch apt und dselect
ignoriert werden und umgekehrt apt- bzw.
dselect-holds durch aptitude ignoriert werden (siehe
Bug #137771),
muss man Pakete mit dem Paketverwaltungsprogramm, das man benutzt auf
hold setzen.
Bei apt bzw. dselect ist es eigentlich ganz einfach:
$ echo paket hold | dpkg --set-selections
wobei paket mit dem Namen des gewünschten Pakets zu ersetzen ist.
Wenn man mehrere Pakete auf einmal auf hold setzen will, kann man
sich mit einem here-Dokument behelfen:
$ dpkg --set-selections << EOF
paket1 hold
paket2 hold
paket3 hold
EOF
Falls aptitude verwendet wird, ist folgendermaßen vorzugehen:
$ aptitude hold paket1 paket2 ...
oder aptitude starten, das Paket suchen und mit der
=-Taste auf hold setzen.
Auch auf hold gesetzte Pakete lassen sich per
apt-get install paket
explizit installieren, nur bei einem upgrade werden sie nicht
aktualisiert. Bei diesem Befehl bleibt das Paket auf hold. Der
entsprechende Befehl für aptitude
aptitude install paket
entfernt den Status hold.
2.7 Wie werde ich ein Paket mit seinen Abhängigkeiten wieder los?
Wenn auch die automatisch mitinstallierten Abhängigkeiten oder alle nicht mehr
benötigten Bibliotheken entfernt werden sollen, empfiehlt sich der Einsatz von
debfoster. Es schaut sich die "obersten" Pakete im
Abhängigkeitsbaum an und fragt jeweils, ob es diese entfernen soll. So kann
man z.B. nach "apt-get install gnome" wieder alle
Gnome-Pakete loswerden. Wer aptitude benutzt, hat dort eine
bereits ähnliche Funktion.
2.8 Sid-Pakete auch in "testing"/"stable" bequem installieren
Seit Woody hat apt die sehr bequeme Funktionalität, eine Default-Distribution
anzugeben, die er bei Installationen von neuen Paketen bevorzugt. Das macht es
möglich, auch die Zeilen für Sid in die sources.list (oder in zB
/etc/apt/sources.list.d/sid.list) einzutragen, ohne dass er gleich
die komplette Distribution updatet, man aber trotzdem komfortabel Pakete für
Sid installieren kann.
Für stable empfiehlt es sich erst einmal zu prüfen, ob das gewünschte Paket
nicht vielleicht bereits auf backports.debian.org gepflegt
wird.
Um dennoch Pakete aus Unstable zu verwenden geht man wie folgt vor:
Dazu schreibt man die Zeile
APT::Default-Release "6.0*";
für Squeeze oder
APT::Default-Release "wheezy";
für Wheezy entweder in die Datei /etc/apt/apt.conf oder in eine
neue Datei unter /etc/apt/apt.conf.d/. Überprüfen lässt sich die
Einstellung per apt-cache policy.
Danach kann man beruhigt die Zeilen für Sid in die sources.list
eintragen, sie werden aber beim aptitude upgrade nicht beachtet,
außer man gibt dies explizit per aptitude upgrade -t unstable an.
Wenn man jetzt ein Paket aus Sid installieren will, benutzt man folgende Zeile:
aptitude install paket/unstable
Dabei werden fehlende Abhängigkeiten auf Pakete in Sid nicht automatisch
aufgelöst, die sollte man gegebenenfalls dann noch per Hand zum
Installationsaufruf hinzufügen.
Möchten Sie es sich einfacher machen (*) und apt erlauben, automatisch die
Abhängigkeiten auf "unstable"-Pakete zu verfolgen, geht das mit einem
anderen Aufruf:
aptitude -t unstable install paket
(*) VORSICHT: Das kann zu unerwarteten Problemen und langen Installationsorgien
führen.
PS: Ein noch feinerer Mechanismus ist das sog. Apt-Pinning, das in der Manpage
apt_preferences (5) dokumentiert ist.
2.9 Apt über einen HTTP-Proxy benutzen
<case> wie geb ich einen http proxy in der bash an ? HTTP_PROXY ? dann tut das gerade bei mir nicht..
<Joey> http_proxy
<Zomb> case / Joey: ich zitiere euch mal im FAQ.
<case> zomb: aber dann vervollständige es: export http_proxy="service://domain_or_ip:port"
Und da wären wir. Die *_proxy-Variablen werden auch von einigen anderen
Programmen benutzt, z.B. von w3m. Die Datei
/etc/environment wird beim Login eingelesen (von PAM), also trägt
man da so etwas ein:
http_proxy=http://www-proxy.t-online.de:80
ftp_proxy=http://ftp-proxy.t-online.de:80
no_proxy=localhost
Vor der Benutzung einfach erneut einloggen oder die Variablen mit source
/etc/environment ; export http_proxy ftp_proxy no_proxy in die aktuelle
Shell einlesen.
Alternativ dazu kann man auch apt direkt so konfigurieren, dass es einen Proxy
verwendet, dazu müssen in /etc/apt/apt.conf oder in eine Datei in
/etc/apt/apt.conf.d/ (/etc/apt/apt.conf.d/custom bietet sich beispielsweise an)
folgende Zeilen eingefügt werden:
Acquire::http::Proxy "http://proxy.adresse.de:port";
Acquire::ftp::Proxy "http://proxy.adresse.de:port";
2.10 Kernel-Module bauen für Debian-Kernel
/* Vorgeplänkel:
> Ich habe Kernel-Module für meine Karte kompiliert
> Es wollte /usr/src/linux haben
> Ich habe Kernel-Quellen von kernel.org installiert
> Aber es sagt, ich habe die falsche Version
> Dann habe ich die Version per Hand in den Headern geändert
> Aber jetzt zeigen die Module "unresolved symbols" und ähnlichen Mist
*/
Die Abhängigkeit von dem lokalen /usr/src/linux-Verzeichnis hat seinen Sinn.
Dort werden die Header des LAUFENDEN Kernels erwartet, und diese sollten GENAU
passen. Quellen eines anderen Kernels bringen nur Ärger.
Für vorkompilierte Debian-Kernel werden auch sog. linux-headers-Pakete
ausgeliefert. Mit diesen kann man Module nachträglich bauen, ohne den ganzen
Quellbaum zu besitzen. Diese installiert man so:
module-assistant prepare
(aptitude install module-assistant wenn nicht vorhanden)
2.11 Kernel selbst kompilieren - nach Debian-Art
Debian hat ein kleines Programm, das den Kernel kompiliert (ggf. inklusive von
Zusätzen wie ALSA oder dem Nvidia-Treiber) und daraus Debian-Pakete erstellt,
die dann einfach installiert - und wieder deinstalliert - werden können.
Folgendes Kommando installiert das Paket und wichtige Zusatzpakete:
$ aptitude install kernel-package fakeroot libc6-dev gcc debianutils make libncurses5-dev
Jetzt entpackt man einen Kernel z.B. nach
/usr/src/kernel-source-VERSION, wechselt in dieses Verzeichnis,
konfiguriert den Kernel wie gewohnt mit make menuconfig,
make xconfig oder make config, und startet dann mit
$ make-kpkg kernel_image --rootcmd fakeroot --revision meinkernel.01
den Kompiliervorgang.
Wenn der abgeschlossen ist, kann man als root mit
# dpkg -i /usr/src/linux-image-VERSION_meinkernel.01_i386.deb
den Kernel wie gewohnt installieren.
Zusatz-Module wie ALSA, LM-Sensors, Nvidia lassen sich mit module-assistant
nachinstallieren.
$ m-a list nvidia
$ m-a a-i nvidia
Tipps: in /boot/config.VERSION liegt die Konfiguration
des installierten Kernels. Wird diese nach
/usr/src/kernel-source-VERSION/.config kopiert, braucht man mit
make oldconfig nur noch die neu hinzugekommenen Optionen
auswählen.
Bei Bedarf baut m-a fakesource den ursprünglichen Kernel-Quellcode
nach (mehr oder weniger).
2.12 Debian-Pakete aus dem Quellcode bauen
Es gibt im Prinzip drei Arten von Quellcode:
Wie baut man nur Pakete? Zunächst ein paar Vorbereitungen:
(als root) # aptitude install build-essential fakeroot
-
Bei der Version 1:
(als root) # apt-get build-dep PAKET
(als user) $ fakeroot apt-get -b source PAKET
Herauskommen sollte(n) fertige Debian-Pakete. Manchmal verzettelt sich apt-get
beim build-dep Schritt, dann kann man einfach weitermachen und warten, bis
fehlende Abhängigkeiten gemeldet werden, z.B. so:
dpkg-checkbuilddeps: Unmet build dependencies: liblircclient-dev
Die aufgelisteten Pakete muss man dann händisch nachinstallieren und den
Build-Vorgang wiederholen.
-
Version 2: Ähnlich vorgehen wie bei Version 1, nur kann apt-get damit nicht
funktionieren. Man startet den Build also manuell, nachdem man die
Source-Dateien heruntergeladen hat (paket_xyz.dsc, paket_xyz.tar.gz oder
.orig.gz plus .diff.gz).
dpkg-source -x paket*.dsc
cd paket*
dpkg-buildpackage -us -uc -rfakeroot
-
Version 3: Bei Third-Party-Code kann man alles mögliche vorfinden. Oft trifft
man mit autoconf erstellte Projekte (configure-Skript), diese erleichtern die
Arbeit (manchmal). Um solche Programme sauber zu installieren, kann das Tool
checkinstall (gleichnamiges Paket) verwendet werden, das die Installation
überwacht und deinstallierbare Pakete erzeugen kann. Bei Build-Abhängigkeiten
in fremden Paketen muss man sich oft auf die Angaben des Autors verlassen
(siehe Dateien README oder INSTALL), die Namen der nötigen Debian-Pakete kriegt
man wie oben (In welchem Paket ist die Datei
foobar?, Abschnitt 2.2) beschrieben raus.
2.13 sources.lists (etch, lenny, sid, kde, java, ATI-Treiber, ...)
Eigentlich gehören noch Einträge wie contrib oder non-free hinein, wie z.B.
deb http://ftp.de.debian.org/debian stable main contrib non-free
in die sources.list, aber in diesen Komponenten befinden sich
keine eigentlichen Debian-Pakete (die gibt es nur in "main") und
können nicht hundertprozentig von uns supportet werden, also beschränken wir
uns hier auf die Angabe der Quellen der main-Pakete. Der Vorgang ist denkbar
einfach:
-
Paket-Indizes holen mit:
aptitude update
-
Upgrade durchführen:
aptitude dist-upgrade
2.13.1 für Lenny == "oldstable", Debian 5.0 (Veraltet, nur für bestehende Installationen nutzen)
deb http://ftp.de.debian.org/debian lenny main
deb-src http://ftp.de.debian.org/debian lenny main
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://security.debian.org/ etch/updates main
deb-src http://security.debian.org/ etch/updates main
2.13.2 für Squeeze == "stable", Debian 6.0
deb http://ftp.de.debian.org/debian squeeze main
deb-src http://ftp.de.debian.org/debian squeeze main
deb http://ftp.de.debian.org/debian squeeze-updates main contrib
deb-src http://ftp.de.debian.org/debian squeeze-updates main contrib
deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main
2.13.3 für Wheezy == "testing"
deb http://ftp.de.debian.org/debian wheezy main
deb-src http://ftp.de.debian.org/debian wheezy main
deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main
2.13.4 für Sid == "unstable"
deb http://ftp.de.debian.org/debian sid main
deb-src http://ftp.de.debian.org/debian sid main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main
2.13.5 Inoffizielle apt sources - nicht von, aber für Debian
2.13.5.1 Google Chrome
Diese werden am besten in einer eigenen sources.list im Verzeichnis
/etc/apt/sources.list.d/ verwaltet.
cat /etc/apt/sources.list.d/google-chrome.list
$ deb http://dl.google.com/linux/chrome/deb/ stable main
Weitere, inoffizielle sources.list
Einträge
2.14 Von Lenny auf Squeeze aktualisieren
Da Squeeze nach langer Wartezeit den "stable"-Status erreicht hat und
Lenny über kurz oder lang archiviert werden wird, sollte man bei Gelegenheit
auf Squeeze umsteigen (es sei denn man ignoriert die potenzielle Gefahr aus
dieser Problematik). Zunächst liest man sich dazu die Release
Notes durch (oder überfliegt zumindest die wichtigsten Kapitel. Die
Kurzversion für Ungeduldige lautet: Man ändert die sources.list entsprechend
der Vorlage und macht ein aptitude update && aptitude
dist-upgrade. Wichtig ist, dass man alle Meldungen aufmerksam mitliest.
Speziell bei Serverdiensten sollte man am Schluss die Konfigurationsdateien
sehr sorgfältig durchsehen - hat ein Paket nicht mehr denselben Syntax, muss
man es von Hand anpassen.
2.15 apt-get/aptitude meckert wegen irgendwelchen Keys / nicht vertrauenswürdigen Paketquellen
Seit Etch ist eine neue Version von apt enthalten, die die Paketinstallation
etwas besser absichert. Dafür wird eine gpg-Signatur (eine digitale
Unterschrift) überprüft. Dazu muss gpg aber wissen, welchen Schlüsseln man
selbst vertraut. Zur Verwaltung dient das Tool apt-key. Ein
apt-key list zeigt Beispielsweise alle Keys an, denen man
vertraut, dabei werden automatisch die notwendigen Schlüssel des
Debian-Projekts für das Jahr 2006 und das Etch-Release importiert. Mit diesem
Kommando verschwindet schon einmal ein Teil der komischen Fehlermeldungen.
Sollte weiterhin von "untrusted sources" und ähnlichem die Rede sein,
so liegt dies wohl daran, dass man zusätzliche Quellen für apt in seiner
sources.list eingetragen hat. Dies sieht dann in etwa so aus: W: GPG
error: ftp://ftp.gwdg.de testing Release: The following signatures couldn't be
verified because the public key is not available: NO_PUBKEY
BB5E459A529B8BDA Sollte man dem genannten Schlüssel wirklich vertrauen
wollen, so lässt er sich mit:
keyid=lange_keyid_die_apt_anmeckert ;
gpg --keyserver subkeys.pgp.net --recv-key $keyid ;
gpg --fingerprint $keyid ;
<kontrollieren des ausgegebenen Fingerprints>
gpg --armor --export $keyid | apt-key add -
in den Schlüssel-Ring von apt importieren. Wichtig ist hier vor allem das
Kontrollieren des Fingerprints. Kontrolliert man nicht anhand des
Fingerprints, dass Signaturen tatsächlich vom Anbieter der Pakete stammen, ist
ganze System ausgehebelt und bringt keinen Mehrwert an Sicherheit. Nähere
Informationen dazu finden sie in man apt-key und man
apt-secure.
2.16 Ich mag "testing" nicht, kann ich wieder zurück?
Die kurze Antwort ist: Nein, mach es lieber nicht. Es gibt dabei zahlreiche
Probleme und Du bist auf Dich alleine gestellt, weil dieser Schritt nicht
unterstützt wird. Es wird zumeist einfacher sein, die alte Version von Grund
auf neu zu installieren.
Falls Du diesen Schritt aber trotzdem unbedingt versuchen willst, hat Joey dies
in einem Artikel über Apt-Pinning beschrieben, der auch Online verfügbar ist:
http://www.linux-magazin.de/Artikel/ausgabe/2002/11/apt/apt.html
2.17 Wo finde ich alte Debian-Pakete?
http://snapshot.debian.org/
[ zurück ]
[ Inhalt ]
[ 1 ]
[ 2 ]
[ 3 ]
[ 4 ]
[ 5 ]
[ 6 ]
[ 7 ]
[ 8 ]
[ 9 ]
[ 10 ]
[ weiter ]
#debian.de - Frequently Asked Questions
#debian.de-FAQ-Team
