gelegentlicher boot-fehler bei squeeze

[kupe]

moin,

folgendes phänomen tritt gelegentlich bei mir auch nach einer neuinstallation unter squeeze mit'm 2.6.32-5-kernel (also alles standard) auf:
normalerweise spricht debian in etwa beim start folgendes:

loading, please wait... usw...

dann bootet auch alles brav wie sich's gehört. soweit, sogut.
manchmal lautet die ausgabe wie folgt:

- (blink, blink, ca. 3-4 sekunden geht das so, normalerweise blinkt hier nichts)
[********] (in den klammern steht eine 7-8stellige zahl, vermutl. irgendein time-out (millesekunden? cpu-takte?))
loading, please wait... usw...

anschließend lädt alles wie gewohnt, wird schön runtergerattert, aber in dem moment des kurzen abschaltens des bildschirms/umschaltens in die gui startet sich der rechner komplett neu!
irgendjemand eine idee, was hier vorgeht bzw. machmal nicht vorgeht?

merci beaucoup.

[rendegast]

squeeze benutzt standardmäßig grub2, welcher den efifb verwendet.

Code: Alles auswählen

dmesg | grep fb 

/etc/default/grub -> /boot/grub/grub.cfg
GRUB_GFXMODE...= -> 'set gfxmode=...' (Anzeige des grub-Menüs)
GRUB_GFXPAYLOAD_LINUX=... -> 'set gfxpayload=...' (Anzeigemodus der virtuellen Konsolen, mittels efifb)
außerdem noch in der /boot/grub/video.lst:

Code: Alles auswählen

vbe
vga
video_bochs
video_cirrus

Hier könnte bis auf vga alles entfernt werden (+ 'update-grub'), sodaß nur vga-Modi für grub verfügbar wären.
Alternativ dem Kernel die Option 'noefi' mitgeben, was die Verwendung des efifb auch unterbindet,
jedoch auch Auswirkungen (aber keine bleibenden) für die Bootfähigkeit haben könnte.

aber in dem moment des kurzen abschaltens des bildschirms/umschaltens in die gui startet sich der rechner komplett neu!

Zur Gegenprobe den grub2 (grub-pc) mal durch den grub1 (grub-legacy) ersetzen.
Dann wird bei einer Kerneloption von zBsp. 'vga=0x305' in der menu.lst der vesafb (hier mit 1024x768) verwendet.
(Resp. bei 'vga=normal' wird gar kein Framebuffertreiber mehr verwendet)
Vielleicht kommt der Grafiktreiber damit besser zurecht?



Eventuell wird unter squeeze auch die Grafikhardware anders angesteuert.
Ich denke da an vielleicht mehr Stromverbrauch, sodaß das Netzteil vielleicht überlastet wird.
Könnte natürlich auch ein kernel- oder X-TreiberBug sein.

Beim Starten ohne X (einen Startlevel ohne X-Start erstellen, oder Booten in Startlevel 1) läuft das System weiter?
-> /var/log/Xorg...log vom Fehlstart posten.


->
Hardware?
Grafiktreiber? Evtl. manuell installierte fglrx oder nvidia?
Dahingehend modifizierte xorg.conf?




----------------------------------
Anmerkung,
der grub2 aus sid, derzeit 1.99-6, hat diesen Hang zum efifb scheinbar nicht mehr,
auch ohne Einschränkung(sversuche) wie obiger video.lst oder 'noefi' wird wieder der vesafb verwendet.
(Im changelog finde ich aber nichts dahingehend.)



EDIT, (Auch?) squeeze grub2 1.98+20100804-14 zeigt nicht (mehr?) das von mir beschriebene Verhalten:
so stark auf efifb zu beharren und vesafb nicht mehr zu ermöglichen.
Ein einfaches 'video=vesafb' und GRUB_GFXPAYLOAD_LINUX="", und vesafb wird verwendet.
(???)
Von meinen Aufzeichnungen vom März ist als Fehler aber geblieben
eine grüne Schrift von efifb im Modus GRUB_GFXPAYLOAD_LINUX=XxYx16.



------------------------------------
Dein Problem kann natürlich auch andere Ursachen / Zusammenhänge besitzen.

[kupe]

danke für die umfangreiche antwort...

-auf die idee mit dem wechseln auf grub legacy bin ich auch schon gekommen, dennoch tritt der fehler gelegentlich auf.

