# extrem langer bootvergang nach kernel kompilieren

## thrashed

hallo liebe gentoo gemeinde:

ich habe seit knapp 3 jahren ein gentoo system am laufen. funktioniert soweit alles einwandfrei. ich mache eigentlich auch immer alle neuen kernelupdates mit und hatte eigentlich nie probleme.

als ich nun auf linux-2.6.22-gentoo-r9 gehen wollte, funktionierte das kompilieren wie immer und hatte diesbzgl. keine probleme. beim ersten bootvorgang blieb das system jedoch bei "INIT: version 2.86 booting" hängen.

Nach erneutem bootvorgang bin ich dann draufgekommen das das system gar nicht hängt sondern nur EXTREMST langsam ist und erst so ca. nach 25minuten fertig hochgefahren ist. normalerweise dauerts so 45sekunden oder so.

Zu erst hatte ich den neuen Kernel unter Verdacht, bis ich mal spasshalber einen alten Kernel mit einer funktionierenden alten .config.bak kompiliert habe. Dieser Kernel hat mit dieser Konfiguration immer funktioniert, bzw. das BackUp funktioniert immer noch, jedoch neukompiliert bekomme ich das selbe Fehlerbild wie mit dem neuen kernel.

Irgendwie weiss ich gar nicht wo ich den Fehler jetzt suchen soll? Durch intensives suchen habe ich Foreneinträge gefunden wo Debianuser das selbe Fehlerbild haben, wenn sie den kernel mit dem debian'scchen 4.2-20070707-1 gcc kompiliert haben. Ich habe sys-devel/gcc-4.1.2 installiert. Bin wirklich ratlos wo ich mit der Problemlösung anfangen soll  :Sad: 

Vielen Dank für Eure kompetente Hilfe,

lg

thrashed

hier hat jemand anscheinend das gleiche problem:

https://forums.gentoo.org/viewtopic-t-576636-highlight-.html?sid=4bd3b93054d0a26f88f9f2aa44109f98

----------

## thrashed

niemand?   :Sad: 

----------

## Mr_Maniac

Ich kann leider auch nur raten...

Hast du schon mal versucht, gcc und glibc neu zu kompilieren?

Haben sich seit dem letzten Kernel-Compile USE- oder CFLAGS geändert (würde zwar nicht die Kernel-Kompilierung betreffen, aber die Kompilierung des Kompilers  :Wink:  )

Sind andere, neu gebaute Programme ebenfalls langsamer geworden oder verhalten sich seltsam?

----------

## SvenFischer

[Spass on]

Schön, dann kann man sich in Ruhe ml die Bootmeldungen ansehen und etwas in sich kehren

[Spaß off]

Etwas kacke, liegt es daran, das das Filesystem ein Problem hat? Mach mal ein Filesystemcheck von einer Live CD. Evtl. hast Du in der /etc/fstab nämlich kein Filesystemcheck aktiviert, dann wäre meine Idee naheliegend.

----------

## thrashed

 *SvenFischer wrote:*   

> [Spass on]
> 
> Schön, dann kann man sich in Ruhe ml die Bootmeldungen ansehen und etwas in sich kehren
> 
> [Spaß off]
> ...

 

ja der spassfaktor hält sich leider in grenzen. aber das mit den bootmeldungen in ruhe ansehen habe ich schon hinter mir. interessant was da alles so kommt haha

filesystemcheck habe ich durchgeführt. ist alles in ordnung. useflags sind auch gleichgeblieben. ich bin echt ratlos und weiss schon nicht mehr was ich machen soll. glibc und gcc habe ich schon mal neukompiliert.

ich hoffe ihr habt noch irgendwelche ideen! lasst mich nicht im stich  :Smile: 

lg

thrashed

----------

## Finswimmer

Welcher Bootloader?

Bei lilo evtl compress oben in die lilo.conf

Tobi

----------

## thrashed

bootloader ist grub. um genau zu sein grub-0.97-r3

kernel die ich vor einiger zeit mal kompiliert habe funktionieren einwandfrei. kernel die ich momentan kompiliere funktionieren nicht. egal welche sourcen ich nehme. selbst wenn ich die sourcen eines funktionierenden kernel nehme und den aktuell noch einmal kompiliere habe ich die selben probleme wie im ersten posting beschrieben.

treibt mich noch in den wahnsinn  :Sad: 

----------

## Finswimmer

Aber ein alter Kernel funktioniert? Du kannst also sicher ausschließen, dass es am Bootloader liegt?

Tobi

----------

## thrashed

 *Finswimmer wrote:*   

> Aber ein alter Kernel funktioniert? Du kannst also sicher ausschließen, dass es am Bootloader liegt?
> 
> Tobi

 

so ist es. ein kernel der vor 2 monaten oder so kompiliert worden ist funktioniert.

die selben sourcen nur eben gestern kompiliert funktioniert nicht. useflags haben sich nicht geändert. irgendein update in den letzten 2 monaten, oder vielleicht auch irgendeine konfiguration durch etc-update hat sich dahingehend verändert das ich bei neu kompilierten kernel diese probleme habe.

interessant zu wissen ist vielleicht auch das ich meine kernel mit "genkernell --menuconfig all" kompilieren. Ich kann mich dran erinnern das es in letzter zeit ein paar genkernel updates gab. und auch die /etc/genkernel.conf getauscht wurde. vielleicht sollte ich den kernel testweise mal wieder von hand kompilieren.

sehr seltsam dieses ganze verhalten und mit meinen beschränkten wissenstand nur mehr durch trial+error herauszufinden   :Sad: 

----------

## Klaus Meier

Eventuell Platte voll? Hatte das mal, dass alles extrem langsam lief, als kein Platz mehr da war.

----------

## thrashed

eine datenpartition ist auf 94%.

das ist jedoch eine eigene partition, die schon seit ca. 8 monaten zwischen 75 und 98% Auslastung hat.

eine volle platte würde jedoch auch nicht erklären warum der vor 2 monaten kompiliert kernel funktioniert und mit den selben sourcen nur vor 2 tagen kompilierte kernel nicht funktioniert. und mit langsam meine ich nicht langsamer als sonst, sondern ca. das 800fache langsamer (achtung keine übertreibung).

----------

## Klaus Meier

 *thrashed wrote:*   

> eine datenpartition ist auf 94%.
> 
> das ist jedoch eine eigene partition, die schon seit ca. 8 monaten zwischen 75 und 98% Auslastung hat.
> 
> eine volle platte würde jedoch auch nicht erklären warum der vor 2 monaten kompiliert kernel funktioniert und mit den selben sourcen nur vor 2 tagen kompilierte kernel nicht funktioniert. und mit langsam meine ich nicht langsamer als sonst, sondern ca. das 800fache langsamer (achtung keine übertreibung).

 

Wer sagt denn, dass es ursächlich am Kernel liegt? Es kann doch sein, dass etwas anderes zeitgleich mit der Installation des neuen Kernels aufgetreten ist. Und einfach mal die Belegung der Partition auf unter 90% bringen wäre doch mal einen Versuch wert.

----------

## TheSmallOne

Hm, vielleicht irgendeine falsche Kerneloption gesetzt, die das ganze so ausbremst?

----------

## schachti

Falls Du das im Kernel eingestellt hast, kannst Du Dir unter beiden Kerneln mal /proc/config.gz auf die Festplatte kopieren, entpacken und vergleichen.

----------

## thrashed

steht bei beiden kernel das komplett gleiche drinnen. sagt mir zumindest diff

das hat bestimmt nix mit meinen kernel zu tun. irgendwas anderes haut da nicht ganz hin   :Confused: 

----------

## Finswimmer

 *Klaus Meier wrote:*   

>  *thrashed wrote:*   eine datenpartition ist auf 94%.
> 
> das ist jedoch eine eigene partition, die schon seit ca. 8 monaten zwischen 75 und 98% Auslastung hat.
> 
> eine volle platte würde jedoch auch nicht erklären warum der vor 2 monaten kompiliert kernel funktioniert und mit den selben sourcen nur vor 2 tagen kompilierte kernel nicht funktioniert. und mit langsam meine ich nicht langsamer als sonst, sondern ca. das 800fache langsamer (achtung keine übertreibung). 
> ...

 

Lies mal genauer nach. Ein Kernel, der vor längerer Zeit kompiliert worden ist, läuft ohne Probleme.

Zumal es ist eine "Daten"partition. Die hat ja noch nichtmal was mit / zu tun...

