[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg: Fehler beim Bearbeiten (libc6_2.3.5-8_i386.deb) [solved]



On 07.01.06 14:07:14, Peter Staudt-Fischbach wrote:
> Andreas Pakulat wrote:
> >On 07.01.06 02:19:53, Sven Hartge wrote:
> >>Michael Bienia <michael@vorlon.ping.de> wrote:
> >>>On 2006-01-06 23:51:15 +0100, Peter Staudt-Fischbach wrote:
> >>>>Die angemeckerte Datei sieht so aus:
> >>>>?rwsrwSr-t  1 daemon 16379 33619980 1971-01-25 22:05 TCVN5712-1.so
> >>>>
> >>>>Gurgeln hat mich nicht weiser gemacht, ich bin mit meinem Latein am Ende. 
> >>>>Weiß jemand Rat?
> Genau das war's. Vielen Dank an alle für die Tipps. Ein einfaches "e2fsck -f 
> /dev/hda1" hat das Problem gelöst.

Du solltest trotzdem bzw. gerade deswegen Festplatte und RAM pruefen,
von alleine treten solche merkwuerdigen Veraenderungen naemlich nicht
auf. Plattenpruefung geht mit smartctl falls die Platte SMART
unterstuetzt oder mit badblocks. Rampruefung macht man ueblicherweise
mit nem 24h Lauf von memtest.

> Jetzt stellt sich mir die Frage: "Hätte ich da alleine draufkommen müssen?" 
> Hmmm, eigentlich ja (Asche auf mein Haupt).

Ja, anhand der Ausgabe von ls haette man da alleine drauf kommen
sollen/muessen. Insbesondere das "?" beim Dateityp und die vollkommen
falschen uid+gid (in /usr/lib gehoert das meiste root.root)

> Für einen Linux-Newbie oder Windoof-Konvertiten ist so eine Fehlermeldung  
> aber meistens erst mal erschreckend.

Ja aber die ls-Ausgabe ist eindeutig.

> Gibt es also irgendwo ein Werkzeug das einem bei der Fehlersuche strukturiert 
> hilft?

Ganz einfach: Wenn dpkg meint es kann eine Datei nicht lesen, mit ls
pruefen ob die Datei existiert und evtl. mit cat ob sie lesbar ist. ls
haette bei dir schon gereicht.

> Interaktiver Fehlersuchbaum wäre ein passendes Stichwort dafür 
> (vielleicht bei Debian-QA ansiedeln?)

Aehm, das ist reichlich aufwendig, insbesondere wenn man sich ueberlegt
wieviele Fehlermeldungen dpkg auswerfen koennte, woher die kommen
koennen und welche Probleme als Verursacher in Frage kommen. Nee da sind
Erfahrungswerte, Google, eine ML wie diese und ein bisschen guter
Menschenverstand (nicht notwendigerweise in dieser Reihenfolge)
einfacher zu nutzen.

> Folgender Link zeigt ungefähr in die Richtung die mir vorschwebt.
> 
> http://arktur.schul-netz.de/wiki/index.php/Administratorhandbuch:Fehlersuche
> 
> Ich vermute mal, dass man mit so einem Werkzeug den RTFM-Anteil in diversen 
> Foren merklich reduzieren könnte (einschl. meines ursprünglichen postings).

Aehm der Aufwand dafuer waere unglaublich gross, insbesondere wenn du
alle von dpkg moeglicherweise durchgereichten Fehlermeldungen abdecken
willst. 

Andreas

-- 
You will meet an important person who will help you advance professionally.



Reply to: