# brauche unbedingt hilfe [solved]

## gruenschnabel

au man...ich bin mit den nerven absolut am ende

heute morgen komm ich ins inst und alle gentoo-kisten stehen

alle müüsen sich dieses WE irgendwas eingefangen haben hinter das ich nicht hinterkomme

leute das sind alles produktivsysteme und ich bekomme sie einfach nicht mehr hoch

habe bereits auf alles systemen memtest und ein fsck gemacht...alles in ordnung

ich bekomme ständig segmentation faults

hab dann angefangen von cd zu booten um überhaupt auf die systeme zu kommen

und versucht mit chroot mir die sachen man anzuschauen

wenn ich dann einen sync versuche um eventuell zu sehen ob es schon neuere packete gibt

(vermute alle server haben bei einem update irgendeinen sch*** mit installiert bekommen)

bekommen ich nen error 10 no child process

sobald ich irgend einen service starten will rennt mir der bildschirm mir 

/lib/rcscripts/sh/rc-deamon.sh: line 230: XXX Segmentation fault   LC_ALL=C /bin/sleep "0.1"    voll

ich hab echt keine ahnung mehr was ich machen könnte und brauche dringend hilfe

hat wer ne idee was hier bei uns los ist?

danke schonmalLast edited by gruenschnabel on Wed May 02, 2007 7:57 pm; edited 1 time in total

----------

## manuels

hmm, was waren denn die letzten Pakete, die upgedatet wurden?

----------

## doedel

memtest und fsck lief ja schon, hast du schonmal cpuburn angeschaut? Einfach mal ne Weile rattern lassen...

----------

## Finswimmer

Dann versuch doch mal per Hand das Netzwerk zu starten?

/lib/rcscripts/sh/rc-daemon.sh (das vertauschte ae war hoffentlich ein Tippfehler) gehört zum Baselayout.

Schau mal mit genlop -t baselayout, ob und wann das neu installiert worden ist.

Ach:

etc-update und revdep-rebuild gemacht?

Geht denn, zum Test, ein einfaches: emerge foo -pv

Tobi

----------

## gruenschnabel

welche packete bin ich mir nicht sicher...lasse am WE immer update laufen und wenn unbedenkliche sachen dabei sind lass ich es einfach durchlaufen

an der CPU liegt es sicher nicht, da es sich ja nicht um ein system sondern um mehrere handelt (sowohl 3server als auch notebook)

es ist mir wirklich ein rätsel

ich kann nicht mal den mc in der chroot-umgebung satrten und bekomme gleich nen segmentation fault

kennt jemand eine lösung wie ich sauber das system "neu aufsetzen" kann ohne das die daten die im system sind (datenbanken/websites/groupware)

verloren gehen

wäre es möglich erstmal schnell ein sauberes system mit genkernel zu erstellen und wieder zugriff auf die daten zu haben?

----------

## manuels

 *gruenschnabel wrote:*   

> welche packete bin ich mir nicht sicher...lasse am WE immer update laufen und wenn unbedenkliche sachen dabei sind lass ich es einfach durchlaufen
> 
> 

 

Wird das nicht in /var/log/emerge.log oder so gespeichert? (Hab hier gerade nur einen Red-Hat-Rechner)

 *Quote:*   

> 
> 
> kennt jemand eine lösung wie ich sauber das system "neu aufsetzen" kann ohne das die daten die im system sind (datenbanken/websites/groupware)
> 
> verloren gehen

 

Hast du etwa von dem Produktivsystem kein Backup?   :Shocked:   :Rolling Eyes: 

Dann wuerd ich mal ganz schnell Knoppix laden und eins erstellen bevor du da irgendwie rumfrickelst...

----------

## gruenschnabel

etc-update geht in der chroot umgebung auch nicht----error 10 no child process und dann nur noch datenmüll in der konsole(üüüüQjeÖyyy......)

genlop....das comando kennt er nicht

emerge-befehle bringen immer error 10

----------

## Finswimmer

Hmm.

Dann lad dir ne stage3 runter, entpacke sie in /stage3 und setz dort drinnen das System auf.

Danach einfach per chroot rein, und du kannst auf die anderen Sachen zugreifen.

genlop ist ein eigenes Paket (was dir nun aber auch nichts hilft)

Mit: grep "completed emerge" /var/log/emerge.log bekommst du alle installierten Pakete ausgegeben (sofern die Datei vorhanden ist)

Tobi

----------

## gruenschnabel

laut log

1173954950: Started emerge on: Mar 15, 2007 11:35:50

1173954950:  *** emerge --verbose jre

1173954961:  >>> emerge (1 of 7) dev-java/java-config-wrapper-0.12-r1 to /

1173954961:  === (1 of 7) Cleaning (dev-java/java-config-wrapper-0.12-r1::/usr/portage/dev-java/java-config-wrapper/java-config-wrapper-0.12-r1.ebuild)

1173954961:  === (1 of 7) Compiling/Merging (dev-java/java-config-wrapper-0.12-r1::/usr/portage/dev-java/java-config-wrapper/java-config-wrapper-0.12-r1.ebuild)

1173954968:  >>> AUTOCLEAN: dev-java/java-config-wrapper

1173954968:  --- AUTOCLEAN: Nothing unmerged.

1173954968:  === (1 of 7) Post-Build Cleaning (dev-java/java-config-wrapper-0.12-r1::/usr/portage/dev-java/java-config-wrapper/java-config-wrapper-0.12-r1.ebuild)

1173954968:  ::: completed emerge (1 of 7) dev-java/java-config-wrapper-0.12-r1 to /

1173954968:  >>> emerge (2 of 7) dev-java/java-sdk-docs-1.5.0-r1 to /

1173954968:  === (2 of 7) Cleaning (dev-java/java-sdk-docs-1.5.0-r1::/usr/portage/dev-java/java-sdk-docs/java-sdk-docs-1.5.0-r1.ebuild)

1173954968:  === (2 of 7) Compiling/Merging (dev-java/java-sdk-docs-1.5.0-r1::/usr/portage/dev-java/java-sdk-docs/java-sdk-docs-1.5.0-r1.ebuild)