-ich verwende den fglrx-ati-treiber, aber nicht den aus synaptic, sondern den direkt von ati --> mobility radeon, xorg.conf ist auch der fglrx nach 'nem ~ $ aticonfig --initial eingetragen worden. läuft soweit wie geschmiert

-stromversorgung? na ja, ich verwende das os auf'm notebook mit vollem akku und angeschloßenem netzteil, schwer zu beurteilen, in wie weit da was reinfunkt.

-für mich sieht es irgendwie so aus, als wolle debian gleich zu beginn etwas laden, schafft's nicht --> blink-blink, vermuteter time-out, lädt dann den rest normal und vor dem umschalten in das gui erkennt es "hoppla, da fehlt ja was" und veranlasst deshalb einen sofortigen (sauberen) neustart der kiste.
zweimal hintereinander ist die auch nach exzessiven versuchen noch nicht aufgetreten...

-die xorg...log-datei ist dermaßen lang, daß ich sie hier lieber erst mal nicht komplett poste, vielleicht könntest du den bereich etwas eingrenzen?

[rendegast]

-ich verwende den fglrx-ati-treiber,

Dann wurde wohl auch der radeon-Treiber installiert.
Vielleicht wird auch das Kernel-Modul radeon geladen, und zusätzlich kernel-Modesetting (KMS) versucht
(Das kann solche "Blinks" machen, und mit dem fglrx kollidieren)
Lösung wäre einerseits das Modesetting zu deaktivieren:
'options radeon modeset=0' in zBsp. /etc/modprobe.d/zz_mein-radeon.conf (danach initrd neu erstellen)
oder
'radeon.modeset=0' der Kernel-Commandline hinzufügen.
Zusätzlich das Modul radeon blacklisten, was auch in der Datei in /etc/modprobe.d/ geschehen kann.

-die xorg...log-datei ist dermaßen lang,

-> nopaste, siehe forums-Wiki.

[kupe]

steh' grade deftig auf'm schlauch...
was meinst du genau mit "initrd neu erstellen" bzw. wie funktioniert dies?

[rendegast]

Code: Alles auswählen

update-initramfs -u -k all

Erfolgskontrolle 'ls -l /boot' sollte für alle initrd dann neue Zeiten ausgeben.

[kupe]

o.k., danke, alles klar, hab das jetze mal erfolgreich durchgeführt, ergebnis bleibt abzuwarten...
falls die methode funktioniert hat, vermerke ich das hier selbstverständlich, dürfte ein paar tage dauern, um dies festzustellen.
und falls nicht, dann schon mal auf ein neues...

[kupe]

hmm, grade eben ist dieser ####-fehler wieder aufgetreten...
hab' nochmal genauer hingesehen, die ausgabe lautete:

- (blink, blink (2-3 sekunden))
[********] not responding (wieder irgendeine zahl in den klammern, keine ahnung ob das eine adresse oder zeit oder was auch immer ist)
loading, please wait... usw...

ab dem "loading, please wait" (inklusive) wird alles ganz normal gebootet und angezeigt, erst beim abschalten/umschalten startet sich die mühle wieder neu...
mit dem grafiktreiber hat's also eher nichts zu tun, es muß irgendetwas sein, was sofort beim start hochgefahren wird und da eben manchmal keine rückmeldung liefert, dennoch aber derart existentiell wichtig ist, daß debian einen reboot veranlasst.
hab auch schon im bum mal nachgesehen, aber dort ist alles brav aktiviert, hab' seit der installation auch keine startprogramme oder ähnliches entfernt... doch das würde das gelegentliche auftreten aber auch kaum erklären.
etwaige andere ideen sind herzlich willkommen...

[rendegast]

Der grub(2) lädt am Anfang Module,
grub-shell: 'lsmod', zBsp. für Grafik und Dateisysteme.

Code: Alles auswählen

$ cat /boot/grub/grub.cfg | grep insmod
  insmod vbe
  insmod vga
  insmod video_bochs
  insmod video_cirrus
insmod part_msdos
insmod ext2
  insmod gfxterm
insmod part_msdos
insmod ext2
insmod gettext
        insmod part_msdos
        insmod ext2
        insmod part_msdos
        insmod ext2
...

Einige kommen da wohl aus dem grub-Startimage ab Sektor 1 der Platte
andere dann wohl auch aus dem /boot/grub/.

