# [erledigt]alles zerschossen - und nu?

## Christoph Schnauß

hallo,

jetzt habe ich den größtmöglichen Unfall: gar nix geht mehr. Der Anlaß war banal: seit einem halben Jahr örgerte mich eine Fehlermeldung zu Beginn jedes emerge-Aufrufs, es ging um irgendeine .config in einem Subverzeichnis von /sys/lib64/portage...pym. Also irgendwas für Python. Ich dachte heute nachmittag, das müßte sich doch mit einem erneuten emergen von Python lösen lassen, tat es aber nicht, also habe ich diese dämliche .config einfach gelöscht.

Das Ergebnis war kastratophal. Zuerst wollte emerge gar nichtr mehr und beschwerte sich, daß nun genau diese .config fehlt. Der X-Server wollte auch nicht mehr. Und schließlich, als ich kucken wollte, was nach einem reboot passiert, zeigte sich, daß auch grub nicht mehr mitspielt. Damit komme ich weder an das vorhandene Gentoo heran noch an das vorhandene Windows. Vermutlich bleibt mir erstmal gar nichts anderes übrig, als mit einem FIXBOOT bzw. FIXMBR erstmal Windows hochzuholen, um nachzusehen, ob da vielleicht noch mehr zerschossen ist.

Dann werde ich schauen müssen, was sich eventuell über die miniinstall und in einer gechrooten Umgebung machen läßt.

Meine Frage ist: wenn ich mir den portage-tree nochmal neu holen muß, wird dann alles, was da schonmal da war (Distfiles-Archive usw.) überschrieben? Muß ich mich darauf gefaßt machen, daß ich einschließlich Partionierung nochmal absolut von vorn anfangen muß?Last edited by Christoph Schnauß on Wed Sep 05, 2012 7:02 pm; edited 3 times in total

----------

## cryptosteve

Moin,

wenn Du den portage-tree neu holst, passiert nichts weiter. Es wird nichts überschrieben, was nicht ohnehin überschreibenswürdig ist. Die distfiles bleiben erhalten, solange du nicht /usr/portage(/distfiles) löschst.

Ansonsten lässt sich zu Deinem Problem wenig Aussage treffen, weil es meiner Meinung nach an einer definitiven Fehlermeldung fehlt. Was passiert denn, wenn Du den Rechner einschaltest? Falls Dir das Abtippen zu blöde ist, mach ein Foto und hänge es an oder lade es irgendwo anders hoch und poste hier den Link. Man kann Gentoo schon final kaputtfrickeln, aber oftmals sieht es auch schnell wüst aus, lässt sich dann aber doch relativ leicht reparieren. Daher erstmal: entspannt bleiben.  :Smile: 

Viel Erfolg ...

----------

## fndark

Hi,

Außerdem wäre es sinnvoll das System erstmal wieder startfähig zumachen in dem Du mithilfe einer LiveCD und Chroot-Umgebung den "Grub" wieder zurecht bügelst, außerdem hätte das Live-System den Vorteil an die Logfiles zugelangen  :Wink:  da dir selbst ein funktionierentes Windows nich alt zu viel bringen dürfte um Gentoo wieder hin zu bekommen

Ansonsten schließ ich mich meinem vorredner an -> Schau, probiere und vorallem überstürtze nix von wegen "... ich mach die Kiste platt"   :Very Happy: 

Grüße, Sven

----------

## Christoph Schnauß

hi,

nee, gleich gar und ganz plattmachen geht nicht so schnell. Es ist eigentlich alles noch da, und in einer gechrooteten Umgebung sollte sich auch mit den logs was machen lassen. Ich muß das bloß erstmal auf einen Stick rüberziehen und dann den in einen anderen Rechner anstöpseln.

grub reparieren wäre schön, geht aber auch nicht.

Ich hole mir erstmal den portage-tree neu dann müßte emerge ja wieder funktionieren. 