1173955435:  >>> AUTOCLEAN: dev-java/java-sdk-docs

1173955435:  --- AUTOCLEAN: Nothing unmerged.

1173955435:  === (2 of 7) Post-Build Cleaning (dev-java/java-sdk-docs-1.5.0-r1::/usr/portage/dev-java/java-sdk-docs/java-sdk-docs-1.5.0-r1.ebuild)

1173955435:  ::: completed emerge (2 of 7) dev-java/java-sdk-docs-1.5.0-r1 to /

1173955435:  >>> emerge (3 of 7) dev-java/java-config-2.0.31 to /

1173955435:  === (3 of 7) Cleaning (dev-java/java-config-2.0.31::/usr/portage/dev-java/java-config/java-config-2.0.31.ebuild)

1173955436:  === (3 of 7) Compiling/Merging (dev-java/java-config-2.0.31::/usr/portage/dev-java/java-config/java-config-2.0.31.ebuild)

1173955453:  >>> AUTOCLEAN: dev-java/java-config

1173955453:  --- AUTOCLEAN: Nothing unmerged.

1173955453:  === (3 of 7) Post-Build Cleaning (dev-java/java-config-2.0.31::/usr/portage/dev-java/java-config/java-config-2.0.31.ebuild)

1173955453:  ::: completed emerge (3 of 7) dev-java/java-config-2.0.31 to /

1173955453:  >>> emerge (4 of 7) dev-java/java-config-1.3.7 to /

1173955453:  === (4 of 7) Cleaning (dev-java/java-config-1.3.7::/usr/portage/dev-java/java-config/java-config-1.3.7.ebuild)

1173955453:  === (4 of 7) Compiling/Merging (dev-java/java-config-1.3.7::/usr/portage/dev-java/java-config/java-config-1.3.7.ebuild)

1173955465:  >>> AUTOCLEAN: dev-java/java-config

1173955465:  --- AUTOCLEAN: Nothing unmerged.

1173955465:  === (4 of 7) Post-Build Cleaning (dev-java/java-config-1.3.7::/usr/portage/dev-java/java-config/java-config-1.3.7.ebuild)

1173955465:  ::: completed emerge (4 of 7) dev-java/java-config-1.3.7 to /

1173955465:  >>> emerge (5 of 7) dev-java/sun-jdk-1.5.0.10 to /

1173955465:  === (5 of 7) Cleaning (dev-java/sun-jdk-1.5.0.10::/usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.10.ebuild)

1173955466:  === (5 of 7) Compiling/Merging (dev-java/sun-jdk-1.5.0.10::/usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.10.ebuild)

1173955678:  >>> AUTOCLEAN: dev-java/sun-jdk

1173955678:  --- AUTOCLEAN: Nothing unmerged.

1173955678:  === (5 of 7) Post-Build Cleaning (dev-java/sun-jdk-1.5.0.10::/usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.10.ebuild)

1173955678:  ::: completed emerge (5 of 7) dev-java/sun-jdk-1.5.0.10 to /

1173955678:  >>> emerge (6 of 7) virtual/jdk-1.5.0 to /

1173955678:  === (6 of 7) Cleaning (virtual/jdk-1.5.0::/usr/portage/virtual/jdk/jdk-1.5.0.ebuild)

1173955678:  === (6 of 7) Compiling/Merging (virtual/jdk-1.5.0::/usr/portage/virtual/jdk/jdk-1.5.0.ebuild)

1173955681:  >>> AUTOCLEAN: virtual/jdk

1173955681:  --- AUTOCLEAN: Nothing unmerged.

1173955681:  === (6 of 7) Post-Build Cleaning (virtual/jdk-1.5.0::/usr/portage/virtual/jdk/jdk-1.5.0.ebuild)

1173955681:  ::: completed emerge (6 of 7) virtual/jdk-1.5.0 to /

1173955681:  >>> emerge (7 of 7) virtual/jre-1.5.0 to /

1173955681:  === (7 of 7) Cleaning (virtual/jre-1.5.0::/usr/portage/virtual/jre/jre-1.5.0.ebuild)

1173955681:  === (7 of 7) Compiling/Merging (virtual/jre-1.5.0::/usr/portage/virtual/jre/jre-1.5.0.ebuild)

1173955685:  === (7 of 7) Updating world file (virtual/jre-1.5.0)

1173955685:  >>> AUTOCLEAN: virtual/jre

1173955685:  --- AUTOCLEAN: Nothing unmerged.

1173955685:  === (7 of 7) Post-Build Cleaning (virtual/jre-1.5.0::/usr/portage/virtual/jre/jre-1.5.0.ebuild)

1173955685:  ::: completed emerge (7 of 7) virtual/jre-1.5.0 to /

1173955685:  *** Finished. Cleaning up...

1173955686:  *** exiting successfully.

1173955690:  *** terminating.

1174310425: Started emerge on: Mar 19, 2007 14:20:25

1174310425:  *** emerge --verbose mc

1174310427:  >>> emerge (1 of 1) app-misc/mc-4.6.1 to /

1174310427:  === (1 of 1) Cleaning (app-misc/mc-4.6.1::/usr/portage/app-misc/mc/mc-4.6.1.ebuild)

1174310428:  === (1 of 1) Compiling/Merging (app-misc/mc-4.6.1::/usr/portage/app-misc/mc/mc-4.6.1.ebuild)

1174310687:  === (1 of 1) Updating world file (app-misc/mc-4.6.1)

1174310687:  >>> AUTOCLEAN: app-misc/mc

1174310687:  --- AUTOCLEAN: Nothing unmerged.

1174310687:  === (1 of 1) Post-Build Cleaning (app-misc/mc-4.6.1::/usr/portage/app-misc/mc/mc-4.6.1.ebuild)

1174310687:  ::: completed emerge (1 of 1) app-misc/mc-4.6.1 to /

1174310687:  *** Finished. Cleaning up...

1174310688:  *** exiting successfully.

1174310688:  *** terminating.

1174310922: Started emerge on: Mar 19, 2007 14:28:42

1174310922:  *** emerge  sync

1174310922:  === sync