Vielleicht ist mit "not responding" auch die Festplatte gemeint.
Im Bios gibt es gelegentlich die Möglichkeit, einer Festplatte mehr Zeit zur Initialisierung zu geben.

Auch hat die grub-shell das Kommando 'sleep', das Du vielleicht trickreich in der grub.cfg einbauen kannst.

Eine testweise Parallelinstallation, selbes/anderes Betriebssystem?

[kupe]

na ja, parallel hab' ich noch win7 am rödeln, war halt auf'm laptop vorinstalliert, hat diesbezüglich (aber nur diesbezüglich!) noch keine mucken gemacht...
ich hatte vorher über lange zeit mint 10, anschließend kurz die mint debian edition installiert, bevor ich eben auf squeeze umgestiegen bin, und da gab's nie ein derartiges problem.
waren beide auch mit grub 2...
eine festplatten-initialisierungs-zeit-vergrößerung hab' ich im puristischen laptop-bios leider nirgendswo entdeckt.
an "trickreich" in die grub.cfg "einbauen" traue ich mich ehrlich gesagt so pi mal daumen nicht ran, da kann man wohl ganz schön viel unsinn produzieren...
ob mit "not responding" die festplatte gemeint ist?
hmm, den einwandfrei bootenden rest holt der rechner doch auch von derselbigen... oder mach' ich da grade 'nen denkfehler?
ah ja, die zahl in den klammern hat folgenden "aufbau": [*.******] not responding; also [ziffer, punkt, sechs ziffern]...

[rendegast]

na ja, parallel hab' ich noch win7 ... hat diesbezüglich (aber nur diesbezüglich!) noch keine mucken gemacht...

Dann geht es vom win-Bootloader->grub oder vom grub->win-Partition/-Bootloader?

ob mit "not responding" die festplatte gemeint ist?

hmm, den einwandfrei bootenden rest holt der rechner doch auch von derselbigen... oder mach' ich da grade 'nen denkfehler?

War nur eine Idee.

ah ja, die zahl in den klammern hat folgenden "aufbau": [*.******] not responding; also [ziffer, punkt, sechs ziffern]...

Sieht nach der Zeitangabe des Kernels aus.
Also ein Kernel-Problem?
Ließe sich vielleicht mit Kernel-Parametern was drehen,
ist aber ein weites Feld resp. schwierig ohne die Angabe, was da "not responding" ist.
Vielleicht hilft ein Zeitvergleich mit der dmesg-Ausgabe.



Vielleicht hilft auch ein Bios-Upgrade?
(Obwohl, wenn es bei win keine Probleme gibt, haben die Entwickler wenig Anlaß für Änderungen.)

-für mich sieht es irgendwie so aus, als wolle debian gleich zu beginn etwas laden, schafft's nicht --> blink-blink, vermuteter time-out, lädt dann den rest normal und vor dem umschalten in das gui erkennt es "hoppla, da fehlt ja was" und veranlasst deshalb einen sofortigen (sauberen) neustart der kiste.

es muß irgendetwas sein, was sofort beim start hochgefahren wird und da eben manchmal keine rückmeldung liefert, dennoch aber derart existentiell wichtig ist, daß debian einen rebbot veranlasst.

Wird da wirklich ein Reboot veranlaßt?
Also Bios-Anzeige (bei modernen Rechnern mittlerweile seeehr kurz), dann neue Anzeige des grub-Menüs?





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

Code: Alles auswählen

an "trickreich" in die grub.cfg "einbauen" traue ich mich ehrlich gesagt so pi mal daumen nicht ran, da kann man wohl ganz schön viel unsinn produzieren...

Die grub.cfg ist einem bash-Skript ja sehr ähnlich,
also der Reihe nach abgearbeiteten Anweisungen.
Die menuentry können zur Boot-Zeit in der grub-shell (mit command/path-completion!) modifiziert/korrigiert werden, zBsp. um bei ganz kruden Anweisungen wieder einen Systemstart zu ermöglichen.

Wenn Du Dir die grub.cfg auch mal ansiehst, gibt es dort zBsp. auch gefahrlose echo-Anweisungen.
Ein 'sleep' + Parameter kannst Du in der grub-shell ausprobieren,
und dann vor der Ladeanweisung für den Kernel einsetzen.
Nach einem 'update-grub' wäre der ursprüngliche Zustand wiederhergestellt.

