Debian bringt "no such file" bei Login

[M80331]

Hallo Forum,

ich weiß der Titel klingt blöd, ich versuch es trotzdem so gut wie möglich zu erklären,
es ist eher eine Liste unerklärlicher Phänomene, einiger Lösungen und ein paar unbeantworteter Fragen:

----------------------------

Ich soll einen Debian 4.0 für jemanden administrieren.
Da der bisher immer lief, klang das nicht weiter problematisch.

Dann kam der bisherige Admin daher, wollte sich "nur mal schnell ein Backup ziehen".
Dies lief mit Acronis TI Home 2012, Festplatte klonen, von einer 80GB SATA auf eine andere.

Lief durch, der Admin weg, ich an der Reihe.
Fahr das Ding hoch, es hängt am Grub fest.

Geguckt: BIOS nix verändert, selber SATA Port, muss doch wieder booten.

Im Grub eingegeben:
find /boot/grub/stage1
find /boot/grub/stage2

Findet beides korrekt die hd(0,0).
Hab ich eben dem grub gesagt:

root (hd0,0)
setup (hd0)

Und seitdem läuft der Bootvorgang auch durch, bis zu dem Login...

----------------------------

Da wird's lustig:

Er zeigt sinngemäß:

daemon so und so geladen
dhcp geladen
ntp geladen
zeigt uhrzeit an
systemversion debian 4.0 tty1

und dann:
pc-name login: _
*blinkender cursor*

Ich geb also root ein, und es spricht:

/bin/sh: root: No such file or directory

Dann wieder Debian 4.0 bla bla und wieder
pc-name login: _
*blinkender cursor*

----------------------------

Eins noch vornweg: ich weiß was "Datei oder Ordner nicht gefunden" bedeutet, aber was hat das an der Stelle zu suchen?

Gebe ich z.B. ein:
/etc

Sagt es sogar:
/etc: /etc is a directory

Gebe ich ein:
ls

Sagt es:
/bin/ls: /bin/ls: cannot execute binary file

Gebe ich ein:
/etc/resolv.conf

Sagt es:
/etc/resolv.conf: line 3: nameserver: command not found

----------------------------

Zwischenbericht:

- ich bin noch nicht eingeloggt
- ich bin an der Stelle wo normalerweise nach Benutzername gefragt wird und das auch dasteht, aber scheinbar kommt er nicht weiter, denn:
- egal was ich eingebe, es wird als Parameter für die /bin/sh interpretiert

----------------------------

Jetzt wollte ich es genau wissen, ich hab in einem Live System eine leere Konfig datei angelegt, die /etc/empty.conf

Wieder das System startend, gab ich ihm:
/etc/empty.conf

Er gab mir eine weitere leere Zeile, danach wieder seine Aufforderung wie oben Debian, bla bla, login, ha ha

Tatsächlich, es gab eine Textausgabe "login: " aber ohne eine Abfrage nach Nutzername dahinter. Ich habe keine Ahnung welche Datei, welches Skript er hier normalerweise startet, was dann nach dem eigentlichen Nutzernamen gefragt hätte.

Doch vorerst: jetzt aber, nächster Versuch, jetzt krieg ich ihn, dachte ich:
Ich schrieb per Live System in meine /etc/empty.conf den Befehl: /bin/sh

Wieder normal gestartet, geb ihm in seiner Aufforderung das: /etc/empty.conf

Und tatsächlich, er nimmt das brav als seinen Bash Parameter, führt die Conf Datei aus und diese startet mir ne shell.
Ein simples "whoami" versichert mir dass ich root bin.

----------------------------

P.S.:
meine /etc/empty.conf ist mittlerweile eine Datei namens "admin" (ohne Endung) und in der wurzel. Wenn jetzt der Login kommt, tippe ich ein:
/admin

Und ich hab meine Shell, irgendwie genial dämlich...

So, seit 12 Stunden auf Arbeit, nix geschafft, aber ich hab zumindest auf dieser Baustelle wieder ne root shell.

----------------------------

P.P.S.:

Ich weiß nicht was da wo zerschossen ist, wäre dankbar für Anregungen wie man den Login Vorgang reparieren kann ohne komplette Neuinstallation.

 

[DrWolfsherz]

Die Kiste würde ich neu aufsetzen.

 

[Boeby]

Selbiges Sympton hatte ich auch schonmal bei einem System von unserem Lehrling.
Der kam ebenfalls mit einem System, mit "no such file..".
Mittels LiveSystem und cat in das ursprüngliche /home/user/.bash_history kam ich dann dahinter dass er ein "sudo chmod 777 /" versucht hat. Linux hat danach seine Funktion verweigert.
Und genau selbiges könnte ich mir bei dir ebenfalls vorstellen..
Hat Acronis an den File-Berechtigungen rumgepfuscht ? Schliesslich willst du ja auch z.b. eine /etc/passwd backuped haben..