1174310922: >>> Starting rsync with rsync://134.68.220.97/gentoo-portage

1174311110: === Sync completed with rsync://134.68.220.97/gentoo-portage

1174311233:  *** terminating.

1174322603: Started emerge on: Mar 19, 2007 17:43:23

1174322603:  *** emerge  sync

1174322603:  === sync

1174322603: >>> Starting rsync with rsync://134.68.220.97/gentoo-portage

1174322656: === Sync completed with rsync://134.68.220.97/gentoo-portage

1174322744:  *** terminating.

1174404176: Started emerge on: Mar 20, 2007 16:22:56

1174404176:  *** emerge  sync

1174404176:  === sync

1174404177: >>> Starting rsync with rsync://134.68.220.74/gentoo-portage

1174404236: === Sync completed with rsync://134.68.220.74/gentoo-portage

1174404330:  *** terminating.

aber heute die ersten problem und daher neustart 

backups sind schon vorhanden...allerdings laufen die nur ein mal die woch....und damit sind sie fast zu alt (wenn es einen anderen weg gibt)

ansonsten müssen die eh herhalten

----------

## gruenschnabel

wenn ich einfach ein stage3 rüberkopiere....kannst du mir das bitte näher erklären?

----------

## Finswimmer

Schau mal nach Config Dateien, die noch nicht genutzt werden.

Also quasi ein "etc-update" per Hand.

----------

## gruenschnabel

zugreifen(kopieren) kann ich die anderen sachen schon (livecd bringt ja zu m glück sshd mit....läuft grad ein backup der wichtigsten daten)

aber wie bekomme ich nun schnellstmöglich wieder ein laufendes system hin ohne alles völlig neu konfigurieren zu müssen?

(bei einer neuistallation)

----------

## gruenschnabel

 *Finswimmer wrote:*   

> Schau mal nach Config Dateien, die noch nicht genutzt werden.
> 
> Also quasi ein "etc-update" per Hand.

 

wenn ich jetzt noch wüsste wo und wie  :Shocked: 

----------

## Finswimmer

Das sind die neuen Config Dateien: ._cfg*

Such die mal im kompletten /etc Verzeichnis.

Zum Thema Neuinstallation:

Mach, wie ich sagte.

Dann nimm vom alten System die jeweiligen Config Dateien aus /etc, überprüfe sie nochmal, und dann drauf.

Und evtl kannst du die World Datei nehmen, um damit wieder alle Pakete zu installieren.

Das ist aber nicht so ratsam, da du (noch) nicht weißt, was dein System geschrottet hat.

Schau mal, ob auf der LiveCD app-forensics/chkrootkit drauf ist, wenn ja, lass es mal laufen.

Man weiß ja nie, ob da wer dir was Böses wollte.

Tobi

----------

## schachti

Vielleicht koennte man auch - nachdem man alles gesichert hat - einfach ein stage3 nach / entpacken und emerge -e world laufen lassen - habe das aber noch nie probiert...

EDIT: Zumindest Dateien wie make.conf etc. muesste man dann wohl vorher noch per Hand anpassen, falls sie durch einspielen des stage3 ueberschrieben werden.

----------

## Finswimmer

 *schachti wrote:*   

> Vielleicht koennte man auch - nachdem man alles gesichert hat - einfach ein stage3 nach / entpacken und emerge -e world laufen lassen - habe das aber noch nie probiert...
> 
> 

 

Hmm. Aber wenn wir davon ausgehen, dass ein Paket Probleme macht, dann hilft das auch nicht viel.

Aber evtl wäre es sinnvoll, in einer frischen Umgebung alles neu zu bauen.

Tobi

----------

## gruenschnabel

das meinte finswimmer auch schon....aber hat das schon mal jemand gemacht(und das system hat überlebt)?

----------

## schachti

 *Finswimmer wrote:*   

>  *schachti wrote:*   Vielleicht koennte man auch - nachdem man alles gesichert hat - einfach ein stage3 nach / entpacken und emerge -e world laufen lassen - habe das aber noch nie probiert...
> 
>  
> 
> Hmm. Aber wenn wir davon ausgehen, dass ein Paket Probleme macht, dann hilft das auch nicht viel.
> ...

 

Wieso? Zumindest alle Pakete des Basissystems werden so doch durch die Version aus dem stage3 ersetzt...

----------

## manuels

ja, aber nicht, wenn man danach ein 

```
emerge -e world
```

 macht.

----------

## schachti

Das kommt drauf an, wodurch das Problem entstanden ist.

----------

## manuels

Jaja, klar. Nur wissen wir das ja noch nicht.

Also lieber auf Nummer sicher gehen.   :Wink: 

----------

## schachti

ok, dann erstmal ein stage3 einspielen und gucken, ob alles geht. Bei Bedarf einzelne, nicht funktionierende Pakete neu emergen. Und vorher vielleicht mal /etc/portage/package.unmask und /etc/portage/package.keywords saeubern.  :Wink: 

----------

## gruenschnabel

was ist mit den ganzen konfigurations dateien?

sollte man die auch einfach überschreiben oder lieber erst sichern und später die alten benutzen?

----------

## schachti

Kommt drauf an. Wenn das System mit den neuen laeuft, mit den alten aber nicht, musst Du Dich halt schrittweise vorantesten, wo es hakt.

----------

## Klaus Meier

 *schachti wrote:*   

> Vielleicht koennte man auch - nachdem man alles gesichert hat - einfach ein stage3 nach / entpacken und emerge -e world laufen lassen - habe das aber noch nie probiert...
> 
> EDIT: Zumindest Dateien wie make.conf etc. muesste man dann wohl vorher noch per Hand anpassen, falls sie durch einspielen des stage3 ueberschrieben werden.

 

Habe ich mal probiert, geht voll in die Hose.

----------

## schachti

ok, was geht denn schief? Zumindest das Basissystem sollte dann doch laufen, so dass man den Rest aus einem laufenden System heraus reparieren kann, oder?

----------

## gruenschnabel

auf dem einen server mache ich das gerade....ging soweit und auch die neue root-umgebung läuft ersttma...gcc wird grad neu kompiliert und dann mal sehen ob er hochkommt

