Wenn die Box bei "Loading Kernel" stehen bleibt ..

[frank_m24]

Hallo,

!Vorsicht! Langer Beitrag!

ich habe schon fleißig gesucht, ob andere User möglicherweise ähnliche Probleme haben wie ich, und nie eine exakte Lösung gefunden. Deshalb habe ich mich mal ein wenig damit beschäftigt.

FYI: Ich habe eine Sagem 1xI Box.

Das Problem: Man erstellt selbst ein Image, z.B mit den Yadi Scripten, flasht es und die Box bleibt bei "loading kernel" im Display hängen. Das Comport Log geht genau bis "freeing unused Kernel memory: 200k" oder so, also der Kernel wird geladen, aber init läuft nicht los, es gibt aber auch kein Panic bzgl. nicht vorhandener Root Partition.
Checkimage erzählt nichts von bad magics, und eigentlich gibs keine Erklärung dafür.

Ich habe mal mehr oder weniger täglich mit dem aktuellen Yadi Script DBox Images erstellt, und zwar auf drei (vier?) verschiedenen Rechnern:
- Ein Dell P4 3200 HT
- VMWare auf diesem Dell P4
- Ein Dell Latitude Notebook mit Pentium M 1.7 GHz
- Ein alter PIII mit 800 MHz (den habe ich morgans angeschmissen, damit die Images abends fertig waren ...
=> Stress für mein Flash ...

Alle diese Rechner waren mit SuSE 9.3, aktuelle Patches etc ausgerüstet, so dass von identischer Entwicklungsumgebung ausgegangen werden kann. mksquashfs und mkfs.jffs2 sind auf Yadi Stand (sprich von da heruntergelanden).

Jetzt das erstaunliche: Alle Images, die mit dem P4 3200 native Linux erstellt wurden, zeigen dieses Problem (squashfs UND jffs2). Die anderen drei Konfigurationen (auch die VMWare auf dem selben Rechner) funktionieren hingegen problemlos.

YADI erstellt immer mehrere Images, JFFS2 only, Sqaushfs, 1x, 2x ... Bei einigen dieser Images zeigte checkimage zuweilen bad magics, meistens nur die 2x Images, die ich nicht nutze.
Ich habe dann mal die Yadi Scripte ein wenig verändert, so dass meine ucodes und Settings direkt beim Erstellungsprozess in das Image übernommen werden. Das hat zuverlässig gegen die bad magics geholfen, aber die P4 Images booten immer noch nicht. Alle anderen nach wie vor problemlos.

Jetzt meine Fragen:
- Was ist beim P4 anders als bei den anderen Konfigurationen?
- Ist es Hyperthreading, also ist das CDK (oder Yadi) vielleicht nicht SMP tauglich?
- ist jemand hier, der Images problemlos auf HT Maschienen (oder gar auf Dual Core oder SMP) erstellen kann?

Ich werde in Kürze mal HT deaktivieren und es dann noch mal probieren, vielleicht ergibt sich da was. Oder hat jemand eine andere zuverlässige Erklärung dafür?

Viele Grüße

Frank

[frank_m24]

Hallo,

wie der Titel schon besagt, hilft das Deaktivieren von HT auch nicht gegen die Probleme.
Ich werden die Sache weiter untersuchen und mich melden, wenn ich was heraus finde.

BTW: Ich habe mal testweise ein Image geflasht, welches von checkimage abgelehnt wurde ("Bad Magic"), und es lief problemlos

Viele Grüße

Frank

[kamikazemike]

hi
hier P4 2800 HT mit suse 9.2 absolut kein problem.
dbox und dreambox, funktioniert einwandfrei.
allerdings kann ich nichts zu den yadi-scripts sagen, die nutze ich nicht.
aber wenn die scripts auf den anderen rechnern funktionieren, liegt der
fehler ja wo anders.
evtl. hast du ja doch einen fehler im cvs gemacht... u-boot, kernel...

cu

[dietmarw]

...Ich habe mal testweise ein Image geflasht, welches von checkimage abgelehnt wurde ("Bad Magic"), und es lief problemlos
...

welches war denn das?
jffs2only laufen scheinbar auch bei negativaussage

[Zaphod Beeblebrox]

[...] - ist jemand hier, der Images problemlos auf HT Maschienen (oder gar auf Dual Core oder SMP) erstellen kann? [...]

Ich habe ein ganz ähnliches Problem auf einem 2-way SMP-System mit Gentoo Linux. (mksquashfs v2.1, mkjffs2 v1.45)

Das Image lässt sich scheinbar problemlos erzeugen und checkimage meldet auch keine "bad magic bytes", aber die Box bleibt an der beschriebenen Stelle hängen.

[Houdini]

ist das nur bei images so oder auch bei per NFS gebooteten systemen?

[Zaphod Beeblebrox]

Der Kernel bootet auch per NFS nicht. Am Image liegt es also nicht. Leider kann ich die Debugausgaben heute nicht mehr sehen/posten. Mir fehlt eine serielle Schnittstelle an diesem Laptop...

Eventuell kann ich zumindest dieses Problem bis morgen lösen und dann ein paar mehr Details liefern.

[Zaphod Beeblebrox]

Ich habe einen ganz bösen Fehler gemacht. Die Debugausgaben haben's mir verraten...

Dummerweise habe ich 2 Benutzeroberflächen eingebaut (neutrino & lcars) und kein lcdmenue. Das Startskript hat nun versucht enigma zu starten, was ich nicht im Image hatte. Deswegen blieb die Box einfach an der Konsole (welche ich ohne die serielle Verbindung nicht sehen konnte) stehen.

Das Problem war also hausgemacht und ist jetzt behoben.

[frank_m24]

Hallo,

@dietmarw: Ja, die JFFS2onlys laufen (teilweise?) auch mit "bad magic bytes".

@Houdini: Ich habe NFS Booten irgendwie noch nie richtig zum laufen bekommen. Ich werde das mal in Angriff nehmen, wenn ich mal wieder ein Stündchen Zeit habe.

@kamikazemike: Daran habe ich auch schon gedacht, vor allem, weil es hier im Forum einen Hinweis gibt, das mit einer geänderten u-boot 1.1.2 genau dieses Problem behoben worden sein soll. Aber ich habe absichtlich mal exakt identische CVS Stände mit den Yadi Scripten auf verschiedenen Systemem kompiliert, einige liefen, andere nicht. Die Yadi Scripte sorgen (denke ich) für das entsprechende Patchen der Sourcen für die Partitionierung etc.

Meine Images sind immer Neutrino only, deshalb kann ich das Problem von Zaphod Beeblebrox ausschließen (glaube ich). Das System kommt ja auch gar nicht bis zum Starten der GUI, sondern bleibt schon vor init stehen.

Viele Grüße

Frank

[frank_m24]

Hallo,

es wird immer seltsamer. Ich habe dem fraglichen Dell P4, der unter SuSE 9.3 immer nicht funktionierende Images erzeugte, eine Gentoo Installation gegönnt. Und siehe da: Die Images laufen problemlos. Es scheint also eine Kombination aus SuSE 9.3 und der Rechnerhardware zu sein, die das Problem hervorruft. Tauscht man eine der Komponenten aus, so geht es.

BTW: Nettes Konzept, das mit dem Gentoo (hatte ich bislang keine Erfahrung mit). Irgendwie clever, alles vom Source hochoptimiert für das Zielsystem zu kompilieren und einzurichten. Woher kenne ich das doch gleich?

MfG

Frank

[StevenSch]

Ich bin ja inzwischen der Meinung das es an einem Teil der Suse9.3-Distribution liegt, denn ich habe das gleiche Problem.
Ohne das ich mein Script seit Juli verändert habe, bekomme ich entweder ein Image mit dem ergebnis "Kein System" oder der Bootvorgang bleibt bei "Loading Kernel" hängen. ja nachdem welche dbox2.flash.c ich verwende (meine eigene die immer lief oder eine "geborgte" zum testen). Ich bau übrigens jffs images.

[wittinobi]

huhu,
hatte die selben probs.
schonmal andere mklibs verwendet ?
hab da noch was in erinnerung, das seit der umstellung auf glibc2.3.2 nicht mehr alle mklibs funzen.

mfg
wittinobi

[Pfingstler82]

Also, ich hatte das Problem auch gestern.

Ich hatte meine DBOX in den DEBUG-Modus gebracht und Neutrino aufgespielt. Jetzt wollte ich den Schalter wieder ablöten und hab eine hauchdünne Brücke auf dem Flash gehabt. Die Box zeigte kein "YADI-Logo" an und es stand nur "Booting kernel". Auch YADD ging nicht!! Nachdem ich die Brücke gefunden habe und vorsichtig vom Flash entfernt hatte lief alles wieder. Was ich damit sagen wolte: Es könnte auch ein hardwarefehler sein!

MfG

[wolgade]

Um nochmal auf Hypertreading und Suse zurückzukommen:

Da ich mein CDK auch nicht gebootet bekommen habe, habe ich mal den gleichen CVS-Stand auf einem anderen Rechner kompiliert und siehe da, es ging.

Konkret: Wenn ich auf meinem Hauptrechner P4 2,8 GHz, Suse 10.0 kompiliere, bleibt die Box bei "loading kernel" hängen, der gleiche CVS-Stand auf einem AMD Duron 600 MHz mit Suse 9.0 kompiliert, bootet problemlos.

Wenn es nicht am Hyperthreading liegt, dann ist irgendwas bei Suse 10.0 anders als bei Suse 9.0.

Weiß da jemand genaueres?

[wolgade]

Auf die Gefahr hin, Selbstgespräche zu führen:

Ich hab jetzt auf dem P4 mal zusätzlich Suse 9.2 und 9.3 installiert, CDK kompiliert und siehe da: Es lief.

Hyperthreading scheidet also aus. Ich vermute das Problem bei Suse 10.0. Diese Distribution verwendet gcc 4.0.2 prerelease. Mein Freund Google meint, damit hätten diverse Leute Probleme.