Eigentlich hatte ich mir eine andere Sonntagsbeschäftigung vorgenommen, grmbl. Meine Sorge war halt, daß ich sämtliche Softwarpakete, die eingespielt sind, nochmal neu machen müßte. Was ich an Konfigurationsdateien unter /etc angepaßt habe und meinen Kernel kann ich erstmal auf einen Stick kopieren als backup.

----------

## bell

Ich kann mir nicht vorstellen dass eine Datei aus /usr/lib64/portage/ (/sys/lib/portage gibt es nicht) den Grub und das ganze System beeinflussen kann. Da muss noch was anderes passiert sein. Starte von einer Live-CD und lasse erstmal mit fsck die Dateisysteme checken bevor Du mountest. Anschließend gehst Du per chroot rein wie im Handbuch bei der Installation beschrieben und installierst erneut Grub.

Teste bei der Gelegenheit ob Portage noch funktioniert in dem Du irgend ein unbedeutendes Paket mergest.

Falls Fehler passieren, bitte diese im genauen Wortlaut postest. Am besten nimmst Du eine Live-CD mit einer grafischen Oberfläche und einem Browser. Damit könntest Du direkt aus der Live-Umgebund die Fehlermeldungen per Copy&Paste posten.

PS: nicht verzweifeln, Gentoo lässt sich nahezu immer reparieren, auch wenn Du aktuell den Eindruck hast dass "alles kaputt" ist.

----------

## ChrisJumper

 *Christoph Schnauß wrote:*   

> hallo,
> 
> jetzt habe ich den größtmöglichen Unfall: gar nix geht mehr.

 

Kopf hoch Christoph, wie bell schon schrieb ist gentoo oder Linux an und für sich sehr robust. Wirklich schlimm wäre es nur wenn du den Schlüssel zu eine verschlüsselten Festplatte nicht mehr hast.

Genau vorstellen was da jetzt schief gelaufen ist kann ich auch nicht. Ich würde eher darauf tippen das dein Python ein Problem hat. Wegen Grub. Hast du bevor du neu gestartet hast Updates gemacht? Wann hast du das letzte mal neugestartet?

Ich hatte Probleme weil ich die Boot-Partition bei einem grub update nicht eingebunden hatte. Ein trivialer Fehler meinerseits aus Unachtsamkeit. Wie genau äussert sich denn den Grub das nicht mehr will? Notfalls abfotografieren.

Du könntest vielleicht auch gleich deine Festplatte an dein anderes System hängen und von da aus chrooten, musst dann vermutlich auch 32 und 64 Bit-Systeme beachten. 

Ruhe bewahren, Kaffee trinken. ToDoliste anfertigen mit Fehlermeldungen und möglicher Ursache. Nichts undokumentiert vornehmen und überstürzen.

Dann hast du in einer Stunde dein System bestimmt wieder.

----------

## Christoph Schnauß

 *ChrisJumper wrote:*   

> wie bell schon schrieb ist gentoo oder Linux an und für sich sehr robust. 

 

Ist mir bewußt, nur was das jetzt mal was Neues, und nicht bloß eine kernel_panic

 *ChrisJumper wrote:*   

> Genau vorstellen was da jetzt schief gelaufen ist kann ich auch nicht. Ich würde eher darauf tippen das dein Python ein Problem hat. Wegen Grub.

 

Nicht nur deshalb. Ich habe ja angegeben, daß die gelöschte .config in irgendeinem Python-Verzeichnis lag. Python hat also mit Sicherheit ein Problem. Ich hab mich bloß nie darum gekümmert, wer alles auf Python angewiesen ist.

 *ChrisJumper wrote:*   

> Hast du bevor du neu gestartet hast Updates gemacht?

 

Ja. Überlicherweise lief einmal emerge --sync durch, dann wollte ich mich um die nvidia-drivers kümmern, weil der XServer nach dem letzten Kernel-Neubau wie üblich gemeckert hat. Und da beschwerte sich emerge das erstemal, mit einem Hinweis auf die jetzt fehlende .config für Python. Ich habe versucht, nun ganz schnell Python zu emergen, aber das war bereits zu spät.

 *ChrisJumper wrote:*   