aber auf einem anderen server habe ich jetzt auch probleme

das booten von livecd und chroot ging problemlos

auch sync war kein problem

aber wenn ich jetzt emergen will kommt das:

>>> Emerging (1 of 1) dev-libs/openssl-0.9.8d to /

/usr/lib/portage/bin/ebuild.sh: line 1152:  4048 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4050 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4051 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4054 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4058 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4060 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4061 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4063 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4064 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4067 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4071 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4073 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4074 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4078 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4082 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4084 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4085 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

 * openssl-0.9.8d.tar.gz RMD160  :Wink:  ...                                                                                                                    [ ok ]

 * openssl-0.9.8d.tar.gz SHA1  :Wink:  ...                                                                                                                      [ ok ]

 * openssl-0.9.8d.tar.gz SHA256  :Wink:  ...                                                                                                                    [ ok ]

 * openssl-0.9.8d.tar.gz size  :Wink:  ...                                                                                                                      [ ok ]

 * checking ebuild checksums  :Wink:  ...                                                                                                                       [ ok ]

 * checking auxfile checksums  :Wink:  ...                                                                                                                      [ ok ]

 * checking miscfile checksums  :Wink:  ...                                                                                                                     [ ok ]

 * checking openssl-0.9.8d.tar.gz  :Wink:  ...                                                                                                                  [ ok ]

/usr/lib/portage/bin/ebuild.sh: line 1152:  4117 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4119 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4120 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4123 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4127 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4129 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4130 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4132 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

/usr/lib/portage/bin/ebuild.sh: line 1152:  4133 Speicherzugriffsfehler  chmod g+w "${T}/eclass-debug.log" >&/dev/null

hat jemand ne ahnung was das jetzt wieder heisst?

wenn ich z.B. mysql starten will kommt das:

livecd / # /etc/init.d/mysql start

/lib/rcscripts/sh/rc-services.sh: line 375: /var/lib/init.d/exitcodes/localmount: Datei oder Verzeichnis nicht gefunden

/lib/rcscripts/sh/rc-services.sh: line 377: return: : numeric argument required

 * ERROR:  cannot start net.eth0 as localmount could not start

/lib/rcscripts/sh/rc-services.sh: line 375: /var/lib/init.d/exitcodes/localmount: Datei oder Verzeichnis nicht gefunden

/lib/rcscripts/sh/rc-services.sh: line 377: return: : numeric argument required

/lib/rcscripts/sh/rc-services.sh: line 375: /var/lib/init.d/exitcodes/net.lo: Datei oder Verzeichnis nicht gefunden

/lib/rcscripts/sh/rc-services.sh: line 377: return: : numeric argument required

was ist mit der kiste los?

ein halbes jahr läuft sie problemlos und jetzt brennt alles!  :Shocked: 

----------

## schachti

Da das auf so vielen Kisten auf einmal passiert, ist einer der beiden folgenden Gruende wahrscheinlich:

1.) Auf allen Kisten ist beim Updaten was schiefgegangen.

2.) Jemand hat Deine kleine Serverfarm gehackt.

----------

## manuels

 *schachti wrote:*   

> 1.) Auf allen Kisten ist beim Updaten was schiefgegangen.
> 
> 

 

Daher wuerd ich dir das naechste mal manuelle Updates empfehlen.

----------

## gruenschnabel

gehäckt werden konnten sie ned....andere pw´s/andere rechenzenter...andere netze

updates werden schon manuell gemacht

updates ... ja das vermute ich auch...da mein läppi seit heute auch nicht mehr will und hab da auch am freitag zusammen mit den servern ein update gemacht....ich vermute ja schon fast das eines der packeges nen bug hat/hatte...aber dann sollten doch auch andere solche probleme haben

mir ist das alles schleierhaft

P.S.

wenn sie die Server gehackt hättet...warum dann nur die gentoo-listen und nicht die fedora und debian server?Last edited by gruenschnabel on Mon Mar 26, 2007 12:29 pm; edited 1 time in total

----------

## firefly

 *gruenschnabel wrote:*   

> gehäckt werden konnten sie ned....andere pw´s/andere rechenzenter...andere netze
> 
> updates werden schon manuell gemacht
> 
> updates ... ja das vermute ich auch...da mein läppi seit heute auch nicht mehr will und hab da auch am freitag zusammen mit den servern ein update gemacht....ich vermute ja schon fast das eines der packeges nen bug hat/hatte...aber dann sollten doch auch andere solche probleme haben
> ...

 

fährst du stable oder unstable?

----------

## gruenschnabel

was meinst du mit stable/unstable?

emergen nie masked packeges?

----------

## Klaus Meier

 *gruenschnabel wrote:*   

> was meinst du mit stable/unstable?
> 
> emergen nie masked packeges?

 

Also ob du x86 oder ~x86 verwendest.

Gibt aber kein unstable bei Gentoo, dass heißt Testing.

----------

## gruenschnabel

keine ahnung...x86 denke ich mal 

hab nie was eingestellt von wegen ~x86

so nu hab ich ein frisches stage3 draufgebügelt und gcc neu kompiliert

nach nem reboot bekomm ich sowas:

ext2fs_check_if_mount: no such gile or............

fsck.ext3: No such.....

The superblock could not be read............

*Filesystem couldn´t be fixed

Give root password for maintenance

was denn da los?

----------

## schachti

Hast Du die /etc/fstab angepasst?

----------

## gruenschnabel

ne (ich dussel)

also wieder livcd und schauen

ich hab vor dem stage3 ne sicherung von meinem kompletten etc gemacht

sollte man das jetzt reinspielen oder eher nicht?

----------

## manuels

ich wuerd nur die dateien reinspielen, die du brauchst.

Also erstmal nur fstab. Wenn dir spaeter noch etwas auffaellt, was fehlt, kopierst du die einzeln nach und nach

----------

## tuxianer

Hi, 

ich mische mich mal ein, zum Thema hacken, wie steht es den mit einem rootkit, das wäre eine option wieso das Sytem von heute auf morgen hops gegangen ist, der rootkit kann dir die ganze Zeit ein wundervoll harmonisch laufendes System vorgaukelt, und dahinter ist die Hölle los.