Tobi

----------

## thrashed

ja, seh ich auch so. danke.

ich sollt den kernel mal von hand kompilieren. ich trau im moment genkernel nicht ganzLast edited by thrashed on Fri Nov 23, 2007 2:32 pm; edited 1 time in total

----------

## schachti

 *thrashed wrote:*   

> steht bei beiden kernel das komplett gleiche drinnen. sagt mir zumindest diff

 

Und wenn Du ein diff auf die beiden Kernel selbst losläßt?

----------

## Finswimmer

 *schachti wrote:*   

>  *thrashed wrote:*   steht bei beiden kernel das komplett gleiche drinnen. sagt mir zumindest diff 
> 
> Und wenn Du ein diff auf die beiden Kernel selbst losläßt?

 

Sollte nur rauskommen, dass sie sich unterscheiden, aber nicht in was...

Nimm die Kernelconfig und kompilier ihn per Hand.

Ist sowieso viel anpassungsfähiger als es mit genkernel zu machen.

Tobi

----------

## Klaus Meier

 *Finswimmer wrote:*   

>  *Klaus Meier wrote:*    *thrashed wrote:*   eine datenpartition ist auf 94%.
> 
> das ist jedoch eine eigene partition, die schon seit ca. 8 monaten zwischen 75 und 98% Auslastung hat.
> 
> eine volle platte würde jedoch auch nicht erklären warum der vor 2 monaten kompiliert kernel funktioniert und mit den selben sourcen nur vor 2 tagen kompilierte kernel nicht funktioniert. und mit langsam meine ich nicht langsamer als sonst, sondern ca. das 800fache langsamer (achtung keine übertreibung). 
> ...

 

Also ich lese, dass ein neukompilieren des alten Kernels mit der alten .config die gleichen Probleme verursacht. Der alte Kernel lief damals, aber der gleiche Kernel jetzt neu übersetzt mit der alten .config nicht. Korrigiere mich, wenn ich das falsch gelesen habe. Und wie gesagt, keine Ahnung, was auf welcher Partition ist, aber einfach mal die Belegung auf unter 90% bringen ist doch einen Versuch wert.

----------

## schachti

 *Finswimmer wrote:*   

>  *schachti wrote:*    *thrashed wrote:*   steht bei beiden kernel das komplett gleiche drinnen. sagt mir zumindest diff 
> 
> Und wenn Du ein diff auf die beiden Kernel selbst losläßt? 
> 
> Sollte nur rauskommen, dass sie sich unterscheiden, aber nicht in was...
> ...

 

Genau das herauszufinden war das Ziel - ob sich die beiden Kernel trotz gleicher Version und trotz gleicher .config unterscheiden. Sollte das nämlich nicht der Fall sein, könnte man den Kernel als Ursache ausschließen.

----------

## bell

Die beiden Kernel werden sich unterscheiden, da der Kompelier-Zeitpunkt mit im gespeichert Kernel ist.

----------

## thrashed

ich hab noch immer keine lösung gefunden  :Sad: 

habe jetzt schon mal auf gcc 4.2.2 upgegraded, weil ich den fehler dort vermutet habe. habe den kernel händisch kompiliert und wirklich die selben einstellungen vorgenommen wie vom funktionierenden. wie ihr oben lesen könnt, wisst ihr das ich das problem mit allen kernel versionen habe die ich kompilieren will. zum glück aber noch einen funktionierenden habe der mir momentan noch das leben rettet.

eine falsche kernel konfiguration kann ich ausschliessen. nach ca. 40minuten kommt mein kernel auch hoch, aber da muss es doch noch irgendwo ein anderes problem geben. irgendwo ist der hund begraben  :Sad: 

ich hoffe von euch hat noch jemand irgendeine idee. ich find hier im forum einfach nichts. google spuckt auch nichts aus. bin echt verzweifelt

----------

## bell

Da niemand eine konkrete Idee hat, mache ich ein Paar mal Schuss ins Blaue.  :Smile: 

Poste mal dein Environment. Vielleicht ist ja irgend eine Variable gesetzt, die nicht sein darf. Bin kein Spezialist, aber evtl. fällt jemanden ja was auf.

Du hast GCC mehrfach geändert. Was sagt gcc-config -l ?