> Wann hast du das letzte mal neugestartet?

 

Das ist inzwischen irrelevant, weil ich jetzt den MBR für Windows freigeräumt habe. Da ist alles unverändert, aber Grub ist nun erstmal fort und muß auf jeden Fall wieder her.

 *ChrisJumper wrote:*   

> Du könntest vielleicht auch gleich deine Festplatte an dein anderes System hängen und von da aus chrooten, musst dann vermutlich auch 32 und 64 Bit-Systeme beachten. 

 

Das ist leider nicht machbar, im wesentlichen deshalb, weil ich mit einer Hand den Rechner vielleicht noch aufmachen kann, aber die Platte nur unter größter Mühe rausziehen und eventuell an den anderen Rechner anstöpseln kann. Da stoße ich einfach an physische Grenzen. Tatsächlich wäre auch noch zu beachten, daß es dann eine andere Archtektur wäre. Ich weiß nicht, ob ein für einen Pentium4-Prozessor gedachter Kernel problemlos mit einem Core2-Prozessor lauffähig wäre.

 *ChrisJumper wrote:*   

> Ruhe bewahren, Kaffee trinken. ToDoliste anfertigen mit Fehlermeldungen und möglicher Ursache. Nichts undokumentiert vornehmen und überstürzen.

 

Ich neige nicht zu Panikattacken. Fehlermeldungen bzw. die letzten logs (dmesg, /var/log/messages u.a) wären zwar verfügbar, nutzen aber nichts. Es hört da auf, wo es Beschwerden wegen mangelhafter Einbindung der nvidia-drivers gibt. Das war mir bereits bekannt. Und nachdem Grub nicht mehr wollte, war kein Neustart mehr möglich, der neue Bootmeldungen erzeugt hätte. Aber nur die wären jetzt interessant.

Der Hinweis, daß ein kompletter Neubau von portage nichts überschreiben würde, war mir wichtig. Ich hoffe, daß das auch für einen stage-tarball gilt, den ich mir wohl auch nochmal neu drüberstülpen muß.

----------

## root_tux_linux

1) Wie wärs mit  der Grub-Shell und den Eintrag von Hand erstellen?

2) Wie wärs mit von Live-CD booten?

3) Wie wärs mit Live-CD booten und dann chrooten?

----------

## cryptosteve

Ich habe jetzt auch noch nicht ganz verstanden, was es bringen soll, den portagetree erneut ins System zu kippen. Was soll dadurch besser werden und wenn etwas dadurch besser wird, wie konnte es zuvor durch Löschen einer .config schlechter werden?

Und ein neues stage-Archiv? Da stellt sich fast die gleiche Frage. Ich sehe noch immer keine vernünftige Fehlermeldung aus einem chroot heraus.

----------

## Christoph Schnauß

 *cryptosteve wrote:*   

> Und ein neues stage-Archiv? Da stellt sich fast die gleiche Frage. Ich sehe noch immer keine vernünftige Fehlermeldung aus einem chroot heraus.

 

Weil es keine Fehlermeldung gibt. Die gechroote Umgebung ist insofern fehlerfrei, als es keine Fehler beim Booten von der miniinstall gibt.

Aber das Problem scheint sich erledigt zu haben, nachdem ich nochmal ein stage-Archiv gezogen habe. Danach ist emerge wieder vorhanden, allerdings auch die Fehlermeldung, die mich irritiert hatte. Sie kommt beim Aufruf von emerge gleich als allererstes:

```
/usr/lib64/portage/pym/portage/package/ebuild/.config.py:353 : UserWarning : 'cache.metadata_overlay.database' is deprecated: /etc/portage/modules
```

Mein Fehler war, daß ich annahm, wenn etwas 'deprecated' ist, sollte ich es doch löschen dürfen. Nunja, darf ich in diesem Fall nicht. portage habe ich gelassen, wie es war, da emerge jetzt wieder mitspielt, es sollte ja genügen, wenn