Wie steht es mit der Option

wenn möglich mach mal

```

emerge chkrootkit

```

MfG

----------

## Klaus Meier

 *gruenschnabel wrote:*   

> ne (ich dussel)
> 
> also wieder livcd und schauen
> 
> ich hab vor dem stage3 ne sicherung von meinem kompletten etc gemacht
> ...

 

Du solltest die für dich entscheidenden Dateien von Hand anpassen. Auf keinen Fall alle zurückspielen. Es ist ja möglich, dass da eine durch das Update zerschossen wurde. Und dann hast du es wieder.

----------

## gruenschnabel

also rootkit ist/war es sicher ned

chkrootkit hat nichts gefunden

es wäre auch äusserst ungewöhnlich wenn 3 server und ein desktop zur gleichen zueit

die hufe hochreissen(nicht nichtmal im selben netz hängen und völlig andere standorte und aufgaben

haben)

----------

## gruenschnabel

so das system ist mehr oder weniger sauber hochgefahren

nur login geht noch ned (muss wohl rootpw neu setzen)

hat jemand ne idee wie ich jetzt am besten wieder alles an den start bekomme?

apache/php/mysql alles neu kompilieren (dauert ewig) und dann daten einspielen

oder gibt es auch ne andere möglchkeit die alten daten zu nutzen (liegen ja alle noch auf der platte in nem "alt" verzeichniss)

wenn nicht müsste ich alle datenbankrechte und andere konfigurationen (alles) neu machen

----------

## Klaus Meier

Ich würde es auf alle Fälle neu installieren. Da liegen Daten in dutzenden verschiedenen Ordnern, oder weißt du, wo mysql bei der Installation überall was hingeschrieben hat? Und alles zurückspielen, na dann hättest du dir das alles sparen können.

----------

## gruenschnabel

 *Klaus Meier wrote:*   

> Ich würde es auf alle Fälle neu installieren. Da liegen Daten in dutzenden verschiedenen Ordnern, oder weißt du, wo mysql bei der Installation überall was hingeschrieben hat? Und alles zurückspielen, na dann hättest du dir das alles sparen können.

 

was sparen?

ich wollte ja so schnell wie möglich wieder ein arbeitendes system(um genau zu sein wenn das eine wieder läuft müssen auch die anderen noch repariert werden)

aber jetzt geht die bastelarbeit los...hab grad gemerkt...kein dhcp-client...also wieder livecd und emergen...und so kommen sicher noch 1000 sachen und ich sitz damit 3 tage an

dachte es gäbe eine andere möglichkeit als wirklich alles nochmal von grundauf zu kompilieren

weiss jemand wie ich die alten mysql-benutzer und berechtigungen wiederbekomme?

einfach nur alle tables in den neuen server reinkopieren...damm müsste er

ja eigentlich auch die alte user-table bekommen...oder?

----------

## trikolon

hallo.

ist evtl etwas offtopic, aber was mich doch sehr verwundert ist, er hat auf seinen stabil laufenden system einfach ein update gemacht von neuen packeten. er hat nicht das ganze system neu gestartet bevor sie zu hängen anfingen und hat auch nicht sachen wie apache usw neu gestartet. er hat nur ein update gemacht. welches packet bzw programm ist denn bitte mächtig genug, damit sich die kisten so verabschieden? sorry wenn ich irgendwas überlesen habe, aber diese frage stellt sich mir eben.

----------

## Finswimmer

 *Klaus Meier wrote:*   

>  *schachti wrote:*   Vielleicht koennte man auch - nachdem man alles gesichert hat - einfach ein stage3 nach / entpacken und emerge -e world laufen lassen - habe das aber noch nie probiert...
> 
> EDIT: Zumindest Dateien wie make.conf etc. muesste man dann wohl vorher noch per Hand anpassen, falls sie durch einspielen des stage3 ueberschrieben werden. 
> 
> Habe ich mal probiert, geht voll in die Hose.

 

Warum eigentlich?

Denn die Pakete werden doch der Reihe nach kompiliert...

Vielleicht sollte man statt emerge -e world lieber ein "emerge -av1 `cat $world-file` machen

Tobi

----------

## Klaus Meier

 *Finswimmer wrote:*   

>  *Klaus Meier wrote:*    *schachti wrote:*   Vielleicht koennte man auch - nachdem man alles gesichert hat - einfach ein stage3 nach / entpacken und emerge -e world laufen lassen - habe das aber noch nie probiert...
> 
> EDIT: Zumindest Dateien wie make.conf etc. muesste man dann wohl vorher noch per Hand anpassen, falls sie durch einspielen des stage3 ueberschrieben werden. 
> 
> Habe ich mal probiert, geht voll in die Hose. 
> ...

 

Weiß nicht mehr genau, was ich da gemacht habe. Aber das Problem ist, dass ja bei vielen Paketen ein Downgrade gemacht wird. Aber die Pakete, die nicht im stage3 drin sind, blieben aktuell. Und wenn man ein aktuelles ~x86 System hat und macht bei dem Grundsystem ein Downgrade auf ein uraltes x86 System? Stellenweise kamen die Stagearchive ja nur im Jahresrythmus. Und dieser Downgrade wird ja nicht von emerge gesteuert, sondern einfach drüberkopiert. Da passt dann doch vieles nicht mehr zusammen. Habe eventuell auch den Fehler gemacht, nach dem drüberkopieren vor dem emerge -e world neu zu booten. Weiß echt nicht mehr, jedenfalls war meine Kiste danach fertig. emerge -e world konnte ich gar nicht erst starten.

----------

## Finswimmer

Gut. Mitm ~x86 könnte es Probleme machen.

*Sollte* aber auch nicht, wenn man so vorgeht:

Stage3 drauf

update -uDavn

emerge -e system

emerge -e world

Denn:

Stage3 an sich funkiortiert ja, auch wenn es zu alte Pakete sind, da machen wir dann nen update, anschließend alles neu bauen.

Tobi

----------

## Klaus Meier

 *Finswimmer wrote:*   

