Re: APT, DSELECT, APTITUDE streiken
Hallo Thomas, Am Montag, den 15.08.2005, 11:46 +0200 schrieb Thomas Schönhoff: ... Der Wert von ulimit ist bei mir auf 2048 gesetzt, also habe ich ihn jetzt auf 4096 gesetzt. Das hat tatsächlich eine Veränderung gebracht, jetzt bricht der Downoad laut strace erst bei 99% ab. Mit ulimit = 8192 bricht die Aktion auch bei 99% ab! Aber endlich bewegt sich mal was :-), hoffe die Lösung ist nicht mehr fern! Ich habe gar keine Ahnung auf welchen Wert ich ulimit eigentlich gefahrlos setzen kann? Wo bzw. wie kann ich diesen Wert dauerhaft setzen? Bei mir ist folgendes voreingestellt: [EMAIL PROTECTED]:~$ ulimit -a core file size(blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files(-n) 1024 pipe size (512 bytes, -p) 8 stack size(kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes(-u) unlimited virtual memory(kbytes, -v) unlimited [EMAIL PROTECTED]:~$ ulimit unlimited ulimit ohne option entspricht ulimit -f (file size in 512byte blocks). Dein Wert von 2048 bedeutet, dass Du Dateien von maximal 1MByte Größe anlegen kannst. Das erscheint mir extrem eingeschränkt. Bisher habe ich auf allen Systemen nur unlimited oder 2097152 (= 1GByte) gesehen. In früheren Linux/UNIX Versionen ist ulimit oft in /etc/profile eingestellt worden. In meinem Debian/unstable System ist das nicht der Fall. Dafür gibt es aber in /etc/login.defs einige Hinweise. Unter anderem steht dort, dass im gecos-Feld der /etc/passwd ein ulimit-Wert untergebracht werden kann. Auf meinem System ist aber weder da noch dort etwas eingetragen, so dass ich davon ausgehe, dass unlimited auf Debian der Vorgabewert ist. Wenn es nötig ist, den ulimit-Wert pro User einzustellen, ist etwas Experimentierfreude verlangt. Denn je nach Login-Methode (Konsole, GUI(KDE, Gnome, ...)) können verschiedene Dateien in Frage kommen. Da wäre z.B.: .profile, .bash_rc, .bash_login, .bash_profile, .xsession, .xsession_prepare. Übrigens gibt es Hard- und Soft-Limits. Das kann man alles in man bash nachlesen im Abschnitt über ulimit. Da steht übrigens auch, dass die file size in 1K blocks angegeben ist, was aber entweder gegenüber UNIX System V Release 4 geändert wurde, oder falsch ist. Aber das kann man ja ausprobieren, wenn man eine echte (nicht-unlimited) Grenze ziehen will. Gruß, Ingo -- Ingo Strüwing, Senior Software Developer MySQL AB, www.mysql.de -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: APT, DSELECT, APTITUDE streiken
Am Freitag, den 12.08.2005, 13:20 +0200 schrieb Thomas Schönhoff:
...
open(/var/cache/apt/pkgcache.bin, O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fchmod(3, 0644) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(3, 12582912, SEEK_SET)= 12582912
write(3, \0, 1) = -1 EFBIG (File too large)
Da fallen mir zwei Sachen ein, die Du noch prüfen könntest:
1. APT::Cache-Limit 33554432; (oder eine andere Zahl größer als
12582912) in /etc/apt/apt.conf oder in einer Datei
in /etc/apt/apt.conf.d/.
2. ulimit -f
Gruß,
Ingo
--
Ingo Strüwing, Senior Software Developer
MySQL AB, www.mysql.de
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: APT, DSELECT, APTITUDE streiken
Moin,
habe mich leider erst heute nochmal um mein APT-Problem kümmern können.
Ich habe einige Vorschläge von Andreas P. und Richard umgesetzt, um der
Misere auf die Spur zu kommen!
Zunächst hat der vorgeschlagene Check des Dateisystems nichts Ungewöhnliches erbracht, das sieht ganz okay aus.
Darüber hinaus habe ich mehrere Dinge ausprobiert:
1)Den Anregungen von Andreas folgend habe ich mal Root auf LANG=C gesetzt und die englische Fehlermeldung erhalten:
thomas:~# apt-cache search foo
File size limit exceeded
Desweiteren habe ich den Cache Limit in /etc/apt/ auf 25165824
verdoppelt, das hat leider nicht den gewünschten Erfolg gebracht :-(
Egal, wie der Cache Limit gesetzt ist, bei einem apt-get update wird
der Download von packages.gz immer bei 60% mit der Fehlermeldung:
E: Method http has died unexpectedly!
abgebrochen!
In meiner sources.list finden sich gegenwärtig nur die Einträge:
deb http://ftp.de.debian.org/debian/ testing main
deb http://security.debian.org/ stable/updates main contrib
Konkret streikt APT bei dem ersten Eintrag, sobald die 60%-Marke erreicht ist.
Ich habe daraufhin mal alle Dateien in /var/lib/apt/lists und
Unterverzeichnissen gelöscht und ein apt-get update durchgeführt, mit
dem bereits bekannten Resultat!
Wenn ich das apt-get update mit strace durchführe, dann ist dort übrigens von bad file descriptor die Rede.
Hier der entsprechende strace-Auszug:
59% [1 Packages 2083416/3489kB
59%]
113kB/s 12s) = 121
select(7, [5 6], [], NULL, {0, 50}) = 1 (in [6], left {0, 399000})
--- SIGCHLD (Child exited) @ 0 (0) ---
read(6, ,
64000)
= 0
waitpid(4504, [{WIFSIGNALED(s) WTERMSIG(s) == SIGXFSZ}], 0) = 4504
close(6)
= 0
close(10)
= 0
gettimeofday({1124091110, 856095}, NULL) = 0
) =
122
close(5)
= 0
close(8)
= 0
kill(4503,
SIGINT)
= 0
waitpid(4503, [{WIFEXITED(s) WEXITSTATUS(s) == 100}], 0) = 4503
--- SIGCHLD (Child exited) @ 0 (0) ---
close(-1)
= -1 EBADF (Bad file descriptor)
close(-1)
= -1 EBADF (Bad file descriptor)
close(4)
= 0
Diese Datei-Deskritporen enthalten doch Metadaten über die zu öffnende
Datei (Größe, Format, byte- oder blockorientierte Lese-/Schreibweise,
Position des EOF-Zeichens usw.). Aber was bedeutet in diesem
Zusammenhang Bad?
Eine zweite Frage, die mir noch durch den Kopf geistert ist: Wenn das
Setzen von APTs Cache Limit keinen Einfluss auf apt-get update hat,
an welcher anderen Stelle als /etc/apt/apt.conf, könnte eine -von mir
bislang übersehende- Konfigurationsoption zu finden sein?
Abschließend, wo findet man in Debian Informationen, ob für irgendwelche Verzeichnisse Quotas/Limits gesetzt wurden?
Vielen Dank für Eure Geduld, aber die Sache ist wirklich misslich, da
APT mein System in diesem Zustand im Augenblick (fast) gänzlich
unbrauchbar macht.
Gruß
Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo Ingo, 2005/8/15, Ingo Strüwing [EMAIL PROTECTED]: Am Freitag, den 12.08.2005, 13:20 +0200 schrieb Thomas Schönhoff:Da fallen mir zwei Sachen ein, die Du noch prüfen könntest:1. APT::Cache-Limit 33554432; (oder eine andere Zahl größer als 12582912) in /etc/apt/apt.conf oder in einer Dateiin /etc/apt/apt.conf.d/.2. ulimit -f Zu ersten Option, die habe ich auf den vorgeschlagenen Wert gesetzt, leider ohne sichtliche Auswirkungen! Der Wert von ulimit ist bei mir auf 2048 gesetzt, also habe ich ihn jetzt auf 4096 gesetzt. Das hat tatsächlich eine Veränderung gebracht, jetzt bricht der Downoad laut strace erst bei 99% ab. Mit ulimit = 8192 bricht die Aktion auch bei 99% ab! Aber endlich bewegt sich mal was :-), hoffe die Lösung ist nicht mehr fern! Ich habe gar keine Ahnung auf welchen Wert ich ulimit eigentlich gefahrlos setzen kann? Wo bzw. wie kann ich diesen Wert dauerhaft setzen? Vielen Dank Thomas
[SOLVED] Re: APT, DSELECT, APTITUDE streiken
Hallo Leute, wie die Mail ja bereits andeutet ist das Problem scheinbar gelöst. Den Stein des Anstosses ist allem Anschein nach ulimit gewesen, dass ich jetzt auf 8192 gesetzt habe. Selbst dann funktionierte apt-get update erst als ich den APT-Cache Limit ganz raus genommen hatte! Warum? Keine Ahnung! Aber selbst bei 1,5 GB RAM kommt mir ein ulimit = 8192 doch ziemlich hoch vor, ist dass irgendwie, mal abgesehen von Forkbombs, noch aus irgendeinem anderen Grund problematisch diesen Wert in der /etc/bashrc konstant zu setzen? Setze ich ulimit -m (realer Speicher) oder ulimit -v (virtueller Speicher) in der bashrc ? Vielen Dank an alle, die sich geduldig die Mühe des Antwortens gemacht haben! Gruß Thomas
Re: APT, DSELECT, APTITUDE streiken
Thomas Schönhoff wrote: Kann mir jemand sagen, von welcher Datei apt-get, dselect oder aptitude da dauernd reden, die angeblich zu groß sein soll? Gibt es vielleicht einen manuellen Weg die Situation in den Griff zu bekommen? Ich würde als erstes mal versuchen, mit strace die exakte Fehlerquelle herauszubekommen. Da ich mit so einem Problem bisher (glücklicherweise) noch nicht konforntiert war, kann ich dazu weiter nichts sagen. Gruss -- Christian Fromme Mail: kaner at strace.org GPG: 9DE5E8B9 If you seek the kernel, then you must break the shell. (Meister Eckhart) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: APT, DSELECT, APTITUDE streiken
Hallo! On Fri, Aug 12, 2005 at 12:16:45PM +0200, Thomas Schönhoff wrote: Jetzt kann ich weder ein Paket installieren, de-installieren oder apt-cache search bzw. Sicherheitsupdates durchführen, es kommt immer: Die maximale Dateigroesse ist überschritten Kannst Du mit # LANG=POSIX apt-cache search foo mal die englischsprachige Fehlermeldung herausfinden und hier posten? Wolf -- SAGEN SIE NICHTS GEGEN DEN PUDEL DES TODES! (nichtlustig.de) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: APT, DSELECT, APTITUDE streiken
Hallo Christian,
Am 12.08.05 schrieb Christian Fromme [EMAIL PROTECTED]:
Thomas Schönhoff wrote:
Kann mir jemand sagen, von welcher Datei apt-get, dselect oder
aptitude da dauernd reden, die angeblich zu groß sein soll?
Gibt es vielleicht einen manuellen Weg die Situation in den Griff zu
bekommen?
Ich würde als erstes mal versuchen, mit strace die exakte Fehlerquelle
herauszubekommen. Da ich mit so einem Problem bisher (glücklicherweise)
noch nicht konforntiert war, kann ich dazu weiter nichts sagen.
vielen Dank für Deine Antwort, in der Tat war dies auch einer meiner
ersten Gedanken, allerdings bin ich aus dem Ergebnis nicht allzu
schlau geworden. Ich poste daher mal den strace-Auszug kurz vor dem
Abbruch, vielleicht kann mir ja jemand auf die Sprünge helfen ;-)
---snip---
open(/usr/lib/gconv/ISO8859-15.so, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\6\0\000...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=7456, ...}) = 0
old_mmap(NULL, 10396, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40325000
old_mmap(0x40327000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40327000
close(3)= 0
stat64(/var/cache/apt/pkgcache.bin, {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
open(/var/cache/apt/pkgcache.bin, O_RDONLY) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
brk(0) = 0x8078000
brk(0x8099000) = 0x8099000
close(3)= 0
unlink(/var/cache/apt/pkgcache.bin) = 0
lstat64(/var/cache/apt/pkgcache.bin, 0xb1fc) = -1 ENOENT (No
such file or directory)
open(/var/cache/apt/pkgcache.bin, O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fchmod(3, 0644) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(3, 12582912, SEEK_SET)= 12582912
write(3, \0, 1) = -1 EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) @ 0 (0) ---
+++ killed by SIGXFSZ +++
--snap---
Er öffnet zuvor /var/cache/apt/pkgcache.bin, dann tritt der Fehler
ein, richtig? Also die besagte Datei-Attribute sehe so aus:
# ls -l /var/cache/apt/pkgcache.bin
-rw-r--r-- 1 root root 0 2005-08-12 13:08 /var/cache/apt/pkgcache.bin
# file /var/cache/apt/pkgcache.bin
/var/cache/apt/pkgcache.bin: empty
Ich kann da keinen Fehler erkennen, aber das will gar nichts sagen :-)
Nochmals Danke
Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo Wolf, Am 12.08.05 schrieb Thomas Schönhoff [EMAIL PROTECTED]: Hallo Wolf, 2005/8/12, Wolf Wiegand [EMAIL PROTECTED]: Hallo! On Fri, Aug 12, 2005 at 12:16:45PM +0200, Thomas Schönhoff wrote: Jetzt kann ich weder ein Paket installieren, de-installieren oder apt-cache search bzw. Sicherheitsupdates durchführen, es kommt immer: Die maximale Dateigroesse ist überschritten Kannst Du mit # LANG=POSIX apt-cache search foo mal die englischsprachige Fehlermeldung herausfinden und hier posten? Würde ich gern tun, allerdings geht es weder von der Befehlszeile noch mit dpkg-reconfigure locales, das System will nur deutsch reden???. Allerdings stand im strace-Auszug was von file too large, keine Ahnung ob das hilfreich ist!? sorry, die letzte Mail ging unbeabsichtig an Wolf als PM, daher nochmal an die Liste! Danke Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo Klaumi Am 12.08.05 schrieb Klaumi Klingsporn [EMAIL PROTECTED]: Am/At Freitag, 12. August 2005 12:16 Thomas Schönhoff [EMAIL PROTECTED] schrieb/wrote: Es kommt leider immer das Gleiche dabei raus, beide Methoden von APT (ftp,http) crashen nach ca. 50% des Downloads der Packages.gz : E: Method http has died unexpectedly! (ebenso mit ftp) Jetzt kann ich weder ein Paket installieren, de-installieren oder apt-cache search bzw. Sicherheitsupdates durchführen, es kommt immer: Die maximale Dateigroesse ist überschritten Gibt es vielleicht einen manuellen Weg die Situation in den Griff zu bekommen? Ich weiss nicht, ob ich da was verwechsle, aber ich denke das cachelimit von apt ist überschritten. Abhilfe schafft eine Datei /etc/apt/apt.conf.d/50cachelimit mit folgenden Inhalt: // increases apts cache-limit to 12 MB (12582912 is 12 * 1024 * 1024) //instead of 6MB // added by Thomas Aug 2005 APT::Cache-Limit 12582912; Wenn es das Verzeichnis /etc/apt/apt.conf.d nicht gibt muß das ganze in die eine Datei /etc/apt/apt.conf, die es dann aber schon geben müsste. Also, ich habe die vorgeschlagene Datei mal angelegt, allerdings hat das keine Auswirkungen auf das Problem gehabt, leider. Danke für Deine Antwort! Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo,erstmal danke für alle bisherigen Vorschläge, auch wenn ich die Sache noch nicht im Griff habe! Als Wolf mich nach der orginal englischen Fehlermeldung gefragt habe, ist mir aufgefallen, dass z.B. apt-cache search als normaler User thomas problemlos funktioniert. Es gibt keine Fehlermeldungen, allerdings funktioniert aus verständlichen Gründen ein apt-get update auch nicht, da das Tool nur unter Root richtig läuft.Meine Frage, könnte es sein, dass ich irgendwo ein Problem mit Zugriffsrechten habe? Ich habe einfach mal etwas rumgeschaut, allerdings ist mir erstmal nichts Wesentliches aufgefallen! Aber vielleicht gucke ich an den falschen Stellen!Hmm, gibt es da Dateien, die man besonders im Auge haben sollte?GrußThomas
Re: APT, DSELECT, APTITUDE streiken
Am Freitag, 12. August 2005 13:20 schrieb Thomas Schönhoff:
Hallo Christian,
Am 12.08.05 schrieb Christian Fromme [EMAIL PROTECTED]:
Thomas Schönhoff wrote:
Kann mir jemand sagen, von welcher Datei apt-get, dselect oder
aptitude da dauernd reden, die angeblich zu groß sein soll?
Gibt es vielleicht einen manuellen Weg die Situation in den Griff
zu bekommen?
Ich würde als erstes mal versuchen, mit strace die exakte
Fehlerquelle herauszubekommen. Da ich mit so einem Problem bisher
(glücklicherweise) noch nicht konforntiert war, kann ich dazu
weiter nichts sagen.
vielen Dank für Deine Antwort, in der Tat war dies auch einer meiner
ersten Gedanken, allerdings bin ich aus dem Ergebnis nicht allzu
schlau geworden. Ich poste daher mal den strace-Auszug kurz vor dem
Abbruch, vielleicht kann mir ja jemand auf die Sprünge helfen ;-)
---snip--
-
open(/usr/lib/gconv/ISO8859-15.so, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\6\0\000..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=7456, ...}) = 0
old_mmap(NULL, 10396, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x40325000 old_mmap(0x40327000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40327000
close(3)= 0
stat64(/var/cache/apt/pkgcache.bin, {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
open(/var/cache/apt/pkgcache.bin, O_RDONLY) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
brk(0) = 0x8078000
brk(0x8099000) = 0x8099000
close(3)= 0
unlink(/var/cache/apt/pkgcache.bin) = 0
lstat64(/var/cache/apt/pkgcache.bin, 0xb1fc) = -1 ENOENT (No
such file or directory)
open(/var/cache/apt/pkgcache.bin, O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fchmod(3, 0644) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(3, 12582912, SEEK_SET)= 12582912
write(3, \0, 1) = -1 EFBIG (File too large)
er versucht eine 12.582.912 Bytes große Datei zu erzeugen. Dabei bekommt
er die Meldung das das zu groß sei.
Dein Filesystem vielleicht defekt oder wirklich nicht mehr soviel Platz
dort?
--
Markus Schulz
Hm, wenn man sich nach einem Screenlock gar nicht mehr wieder anmelden
kann, ist das natürlich sehr sicher. In diesem Sinne wird die Sicherheit
des Systems durch den Bug sogar sehr erhöht. :-))
Re: APT, DSELECT, APTITUDE streiken
Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 2005 14:23:17 +0200): Hallo, erstmal danke für alle bisherigen Vorschläge, auch wenn ich die Sache noch nicht im Griff habe! Als Wolf mich nach der orginal englischen Fehlermeldung gefragt habe, ist mir aufgefallen, dass z.B. apt-cache search als normaler User thomas problemlos funktioniert. Es gibt keine Fehlermeldungen, allerdings funktioniert aus verständlichen Gründen ein apt-get update auch nicht, da das Tool nur unter Root richtig läuft. [...] Am Dateisystem (/var) hast du genug Platz? Hab ja keinen Schimmer woran das liegen koennte, aber wenn du den Fehler nicht finden kannst (du hast ja schon so einiges versucht, dass in anderen/aehnlichen Faellen zum Erfolg fuehrte) hilft vielleicht dieser Wuerg'around: Hol die, das apt*system betreffende, packete (version beachten) via ftp vom mirror und reinstallier sie von 'nem lokalen Datentraeger. Das wuerd' ich aber nur _nach_ Backup und als letzte schnelle Loesung vorschlagen, da dabei ja eventuell noch mehr kaputtgehen koennte. Thomas sl ritch
Re: APT, DSELECT, APTITUDE streiken
Hallo Markus,
Am 12.08.05 schrieb Markus Schulz [EMAIL PROTECTED]
:
Am Freitag, 12. August 2005 13:20 schrieb Thomas Schönhoff: Hallo Christian, Am 12.08.05 schrieb Christian Fromme
[EMAIL PROTECTED]: Thomas Schönhoff wrote:
Kann mir jemand sagen, von welcher Datei apt-get, dselect oder aptitude da dauernd reden, die angeblich zu groß sein soll? Gibt es vielleicht einen manuellen Weg die Situation in den Griff
zu bekommen? Ich würde als erstes mal versuchen, mit strace die exakte Fehlerquelle herauszubekommen. Da ich mit so einem Problem bisher (glücklicherweise) noch nicht konforntiert war, kann ich dazu
weiter nichts sagen. vielen Dank für Deine Antwort, in der Tat war dies auch einer meiner ersten Gedanken, allerdings bin ich aus dem Ergebnis nicht allzu schlau geworden. Ich poste daher mal den strace-Auszug kurz vor dem
Abbruch, vielleicht kann mir ja jemand auf die Sprünge helfen ;-) ---snip--- open(/usr/lib/gconv/ISO8859-
15.so, O_RDONLY) = 3 read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\6\0\000..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=7456, ...}) = 0 old_mmap(NULL, 10396, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x40325000 old_mmap(0x40327000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40327000
close(3)=
0 stat64(/var/cache/apt/pkgcache.bin, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 open(/var/cache/apt/pkgcache.bin, O_RDONLY) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
brk(0)=
0x8078000
brk(0x8099000)=
0x8099000
close(3)=
0 unlink(/var/cache/apt/pkgcache.bin) = 0 lstat64(/var/cache/apt/pkgcache.bin, 0xb1fc) = -1 ENOENT (No such file or directory) open(/var/cache/apt/pkgcache.bin, O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fchmod(3,
0644)
= 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 lseek(3, 12582912, SEEK_SET)= 12582912
write(3, \0,
1)
= -1 EFBIG (File too large)er versucht eine 12.582.912 Bytes große Datei zu erzeugen. Dabei bekommter die Meldung das das zu groß sei.Dein Filesystem vielleicht defekt oder wirklich nicht mehr soviel Platz
dort?
Hmm, das / Verzeichnis (zu dem auch var gehört) hat 4GB
Speicherplatz frei. Die oben genannte Dateigroesse bezieht sich auf das
CacheLimit von APT, in /etc/apt/apt.conf.d/50CacheLimit ; dies hatte
ich auf einen Tip hin auf:
APT::Cache-Limit 12582912;
.gesetzt.
Die gleiche Meldung bekomme ich allerdings auch, wenn der CacheLimit
auf die Hälfte gesetzt wird. Eigentlich dürfte das doch kein
ernstzunehmendes Problem bei 4 GB verfügbaren Speicher sein, oder bin
ich da auf dem Holzweg?
Ich verstehe nicht genau, was da passiert:
fchmod(3, 0644)
= 0 (hier werden die Zugriffsrechte von
pkgcache-bin gescheckt)
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 (Datei ist schreibbar, okay!)
lseek(3, 12582912, SEEK_SET) = 12582912 (liest das CacheLimit in apt.conf aus)
write(3, \0, 1)
= -1 EFBIG (File too large) (will
Cache in /var/cache/apt/pkgcache-bin schreiben, aber zu groß,
daher Abbruch)
Verstehe ich das richtig?
Vielen Dank
Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo Richard, 2005/8/12, Richard Mittendorfer [EMAIL PROTECTED]: Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 200514:23:17 +0200): Hallo, erstmal danke für alle bisherigen Vorschläge, auch wenn ich die Sache nochnicht im Griff habe! Als Wolf mich nach der orginal englischen Fehlermeldung gefragt habe, istmir aufgefallen, dass z.B. apt-cache search als normaler User thomasproblemlos funktioniert. Es gibt keine Fehlermeldungen, allerdingsfunktioniert aus verständlichen Gründen ein apt-get update auch nicht, dadas Tool nur unter Root richtig läuft. [...]Am Dateisystem (/var) hast du genug Platz? Ich denke ja, daran liegt es nicht. Hab ja keinen Schimmer woran das liegen koennte, aber wenn du den Fehlernicht finden kannst (du hast ja schon so einiges versucht, dass in anderen/aehnlichen Faellen zum Erfolg fuehrte) hilft vielleicht dieserWuerg'around:Hol die, das apt*system betreffende, packete (version beachten) via ftpvom mirror und reinstallier sie von 'nem lokalen Datentraeger. Das wuerd' ich aber nur _nach_ Backup und als letzte schnelle Loesungvorschlagen, da dabei ja eventuell noch mehr kaputtgehen koennte.Hmm, das werd' ich wirklich als allerletzte Möglichkeit in Betracht ziehen. Mein schönes Etch ;-) MfG Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo, On Fri, Aug 12, 2005 at 03:13:34PM +0200, Thomas Schönhoff wrote: lseek(3, 12582912, SEEK_SET)= 12582912 (liest das CacheLimit in apt.conf aus) Nein, es wird zur Position 12582912 in der Datei pkgcache-bin gesprungen... write(3, \0, 1) = -1 EFBIG (File too large) (will Cache in /var/cache/apt/pkgcache-bin schreiben, aber zu groß, daher Abbruch) ...und hier wird probiert, etwas an diese Datei anzuhängen, was nicht klappt, da Limit==12582912 (vermute ich). Setze das Limit mal noch höher. Wolf -- Schöne Versprecher: Und nun die Lottovorhersage... (Jens Riewa in der Tagesschau) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: APT, DSELECT, APTITUDE streiken
On 12.Aug 2005 - 13:47:13, Thomas Schönhoff wrote: Am 12.08.05 schrieb Thomas Schönhoff [EMAIL PROTECTED]: 2005/8/12, Wolf Wiegand [EMAIL PROTECTED]: Kannst Du mit # LANG=POSIX apt-cache search foo mal die englischsprachige Fehlermeldung herausfinden und hier posten? Würde ich gern tun, allerdings geht es weder von der Befehlszeile noch mit dpkg-reconfigure locales, das System will nur deutsch reden???. Auf was steht denn die Variable LC_ALL? Was sagt locale? Der root-Account sollte keine LANG gesetzt haben, bzw. wenn dann C/POSIX. Deswegen waehle ich bei dpkg-reconfigure locales nichts anderes aus und packe das LANG=XXX in die $HOME/.bash_profile Andreas -- Don't relax! It's only your tension that's holding you together. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: APT, DSELECT, APTITUDE streiken
On 12.Aug 2005 - 14:23:17, Thomas Schönhoff wrote: Hallo, erstmal danke für alle bisherigen Vorschläge, auch wenn ich die Sache noch nicht im Griff habe! Als Wolf mich nach der orginal englischen Fehlermeldung gefragt habe, ist mir aufgefallen, dass z.B. apt-cache search als normaler User thomas problemlos funktioniert. Es gibt keine Fehlermeldungen, allerdings funktioniert aus verständlichen Gründen ein apt-get update auch nicht, da das Tool nur unter Root richtig läuft. Hmm, ist dein / evtl. voll? Was sagt denn df? Vllt. auch nur /var? Andreas -- Avert misunderstanding by calm, poise, and balance. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: APT, DSELECT, APTITUDE streiken
Am Freitag, 12. August 2005 15:13 schrieb Thomas Schönhoff:
Dein Text war aus irgendeinem Grund bereits zitiert?
Hallo Markus,
Am 12.08.05 schrieb Markus Schulz [EMAIL PROTECTED]:
[...]
er versucht eine 12.582.912 Bytes große Datei zu erzeugen. Dabei
bekommt er die Meldung das das zu groß sei.
Dein Filesystem vielleicht defekt oder wirklich nicht mehr soviel
Platz dort?
Hmm, das / Verzeichnis (zu dem auch var gehört) hat 4GB
Und /var ist nicht auf einer eigenen Partition?
Dann scheint das Filesystem wohl eine Macke zu haben.
Am besten du gehst mal in runlevel 1 (init 1) und prüfst es mal mit fsck
(Variante je nach Filesystem Typ) durch. (vorher mount -o,ro,remount /
damit dir keiner dazwischenfunkt)
Speicherplatz frei. Die oben genannte Dateigroesse bezieht sich auf
das CacheLimit von APT, in /etc/apt/apt.conf.d/50CacheLimit ;
dies hatte ich auf einen Tip hin auf:
APT::Cache-Limit 12582912;
.gesetzt.
Die gleiche Meldung bekomme ich allerdings auch, wenn der
CacheLimit auf die Hälfte gesetzt wird. Eigentlich dürfte das doch
kein ernstzunehmendes Problem bei 4 GB verfügbaren Speicher sein,
oder bin ich da auf dem Holzweg?
Ich verstehe nicht genau, was da passiert:
fchmod(3, 0644) = 0 (hier werden die Zugriffsrechte von
pkgcache-bin gescheckt)
sie werden nicht gecheckt sondern gesetzt.
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 (Datei ist
schreibbar, okay!)
stat holt alle relevanten Informationen zu der Datei, mehr nicht. Das
Holen hat geklappt (weil Result == 0).
Du kannst auf die Datei ja mal auf einer Konsole stat machen und das
hier posten.
lseek(3, 12582912, SEEK_SET) = 12582912 (liest das CacheLimit in
apt.confaus)
das seeked um die angegeben Anzahl Bytes nach vorn (interner Dateizeiger
wird nach weiter nach vorn gesetzt) um damit eine leere Datei der
entsprechenden Größe zu erzeugen. Da als Ergebnis die Stelle
zurückgegeben wird, klappt das also auch. Es ist allerdings kein
Problem den Dateizeiger hinter das EndOfFile (EOF) zu setzen.
write(3, \0, 1) = -1 EFBIG (File too large) (will Cache in
/var/cache/apt/pkgcache-bin schreiben, aber zu groß, daher Abbruch)
Jetzt will er eine abschliessende Null Terminierung dort reinschreiben
um die Datei mit der neuen Größe wirklich zu erzeugen und genau das
funktioniert nicht.
Wenn dort also noch genug Platz ist und die Partition auch schreibbar
(nicht ro gemountet) ist, dann sollte das auch funktionieren.
Andernfalls ist da ein Fehler im Filesystem zu vermuten.
Kannst du denn sonst noch Dateien auf dieser Partition anlegen?
z.B. mit
dd if=/dev/urandom bs=1024 count=1024 of=filename
legt eine 1MB Große Datei mit Random Daten an.
--
Markus Schulz
Aber meiner persönlichen Meinung nach ist ein Sid an 355 Tagen im Jahr
mehr stable als z.B. ein Suse fertig in den Läden steht.(Joerg
Rossdeutscher)
Re: APT, DSELECT, APTITUDE streiken
Hallo Andreas, Am 12.08.05 schrieb Andreas Pakulat [EMAIL PROTECTED]: On 12.Aug 2005 - 14:23:17, Thomas Schönhoff wrote: Hallo, erstmal danke für alle bisherigen Vorschläge, auch wenn ich die Sache noch nicht im Griff habe! Als Wolf mich nach der orginal englischen Fehlermeldung gefragt habe, ist mir aufgefallen, dass z.B. apt-cache search als normaler User thomas problemlos funktioniert. Es gibt keine Fehlermeldungen, allerdings funktioniert aus verständlichen Gründen ein apt-get update auch nicht, da das Tool nur unter Root richtig läuft.Hmm, ist dein / evtl. voll? Was sagt denn df? Vllt. auch nur /var?Also: thomas:~# df -m /var/ /dev/hda1 6571 2177 4060 35% / thomas:~# df -m / gibt das Gleiche aus! Danke Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo Andreas, Am 12.08.05 schrieb Andreas Pakulat [EMAIL PROTECTED]: On 12.Aug 2005 - 13:47:13, Thomas Schönhoff wrote: Am 12.08.05 schrieb Thomas Schönhoff [EMAIL PROTECTED]: 2005/8/12, Wolf Wiegand [EMAIL PROTECTED]: Kannst Du mit # LANG=POSIX apt-cache search foo mal die englischsprachige Fehlermeldung herausfinden und hier posten? Würde ich gern tun, allerdings geht es weder von der Befehlszeile nochmit dpkg-reconfigure locales, das System will nur deutsch reden???.Auf was steht denn die Variable LC_ALL? Was sagt locale? Der root-Account sollte keine LANG gesetzt haben, bzw. wenn dann C/POSIX.Deswegen waehle ich bei dpkg-reconfigure locales nichts anderes aus undpacke das LANG=XXX in die $HOME/.bash_profile Ah, das klingt logisch! thomas:~# env [EMAIL PROTECTED] [EMAIL PROTECTED] Kann man dies per Hand problemlos ändern? Gruß Thomas
Re: APT, DSELECT, APTITUDE streiken
Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 2005 15:17:30 +0200): Hallo Richard, hoi! 2005/8/12, Richard Mittendorfer [EMAIL PROTECTED]: Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 2005 14:23:17 +0200): Hallo, erstmal danke für alle bisherigen Vorschläge, auch wenn ich die Sache noch nicht im Griff habe! Als Wolf mich nach der orginal englischen Fehlermeldung gefragt habe, ist mir aufgefallen, dass z.B. apt-cache search als normaler User thomas problemlos funktioniert. Es gibt keine Fehlermeldungen, allerdings funktioniert aus verständlichen Gründen ein apt-get update auch nicht, da das Tool nur unter Root richtig läuft. [...] Am Dateisystem (/var) hast du genug Platz? Ich denke ja, daran liegt es nicht. Eher nicht ;) Ein Versuch war's wert... gate:/var/cache/apt# ls -lh insgesamt 19M drwxr-xr-x 3 root root 96 2005-08-12 13:40 archives -rw-r--r-- 1 root root 5,6M 2005-08-12 13:39 pkgcache.bin -rw-r--r-- 1 root root 5,4M 2005-08-12 13:37 srcpkgcache.bin Wobei ich ja noch unter der 6M Grenze bleibe (etch ). Hab mal versuchsweise die pkgcache.bin wegge-mv'd und dann nochmal in dselect ein [U]pdate gemacht - Datei wieder da. Die (dpkg)Install- informationen sind selbstvernatuerlich auch noch da. Sollte zwar nicht stoeren, aber tue die pkgcache.bin mal weg, stell einen hoeheren Wert (als das strace bringt) fuer Cache-Limit ein und versuchs nochmal. fs-check ist moeglicherweise (wie Markus schon angedeutet hat) auch keine schlechte Idee. Aber das file too large weisst eher auf ein apt-internes Resourcenproblemchen hin. Also wird eine Neuinstallation mit ziemlicher Sicherheit nix helfen. Was hast du so alles in deiner sources.list - koenntest ja mal was auskommentieren um etwas Platz zu sparen. HTH ritch
Re: APT, DSELECT, APTITUDE streiken
Hallo Markus,
2005/8/12, Markus Schulz [EMAIL PROTECTED]:
Am Freitag, 12. August 2005 15:13 schrieb Thomas Schönhoff:Dein Text war aus irgendeinem Grund bereits zitiert? Hallo Markus, Am 12.08.05 schrieb Markus Schulz
[EMAIL PROTECTED]:[...] er versucht eine 12.582.912 Bytes große Datei zu erzeugen. Dabei bekommt er die Meldung das das zu groß sei. Dein Filesystem vielleicht defekt oder wirklich nicht mehr soviel
Platz dort? Hmm, das / Verzeichnis (zu dem auch var gehört) hat 4GBUnd /var ist nicht auf einer eigenen Partition?
Nein, ich habe da ganz unkritisch dem Partitionsvorschlag (Desktop-System) des Debian-Installer vertraut!
Dann scheint das Filesystem wohl eine Macke zu haben.Am besten du gehst mal in runlevel 1 (init 1) und prüfst es mal mit fsck
(Variante je nach Filesystem Typ) durch. (vorher mount -o,ro,remount /damit dir keiner dazwischenfunkt) fchmod(3, 0644) = 0 (hier werden die Zugriffsrechte von pkgcache-bin gescheckt)
sie werden nicht gecheckt sondern gesetzt. fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 (Datei ist schreibbar, okay!)stat holt alle relevanten Informationen zu der Datei, mehr nicht. Das
Holen hat geklappt (weil Result == 0).Du kannst auf die Datei ja mal auf einer Konsole stat machen und dashier posten.
Hier die Ergebnisse:
thomas:/var/cache/apt# stat pkgcache.bin
File: ,,pkgcache.bin
Size:
0
Blocks: 0 IO
Block: 4096 reguläre leere Datei
Device: 301h/769d Inode: 16135 Links: 1
Access: (0644/-rw-r--r--) Uid: (
0/ root) Gid: (
0/ root)
Access: 2005-08-12 15:18:59.579415432 +0200
Modify: 2005-08-12 15:18:59.579415432 +0200
Change: 2005-08-12 15:18:59.579415432 +0200
lseek(3, 12582912, SEEK_SET) = 12582912 (liest das CacheLimit in
apt.confaus)das seeked um die angegeben Anzahl Bytes nach vorn (interner Dateizeigerwird nach weiter nach vorn gesetzt) um damit eine leere Datei derentsprechenden Größe zu erzeugen. Da als Ergebnis die Stelle
zurückgegeben wird, klappt das also auch. Es ist allerdings keinProblem den Dateizeiger hinter das EndOfFile (EOF) zu setzen. write(3, \0, 1) = -1 EFBIG (File too large) (will Cache in
/var/cache/apt/pkgcache-bin schreiben, aber zu groß, daher Abbruch)Jetzt will er eine abschliessende Null Terminierung dort reinschreibenum die Datei mit der neuen Größe wirklich zu erzeugen und genau das
funktioniert nicht.Wenn dort also noch genug Platz ist und die Partition auch schreibbar(nicht ro gemountet) ist, dann sollte das auch funktionieren.Andernfalls ist da ein Fehler im Filesystem zu vermuten.
Kannst du denn sonst noch Dateien auf dieser Partition anlegen?z.B. mitdd if=/dev/urandom bs=1024 count=1024 of=filenamelegt eine 1MB Große Datei mit Random Daten an.
thomas:~# dd if=/dev/urandom bs=1024 count=1024 of=/var/cache/apt/testradnomdaten
Funktioniert , stat sagt zur Datei:
File: ,,testradnomdaten
Size: 1048576
Blocks: 2056 IO Block:
4096 reguläre Datei
Device: 301h/769d Inode: 16164 Links: 1
Access: (0644/-rw-r--r--) Uid: (
0/ root) Gid: (
0/ root)
Access: 2005-08-12 15:56:04.622157520 +0200
Modify: 2005-08-12 15:54:37.373421344 +0200
Change: 2005-08-12 15:54:37.373421344 +0200
Also, das sieht erstmal ziemlich normal aus, oder?
Gruß
Thomas
Re: APT, DSELECT, APTITUDE streiken
Hallo Richard,2005/8/12, Richard Mittendorfer [EMAIL PROTECTED]: Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 200515:17:30 +0200): Hallo Richard,hoi! 2005/8/12, Richard Mittendorfer [EMAIL PROTECTED]: Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 2005 14:23:17 +0200): Hallo, erstmal danke für alle bisherigen Vorschläge, auch wenn ich die Sache noch nicht im Griff habe! Als Wolf mich nach der orginal englischen Fehlermeldung gefragt habe, ist mir aufgefallen, dass z.B. apt-cache search als normaler User thomas problemlos funktioniert. Es gibt keine Fehlermeldungen, allerdings funktioniert aus verständlichen Gründen ein apt-get update auch nicht, da das Tool nur unter Root richtig läuft. [...] Am Dateisystem (/var) hast du genug Platz? Ich denke ja, daran liegt es nicht. Eher nicht ;) Ein Versuch war's wert...gate:/var/cache/apt# ls -lhinsgesamt 19Mdrwxr-xr-x3 root root 96 2005-08-12 13:40 archives-rw-r--r--1 root root 5,6M 2005-08-12 13:39 pkgcache.bin -rw-r--r--1 root root 5,4M 2005-08-12 13:37 srcpkgcache.binWobei ich ja noch unter der 6M Grenze bleibe (etch ).Hab mal versuchsweise die pkgcache.bin wegge-mv'd und dann nochmal indselect ein [U]pdate gemacht - Datei wieder da. Die (dpkg)Install- informationen sind selbstvernatuerlich auch noch da. Sollte zwar nichtstoeren, aber tue die pkgcache.bin mal weg, stell einen hoeheren Wert(als das strace bringt) fuer Cache-Limit ein und versuchs nochmal. Ja, die Idee war mir auch schonmal gekommen, etwas anders! ;-) Ich werde es aber nochmal in Deiner Variante versuchen! Aber pkgcache-bin und srcpkgcache-bin werden dann mit den packges.gz der einzelnen Mirrors gefüllt, wenn ich das richtig verstanden habe (okay, wohl eher angehängt). Deshalb war meine alte srcpkgcache-bin wohl auch 5.3 MB groß. Da ich mittlerweile alle meine src- Referenzen aus der sources.list verbannt habe, glaubte ich das Problem vielleicht in den Griff zu bekommen. fs-check ist moeglicherweise (wie Markus schon angedeutet hat) auchkeine schlechte Idee. Aber das file too large weisst eher auf ein apt-internes Resourcenproblemchen hin. Also wird eine Neuinstallationmit ziemlicher Sicherheit nix helfen. Ja, das werd' ich aus Zeitgründen auf morgen verschieben müssen, die Freundin wartet ;-) (steht nicht so auf Computerkrams) Was hast du so alles in deiner sources.list - koenntest ja mal wasauskommentieren um etwas Platz zu sparen. Aslo aktuell sieht meine sources.list so aus: deb http://ftp.de.debian.org/debian/ testing main deb http://security.debian.org/ testing main Ich werde mal die erste Zeile auskommentieren, Sicherheitsupdates scheinen mir wichtiger! Gruß Thomas
Re: APT, DSELECT, APTITUDE streiken
Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 2005 16:38:47 +0200): Hallo Richard, hi. 2005/8/12, Richard Mittendorfer [EMAIL PROTECTED]: Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 2005 15:17:30 +0200): gate:/var/cache/apt# ls -lh insgesamt 19M drwxr-xr-x 3 root root 96 2005-08-12 13:40 archives -rw-r--r-- 1 root root 5,6M 2005-08-12 13:39 pkgcache.bin -rw-r--r-- 1 root root 5,4M 2005-08-12 13:37 srcpkgcache.bin Wobei ich ja noch unter der 6M Grenze bleibe (etch ). Hab mal versuchsweise die pkgcache.bin wegge-mv'd und dann nochmal in dselect ein [U]pdate gemacht - Datei wieder da. Die (dpkg)Install- informationen sind selbstvernatuerlich auch noch da. Sollte zwar nicht stoeren, aber tue die pkgcache.bin mal weg, stell einen hoeheren Wert (als das strace bringt) fuer Cache-Limit ein und versuchs nochmal. Ja, die Idee war mir auch schonmal gekommen, etwas anders! ;-) Ich werde es aber nochmal in Deiner Variante versuchen! Aber pkgcache-bin und srcpkgcache-bin werden dann mit den packges.gz der einzelnen Mirrors gefüllt, wenn ich das richtig verstanden habe (okay, wohl eher angehängt). Seh' ich auch so. Deshalb war meine alte srcpkgcache-bin wohl auch 5.3 MB groß. Da ich Wann war er das? Deine (unten gepostete) sources.list scheint mir leer genug um keine 12M zu beanspruchen. mittlerweile alle meine src- Referenzen aus der sources.list verbannt habe, glaubte ich das Problem vielleicht in den Griff zu bekommen. Mein Gedanke war vielmehr, dass deine Zero-Byte-Datei und die apt-Limitierung(6M) da Probleme macht. Die src-Eintraege aus der sources.list zu loeschen scheint mir wenig sinnvoll, weil da ein eigener srcpkgcache.bin dafuer angelegt wird. fs-check ist moeglicherweise (wie Markus schon angedeutet hat) auch keine schlechte Idee. Aber das file too large weisst eher auf ein apt-internes Resourcenproblemchen hin. Also wird eine Neuinstallation mit ziemlicher Sicherheit nix helfen. Einen FS-Schaden wuerd' ich bei sachlicher Betrachtung ausschliessen. Schaden kann ein check aber nie. Ja, das werd' ich aus Zeitgründen auf morgen verschieben müssen, die Freundin wartet ;-) (steht nicht so auf Computerkrams) Freundin??? Meine Freundinnen haben zwei Ventilatoren, koennen ganz schoen heiss, und damit furchtbar laut werden und _stehen geradezu_ auf dieses Computerzeugs! ;)) Was hast du so alles in deiner sources.list - koenntest ja mal was auskommentieren um etwas Platz zu sparen. Aslo aktuell sieht meine sources.list so aus: deb http://ftp.de.debian.org/debian/ testing main deb http://security.debian.org/ testing main Ich werde mal die erste Zeile auskommentieren, Sicherheitsupdates scheinen mir wichtiger! Das kann ich wieder nicht nachvollziehen. Nachdem testing etch ist und hier etch(+src), volatile und ein paar non-debian-sources die quellen sind: Wie kann dein packet-cache auf stattliche 12M anwachsen, wenn er hier (3 etch boxes gecheckt) 5,5M - 5,7M hat? ..hmmm - dass das irgendwie mit den installierten Packeten zu tun hat, kann ich mir aber echt schwer vorstellen und deine sources.list ist nicht gerade ueberfuellt. Ist dein gzip kaputt? ;) Gruß Thomas good luck, ritch
Re: APT, DSELECT, APTITUDE streiken
Hallo Richard, 2005/8/12, Richard Mittendorfer [EMAIL PROTECTED]: Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 200516:38:47 +0200): Hallo Richard,hi. 2005/8/12, Richard Mittendorfer [EMAIL PROTECTED]: Also sprach Thomas Schönhoff [EMAIL PROTECTED] (Fri, 12 Aug 2005 15:17:30 +0200): gate:/var/cache/apt# ls -lh insgesamt 19M drwxr-xr-x 3 root root 96 2005-08-12 13:40 archives -rw-r--r-- 1 root root 5,6M 2005-08-12 13:39 pkgcache.bin -rw-r--r-- 1 root root 5,4M 2005-08-12 13:37 srcpkgcache.bin Wobei ich ja noch unter der 6M Grenze bleibe (etch ). Hab mal versuchsweise die pkgcache.bin wegge-mv'd und dann nochmal in dselect ein [U]pdate gemacht - Datei wieder da. Die (dpkg)Install- informationen sind selbstvernatuerlich auch noch da. Sollte zwar nicht stoeren, aber tue die pkgcache.bin mal weg, stell einen hoeheren Wert (als das strace bringt) fuer Cache-Limit ein und versuchs nochmal. Ja, die Idee war mir auch schonmal gekommen, etwas anders! ;-) Ich werde esaber nochmal in Deiner Variante versuchen! Aber pkgcache-bin undsrcpkgcache-bin werden dann mit den packges.gz der einzelnen Mirrorsgefüllt, wenn ich das richtig verstanden habe (okay, wohl eher angehängt).Seh' ich auch so. Deshalb war meine alte srcpkgcache-bin wohl auch 5.3 MB groß. Da ich Wann war er das? Deine (unten gepostete) sources.list scheint mir leergenug um keine 12M zu beanspruchen. mittlerweile alle meine src- Referenzen aus der sources.list verbannt habe,glaubte ich das Problem vielleicht in den Griff zu bekommen. Mein Gedanke war vielmehr, dass deine Zero-Byte-Datei und dieapt-Limitierung(6M) da Probleme macht.Die src-Eintraege aus der sources.list zu loeschen scheint mir wenigsinnvoll, weil da ein eigener srcpkgcache.bin dafuer angelegt wird. fs-check ist moeglicherweise (wie Markus schon angedeutet hat) auch keine schlechte Idee. Aber das file too large weisst eher auf ein apt-internes Resourcenproblemchen hin. Also wird eine Neuinstallation mit ziemlicher Sicherheit nix helfen.Einen FS-Schaden wuerd' ich bei sachlicher Betrachtung ausschliessen.Schaden kann ein check aber nie. Ja, das werd' ich aus Zeitgründen auf morgen verschieben müssen, die Freundin wartet ;-) (steht nicht so auf Computerkrams)Freundin??? Meine Freundinnen haben zwei Ventilatoren, koennen ganzschoen heiss, und damit furchtbar laut werden und _stehen geradezu_ aufdieses Computerzeugs! ;)) Was hast du so alles in deiner sources.list - koenntest ja mal was auskommentieren um etwas Platz zu sparen. Aslo aktuell sieht meine sources.list so aus: deb http://ftp.de.debian.org/debian/ testing main deb http://security.debian.org/ testing main Ich werde mal die erste Zeile auskommentieren, Sicherheitsupdates scheinenmir wichtiger!Das kann ich wieder nicht nachvollziehen. Nachdem testing etch ist undhier etch(+src), volatile und ein paar non-debian-sources die quellensind: Wie kann dein packet-cache auf stattliche 12M anwachsen, wenn er hier (3 etch boxes gecheckt) 5,5M - 5,7M hat? ..hmmm - dass dasirgendwie mit den installierten Packeten zu tun hat, kann ich mir aberecht schwer vorstellen und deine sources.list ist nicht geradeueberfuellt. Ist dein gzip kaputt? ;) Also, ich werd' morgen mal die von Dir angesprochenen Dinge eingehend untersuchen, muß los.. Vielen Dank nochmal an alle bisherigen Helfer, werd' Euch über den Stand der Dinge auf dem Laufenden halten! Möglicherweise finde ich gar 'ne Lösungen, dann erfährt es die Liste auf jeden Fall! Danke, schönen Abend! Thomas
Re: APT, DSELECT, APTITUDE streiken
On 12.Aug 2005 - 15:46:22, Thomas Schönhoff wrote: Hallo Andreas, Am 12.08.05 schrieb Andreas Pakulat [EMAIL PROTECTED]: On 12.Aug 2005 - 13:47:13, Thomas Schönhoff wrote: Am 12.08.05 schrieb Thomas Schönhoff [EMAIL PROTECTED]: 2005/8/12, Wolf Wiegand [EMAIL PROTECTED]: Kannst Du mit # LANG=POSIX apt-cache search foo mal die englischsprachige Fehlermeldung herausfinden und hier posten? Würde ich gern tun, allerdings geht es weder von der Befehlszeile noch mit dpkg-reconfigure locales, das System will nur deutsch reden???. Auf was steht denn die Variable LC_ALL? Was sagt locale? Der root-Account sollte keine LANG gesetzt haben, bzw. wenn dann C/POSIX. Deswegen waehle ich bei dpkg-reconfigure locales nichts anderes aus und packe das LANG=XXX in die $HOME/.bash_profile Ah, das klingt logisch! Sag mal kannst du deinen Text in Zukunft bitte unter das letzte Quoting-Zeichen setzen, sonst denkt man das haette der Vorredner gesagt. thomas:~# env [EMAIL PROTECTED] [EMAIL PROTECTED] Kann man dies per Hand problemlos ändern? Das passiert als root? Dann pruefe mal /etc/bash.bashrc und /etc/profile ob da ein export LC_ALL drin steht. Wenn ja: Rausnehmen, ebenso LANGUAGE=.. und LANG=.. Eintraege aus diesen Dateien. Du hattest ja ein Sarge-System, wenn du dich ueber grafischen Login-Manager einloggst sollte dann in /etc/environment [EMAIL PROTECTED] stehen und im Home von root (also /root) in der Datei .bashrc ein Eintrag ala LANG=C oder LANG=POSIX (was da sinnvoller ist, weiss ich so nicht). Andreas -- You get along very well with everyone except animals and people. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