Meine Lösung möchtest du nicht hören, aber evtl. hilfts dir wenn du dir mal die File-Berechtigungen genauer anschaust.. Ich habe den Thread mal im Beobachter, mal schauen was andere schreiben..

 

[Zedar]

Boebys Ansatz ist schon mal was was ich mir auch gedacht hatte.

Entweder hat Acronis irgendwie Dateien "vergessen" oder es sind Links verlorengegangen oder die Rechte sind zerbeult, was eigentlich am nächsten liegen würde wegen der Ausgabe:

Gebe ich ein:
ls

Sagt es:
/bin/ls: /bin/ls: cannot execute binary file

/etc/ hingegen scheint nicht betroffen zu sein, /etc/resolv.conf könnte auch wieder in einen Bereich linken wo die Rechte zerschossen sind.

Live-System nehmen und nachschauen

Und warum wurde überhaupt Acronis genommen? Ist das schon mal erfolgreich benutzt worden?

 

[M80331]

Meine Lösung möchtest du nicht hören, aber evtl. hilfts dir wenn du dir mal die File-Berechtigungen genauer anschaust.. Ich habe den Thread mal im Beobachter, mal schauen was andere schreiben..

Doch, ich würd auch gern deine Lösung hören. Wenn ich irgendwo was mit chmod oder ls gucken soll, frag mich ruhig. Geht schneller als wenn ich jede Datei mit einem blanken Etch auf einer anderen Maschine vergleiche.

Und warum wurde überhaupt Acronis genommen? Ist das schon mal erfolgreich benutzt worden?

Imho: nein
Acronis wurde wohl nur mal schnell genommen a'la "ist ja nur 1:1 klonen".

Bei Windows kann Acronis die ACL's beibehalten, aber bei Linux im ext2/3 kann es kein ugo rwx beibehalten? Irgendwie schwach.

Aber denke ich mir auch so, dass das so in etwa was zerschossen hat.
Deckt sich mit einigen "kein Zugriff" Meldungen während der init Phase, denke zumindest die kamen früher nicht.

Nochmal wegen ls, etc & Co.: das Linux erwartet ja nicht dass ich eine Datei eingebe, sondern es will den Pfad zu einem Script, warum auch immer.

Gebe ich irgendwas ein, kommt nicht gefunden.
Gebe ich eine BinärDatei an, kann er sie nicht ausführen.
Gebe ich ein Ordner an, meint er "ja, ist ein Ordner".
Gebe ich ein Script an, das geht.

Wird wohl eine Neuinstallation werden, eventuell benötigte Dateien kriegt man ja per Live System raus.

Danke trotzdem Leute.

 

[Boeby]

Meine Lösung wäre eben auch eine Neuinstallation.
Selbst wenn du mittels Skript die Berechtigungen vergleichen würdest, und änderst, bleibt es ein Gebastel.. Gibt ja auch neue Files auf dem System die nicht mehr der Standart-Installation gleichen..

Frage: Sind denn wirklich die Berechtigungen das Problem ? Wäre einfach interessant ob sich meine Theorie bestätigt..

Bezüglich kopieren (bevor da jemand dd empfiehlt), mit Clonezilla welches intern partimage benutzt, habe ich auf Linux-Systemen gute Erfahrungen gemacht. Nicht dass dies jetzt die Lösung sei, aber aufgrund meiner Erfahrung traue ich dem eher als Acronis oder Norton/Symantec Ghost oder ähnlichem. Diese sind vielleicht super easy zu bedienen aber oftmals liegt die Priorität auf den Windows-Systemen der Privatuser.
Clonezilla soll auch mit LVM und mdadm umgehen können.. (Wichtig: Clonezilla kann keine Datenträger schrumpfen und benötigt als Ziel immer mindestens die gleich grosse Disk)
DD ist sicherlich auch nicht schlecht, aber ein too much für eine solche einfache Kopie.


Bezüglich dem "Kein Zugriff" und dem Pfad zu dem Script kann ich dir nicht weiterhelfen. Deinen Gedankengang und wie du auf die Idee mit dem /etc/empty.conf gekommen bist, habe ich bis jetzt nicht geschnallt. Dies halte ich einfach für genial!

 

[M80331]

Ja, dd war auch im Gespräch neulich. Auch wenn eine "solch einfache Kopie" ein bisschen unter dem Niveau eines dd gewesen wäre, es hätte es auch getan, stimmt schon.

Von Clonezilla habe ich Abstand genommen als es mir vor etwa einem Jahr in einer Dual Boot Konfiguration aus WinXP und Linux das letztere leicht beschädigte. Mit meinem heutigen Wissen über Grub wär's damals vielleicht zu beheben gewesen. Jedenfalls bleibt da so ein fader Beigeschack bei Clonezilla, vielleicht geb ich ihm irgendwann in einer Testumgebung noch ne Chance.

Norton Ghost hatte ich auch in der Überlegung ob das künftig was besseres wäre, aber das hatte das letzte mal genutzt als weder NTFS, noch ext3 oder SATA auf'm Markt waren.