> Gut. Mitm ~x86 könnte es Probleme machen.
> 
> *Sollte* aber auch nicht, wenn man so vorgeht:
> 
> Stage3 drauf
> ...

 

Ich denke auch, mein Fehler war der reboot. Vor dem Update halt. Und da werden ja Dienste gestartet, die nicht zum stage3 gehören. Und wenn man denen dann eine alte glibc unterschiebt, bumm... Sagen wir mal so, theoretisch ist es möglich, aber ich denke, der Aufwand ist höher, als komplett neu.Last edited by Klaus Meier on Mon Mar 26, 2007 3:35 pm; edited 1 time in total

----------

## schachti

 *gruenschnabel wrote:*   

> 
> 
> hat jemand ne idee wie ich jetzt am besten wieder alles an den start bekomme?
> 
> apache/php/mysql alles neu kompilieren (dauert ewig) und dann daten einspielen
> ...

 

Wenn Du über das alte System einfach ein stage3 drübergebügelt hast, sollte doch noch alles da sein, was vom stage3 nicht überschrieben wurde... Zumindest die Daten und Konfigurationen kannst Du dann weiternutzen, Du mußt nur die Pakete nochmal neu bauen.

----------

## gruenschnabel

haben das jetzt so gemacht das wir das ganze system mit stage3 neu aufgesetzt haben

update

und jetzt die wichtigsten komponenten kompiliert werden (wird noch ne weile dauern)

werde die halbe nacht beten das ich die daten morgen in aller frühe sauber migriert bekomme

damit die systeme morgen wieder "normal" laufen

das ein update ein gentoo-system dermassen zerschiessen kann erschreckt mich sehr (und es ist ja nicht eines sondern 4 systeme zeitgleich)

und zwar dermassen das wirklich nichts mehr geht und man auf eine neuinstallation zurückgreifen muss  :Shocked:   :Shocked:   :Shocked: 

ich bin zu gentoo gewechselt weil es eigentlich vom packetmanagement und der abhängigkeitsauflösung

sehr schön zu handhaben ist

ein system aufzusetzen dauert natürlich länger als bei anderen distries

aber wenn das system erstmal läuft ist es hochperformant und leicht zu warten (update etc...)

^^das dachte ich zumindest bis heute

vielleicht ist es doch nicht das perfecte system für einen produktiven serverbetrieb  :Sad: 

----------

## gruenschnabel

by the way

kennt jemand eine gute und schnelle möglichkeit unter gentoo

komplettbackups zu machen (in der art wie ghost-images)

die man dann bei einem solchen notfall einfach zurückspielen kann 

und den stand von vor ner woche hat ohne neuinstallation

(perfekt wäre es natürlich wenn das ganze auch noch beim

backupen incremental gemacht wird)

----------

## Fauli

 *trikolon wrote:*   

> welches packet bzw programm ist denn bitte mächtig genug, damit sich die kisten so verabschieden?

 

Die GNU C Bibliothek (glibc).

----------

## gruenschnabel

aber wenn es wirklich daran liegt (was ja naheliegend ist....da ja allle abstürze gleichzeitig auf völlig differenten systemen ...nach einem update geschehen sind)

dann frage ich mich wie dies in ein stable release kommen kann  :Shocked: 

----------

## schachti

 *gruenschnabel wrote:*   

> 
> 
> kennt jemand eine gute und schnelle möglichkeit unter gentoo
> 
> komplettbackups zu machen (in der art wie ghost-images)
> ...

 

Da gibt's im Forum bestimmt Tausende Threads zu, einfach mal die Suchfunktion benutzen.  :Wink: 

Gerne genommen wird partimage (das entspricht am ehesten den Ghost-Images, denke ich), aber Du kannst auch mal nach stage4 suchen hier im Forum.

----------

## schachti

 *gruenschnabel wrote:*   

> aber wenn es wirklich daran liegt (was ja naheliegend ist....da ja allle abstürze gleichzeitig auf völlig differenten systemen ...nach einem update geschehen sind)
> 
> dann frage ich mich wie dies in ein stable release kommen kann 

 

Es scheint ja so, als wären andere Nutzer nicht betroffen - zumindest ist Dein Thread zum Thema der erste, in dem ich sowas lese. Daß ein Fehler, der nur unter ganz seltenen Randbedingungen auftritt, durch jede noch so gute Qualitätskontrolle rutschen kann, ist klar. Außerdem - ohne Dir zu nahe treten oder Dir etwas unterstellen zu wollen - steht ja noch nicht mal fest, daß der Fehler bei der Distribution und nicht beim Anwender liegt.

----------

## Klaus Meier

Für einen Server bist du eventuell mit Debian besser bedient. Gentoo würde ich für den erfahrenen Desktopbenutzer empfehlen. Für was brauchst du bei einem Server ständige Updates, wenn es läuft? Bei einem Desktop sind die neuen Features dann doch wichtig.

----------

## manuels

Der Meinung bin ich nicht.

Gentoo ist auf für Server geeignet. Aber das ständige emerge -u world würd ich weglassen und einfach nur einen glsa-check durchführen.

----------

## gruenschnabel

also wollt ihr sagen das updates nicht wichtig sind bei linux-servern?

interessant

ich habe nie behauptet das ich DER erfahrene gentoo-benutzer bin...bin ein noob auf dem gentoo-spielplatz

wenn dieser systemzusammenbruch bei einem rechner aufgetreten wäre wüsste ich

sofort das ich was falsch gemacht habe, aber da er auf 4 systemen gleichzeitig passiert ist

und alle gentoosysteme waren wohingegen alle anderen systeme hier völlig normale lauf

(auch bei regelmässigen updates)

war es für mich nunmal naheliegend das es irgendwas mit der distribution zu

tun hat.....ich wollte euch gentoo-community keinesfalls zu nahe treten oder

gar eure distribution schlecht machen....ganz im gegenteil....wenn ich nicht davon

überzeugt gewesen wäre das sie gut ist hätte ich sie nie genommen

es ist nunmal eines der performantesten systeme und wenn es stabil 

läuft (wie hier auch schon seit einiger zeit) absolut empfehlenswert

jedenfalls danke für eure bemühungen

