# Gentoo über Nacht zerschossen

## Vortex375

Tag zusammen.

Habe gestern Abend ein emerge -uDN world gestartet. Wie ich heute morgen wiederkomme, steht auf dem Bildschirm als letzte Meldung ">>> sys-libs/glibc-2.5 merged" und der PC reagierte nicht mehr. Ich sah mich gezwungen den Reset-Knopf zu drücken.

Nach dem Neustart funktioniert nun gar nichts mehr. Die Meldungen beim Bootvorgang werden zugespammt von Fehlermeldungen von udev, der irgendwelche benötigten Anwendungen nicht starten kann (á la "Cannot execute: "/sbin/udev-*"). 

Beim login dann kommt Mehrmals die Fehlermeldung "setenv: command not found". Portage funktioniert nicht und spuckt mir, egal was ich eingebe, nur einen python-Traceback aus (den genauen Traceback hab ich grad leider nicht parat).

Weiß einer auf die schnelle, was da schief gegangen sein kann und wo ich jetzt am besten mit der Reparatur anfange?

----------

## Treborius

um ne rescue-cd kommst du wohl nicht rum, das mit udev hatte ich auch

lösung : udev unmergen (am besten auch hotplug und coldplug)

alle configs von udev löschen (/etc/udev)

und udev neu mergen

(eine schönere lösung kenn ich nicht)[/code]

das mit glibc könnte kompliziert werden ...

----------

## XMath

Mahlzeit,

vielleicht reicht auch ein "etc-update", um udev zu beruhigen.

----------

## Vortex375

 *Quote:*   

> das mit glibc könnte kompliziert werden ...

 

Wie meinst du das? Das mergen von glibc war ja eigentlich schon fertig und wenn die glibc beschädigt wäre, dann könnte ich den PC höchstwahrscheinlich nicht mehr hochfahren.

Das Hauptproblem ist glaube ich, dass er setenv nicht finden kann, weswegen wohl auch portage nicht läuft. In welchem Paket ist setenv enthalten?

Und wie repariere ich mein System per rescue-cd wenn mein portage streikt?

----------

## Vortex375

So, ich hab jetzt nochmal das defekte System hochgefahren und mit gpm die Fehlermeldungen rauskopiert.

portage:

```

Traceback (most recent call last):

  File /usr/bin/emerge, line 5299, in ?

    retval = emerge_main()

  File /usr/bin/emerge, line 5001, in emerge_main

    settings, trees, mtimedb = load_emerge_config()

  File /usr/bin/emerge, line 4886, in load_emerge_config

    trees = portage.create_trees(trees=trees, **kwargs)

  File /usr/lib/portage/pym/portage.py, line 8167, in create_trees

    config_incrementals=portage_const.INCREMENTALS)

  File /usr/lib/portage/pym/portage.py, line 1245, in __init__

    env_d = getconfig(

  File /usr/lib/portage/pym/portage_util.py, line 349, in getconfig

    raise portage_exception.ParseError(str(e)+ in +mycfg)

portage_exception.ParseError: ParseError: Invalid token (not '='): /etc/profile.env: line 5 in /etc/profile.env
```

Beim Bootvorgang und beim login mehrmals:

```
-bash: setenv: command not found
```

Beim Bootvorgang verdammt oft:

```

udevd-event[3823]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3824]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd-event[3827]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3828]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd-event[3831]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3832]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd-event[3835]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3836]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd-event[3802]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3839]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd-event[3842]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3843]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd-event[3846]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3847]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd-event[3850]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

udevd-event[3851]: run_program: exec of program '/sbin/udev_run_devd' failed
```

Auch andere Dienste können Dateien nicht finden:

```
/sbin/start-stop-daemon: stat /usr/bin/xdm: No such file or directory (No such file or directory)

 * ERROR: could not start the Display Manager...

xdm: no process killed
```

Ist das Dateisystem beschädigt worden? Ich verwende jfs. Der fsck beim Hochfahren behauptet, "Filesystem is clean.".

----------

## Vortex375

Soo also neue Erkenntnisse:

"setenv" ist kein Programm, sondern irgend ein API-Aufruf. Die glibc ist also definitiv im A****. 

Ich habe mit einem "rm /etc/profile.env" und anschließendem "env-update" mein portage nun wieder zum Leben erweckt. Aber ich kann glibc trotzdem nicht neu draufmachen, weil rm nicht funktioniert und portage dies wohl zum arbeiten braucht.

Es kommt immer so ein Fehler wie:

```
rm: cannot remove '...': Function not implemented
```

Ich muss mir wohl von irgendwoher ne vorkompilierte glibc ziehen. Wo finde ich so etwas?

----------

## benjamin200

 *Quote:*   

> 
> 
> Ich muss mir wohl von irgendwoher ne vorkompilierte glibc ziehen. Wo finde ich so etwas?
> 
> 

 

das ist doch bei der Stage3 Installation bzw. auf dem Package- CDs bei. Wenn ich mich noch an meine erste Stage3 Installation errinnern kann wurde die Packages mit emerge -k packagename emerged (ohne zu kompelieren).

Du wirst ja sicher eine bestimmte Version von glibc benötigen - vielleicht kann dir jemand aus der Community das Packet aus seinem laufenden Package als binary zur Verfügung stellen (emerge --buildpkg (-b))

----------

## Vortex375

Ich poste jetzt wieder von Linux aus. Durch irgend eine Wunderheilung findet er jetzt plötzlich xdm wieder und mein kde scheint unbeschädigt geblieben zu sein.

Tatsächlich sieht es im ersten Moment nicht so aus, als wäre das System überhaupt defekt, aber emergen klappt immernoch nicht.

Da er beim emergen von glibc-2.5 gescheitert ist, wäre ich wohl am besten mit einer vorkompilierten glibc-2.5 für amd64 beraten.

Hier meine make.conf:

```
$ cat /etc/make.conf

# These settings were set by the catalyst build script that automatically built this stage

# Please consult /etc/make.conf.example for a more detailed example

CFLAGS="-march=k8 -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

ALSA_CARDS="emu10k1 intel8x0"

VIDEO_CARDS="nv vesa"

INPUT_DEVICES="keyboard kbd mouse evdev"

USE="alsa acl ipv6 opengl utf8 unicode nptl nptlonly mmx mmxext sse X kdehiddenvisiblity samba"

DISTDIR="/wz1/store/mirror/portage"

FEATURES="parallel-fetch"

PORTDIR_OVERLAY="/usr/local/portage"

source /usr/portage/local/layman/make.conf
```

----------

## STiGMaTa_ch

Schon mal ein revdep-rebuild laufen lassen?

Lieber Gruss

STiGMaTa

----------

## mv

 *Vortex375 wrote:*   

> Ich sah mich gezwungen den Reset-Knopf zu drücken.

 

Für mich sieht das eher so aus, als wenn Du Dir damit Dein Filesystem zerschossen hast (Begründungen kommen gleich). War jfs nicht auch das Filesystem, das so viel im RAM cached?

Deswegen aktiviert man im Kernel grundsätzlich den Sys-Request-Key (bei Kernel-Hacking) und drückt dann in einem Fall wie diesem Alt-Print-[eisub]. Ich habe noch nie erlebt, dass das nicht mehr geht...

 *Quote:*   

> Der fsck beim Hochfahren behauptet, "Filesystem is clean."

 

Beim Hochfahren wird vermutlich nur ein Statusbit überprüft. Ruf mal explizit fsck auf.

Wenn Du kein Backup hast, würde ich zumindest anschließend mal mit qcheck (von portage-utils) die Prüfsummen der installierten Files überprüfen.

 *Quote:*   

> /sbin/start-stop-daemon: stat /usr/bin/xdm: No such file or directory (No such file or directory)

 

War diese Meldung jetzt berechtigt, d.h. gibt es diese Datei nun oder nicht?

Mir scheint, das Filesystem zeigt sie bei manchen Gelegenheiten an (etwa bei ls), bei anderen Gelegenheiten aber nicht (ev. fehlt auch das +x-Bit, oder es verhält sich wie ein "noexec" filesystem o.ä.?). Das würde auch die Fehlermeldungen von udev erklären.

 *Quote:*   

> setenv: command not found

 

Wenn diese Meldung kommt, ist sicherlich nicht die API-Funktion gemeint, sondern die Bash o.ä. versucht "setenv" auszuführen. "setenv" ist ein Kommando, das die tcsh versteht. Möglicherweise sind da Teile einer tcsh-Konfigurationsdatei durch das kaputte Filesystem in eine Bash-Konfigurationsdatei geraten.

 *Quote:*   

> ParseError: Invalid token (not '='): /etc/profile.env: line 5 in /etc/profile.env

 

Leider hast Du jetzt diese Datei schon gelöscht: In /etc/profile.env stand sicherlich auch irgendwelcher Bockmist drin (was ebenfalls auf eine Filesystem-Beschädigung hindeutet).

 *Quote:*   

> rm: cannot remove '...': Function not implemented

 

Geht "rm" denn von Hand? Du kannst auch die busybox-Version (statisch, ohne glibc!) benutzen:

```
mv -i /bin/rm /bin/rm.ori

ln -s /bin/bb /bin/rm
```

Ähnliches ist für andere elementare Kommandos möglich...

Wenn dieses rm auch nicht geht, liegt es definitiv am Filesystem.

----------

## bbgermany

Hallo,

vielleicht solltest du nicht gleich ein ganzes stage3 Archiv entpacken. Vielleicht hilft es erstmal von einem Binhost die glibc zu ziehen und die zu installieren:

http://gentoo-wiki.com/TIP_Using_PORTAGE_BINHOST#x86

MfG, Stefan

----------

## Vortex375

So, es war zwar etwas chaotisch aber das System scheint wieder zu laufen.

Nach dem mein erster Versuch glibc einfach neu zu mergen wie oben beschrieben an rm gescheitert war habe ich noch einen Versuch gestartet und dabei lief das emerge sauber durch.

Die Probleme sind damit jetzt alle verschwunden. Auch die "verschwundenen" Dateien sind wieder aufgetaucht (udev hab ich sicherheitshalber auch nochmal neu installiert).

Das Problem mit setenv ist auch verschwunden. Meine /etc/profile.env sieht jetzt wieder so aus:

```

export ANT_HOME='/usr/share/ant-core'

export BROWSER='firefox'

export CLASSPATH='.'

export CONFIG_PROTECT='/usr/share/X11/xkb /usr/kde/3.5/share/config /usr/kde/3.5/env /usr/kde/3.5/shutdown /usr/share/config'

...

```

Vorher sah das aus irgend einem Grund so aus:

```
setenv ANT_HOME '/usr/share/ant-core'
```

Deswegen musste ich auch erst /etc/profile.env löschen (was funktioniert hat, das einzige was rm anscheinend nicht löschen konnte waren Verzeichnisse) und dann nochmal env-update ausführen.

----------

## mv

 *Vortex375 wrote:*   

> Vorher sah das aus irgend einem Grund so aus:
> 
> ```
> setenv ANT_HOME '/usr/share/ant-core'
> ```
> ...

 

Wie ich vermutet hatte: Die Syntax ist für die tcsh, nicht für die bash.

Entweder portage oder irgendein ebuild oder das Filesystem hatten /etc/profile.env durch /etc/profile.csh o.ä. (oder durch Teile davon) ersetzt.

Einen Filesystemcheck sowie qcheck -a würde ich sicherheitshalber trotzdem noch nachschieben.

----------

## Child_of_Sun_24

Ein kleiner Tip für die Zukunft, hatte auch schon manches mal bei einem neu aufsetzen des Systems das Problem mit rm und touch, das bestimmte funktionen einfach nicht liefen die für Portage wichtig waren, habe dann einfach die rm und touch dateien von der liveCD genommen und auf meinem System ersetzt (Glaube das kam dadurch das ich als erstes Portage installiert hatte) und schon lief es, da ich sowieso immer ein emerge -avuDe mache wenn ich ein System neu aufsetze waren die dateien natürlich hinterher wieder vom entsprechenden Paket emerged (Glaube coreutils).

Hat mir bisher immer geholfen.

CoS24

----------

