fehler bei apt-get dist-upgrade

[Pischti]

hi,
nach langerer zeit (3 Monate) wollte ich wieder mal meine installation updaten (debian testing)

nach einem apt-get update und apt get dist-upgrade gings um ca 200 packages und er fing
an mit downloaden

bei der installation ist aber jetzt ein fehler aufgetreten

166 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0B/41.3MB of archives. After unpacking 9660kB will be used.
Do you want to continue? [Y/n]
Preconfiguring packages ...
(Reading database ... 27089 files and directories currently installed.)
Preparing to replace coreutils 4.5.2-1 (using .../coreutils_5.0-3_i386.deb) ...
Unpacking replacement coreutils ...
dpkg: error processing /var/cache/apt/archives/coreutils_5.0-3_i386.deb (--unpack):
unable to make backup link of `./bin/ls' before installing new version: Operation not permitted
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/coreutils_5.0-3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

ein apt-get -f install schlägt fehl

was kann ich noch alles machen ?

noch was: ich konnte einige packages mit
apt-get -f install zum update bewegen - in der hoffnung, das irgendwann was installiert wird, was den fehler behebt. nur nach 50 eingaben hatte ich die nase voll

aber: auser coreutils lies sich auch debianutils nicht installieren, weil das wohl von coreutils abhängt ... kann damit jemand was anfangen... ?

[jogix]

Hi,

hm.... zeigt er Dir irgendwelche Abhängigkeitsprobleme an?
In solchen Situationen installiere ich ab und an mal ein einzelnes Paket per dpkg -i <Paketname>.deb
Wenn sie downgeloadet sind, findest Du die Pakete ja alle in /var/cache/apt/archives/
wenn's nu also um Abhängigkeiten von dem ein oder anderen Paket geht, kannst Du versuchen, das per Hand hinzubiegen und dann mit apt-get weitermachen

[Pischti]

das problem hab ich immer noch, hab aber was entdeckt
es soll unter anderem die datei /bin/ls ausgetauscht werden (und noch 2,3 andere) - und da gab's den fehler
seltsamerweise hat diese datei den besitzer 500 und die gruppe 500 (die es gar nicht gibt). wie kann sowas überhaupt passieren ???
jetzt habe ich als root auch kein recht diese datei wieder root zuzuweisen, kein löschen kein umbenennen ...
weiss jemand ne lösung?
(möglichst ohne neubooten mit anderem system oder ähnlichem, der rechner steht tief untem im keller ... -:)

[.zAr]

ich hatte so ein ähnliches problem mit libpam0g.
erst auf testing und dann auf unstable upgraden!!!
Dann gehts.

[Pischti]

was hat denn das mit testing und unstable zu tun?
ausserdem will ich ja bei testing bleiben ...

[startx]

hmmm, schaut doch auch nicht nach einem abhängigkeitsproblem aus.

[quote] unable to make backup link of `./bin/ls' before installing new version: Operation not permitted[/quote]

da liegt doch wohl der hund im pfeffer ;-) , oder?
warum ist das nicht erlaubt /bin/ls zu löschen?

angenommen da wäre ein besonderer schreibschutz drauf, würde das dpkg eigentlich
stören?

startx

[Pischti]

das ist kein besonderer schreibschutz, normalerweise gehört die datei root
aber aus irgendeinem grund gehört sie jetzt 500 (wie auch immer das passiert ist) - jedenfalls will ich sie jetzt wieder in den besitz von root überführen, nur wie macht man das ... ?

[Chimerer]

normalerweise mit chown root.root file

[Pischti]

ja, aber eben das geht nicht ... keine berechtigung ...

[startx]

@pischti

was meinst du mit "gehört 500"?
user "500" oder gruppe "500" oder wie???

was gibt
ls -l /bin/ls
denn aus?

was sagt er den wenn du als root ein
chown root:root /bin/ls

versuchst?

[Pischti]

als root angemeldet :