----------

## gruenschnabel

 *manuels wrote:*   

> Der Meinung bin ich nicht.
> 
> Gentoo ist auf für Server geeignet.

 

dem kann ich nur zustimmen

wie gesagt bin ich umgestiegen da der leistungszuwachs im gegensatz zu anderen

systemen ein unterschied wie tag und nacht ist

----------

## manuels

 *gruenschnabel wrote:*   

> also wollt ihr sagen das updates nicht wichtig sind bei linux-servern?
> 
> interessant

 

Da hast du mich wohl missverstanden.

Das Updaten (um neue Funktionen zu erlangen) ist bei Servern nicht so wichtig, wenn man sie nicht wirklich brauch.

Der GLSA-Check ist eine Funktion (die irgendwann evtl. mal in den Portage kommt, zur Zeit ist es noch ein eigenständiges Programm) die prüft, ob es sicherheitsrelevante News gibt und dem entsprechend up- oder downdatet.

 *Quote:*   

> wenn dieser systemzusammenbruch bei einem rechner aufgetreten wäre wüsste ich
> 
> sofort das ich was falsch gemacht habe, aber da er auf 4 systemen gleichzeitig passiert ist
> 
> und alle gentoosysteme waren wohingegen alle anderen systeme hier völlig normale lauf
> ...

 

Naja, es muss aber auch daher nicht an der Distribution liegen. Es kann genau so daran liegen, dass die Gentoo-Systeme alle die selbe Version eines Programms hatten, die ein Sicherheitsleck hatte (daher mein Hinweis auf den GLSA-Check).

Aber das sind alles nur Mutmaßungen. Solange man nicht weiß, wie dieses Problem auftrat, möchte ich hier keine Schuldzuweisungen machen.

Angepisst fühlen wir uns auf jeden Fall nicht (ich jedenfalls nicht). Und die meisten Leute hier sind dafür wohl auch zu empfindlich für eventuelle Trolle (damit bist nicht du gemeint. Meinte das nur allgemein).

----------

## Keruskerfuerst

```
Kennt jemand eine gute und schnelle möglichkeit unter gentoo

komplettbackups zu machen (in der art wie ghost-images) 
```

Zusätzliche Festplatte einbauen:

1. Ein zusätzliches OS installieren. Zweite Instanz Debian, Gentoo,...

2. Partitionen der Reihe nach mounten: /boot, root, usw.

3. Dann mit cp -ar /Quellpartition /Zielpartition die jeweiligen Partitionen kopieren.

Dies kann auch mit einem kleinen Script automatisiert werden.

----------

## c_m

 *Keruskerfuerst wrote:*   