```
emerge --sync
```

wieder möglich ist.

----------

## cryptosteve

http://www.gentooforum.de/artikel/20308/emerge-wirft-eine-meldung-aus-was-bedeutet-das.html

----------

## Christoph Schnauß

 *cryptosteve wrote:*   

> http://www.gentooforum.de/artikel/20308/emerge-wirft-eine-meldung-aus-was-bedeutet-das.html

 

Da ist jemand auf dieselbe Idee gekommen wie ich, allerdings hat er was andres gelöscht. Ich finde in /etc/portage eine kleine Datei namens "modules", die nur eine einzige Textzeile enthält:

```
portdbapi.auxdbmodule = cache.metadata_overlay.database
```

Und ich werde mich hüten, das Ding wegzuwerfen, auch wenn es diese dumme Meldung erzeugen sollte.

----------

## cryptosteve

Wenn man sich nicht sicher ist, sollte man ohnehin besser erstmal umbenennen, anstatt gleich unwiederbringlich zu löschen.  :Smile: 

----------

## firefly

Die datei kannst du löschen oder die zeile darin abändern/entfernen. siehe auch https://forums.gentoo.org/viewtopic-t-903494.html

ursprünglich kenn ich persönlich diese zeile auch nur in zusammenhang, wenn man als metadata backend sqlite statt die datei bassierte fassung verwenden möchte.

----------

## Josef.95

Auch ein versehentlich beschädigtes portage lässt sich relativ einfach wieder reparieren, siehe

Manually fixing broken portage installations

----------

## Christoph Schnauß

danke für die Tips, aber inzwischen habe ich ein neues Problem. Ich habe gestern ein stage-Archiv neu geholt und einfach drübergestülpt, und weil emerge erstmal mit

```
emerge --sync
```

dadurch wieder mitzspielen schien, habe ich den portage-Tree dann gar nicht erst angefaßt. Ich wollte nur rasch Grub wieder einspielen, aber dabei verweigerte sich emerge erneut, diesmal mit 

```
command not found
```

. Ich dachte, es hilft vielleicht ein reboot. Also nochmal die Tippeltappeltour mit Netzverbindung aufbauen, dann mounten wie im Handbuch beschrieben - also

```
mount /dev/sdb3 /mnt/gentoo

mount -t proc none /mnt/gentoo/proc

mount --rbind /sys /mnt/gentoo/sys

mount --rbind /dev /mnt/gentoo/dev
```

Und danach kommt

```
cd /mnt/gentoo

chroot /mnt/gentoo /bin/bash
```

Frustrierenderweise wollte das aber nicht mehr.

```
command not found - /bin/bash
```

Also kein komplettes chroot möglich, und damit auch kein Zugriff auf das gemountete System. Das wiederholte sich mehrfach, und dann hatte ich erstmal keine Lust mehr.

Heute wollte ich es wieder probieren - dassselbe Ergebnis. Kein chroot möglich, weil /bin/bash nicht gefunden wird. Ich dachte, es könnte an der CD liegen, vielleicht ein Kratzer drauf oder so. Also habe ich eine neue miniinstall gebrannt, meine Partition (/dev/sdb3 ist korrekt) sowie die Dateisysteme gemountet - aber wieder nix Befehl /bin/bash nicht ausführbar. Und damit keine gechrootete Umgebung herstellbar und kein Aufruf von emerge oder irgendwelchen Systemprogrammen. Übrigens auch keinerlei Fehlermeldung bis auf dieses 

```
command not found - /bin/bash
```

Hm. 

*kopfkratz*

----------

## Schorchgrinder

 *Christoph Schnauß wrote:*   

> 
> 
> ```
> command not found - /bin/bash
> ```
> ...

 

schau doch einfach mal nach, normal sollte ja das /bin/bash auf der LiveCD sein.

ls -lA /bin/bash außerhalb von Chroot

----------

## Christoph Schnauß

 *Schorchgrinder wrote:*   