Als Doku benutze ich nur die help-Funktion in der grub-shell
und die wiki-Doku von gnu.org.

[kupe]

rendegast, ich glaub', ich muß dir mal ein kühles helles für deine bemühungen spendieren!
zu deinen anmerkungen:

- ja, es wird tatsächlich ein reboot veranlasst, man hört auch, daß der bios-piepser kurz anzieht, dann wirklich sehr kurze bios-anzeige, anschließend erscheint ganz normal wieder der boot-loader, dann kann man squeeze wieder nach allen regeln der kunst booten...

-es geht mit mbr vom grub --> win-partition/bootloader.

-bios wurde schon upgegraded (komisches wort), keinerlei auswirkung...

-kernel problem? schwer zu sagen...
haargenau den gleichen kernel, als den standard 2.6.32-5er hab' ich auch wochenlang bei der mint-debian-edition benutzt (da ein upgrade auf den 2.6.38-2er oder -5er meinen grafiktreiber abgeschossen hat), ohne probleme, mit bspw. dem .35er hatte meine netzwerkkarte immer irgendwie probleme, nur mit dem .32er funktionierte bis jetzt sowohl unter mint als auch unter debian die komplette hardware einwandfrei...
ich hab' auch das firmware-non-free paket installiert, hat aber auch nix gebracht.

-so, das mit der sleep-funktion in grub.cfg hab' ich jetze mal ausprobiert (tolles wiki übrigens!), vor den kernel-ladebefehl gesetzt, hat auch soweit das laden tatsächlich verzögert, was da aber auch immer sein "not responding" ausspuckt, zeigte sich davon unbeindruckt, weshalb ich mit dem empfohlenen update-grub mal wieder den ausgangszustand hergestellt hab'.
soll heißen: die methode an sich hat funktioniert, aber nicht die erwünschte wirkung gehabt...

was mich halt auch wundert, ist die tatsache, daß dieses mysterium nicht jedesmal, sondern etwa alle 7-10 boots einmal vorkommt.
könnte das vielleicht auch an einem "ausgelutschten" hardwareteil (festplatte?) liegen?
der laptop samt innereien ist allerdings erst ein gutes jahr alt...

[rendegast]

was da aber auch immer sein "not responding" ausspuckt, zeigte sich davon unbeindruckt,

Mal alle "not responding" aus kernel 2.6.32.39

Code: Alles auswählen