# ls -l /bin/ls
-rwxr-xr-x 1 500 500 39696 Oct 9 2002 /bin/ls
# chown root:root /bin/ls
chown: changing ownership of `/bin/ls': Operation not permitted

das isses ja gerade. es gibt keinen user und gruppe 500. irgendwie muss es da mal was gegeben haben, das die datei jetzt diese rechte hat.mir ist es jetzt auch egal (naja, eigentlich nicht) , wie es dazu gekommen ist. nur wie behebe ich jetzt das problem ...?

[startx]

also das scheint tatsächlich abgefahren ...
hmm also ich hätt da ne entsprechend abgefahrene idee,
auch auf die gefahr dass mich die älteren debianspezis mit kill -9 killen.

mach doch mal mit
adduser 500
einen user der so heisst, log dich ein und vesuch dann
mit chown die datei root oder so zu schenken. oder zumindest
chmod auszuführen.

( @freaks ... nicht gleich hauen bitte )

startx

[Pischti]

wollte ich auch schon mal machen ... aber es lasst sich keiner mit namen 500 anlegen - da sperrt sich adduser dagegen (macht ja auch sinn)

[MoFunk]

gleich mal vorab, ich kenn mich mit den abhängigkeiten auch nicht so 100% aus....
aber ich bin der meinung, dass man dein problem auch mit
dpkg --force-conflicts -i packetname.deb eventuell lösen könnte

und irgendwo hab ich mal gesehen, dass es auch eine extrem russische methode mittels overwrite gibt, aber da kann man sich anscheinend das ganze system extrem schnell zerschießen

[startx]

@pischti

ja, hast natürlich recht dass das nicht geht.
und nu weiss ich auch nicht weiter, ist /bin/ls eigentlich die einzige
datei mit user 500 ?

welchen user hat eigentlich dass verzeichnis /bin ?
ich google mal noch ein bisschen danach.

startx.

[startx]

hi pischti.

schau mal hier:
http://www.darc.de/referate/ag_www/html/faq.html

Was ist dieses ls im Verzeichnis /bin und warum kann ich es nicht löschen?
Dieses /bin/ls wird für die Ordnungsgemäße funktion des FTP-Servers benötigt. Ohne es sind keine Zugriffe auf das FTP-Verzeichnis mehr möglich. Aus diesem Grund kann es auch nicht gelöscht werden.

vielleicht gibt das einen hinweis.
vielleicht greift der dtp-server grad darauf zu(?)

[pdreker]

Wahrscheinlich hat das Update das base-systen ge-updated, und da hat sich was geändert. Der User heisst übrigens nicht 500 sondern hat die UID 500, und es existiert kein User mit dieser Nummer.

Versuch erstmal die Permissions als root so zu setzen, dass Du schreiben darfst: chmod 777 /bin/ls

Danach *solltest* Du auch den Owner neu setzen können. Falls nicht poste 'mal den Output von "lsattr /bin/ls" vielleicht ist die Datei aus irgendeinem unbekannten Grund immutable.

Patrick

[Pischti]

das verzeichnis gehört natürlich auch root
betroffen sind noch die dateien top, slocate, find, und dir
zumindest sind das die dateien, die ich so auf den ersten blick gesehen habe. welche dateien es betrifft spielt hier wahrscheinlich auch nur eine untergeordnete rolle
auf alle fälle sind die aber dafür ausschlaggebend, das mein apt-get upgrade | dist-upgrade fehl schlägt. mir wäre ja das auch sonst nie aufgefallen ....

@pdreker
ein chown schlägt fehl:
chmod: changing permissions of `ls': Operation not permitted

mit lsattr kommt folgendes:
suS-iadAc-------- /bin/ls

das mit dem user 500 kann ich nicht so genau sagen, auf alle fälle gibts auch keine UID500 - hatts meines wissens auch nie gegeben, zumindest ist in der passwd nicht mal eine UID in der nähe von 500 - wer weiss
jetzt weiss ich nicht genau, wie ich dann die anzeige von ls -l interpretieren soll, wenn statt root dann 500 da steht (wahrscheinlich bei nicht vorhandenem namen wird die UID angezeigt ... oder so ...

[startx]

@pdreker

was bedeutet "eine datei ist immutable"?
ist das irgendwas was im system vorgesehen ist?

(könnte es irgendwas bringen von der norfall-cdrom zu starten, die
festplatte zu mounten und ein chmod/chown zu versuchen? das rate ich jetzt
so ins blaue hinein ...)

[pdreker]

Code: Alles auswählen

dreker@wintermute:dreker$ lsattr /bin/ls
----------------- /bin/ls

So wäre es korrekt....

Hast Du 'mal ein fsck über die Partition laufen lassen? Irgendwie scheint die Struktur da einen Schatten zu haben... Mit chattr kannst Du die ganzen Flags löschen (chattr -suSiadAc /bin/ls)

Immutable bedeutet, dass die Datei absolut nicht verändert werden kann, also auch keine Permissionänderungen und ähnliches. Auch nicht von root, bis root das entsprechende Flag entfernt. Normalerweise sind diese Flags alle *nicht* gesetzt. Evtl. könnte es sich lohnen, chattr einmal rekrusiv durch /bin laufen zu lassen, und dort alle Flags zu löschen (chattr -Rv -AacDdijsSu /bin/*)

Danach kannst Du betroffenen Dateien von Hand auf den korrekten Owner und auf korrekte Permissions setzen...

Patrick

[Pischti]

@pdreker
hat funktioniert, danke ...

[PowerMage]

Hallo! Ich habe heute das gleiche Problem gehabt. Dabei sind mir noch ne ganze Reihe anderer Dateien aufgefallen. Das komische war, das es nur typische Sachen wie top, ps, find, etc waren. Ich vermute mal das es sich vielleicht um ein Rootkit handelt? Vor einiger Zeit hatte ich mal Besuch auf meinem Rechner. Jmd hatte sich über Samba zugang verschafft. Inzwischen ist meine Firewall aber dicht. Vielleicht könnte das von nem Rootkit stammen?

[pdreker]

Google: chkrootkit

Patrick