> schau doch einfach mal nach, normal sollte ja das /bin/bash auf der LiveCD sein.

 

Ist es auch. /bin ist auf der CD ein Link zu /mnt/livecd/bin. Und da ist die bash durchaus vorhanden. Das bereitet mir geringfügige Kopfschmerzen. Zumal das ja bisher immer völlig problemlos ging.

----------

## platinumviper

chroot wechselt zuerst das root-Verzeichnis und führt dann /bin/bash von dort aus, es wird also /mnt/gentoo/bin/bash nicht gefunden. Hat das mounten ohne Fehler geklappt?

----------

## Schorchgrinder

schau doch mal nach was eine LiveCD von einer anderen Distri sagt. Schon komisch das ganze, wirklich mal schauen was beim mount als meldung mitkommt.

----------

## bell

 *Christoph Schnauß wrote:*   

> Ich habe gestern ein stage-Archiv neu geholt und einfach drübergestülpt,

 Das war keine gute Idee. Bitte NIE Dateien am Portage vorbei in das System schmeißen. Damit schaffst Du Dir Leichen im System die weitere Probleme verursachen können.

Aber lösen wir erstmal das "command not found" Problem. Anschließend schauen wir wie wird das System wieder bereinigt kriegen.

Hast Du vorab ein Dateisystem-Check druchgeführt?

Sind die Dateien noch da die bemeckert werden? Und welche Rechte haben die?

Also nach dem mounten von der Live-CD und vor dem chroot, poste mal:

```
ls -l /mnt/gentoo

ls -l /mnt/gentoo/bin/bash

ls -l /mnt/gentoo/usr/bin/emerge
```

----------

## Christoph Schnauß

 *bell wrote:*   

> Hast Du vorab ein Dateisystem-Check druchgeführt?

 

Wenn du damit e2fsck meinst, ja. Das hat nichts zu meckern gefunden

 *bell wrote:*   

> Sind die Dateien noch da die bemeckert werden?

 

Natürlich. Es handelt sich ja um das, was auf der CD "fest" vorhanden ist und eh nicht verändert werden kann, es sei denn, die CD hat einen mechanischen Fehler

 *bell wrote:*   

> Und welche Rechte haben die?

 Das ist irrelevant, man wird ja grundsätzlich erstmal automatisch als root eingeloggt.

 *bell wrote:*   

> Also nach dem mounten von der Live-CD und vor dem chroot, poste mal:
> 
> ```
> ls -l /mnt/gentoo
> ```
> ...

 

Das zeigt die Dateistruktur meines gemounteten Systems, die Standardverzeichnisse, da es noch keine eigenen Verzeichnisse oder mount-Points gibt. Bringt eigentlich nichts, kannst du aber gern haben:

```
drwxr-xr-x  2 root root  4096 Sep  2 22:06 bin

drwxr-xr-x  3 root root  4096 Jun 21 02:45 boot

drwxr-xr-x 16 root root  5040 Sep  4 09:53 dev

drwxr-xr-x 61 root root  4096 Sep  2 22:08 etc

drwxr-xr-x  2 root root  4096 Jun 21 02:45 home

lrwxrwxrwx  1 root root     5 Sep  2 21:32 lib -> lib64

drwxr-xr-x  4 root root  4096 Sep  2 22:08 lib32

drwxr-xr-x 12 root root  4096 Sep  2 22:08 lib64

drwx------  2 root root 16384 Dec 29  2011 lost+found

drwxr-xr-x  2 root root  4096 Jun 21 02:45 media

drwxr-xr-x  2 root root  4096 Jun 21 02:45 mnt

drwxr-xr-x  3 root root  4096 Jun 21 02:45 opt

dr-xr-xr-x 87 root root     0 Sep  4 09:52 proc

drwx------ 15 root root  4096 Jun 21 12:09 root

drwxr-xr-x  3 root root  4096 Jun 21 12:00 run

drwxr-xr-x  2 root root  4096 Sep  2 22:08 sbin

drwxr-xr-x 13 root root     0 Sep  4 09:52 sys

drwxrwxrwt  4 root root  4096 Sep  2 22:06 tmp

drwxr-xr-x 13 root root  4096 Jun 21 12:10 usr

drwxr-xr-x 12 root root  4096 Jun 21 02:45 var
```

 *bell wrote:*   