Gibt es Unterschiede zwischen den Bootmeldungen der beiden Kernel? Die dmesg beider Kernel wären interessant.

Nutzt Du eine initrd ? Evtl. muss diese neu erzeugt werden.

An sonsten fällt mir noch die Holzhammermethode emerge -e system && emerge -e world ein.

Hoffe es ist ein Treffer dabei  :Smile: 

----------

## thrashed

danke für deine antwort:

gcc habe ich immer nach dem gcc upgradeleitfaden upgedated:

es sind deswegen soviele versionen installiert, da das system seit 3 jahren die selbst installation ist

```
 # gcc-config -l

 [1] i686-pc-linux-gnu-3.3.6

 [2] i686-pc-linux-gnu-3.4.6

 [3] i686-pc-linux-gnu-3.4.6-hardened

 [4] i686-pc-linux-gnu-3.4.6-hardenednopie

 [5] i686-pc-linux-gnu-3.4.6-hardenednopiessp

 [6] i686-pc-linux-gnu-3.4.6-hardenednossp

 [7] i686-pc-linux-gnu-4.1.2

 [8] i686-pc-linux-gnu-4.2.2 *

```

die bootmeldungen sind zwischen all den kernel die gleiche, da ich ja überall die selben settings fahre. mit dmesg kann ich jetzt auf die schnelle nicht dienen, aber am abend dann.

ich nutze keine initrd und habe ich noch nie eine benötigt.

mal ein backup machen und dann über die holzhammer methode nachdenken hehe. danke auf jeden fall. ich halte euch am laufenden.

lg thrashed

----------

## AmonAmarth

 *thrashed wrote:*   

> danke für deine antwort:
> 
> gcc habe ich immer nach dem gcc upgradeleitfaden upgedated:
> 
> es sind deswegen soviele versionen installiert, da das system seit 3 jahren die selbst installation ist
> ...

 

also, ich würd auf "fehlerhaften gcc" plädieren, in welcher form auch immer!

wenn du wirklich alles exakt gleich gemacht hast wie, vor ein paar monaten hat sich in der zwischenzeit doch eigentlich nur der compiler verändert!

mein vorschlag also: versuche rauszufinden mit welcher gcc version du damals den alten kernel kompiliert hast, schalte mal testweise mit gcc-config auf den zurück und versuchs damit noch mal.

wenn es dann funktioniert hast du jedenfalls schonmal einen ansatz. evtl musst du auch nur (bei deinem neuen) gcc binutils o.ä. neu compilieren damit der wieder brauchbaren code erstellt.

was noch interessant wäre wären deine CFLAGS, nutzt du evtl irgend etwas überoptimiertes (-ffast-math o.ä.) und der neue gcc mags nicht mehr?

mfg

----------

## thrashed

es ist echt wie verhext:

ich habe nun meinen gcc von 4.2.2 auf 4.1.2 auf 3.4.6 auf 3.3.6 downgegraded. jeweils habe ich auch die binutils neukompiliert und den kernel mit der neu eingestellten gcc version kompiliert.

wenn ich mit dem neu gebauten kernel booten will dauert der bootvorgang von grub bis zum konsolenlogin auf der console ca. 1'e Stunde und 10 Minuten. Es sind alle driver vorhanden und das System kommt mit allen Diensten hoch und ist extrem langsam. Das System rennt CPU technisch gesehen ständig unter voller Last - das kann ich mir eben mit TOP anzeigen lassen.

hier der dmesg output des funktionierende kernels  2.6.21-gentoo-r4 

hier der dmesg output des NICHT funktionierendem kernel  2.6.23-gentoo-r3

ich habe echt keinen plan mehr was ich noch machen soll.

ein "emerge --sync && emerge -Duve world && emerge -e system" habe ich auch schon hinter mir.

hoffentlich hat noch jemand eine idee.

ich habe einen Pentium Mobile als Prozessor. Kann ich da in der Kernel.Config was verbockt haben?

hier noch meine .config vom aktuellen 2.6.23-r3'er

bin wirklich für jeden nur so kleinsten tip dankbar. bin am ende mit meinen latein  :Sad: 

----------

## papahuhn

Ich glaube eigentlich nicht, dass es daran liegt; aber was hast du zu verlieren:

Bei deinem funktionierenden Kernel wird dein Floppylaufwerk erkannt; bei dem anderen nicht. Bei einigen Leuten ist das Diskettenlaufwerk dafür verantwortlich, dass das BIOS und grub sehr langsam laden; der Kernel danach aber wieder flott ist. Vielleicht ist das bei dir irgendwie andersrum. Vielleicht kannst du mal ein paar Kombinationen von BIOS-Floppy an/aus und Kernel-Floppy an/aus probieren.

Edit: CPU unter Volllast? Welche Prozesse?

----------

## thrashed

iiiissssssccchhhh aaabe gar kein floppy laufwerk   :Laughing: 

hab es spasshalber trotzdem mal ausprobiert, weil ich gar nicht mehr weiter weiss. bios/floppy an/aus in kombinationen mit kernel/floppy an/aus.

erfolg gleich 0  :Sad: 

ja, cpu is unter volllast. ach diverse prozesse wechseln sich da immer ab. openssl (sshd) und apache sind immer ganz vorne dabei. ich gehe aber mal davon aus das das jedoch egal is, da bevor irgendein dieser prozesse geladen wird alles schon so unendlich langsam ist, das es nicht mehr zum aushalten ist. sshd wird bei diesen bootvorgang eigentlich erst so nach 45minuten gestarten.

ich versteh echt die welt nicht mehr. das kann doch nur was mit dem gcc oder dem kernel ansich zu tun haben oder?

wo sind hier die profis?    :Very Happy: 

alles liebe,

thrashed.

----------

## peterpeterson

hi

mal nur sonne idee..

wenn du sagst der rechner läuft seid drei jahren, lass doch vielleicht vom festplattenhersteller nen HDD-Test drüberlaufen, vielleicht ist auf deiner boot-partition was nicht in orndung und zwar an der stelle, wo der neue kernel hinkopiert wird. 

damit könnte man auch erklären, dass der alte kompilierte kernel (funktionierende) vielleicht unbewegt auf heilen sektoren liegt.

alternativ kannst du ja auchmal das smart von der platte auslesen und gucken, ob da fehler protokolliert worden sind.

vielleicht auchmal den smart-test durchlaufen lassen.

Anmerkung fsck und badblock müssen nicht zwinged etwas finden, wenn die platte einen weg hat. es gibt nen reservierten bereich, auf den die hdd bei den ersten datenträgerfehlern automatisch (unsichtbar) sektoren umschiebt. musst du mal gucken und hören, was die hdd macht. wenn mehrere sektoren schon ausgelagert worden, dann springt der lesekopf immer zwischen den heilen und ausgelagertem bereich hin und her, dass machts schon teilweise etwas langsam. Abgesehen davon finden die beiden programme auch keine datenübertragungsfehler vom kontroller zur hdd.

oder die beste aller lösungen... warum muss man ein linux neu starten ...!?  :Wink: 

cu tim

----------

## peterpeterson

hi (nochmal ... habe erst jetzt die zweite seite gesehen)

wenn du sagst die cpu macht 100% (was eigendlich kaum was aussagt)

was sagen denn:

"load average:", swap, wa,  hi, si, st

ich vermute mal das "load average" so grob über 10 liegt... cpu bei 100% machts nämlich eigendlich nicht langsam

swap't er wie wahnsinnig? ein programm das speicher frisst?

die aussage von: hi, si, st

weiss ich leider nicht mehr genau... und finde gerade die seite nicht wieder wo das erklärt war.

der wert  "wa" sagt aber aus, dass er auf ein hardware gerät wartet. 

vermute mal das heisst: wating for access

z.b. langsame/defekte platte macht diese wert sehr schon hoch.

/var/log/messages gibt auch keinen anhaltspunkt?

cu tim

----------

## peterpeterson

hi 

nochwas: 

in deiner dmegs: 3w-xxxx: AEN: ERROR: Unit degraded: Unit #0.

je nachdem wie du den controler eingestellt hast priorität: "zugriff" oder "recover" bei wiederherstellung des arrays.

wird die karre wer weiss wie langsam. hast du das 3DM2-Dings installiert? guck dochmal ob er recovert. oder ob ne platte hängt.

cu tim

----------

## peterpeterson

hi 

nochwas zum  3ware

> sd 0:0:0:0: [sda] Write cache: enabled, read cache: disabled, supports DPO and FUA