grep -ri "not responding" linux-2.6.32.39/*

http://nopaste.debianforum.de/35630
(Darstellung 'FreeBasic' hebt die Meldungen gut hervor)

Das mit den CONFIG_....=y aus der /boot/config-.... verglichen führt zu den Teilen,
die sich im Kernel befinden
(denn Modul-Treiber, die ja erst aus der initrd kämen, sind wohl ausgeschlossen?)


Mal ein Eingrenzungsversuch mit den reinen "not responding":

Code: Alles auswählen

arch/x86/kernel/smpboot.c:                              printk(KERN_ERR "Not responding.\n");
arch/m32r/kernel/smpboot.c:                     printk("Not responding.\n");
drivers/scsi/sd.c:                      printk("not responding...\n");
drivers/net/3c505.c:            pr_cont("not responding to second PCB\n");
drivers/ide/cmd640.c:                   port2 = "not responding";

net fällt heraus.
cmd640 ist im debian 2.6.32 / 2.6.39 nur als pata_cmd64x enthalten,
also auch erst aus der initrd.


Du hast von "not responding" und nicht "Not responding" geschrieben,
dann würde smpboot herausfallen. Schade, wäre ein schöner Verdächtiger.

sd.c, erst / nur in den Modulen scsi_mod und sd_mod verbaut?
-> Doch die Platte? Wird darauf nicht erst später zugegriffen?

Vielleicht ist "not responding" aber durch den Abbruch auch nur eine unvollständige Meldung?



Hier als Beispiel das dmesg (m)eines kernels bis zum Laden der initrd:
http://nopaste.debianforum.de/35633
Verbunden mit dem time-Code könnten verdächtige Treiber/Hardware vielleicht so eingegrenzt werden.

könnte das vielleicht auch an einem "ausgelutschten" hardwareteil (festplatte?) liegen?
der laptop samt innereien ist allerdings erst ein gutes jahr alt...

Solange das Win oder ein alternativer kernel wie zBsp. der 2.6.39 aus sid, oder eine andere Distribution nicht so reagieren,
sind eher der kernel resp. dessen default-Parameter schuld.

Die Suche zur Behebung ist leider müßig, es sieht aus, als ob nur ein Glückstreffer weiterhelfen würde.

Einfacher, eine andere, problemlose Distribution / Kernel zu benutzen?




-------------------
Nebenbei, mit dem debian 2.6.38 hatte ich auch Probleme, bei mir mit qemu / kvm.

[kupe]

puhpuhpuh... also:

-andere distribution? sehr ungern... ansonsten bin ich hier nämlich vollauf zufrieden; und zu mint und ubuntu zieht's mich schon gar nicht mehr zurück.
anderer kernel? tja, nur welcher? die bereits erwähnten will ich aus genannten gründen eigentlich nicht nochmal draufspielen... zumal ich ehrlicherweise zugeben muss, daß ich damals die kernel-umstellungen nicht manuell vorgenommen habe, sondern diese durch solche scherze wie

Code: Alles auswählen

full-upgrade

oder

Code: Alles auswählen

dist-upgrade

entstanden sind. jeder fängt mal klein an...

-ja, "not" wird tatsächlich kleingeschrieben, leider, den smpboot hatte ich auch schon im verdacht.
ob diese fehlermeldung vollständig ist, kann ich nicht beurteilen, weil anschließend ja die ganz normlen zeilen heruntergerattert werden...

sd.c, erst / nur in den Modulen scsi_mod und sd_mod verbaut?
-> Doch die Platte? Wird darauf nicht erst später zugegriffen?

-tut mir leid, damit kann ich so leider nichts anfangen, da hab' ich einfach zu viel zu wenig ahnung von der materie, wie finde ich so etwas heraus?

aber du hast recht, das scheint irgendwie eine sehr zähe suche zu werden und für mein glück bin ich auch nicht grade weltberühmt...

[rendegast]

Es gibt ja noch die debug-kernel:
http://packages.debian.org/linux-image-2.6.32-5 ->
Paket linux-image-2.6.32-5-686-bigmem-dbg
Paket linux-image-2.6.32-5-amd64-dbg
Wie die allerdings eingesetzt werden? gnu-debugger o.ä.?

sd.c, erst / nur in den Modulen scsi_mod und sd_mod verbaut?
-> Doch die Platte? Wird darauf nicht erst später zugegriffen?

-tut mir leid, damit kann ich so leider nichts anfangen, da hab' ich einfach zu viel zu wenig ahnung von der materie, wie finde ich so etwas heraus?

War nur so in den Raum gestellt,
sollte sich jemand mit mehr kernel/modul-Erfahrung zu äußern.





magic-keys bringen nur etwas wenn der kernel stehenbleibt,
nicht wenn er einfach rebootet?
http://www.stonki.de/computer/linux-magic-keys/
http://en.wikipedia.org/wiki/Magic_SysRq_key






Und nochmal zum Reboot: Dieser findet erst beim Umschalten auf den Xserver statt
(normalerweise der letzte Start eines Dienstes),
nicht (direkt) nach dem "not responding", also in einem frühen Status?
(Weil Du mehrmals gesagt hast, daß nach der responding-Meldung die kernel-Meldungen weiterlaufen)

Es wäre bei Verzicht auf den grafischen Desktop dann möglich ,
dmesg abzuspeichern und dadurch mit einem korrekten Durchlauf zu vergleichen.

[kupe]

stop, kommando zurück, "Not responding" wird tatsächlich mit großem "N" geschrieben.. ich hätte schwören können, daß es klein war, aber wie auch immer, mein fehler, ich nehm' an das kostet ein fäßchen (oder auch zwei)...
tut mir echt leid, aber der text rattert dermaßen schnell herunter, hab's jetzt bloß auch richtig gesehen, weil's kurzzeitig mal gestockt hat(?).
also ist doch der smpboot staatsfeind nummer eins?!
wär' klasse, wenn du mir da noch ein bisschen weiterhelfen könntest, anscheinend hast du ja für diesen fall schon sowas wie 'ne idee parat gehabt, und nur so per tante google usw. ist mir die sache ein wenig zu haarig...
ach ja, die sache mit dem reboot hast du vollkommen richtig interpretiert, genau so isses, reboot nach dem x-server-start.

[matthiasklein]

Du könntest Dir aber auch einfach den aktuellsten Stable-Kernel 2.6.39.1 von http://www.kernel.org selbst kompilieren:

- falls nicht vorhanden, folgende Pakete installieren: fakeroot bzip2 kernel-package libncurses-dev build-essential
- Kernel entpacken:
- $ tar -xvjf linux-2.6.39.1.tar.bz2
- in das Kernelverzeichnis wechseln
- $ cd linux-2.6.39.1
- $ make clean
- $ make mrproper
- Konfiguaration des aktuell laufenden Kernels kopieren
- $ cp –v /boot/config-2.6.32.5-686 ./.config
- $ make silentoldconfig
=> alle Fragen mit ENTER beantworten (Standard Antwort)
- $ fakeroot make -j4 deb-pkg
=> bei der Option -j Anzahl CPU Kerne mal 2 (bei 2 Kernen => 4)

- Kernel-Paket installieren (als root)
- $ dpkg ../linux-firmware-image_2.6.39.1-1_i386.deb
- $ dpkg ../linux-image-2.6.39.1_2.6.39.1-1_i386.deb


Du kannst Dir aber auch eine von mir nach o.g. Anleitung kompilierte Version herunterladen:
http://www.fileuploadx.de/796997
http://www.fileuploadx.de/847194


Gruß,

Matthias

[kupe]

abend,

tja, danke für die anleitung...
ich hab's faulerweise zuerst mit deinen vorkompilierten paketen versucht, dpkg machte faxen, gdebi-paketinstaller brachte dann auch die lösung: falsche architektur, ich hab'n amd64...
dann hab ich's eben mit deiner anleitung probiert:

-downloaden konnte ich den 39.1er problemlos, alle pakete hab' ich auch installiert; von libncurses-dev fand' ich synaptic allerdings nur ein libncurses5-dev, ich hoffe mal, daß dies keinen existentiellen unterschied macht... oder doch?

-entpacken bekam auch auf die reihe

-verzeichniswechsel, make clean und make mproper funktionierten auch

-beim kopieren gab's irgendwie schon probleme, was ist denn das genau für ein strich vor dem v? ein doppelter spiegelstrich? sehen eigentlich so aus: --? oder wieso ist der so lang? terminal kam gar nicht klar damit...
wie auch immer, hab' die datei (bei mir eben config-2.6.32-5-amd64) halt dann graphisch in /.config reinkopiert, das ging also noch.

-dann kam aber folgendes

Code: Alles auswählen

~$ make silentoldconfig
make: *** Keine Regel, um »silentoldconfig« zu erstellen.  Schluss.

sonderbar, ich kann mir ehrlich gesagt keinen reim drauf machen...

[matthiasklein]

Ich hatte gar nicht daran gedacht, dass Du eine andere Archtektur haben könntest ...

Bei dem cp Kommando soll es ein ganz normaler Bindestrich/Minus sein. (-v für verbose)
Du musst die entsprechende Konfigurationsdatei in das Kernelverzeichnis unter dem Namen .config kopieren.

Das "make silentoldconfig" Kommando musst Du im Kernelverzeichnis ausführen.
Von der Fehlermeldung her sieht es so aus, als wenn Du Dich nicht im richtigen Verzeichnis befindest.

Gruß,

Matthias

[matthiasklein]

Der Pfad für die Konfigurationsdatei lautet nicht "/.config" sondern "./.config". (Also im root-Verzeichnis der Kernel-Quellcodes)
Oder war das nur ein Tippfehler in dem Posting ?

[kupe]

war sowohl'n tippfehler als auch sehr sonderbar formuliert, sorry...
kannst du mir bitte noch den genauen wortlaut des cd-ins-kernelverzeichnis-befehls sagen, irgendwie krieg ich's grade gar nicht mehr gebacken....

[matthiasklein]

Das Kommando müsste "cd linux-2.6.39.1" lauten. (Anhängig davon wo genau Du den Quellcode hin entpackt hasst ...)

[rendegast]

also ist doch der smpboot staatsfeind nummer eins?!

Da wäre in http://www.kernel.org/doc/Documentation ... meters.txt
erstmal alles zu "apic" und "smp", für den Anfang vielleicht
'apic=debug show_lapic=all'
(ist die Datei des aktuellen kernel.org-Kernels, also nicht alle Optionen für zBsp. den debian 2.6.32)

http://git.kernel.org/?p=linux/kernel/g ... xt;hb=HEAD,
für andere Kernel den Link entsprechend ändern.



Das angesprochene Abschalten des X am Beispiel des gdm:

Code: Alles auswählen

# find /etc/rc* -name *gdm | sort
/etc/rc0.d/K01gdm
/etc/rc1.d/K01gdm
/etc/rc2.d/S03gdm
/etc/rc3.d/S03gdm
/etc/rc4.d/S03gdm
/etc/rc5.d/S03gdm
/etc/rc6.d/K01gdm

# /usr/sbin/update-rc.d gdm disable 2 3 4 ; insserv               # Mindestens 2 Stück müssen angegeben werden (kleiner Bug?)
...

# find /etc/rc* -name *gdm | sort
/etc/rc0.d/K01gdm
/etc/rc1.d/K01gdm
/etc/rc2.d/K01gdm
/etc/rc3.d/K01gdm
/etc/rc4.d/K01gdm
/etc/rc5.d/S03gdm
/etc/rc6.d/K01gdm

Die Wiederherstellung des Normalzustandes

Code: Alles auswählen

/usr/sbin/update-rc.d gdm enable ; insserv

(Ich halte runlevel2 ziemlich dienstlos, als eine Art multiuser-runlevel1,
runlevel3 als "Normal" ohne X (alte suse-Angewohnheit),
runlevel4 als mal-so, mal-so.
Weitere Runlevel habe ich mal versuchsweise definiert, war aber zuviel Aufwand.
Auch die Tools sind nicht darauf ausgerichtet.)





Den sid 2.6.39 kannst Du momentan recht gefahrlos benutzen, es braucht noch die sid initramfs-tools.
Jedoch könnte dieser mit der nächsten Version schon ein höheres udev als in squeeze fordern,
dann wird es komplizierter.

[kupe]

so:
hab' jetzt den 39er kernel tatsächlich voll und ganz installiert bekommen, aber:
dasselbe fglrx-treiber problem wie beim 38er, sinngemäß sagt debian folgendes:

Code: Alles auswählen

dkms-part of installation failed

genau das gleiche passierte auch beim 38er, irgendwie zwickt dkms das ab einer gewissen kernel-version?!
daß ich beim kernel-basteln keinen murks gemacht habe, beweist die tatsache, daß debian mit dem 39er und 'nem radeon (anstatt fglrx, per live-system die xorg.conf umgeschrieben) einwandfrei läuft.
den radeon kann ich leider aber nicht verwenden, da dabei meine graka enorm überhitzt, mit fglrx bleibt sie dagegen eiskalt...
doch es gibt auch frohe kunde:
der eigentliche fehler scheint tatsächlich verschwunden zu sein!

jetzt hätte ich eigentlich nur noch eine frage: weiß jemand, bis zu welcher kernel-version diese dkms probleme noch nicht auftreten?
ich meine mich erinnern zu können, daß mint 10 standardmäßig mit irgeneinem 35er lief, da ging fglrx noch, aber sicher bin ich mir auch nicht mehr.
hätte eine longterm-variante ggü. der stable variante irgenwelche vorteile?
irgendwelche erfahrungen bzgl. des 34.9er oder 35.13er von kernel.org?
weil so auf teufel komm raus ein dutzend kernel zu installieren dürfte wohl nicht sehr zielführend seinn...

[rendegast]

Nachsehen in
'cat /var/lib/dkms/fglrx/......../make.log'


Könnte das nicht am vom fglrx-Installer erstellten dkms-Paket liegen?

Wenn die header noch nicht installiert waren (linux-vanilla-kernel oder der sid-2.6.39?),
bricht die Modulkompilierung ja ab.
Der Fehler sollte jedoch abgefangen werden,
jedenfalls bei mir gerade beim Upgrade auf den sid 2.6.39-2.

Du kannst den dkms-Prozeß ja mal mit '--verbose' händisch durchführen.
(falls das dkms-Modulpaket trotz des Fehlers ganz installiert wurde

Code: Alles auswählen

dpkg -l | egrep "fglrx|dkms"

)




Vielleicht ein systematischer Fehler?
Das fglrx-modules-dkms 10-9-3 aus squeeze baut auf meinem 32bit-squeeze nicht für die *-amd64 oder die 2.6.39-*.
Du benutzt den ati-driver-installer-11-5-x86.x86_64.run ?