> 
> 
> ```
> ls -l /mnt/gentoo/bin/bash
> ```
> ...

 

das ist _ohne_ chroot unwichtig, da das das /bin-Verzeichnis meiner gemounteten Partition betrifft, und da der gewünschte Aufruf einem binary, also einer einzelnen ausführbaren Datei gilt, ist hier kein listing möglich. 

 *bell wrote:*   

> 
> 
> ```
> ls -l /mnt/gentoo/usr/bin/emerge
> ```
> ...

 

Dasselbe. emerge ist eine binäre Datei, als einzelne Datei erzeugt sie kein listing, sofern sie vorhanden ist. Ist sie erstaunlicherweise nicht, aber das wäre ohnehin erst _nach_ einem chroot von Bedeutung. Wenn du dir das /bin-Verzeichnis der CD anschauen willst, so liegt es unter /mnt/livecd/bin, chroot ist da selbstverständlich vorhanden, genauso wie bash, und selbstverständlich _nicht_ emerge, da das kein Bestandteil der CD ist.

Wahrscheinlich ist es jetzt doch sinnvoll, die ganze Partition nochmal zu formatieren und ganz von vorn anzufangen, das geht inzwischen vermutlich sogar schneller, und die wichtigen eigenen Konfigurationsdateien (einschließlich Kernel) kann ich ja problemlos noch extern sichern.

----------

## py-ro

Öhm ls erzeugt auch ein Listing bei einzelnen Dateien...

----------

## Christoph Schnauß

 *py-ro wrote:*   

> Öhm ls erzeugt auch ein Listing bei einzelnen Dateien...

 

Ja, aber außer dem Dateinamen nichts, was man nicht schon wüßte ;-)

----------

## firefly

Könntest du es trotzdem posten, denn nur weil du meinst die Ausgabe würde nichts wichtiges enthalten muss dass nicht stimmen  :Wink: 

----------

## bell

Denke beim "ls" an den Parameter "-l" (kleines L). Damit werden ja Zusatzinformationen angezeigt wie zB. die Berechtigungen, die mich/uns interessieren.

Mit "sind die Dateien noch vorhanden" meinte ich nicht die Live-CD Dateien sondern die Dateien auf Deiner Partition, auf die das "chroot" zugreifen würde. Die 3 "ls -l" Anfragen würden diese Info liefern.

----------

## Christoph Schnauß

 *firefly wrote:*   

> Könntest du es trotzdem posten, denn nur weil du meinst die Ausgabe würde nichts wichtiges enthalten muss dass nicht stimmen ;)

 

Bittesehr:

 *bell wrote:*   

> 
> 
> ```
> ls -l /mnt/gentoo/bin/bash
> ```
> ...

 

```
-rwxr-xr-x  1 root root  745 912 Jun 21 09:06 /mnt/gentoo/bin/bash
```

 *bell wrote:*   

> 
> 
> ```
> ls -l /mnt/gentoo/usr/bin/emerge
> ```
> ...

 

```
lrwxrwxrwx  1 root root  27 Sep 2 21:34  /mnt/gentoo/usr/bin/emerge --> ../lib64/portage/bin/emerge
```

Ich kann daran keinen Fehler entdecken.

 *bell wrote:*   

> Denke beim "ls" an den Parameter "-l" (kleines L). Damit werden ja Zusatzinformationen angezeigt wie zB. die Berechtigungen, die mich/uns interessieren.
> 
> Mit "sind die Dateien noch vorhanden" meinte ich nicht die Live-CD Dateien sondern die Dateien auf Deiner Partition, auf die das "chroot" zugreifen würde. Die 3 "ls -l" Anfragen würden diese Info liefern.

 