Bezüglich dem "Kein Zugriff" und dem Pfad zu dem Script kann ich dir nicht weiterhelfen. Deinen Gedankengang und wie du auf die Idee mit dem /etc/empty.conf gekommen bist, habe ich bis jetzt nicht geschnallt. Dies halte ich einfach für genial!

Hab dir dazu ne PN geschrieben, aber danke für die Blumen.

 

[Zedar]

Schreibs doch mal hier rein, mich würde das auch interessieren und andere denke ich auch.

Ich hab leider nicht alle Rechte-Bits im Kopf. Gibts irgendwas mit dem man die Standard-Rechte wiederherstellen kann? Es kann auch sein das Acronis die Besitzer der Dateien durcheinandergebracht hat. Hast du eigentlich das Orginal oder das Backup?

Ich bin dank meines Berufes ein sehr misstrauischer Mensch. Wie sieht das Image von deinem alten Admin aus? Funktioniert das?

Falls du noch nicht wiederhergestellt hast kannst du bitte mal

ls -la /bin/bash

posten?

 

[M80331]

Schreibs doch mal hier rein, mich würde das auch interessieren und andere denke ich auch.

Ok, hier die Langfassung:

Es war einmal...

als ich alle Benutzer aus einer Standard passwd durchprobieren wollte, also etwa so:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh

bei root kam z.B. no file or directory
und bei bin z.B. kam dann: bin is a directory

Da wurde ich stutzig und hab /bin eingegeben, kam auch "is a directory"
Und dann eben eine Binärdatei wie /bin/sh , kam "cannot execute binary".
Da war es klar, der hat garnicht ein Problem die /bin/sh zu finden, der will was für selbige zum Abarbeiten, muss wohl ein script sein dass er will, welches auch immer.

Da fiel mir keins ein, aber mir fiel spontan die /etc/resolv.conf ein, is ne Textdatei, steht was drin, warum nicht, "test it". Die hat er ja versucht, klar kannte er "namespace ..." nicht, aber er hat was versucht.

Ich dachte also der sagt zwar "login", ist aber intern noch nicht an der Stelle wo er tatsächlich nach dem User fragt, deswegen wollte ich ihm ne leere Datei geben, in der Hoffnung, dass er dann in seiner Logik fortfährt und vlt. den echten Login Prompt bringt.

Als das scheiterte, hab ich in die leere Datei geschrieben "/bin/sh", tatsächlich hat er mir dann ne sh aufgemacht, is ja vor dem Login, da is eh alles root.

Die /etc/empty.conf wurde dann noch nach root verschoben und /admin genannt, einfach just4fun, hat genauso geklappt.

Und wenn ich in dieser shell "exit" eingebe, lande ich wieder im vermeintlichen Login, komm aber mit /admin wieder in eine neue shell.

-----------

Ich hab leider nicht alle Rechte-Bits im Kopf. Gibts irgendwas mit dem man die Standard-Rechte wiederherstellen kann?

Hey, das wäre auch meine Frage. Aber ich kenn da bestenfalls "ein Script schreiben dass die Rechte mit einem blanken System auf einer zweiten Platte vergleicht".

Es kann auch sein das Acronis die Besitzer der Dateien durcheinandergebracht hat. Hast du eigentlich das Orginal oder das Backup?

Ich bin dank meines Berufes ein sehr misstrauischer Mensch. Wie sieht das Image von deinem alten Admin aus? Funktioniert das?

Falls du noch nicht wiederhergestellt hast kannst du bitte mal

ls -la /bin/bash

posten?

Bis gestern hatte ich Original und Backup. Jetzt wird die Kiste neu gemacht, aber am Backup (oder dem Versuch davon) kann ich noch gucken.

Jedoch: beide Platten hatten dieses Problem, dass sie nur bis zum Grub kamen, ohne dass ich eine Bootreihenfolge geändert hatte, nie eine 2. Platte drin wenn die 1. booten sollte, immer den selben(!) SATA Port, nix anders gemacht.

Acronis hat wohl auf der Quellplatte Mist gebaut, aber zumindest den Mist ordentlich geklont.

Wegen ls -la müßte ich gucken, war aber glaube ich - rwx r-x r-x.

Wie boeby mir noch per PN schrieb:

Er scheint ja in deinem Fall irgendwie die grundlegende Runtime um das executable binary ausführen zu können, nicht geladen zu haben. Bzw. nicht laden zu können. Dass du ihn dann doch noch rumgekriegt hast mit der datei mit inhalt /bin/sh ist echt stark..

------

Rein aus Forscherdrang:

Ich weiß immer noch nicht, welche Dateien Linux zum Login lädt, ich kenne die ganzen Init Vorgänge und dass dann irgendwann der Login kommt wo irgendwann u.a. in die passwd und shadow geguckt wird. Aber wie es zu dem Login kommt, was da was macht, das hat mir Onkel Google noch nicht beantworten können.

Weiß das jemand, ich meine ohne das man sich den Quelltext eines Linux Kernel durchlesen muss?