> sd 0:0:0:0: [sda] Write cache: enabled, read cache: disabled, supports DPO and FUA

Write cache: enabled

du hast eine BBU oder bist des wahnsinns?

read cache: disabled

macht das sinn?

cu tim

----------

## thrashed

 *peterpeterson wrote:*   

> hi (nochmal ... habe erst jetzt die zweite seite gesehen)
> 
> wenn du sagst die cpu macht 100% (was eigendlich kaum was aussagt)
> 
> was sagen denn:
> ...

 

Hallo Tim,

vielen Dank für deine Hilfe. die genauen TOP werte kann ich dir erst im laufe des nächsten Tages liefern. Um die downtime kurz zu halten, lass ich ihn nur selten bis zum consolenlogin durchbooten. 1e stunde 10 minuten sind doch etwas lang  :Wink: 

selbst wenn ich langsame oder defekte platten haben sollte, versteh ich nicht warum mein system mit den einen funktionierenden kernel normal schnell ist. selbst wenn der/die neuen kernel in einem fehlerhaften sektor sitzen würden, müsste man dann ja im laufenden betrieb auch probleme haben oder? hab ich bei dem einen funktionierenden kernel jedoch nicht.

den write cache hatte ich die ganzen jahre nie an, hab aber im zuge meiner kernel probleme auch einmal damit rumgespielt. das resultat war nun eben die eine degraded platte vom boot vorgang abwürgen. hab den write cache nun wieder draussen, und mein 3dm2 sagt mir eigentlich auch - alles ok.

```
Unit  UnitType  Status         %Cmpl  Stripe  Size(GB)  Cache  AVerify  IgnECC

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

u0    RAID-1    OK             -      -       186.31    OFF    -        -       

Port   Status           Unit   Size        Blocks        Serial

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

p0     OK               u0     186.31 GB   390721968     S088J10Y413625

p1     OK               u0     186.31 GB   390721968     S088J1RY500761

```

sind 2 lowcost samsung-ide platten zu je 200gb. tun ihre arbeit aber ganz gut. und falls mal eine eingeht, sind die 50€ für eine neue auch kein ding. scsi/sata performance benötige ich zu hause einfach nicht.

würdest du das problem eher hardwaremässig ansiedeln?

mir geht das einfach nicht aus dem kopf das der eine kernel schnurrt wie ein kätzchen und ALLE neu kompilierten diesen fehler machen  :Sad: 

----------

## peterpeterson

 *thrashed wrote:*   

> vielen Dank für deine Hilfe. die genauen TOP werte kann ich dir erst im laufe des nächsten Tages liefern. Um die downtime kurz zu halten, lass ich ihn nur selten bis zum consolenlogin durchbooten. 1e stunde 10 minuten sind doch etwas lang 

 

tja ich habe 2*250sata 24/7  :Smile:  da dauert das rebuilden rebilden gut 90min. 

in beiden dmesg stand drin, dass das array degraded war.... von daher dachte ich vielleicht hängts daran.

wenn das booten so lange dauert, dann drück doch "I" beim starten für interaktiv-irgenwas. und sag bei allem nein, dann kannst du auch ausschliessen, ob es an anderer software liegt.

 *thrashed wrote:*   

> selbst wenn ich langsame oder defekte platten haben sollte, versteh ich nicht warum mein system mit den einen funktionierenden kernel normal schnell ist. selbst wenn der/die neuen kernel in einem fehlerhaften sektor sitzen würden, müsste man dann ja im laufenden betrieb auch probleme haben oder? hab ich bei dem einen funktionierenden kernel jedoch nicht.
> 
> würdest du das problem eher hardwaremässig ansiedeln?
> 
> mir geht das einfach nicht aus dem kopf das der eine kernel schnurrt wie ein kätzchen und ALLE neu kompilierten diesen fehler machen 

 

defekte hardware verusrsacht immer interessante fehler.

.. lustige anekdote: hatte mal einen pc, der sehr instabil lief.... es war das diskettenlauferk, obwohl es funktionabel war....

daher würde ich bei einem so unklaren fehler immer versuchen dies auszuschliessen.

den samsung-hdd-test gibt es irgendwo hier:

http://www.samsung.com/us/consumer/type/type.do?group=computersperipherals&type=harddiskdrives

cu tim

----------