Sie gehören root. Ich hätte nicht gewußt, warum ich sie einem Benutzer (mir) übergeben sollte. Außerdem halte ich die Frage nach den Rechten für weniger wichtig, da ich ja vor chroot auf jeden Fall als root angemeldet bin, es ist gar nichts andres möglich

----------

## firefly

was ist aber mit dem Flag eine Datei auszuführen, wenn das fehlt, dann kann selbst root eine datei nicht ausführen ohne vorher das flag zu setzen.

----------

## bell

Ja, mir ging es um das "x" bei den Rechten. Sieht soweit gut aus. Das chroot müsste also klappen. Drei Sachen fallen mir noch ein:

- Die Partitionen waren nicht gemounted als Du getestet hast

- Die Live-CD ist 32-bit und Dein System 64-bit

- Auf der Live-CD fehlt das chroot. Das kannst Du mit "which chroot" prüfen.

Teste auf jeden Fall mal auch mit einer anderen Live-CD ob es damit klappt.

Wenn das chroot geklappt hat, bitte das 

```
env-update

source /etc/profile
```

ausführst bevor Du versuchst was zu mergen.

----------

## Christoph Schnauß

 *firefly wrote:*   

> was ist aber mit dem Flag eine Datei auszuführen, wenn das fehlt, dann kann selbst root eine datei nicht ausführen ohne vorher das flag zu setzen.

 

Ich weiß nicht, wieso da etwas geändert werden könnte. Auch als root kann ich Dateien der CD weder verändern noch gar löschen. Das kann ich nur auf meiner eigenen Partition auf der Platte.

Aber so weit komme ich ohne chroot gar nicht.

Ich habe inzwischen zum drittenmal eine neue miniinstall-CD gezogen, und es ist jedesmal dasselbe. Es ist höchst unwahrscheinlich, daß mit den aus den ISO-Files gebrannten CDs dreimal irgendwas ausgerechnet bei /bin/bash nicht korrekt ist.

Ohne den vorangestellten chroot-Befehl läßt sich /bin/bash problemlos aufrufen. Das läßt sich aber nur daran erkennen, daß dann die history fort ist, also vorangegangene Shell-Befehle nicht über die Taste "nach oben" erneut aufgerufen werden können.

Eine andere Shell als bash steht mir auf der CD, also in /bin bzw. /mnt/livecd/bin, nicht zur Verfügung.

Ich habe natürlich auch versucht, mal die bash aus meiner gemounteten Partition, also mit /mnt/gentoo/bin/bash, aufzurufen. Da wird dann die fehlende GLIBC angemeckert, was sich _nach_ chroot erledigen müßte. Aber so weit kommt es eben leider nicht.

logs gibt es leider keine. /var/log/messages existiert, enthält aber lediglich die Bootmeldungen vom CD-Start. Auch dmesg liefert nur die Bootmeldungen, sonst nichts. Ohne chroot wird in /mnt/gentoo/var/log - also in meiner genmounteten Partition - auch nichts eingetragen.

 *bell wrote:*   

> Ja, mir ging es um das "x" bei den Rechten. Sieht soweit gut aus. Das chroot müsste also klappen. Drei Sachen fallen mir noch ein:
> 
> - Die Partitionen waren nicht gemounted als Du getestet hast
> 
> - Die Live-CD ist 32-bit und Dein System 64-bit
> ...

 

Die Partition war gemountet, ein listing von ls -l /mnt/gentoo wäre sonst leer gewesen.

Sowohl die CD wie auch mein Rechner haben eine 64-bit-Struktur (amd64)

chroot ist auif der CD vorhanden. which chroot erzeugt 

```
/usr/bin/chroot
```

 *bell wrote:*   

> Teste auf jeden Fall mal auch mit einer anderen Live-CD ob es damit klappt.

 

Wie angegeben ist das inzwischen die dritte neu gebrannte CD.

 *bell wrote:*   