> 
> 
> ```
> Kennt jemand eine gute und schnelle möglichkeit unter gentoo
> 
> ...

 

Das würde ja bedeuten, dass er jedesmal das Produktivsystem stoppen müsste?!

Halte ich für nicht praktikabel.

Stage 4 wurde ja schon erwähnt: ein Tar Backup vom System. Dazu eine kopie vom Bootsektor mit dd machen und fertig ist dein Backup. Im Fehlerfall mit LiveCD Booten und Tar (+ Bootsektor) wieder auf die Platte schreiben.

vorher am besten leeren und ggf natürlich neu partitionieren wenns ganz zerschortet ist.

 *gruenschnabel wrote:*   

> das ein update ein gentoo-system dermassen zerschiessen kann erschreckt mich sehr (und es ist ja nicht eines sondern 4 systeme zeitgleich)
> 
> und zwar dermassen das wirklich nichts mehr geht und man auf eine neuinstallation zurückgreifen muss   
> 
> [...]
> ...

 Naja, seien wir mal ganz ehrlich: Dein vorgehen Updates einzuspielen auf Produktivsystemen ist nun aber auch nicht grad sehr professionell... (ohne dir zu nahe treten zu wollen und deine Fähigkeiten als Admin in Frage zu stellen). Es hat schon seinen Grund warum man selbst bei Stable Paketen vorher immer alles auf nem Testsystem prüfen sollte.

----------

## gruenschnabel

>Zusätzliche Festplatte einbauen:

>1. Ein zusätzliches OS installieren. Zweite Instanz Debian, Gentoo,...

>2. Partitionen der Reihe nach mounten: /boot, root, usw.

>3. Dann mit cp -ar /Quellpartition /Zielpartition die jeweiligen Partitionen kopieren.

das wäre die einfachste und schnellste möglichkeit...allerdings würde man dann ständig das gesamte system spiegeln müssen

soetwas würde ich für ein monatliches backup benutzen

(würde einem stage4 image entsprechen)

aber wie sieht es mit lösungen für ein inkrementelles backup aus?

in der art des TSM-clients

(den könnte ich mir natürlich draufziehen....aber wenn es bereits ein ähnliches gentoo-modul gibt

würde ich dieses gerne testen)

>Naja, seien wir mal ganz ehrlich: Dein vorgehen Updates einzuspielen auf Produktivsystemen ist nun aber auch nicht grad sehr professionell... (ohne dir zu nahe treten zu >wollen und deine Fähigkeiten als Admin in Frage zu stellen). Es hat schon seinen Grund warum man selbst bei Stable Paketen vorher immer alles auf nem Testsystem prüfen >sollte.

Ich habe anscheinend vergessen zu erwähnen das ein Produktivsystem vielleicht nicht ganz der richtige Ausdruck ist.

Bevor hier noch mehr Leute "böser-dummer Admin schreinen".....Ich arbeite an nem Forschungsinstitut an der Uni....was

bedeutet das immer alle Systeme develop sind...auch die produktivsysteme.

wer von euch an schonmal an ner uni gearbeitet hat weiss sicher das ständig an allem

weitergebastelt wird.

Man nennt dies Forschung/Weiterentwicklung....wozu ein system benötigt wird was den derzeitigen Stand der technik darstellt.

Gerade deshalb auch meine Wahl von gentoo....man kann sehr schnell neue Sandboxumgebungen schaffen und module einspielen

um sie zusammen mit den selber entwickelten Applicationen zu testen.

(unseren Webserver date ich nicht jede Woche ab...wenn der läuft lass ihn laufen)

Um nochmal auf den Fehler zu kommen:

Ich werde heute Mittag meinen auch zuschossenen Laptop von CD booten und jedem der will nen ssh-Zugang per PN schicken...wenn ihr wollt könnt ihr

ja mal raufschauen und mir sagen welche grob-fahrlässige Dummheit ich begangen habe.

----------

## gruenschnabel

 *manuels wrote:*   

>  *gruenschnabel wrote:*   also wollt ihr sagen das updates nicht wichtig sind bei linux-servern?
> 
> interessant 
> 
> Da hast du mich wohl missverstanden.
> ...

 

GLSA-Check...und ich dachte das ist die Aufgabe von portage

oder meinst du das es eine art flag sein wird das du setzt damit nur "sicherheutsupdates" bei emerge gemacht werden und alle anderen updates nicht?

fehlt dann nur noch die Funktion das unten rechts im KDE ein popup kommt "updates wurden heruntergeladen und können jetzt installiert werden"  :Wink: 

wie genau heisst das modul? konnte es im portage-tree leider nicht finden

Sicherheitsleck...weiss ich noch nicht...aber ich hatte halt angenommen das bei programme im portage stable sind ein einspielen/update unbedenklich ist.

----------

## c_m

dann betrachte meine aussage als gegenstandslos  :Wink: 

Es klang für mich so ("es brennt!") als wenn es wirklich wichtige Systeme sind.

----------

## gruenschnabel

 *c_m wrote:*   

> dann betrachte meine aussage als gegenstandslos 
> 
> Es klang für mich so ("es brennt!") als wenn es wirklich wichtige Systeme sind.

 

es sind schon wichtige systeme....vielleicht war der ausdruck "produktivsystem" nicht ganz korrekt da er eigentlich

aus der Wirtschaft stammt

Aber wenn bei uns im Institut alle gentoo-systeme stehen gleicht das schon einem Brand

Ständig klingelt das Telefon und Projektpartner wollen wissen was los ist

Naja denke heute Abend wird erstmal alles soweit laufen das man etwas Luft hat und das man mit der Fehlersuche anfangen kann

----------

## Finswimmer

glsa-check ist in app-portage/gentoolkit

Und eigentlich *sollten* alle stable Pakete ohne Probleme laufen.

Was bei dir passiert ist, kann ich leider nicht sagen. 

Ich tippe immer noch auf gcc/glibc

Hoffe, bei dir geht nun alles wieder.

Tobi

----------

## tacki

hatte mal ein ähnliches problem. bei segfaults sind bei mir meist eines von 2 dingen kaputt:

1) Hardware (insbesonders Speicher oder 'geplatzte' Kondensatoren auf dem Board

2) glibc mit falschen cflags installiert (lässt nacheinander fast alles abschmieren)

Ich tippe in deinem Fall wohl eher auf 2).

----------

## Finswimmer

 *tacki wrote:*   

> hatte mal ein ähnliches problem. bei segfaults sind bei mir meist eines von 2 dingen kaputt:
> 
> 1) Hardware (insbesonders Speicher oder 'geplatzte' Kondensatoren auf dem Board
> 
> 2) glibc mit falschen cflags installiert (lässt nacheinander fast alles abschmieren)
> ...

 

Sehe ich auch so, aber die make.conf ist korrekt, also muss da entweder jmd dran rumgeschraubt haben, und es wieder in Ordnung gebracht haben.

Oder, aus welchem ominösen Grund auch immer, hat glibc bei dem Emerge nicht auf die make.conf geachtet....

Tobi

----------

## schachti

 *gruenschnabel wrote:*   

> 
> 
> das wäre die einfachste und schnellste möglichkeit...allerdings würde man dann ständig das gesamte system spiegeln müssen
> 
> soetwas würde ich für ein monatliches backup benutzen
> ...

 

Vielleicht ist rdiff-backup das, was Du suchst?

----------

## gruenschnabel

so....alle server laufen wieder

aber meinen laptop habe ich noch unverändert gelassen

wenn jemand bedarf hat kann er mal einen blick drauf werfen

habe von der livecd gebootet und die platte gemountet

also wer will dem geb ich die ip und nen root login(wenn er verspricht anständig zu sein  :Wink:  )

sobald ich chroote geht auch bei dem nix mehr

----------

## Keruskerfuerst

Dann nimm mal eine Livecd, mounte die Partitionen   und wirf einen Blick auf die Daten.

Remotelogin auf einen fremden Rechner:   :Shocked: 

----------

## gruenschnabel

 *Keruskerfuerst wrote:*   

> Dann nimm mal eine Livecd, mounte die Partitionen   und wirf einen Blick auf die Daten.
> 
> Remotelogin auf einen fremden Rechner:  

 

wie bereits oben geasgt habe ich genau das getan

die daten sind alle gesichert und der rechner wird die tage plattgemacht

deshalb ja auch mein vorschlag des remotelogins...mehr kaputtzumachen geht sowieso

nicht mehr

also warum nicht...vielleicht könnt ihr mir ja sagen was schiefgelaufen ist

----------

## Anarcho

 *gruenschnabel wrote:*   

> also wer will dem geb ich die ip und nen root login(wenn er verspricht anständig zu sein  )

 

Jetzt wundert mich nichts mehr...  :Twisted Evil: 

Ich tippe auch auf gcc/glibc.

Aber mich wundert das hier noch keiner nach einem emerge --info gefragt hat, bzw. nach den CFLAGS/LDFLAGS.

Gibt dochmal den Inhalt der make.conf vom Laptop an.

----------

## Keruskerfuerst

Ja, O.K.

Schick mal die IP Adresse. Mal sehen, was ich auf dem Rechner finde...

----------

## Finswimmer

 *Anarcho wrote:*   

>  *gruenschnabel wrote:*   also wer will dem geb ich die ip und nen root login(wenn er verspricht anständig zu sein  ) 
> 
> Jetzt wundert mich nichts mehr... 
> 
> Ich tippe auch auf gcc/glibc.
> ...

 

Wie kann man das denn mit gcc/glibc am Besten überprüfen?

Tobi

----------