> Wenn das chroot geklappt hat, bitte das 
> 
> ```
> env-update
> 
> ...

 

das steht so im Handbuch und wird selbstverständlich peinlich genau befolgt. Nur die Voraussetzung, daß eben chroot funktioniert, ist nicht einlösbar.

----------

## Christoph Schnauß

hallo,

offenbar verhindert irgendetwas, was durch das "Drüberstülpen" eines stage-Archivs auf meiner Partition entstanden ist, die Ausführung des chroot-Befehls bzw. von /bin/bash.

Ich habe auf meiner Platte keinen Platz mehr, um noch eine neue Partition anzulegen, ohne die bisherige Partition neu zu formatieren. Also habe ich es jetzt mal mit einem USB-Stick getestet. Ich habe einen großen Stick mit 64 GB, dem ich jetzt testweise eine 30 GB große Partition freigeräumt und formatiert habe. Nach dem Auspacken des stage-Archivs und des portage-Trees hat dann chroot von derselben CD aus problemlos funktioniert, von der es mit meiner Platten-Partition nicht möglich war. Ich ziehe daraus folgende Schlüsse:

1. ist die CD in Ordnung und "kann" chroot aufrufen

2. habe ich mir meine Festplattenpartition durch das Darüberkopieren eines neuen stage-Archivs offenbar doch zerschossen

3. muß ich nun wohl oder übel doch das gesamte ehemals vorhandene System plattmachen und neu aufbauen 

Ich wollte sowieso immer mal ausprobieren, ob ich ein komplettes Gentoo auf einen bootfähigen Stick installieren kann. Da mein Stick groß genug ist, probiere ich das nun bei dieser Gelegenheit. Die alte Installation kann ich immer noch löschen, und da ich Kernel und Kernelkonfiguration (/usr/src/linux/.config) sowie die personalisierten Konfigurationsdateien aus /etc gesichert habe, wird der Neubau des Systems nicht mehr ganz so viel Zeit brauchen..

Ich bedanke mich für alle Denkanstöße.

Was eventuelle Fragen zu einem kompletten Gentoo auf einem bootfähigen USB-Stick betrifft, so wäre das wohl Thema für einen neuen Thread.

----------

## Schorchgrinder

auch mal mit einer LiveCD von Archlinux oder so probiert? chroot sollte da ja auch gehen

----------

## firefly

 *Christoph Schnauß wrote:*   

>  *firefly wrote:*   was ist aber mit dem Flag eine Datei auszuführen, wenn das fehlt, dann kann selbst root eine datei nicht ausführen ohne vorher das flag zu setzen. 
> 
> Ich weiß nicht, wieso da etwas geändert werden könnte. Auch als root kann ich Dateien der CD weder verändern noch gar löschen. Das kann ich nur auf meiner eigenen Partition auf der Platte.
> 
> Aber so weit komme ich ohne chroot gar nicht.

 

Es geht auch gar nicht um die dateien auf der livecd sondern die auf der platte...

----------

## bell

Huh.. Ich sehe das Thema ist [erledigt]. Was war denn die Lösung?

Mir ist noch was eingefallen: Das Auspacken eines Stages war wirklich eine schlechtere Idee als ich zuerst angenommen hatte. Denn damit hast Du nicht nur viele Binaries und Libs überschrieben, sondern auch /etc Konfigurationen und das schlimmste: auch die Portage Datenbank /var/db/pkg/. Damit hast Du Dein Gentoo getötet. Die einfachste Lösung ist also eine Neu-Installation. Sicherlich kannst Du eine Sicherung ziehen, damit Du bei Bedarf in die nicht überschriebenen Konfigurationen reinschauen kannst, aber es wäre das beste bei einer frisch formattierten Partition wieder anzusetzen.

PS: Falls Du jetzt sagst "Ihr habt aber gesagt..": Da ging es um Portage-Snapshot. Dieses auszupacken wäre unproblematisch. Du hast jedoch ein Stage in das System ausgepackt. Das ist so als ob man ein Win7-C:\WINDOWS in das Win8-C:\WINDOWS  rein kopiert. Das kann nicht gut gehen.

----------

