[gelöst]Debian Wheezy hängt direkt nach dem Grub2

[hias]

Hallo,

jetzt bin ich mit meiner zweiten Wheezy Installation auf meinem Dell-Desktop schon wieder am Ende. Der Rechner hängt sich unmittelbar nach Grub mit blinkendem Cursur links oben auf, bevor bei einem funktionierenden Boot loading initial ramdisk käme.

Bei einem Versuch, den Rechner im Recovery Modus zu starten, waren die letzten Zeilen diese (abgetippt vom Bildschirm):

Code: Alles auswählen

[  0.145980] PCI: MMCONFIG at [mem 0x0000000-0xefffffff] reserved in E820
[  0.145980] PCI: Using MMCONFIG for extended config space
[  0.145980] PCI: Using configuration type 1 for base access
[  0.145980] bio: create slab <bio-0> at 0

Das Problem kommt schleichend. Nach einer frischen Installation besteht es noch nicht. Es tritt erstmals nach der Installation der Kernel Header für den proprietären NVidia-Treiber auf. Erst vereinzelt dann regelmäßig. Anfangs kann ich noch ins System, wenn ich im Grub-Menü mit e in den Editiermodus für den entsprechenden Eintrag gehe und dann mit F10 starte, mittlerweile geht auch das nicht mehr, so dass Wheezy nicht mehr startet.

Im Moment ist Wheezy neben Xubuntu installiert und ich nutze den Xubuntu Grub für beide (hab ich Debian keinen Grub installiert). Ich habe aber auch schon Wheezy allein installiert gehabt und dessen Grub in der MBR installiert, gleiches Problem. Ubuntu hat dieses Problem übrigens nicht, so dass ich auf diesem Rechner mehr oder weniger Zwangs-Ubuntu habe...
Was macht Ubuntu in einem so frühen Zeitpunkt des Bootvorgangs anders als Debian Wheezy ?

Unter Squeeze hab ich ein ähnliches, aber weniger schwerwiegendes Problem bei Reboots gehabt, siehe hier: http://debianforum.de/forum/viewtopic.php?f=13&t=123806

Hat jemand ein vergleichbares Problem oder irgendeine Idee ? Gibt es ein Log, das zu einem so frühen Zeitpunkt schon Informationen enthält.
Meine /boot/grub/grub.cfg hänge ich mal an. 35864

Über Vorschläge würde ich mich sehr freuen.

Gruß Hias

Edit: Mit acpi=off bootet der Wheezy, der Rechner ist dann aber unbenutzbar langsam.

[rendegast]

Bei sowas

loading initial ramdisk

ist der kernel ja schon eingelesen, die Festplatte also gestartet,
aber existiert vielleicht eine Einstellung zur Festplatte im BIOS,
um eine kurze Initialisierungs-Pause einzubauen?
Sowas wie "Wait for disk to come up 1s/2s/3s/..."?

memtest? auch mal mit vertauschten Riegeln durchgeführt?

Die Festplatte ist am Ort des Kernels / initrd ohne badblocks?
Hinweise aus 'smartctl -a /dev/sdX'?


http://support.dell.com/support/DPP/Ind ... DSKTP_D530
"View All"
Mehrere recommended oder urgent firmware-Upgrade für Festplatten (WD/Samsung/Seagate).
Zwei recommended bios-upgrades

Bios (2)
File Title(s) Importance Release Date Version Download & Options FileSizeBytes Description Size DeviceID VersionCount LibraryID FileID Is this in my List? ReleaseId Title FTP Url Format Url NumberOfFormats IsSecure
Dell - BIOS
Applies to:
Inspiron Desktop 530 System BIOS
Recommended 3/11/2009 1.0.18
Download
Add To Download List
741376 724 KB 14390 9 1 299050 0 R212148 Dell - BIOS
http://support.dell.com/support/downloa ... ormat=true

Dell - BIOS
Applies to:
Inspiron Desktop 530b/530Sb System BIOS
Recommended 2/16/2009 1.0.2
Download
Add To Download List
643072 628 KB 19521 1 1 292005 0 R208322 Dell - BIOS
http://support.dell.com/support/downloa ... ormat=true

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

Unter Squeeze hab ich ein ähnliches, aber weniger schwerwiegendes Problem bei Reboots gehabt,

Der letzte Post dort vom Januar 2011, gab es später noch eine Lösung?

[hias]

Hallo rendegast,

vielen Dank für Deine Antwort.

Dabei merke ich, dass ich das Problem unzutreffend beschrieben habe. Wenn der Rechner hängen bleibt, erscheint gerade kein

Code: Alles auswählen

loading initial ramdisk

, so dass wohl der Kernel nicht eingelesen wird.

Sollte Wheezy doch mal wieder starten, installiere ich mal testweise den Liquorix-Kernel, denn - wie gesagt - unter Ubuntu gibt es das Problem nicht.

Danke auch für die Dell-Links, für meinen Dell 530 war aber nur ein BIOS-Update dabei. Schön ist dabei schon mal, dass man die Datei von der Dell-Website nur mit dem Internet Explorer runterlagen kann - ich glaub ich spinn, wir haben doch nicht 2003 ???
Die Installation ohne Windows ist allerdings nicht trivial, da lass ich besser die Finger davon.

Memtest sollte passen, ich hab nur einen Riegel. Die Ergebnisse von smartctl -a /dev/sda2 (da ist Wheezy installiert) von Ubuntu ausgeführt (Wheezy startet ja nicht mehr) hänge ich an. 35870. Für mich böhmische Dörfer, von errors oder so steht aber nichts drin.

Gruß Hias

[hias]

Letzte Meldung vor dem Schlafengehen...

Der Liquorix-Kernel bringt für dieses Problem nichts . Dafür ist Wheezy heut zweimal mit dem Trick hochgekommen, ins Editiermenü zu gehen und dann mit F10 zu starten. Trotzdem sehr unbefriedigend - und Xubuntu hat dieses Problem (gottseidank) nicht. Was machen die anders ?

Gruß Hias

[rendegast]

Schön ist dabei schon mal, dass man die Datei von der Dell-Website nur mit dem Internet Explorer runterlagen kann

Stimmt nicht, im aufpoppenden Fenster ist auch eine Abfrage nach "Herunterladen mit einem Internet Browser".

Die Installation ohne Windows ist allerdings nicht trivial, da lass ich besser die Finger davon.

Die entpackenden EXE sind wohl Hybride,
unter Windows flasht eine Kombo winflash.exe/winflash.sys das *.bin,

Code: Alles auswählen

"C:\DOKUME~1\user\Lokale Einstellungen\Temp\_749F.tmp\WinFlash.exe" C:\DOKUME~1\user\Lokale Einstellungen\Temp\_749F.tmp\713D1P53.BIN /id:$FB$B1$1.0.18$D1$SEPANG$020D /wb /fb /ft /r

unter DOS arbeitet es wohl selbst als flash-Programm.
freedos des grml reicht für den Zweck (kürzlich bei einem anderen DELL).

Und die Anleitung:

Code: Alles auswählen

Run the BIOS update utility from Windows environment

   1. Double click the Icon on your desktop labeled 530_1018.EXE.
      The Update BIOS window appears
   2. Click the Update button.
      The message Updating BIOS. Please DO NOT POWER OFF! appears. BIOS update will begin.
   3. After BIOS update complete, the WinFlash window appears to tell you "Update successful". Click Yes button. The system will restart and the BIOS Flash will be completed.



Run the BIOS update utility from DOS or DRMK environment (Non-Windows users)

NOTE: You will need to provide a bootable DOS or DRMK USB Memory Key. This executable file does not create the DOS or DRMK system files.

   1. Copy the file 530_1018.EXE to a bootable USB Memory Key.
   2. Boot from the USB Memory Key to the DOS or DRMK prompt.
   3. Run the file by typing Y:\530_1018.EXE (where y is the drive letter where the executable is located).

Aber ich glaube eigentlich auch nicht, daß es daran liegt.
aber das

Das Problem kommt schleichend. Nach einer frischen Installation besteht es noch nicht.
Es tritt erstmals nach der Installation der Kernel Header für den proprietären NVidia-Treiber auf.
Erst vereinzelt dann regelmäßig.

klingt total mystisch,
zudem der nvidia-Installer nur das nvidia.ko Modul gegen den Kernel linkt und in das Modulverzeichnis kopiert.
Mit dem Bootvorgang des kernel und grub hat das nichts zu tun.

Anfangs kann ich noch ins System,
wenn ich im Grub-Menü mit e in den Editiermodus für den entsprechenden Eintrag gehe und dann mit F10 starte

Das muß ich mir nochmal ansehen.

Wenn grub 1.98 das Problem sein sollte,
der kann recht gefahrlos gegen den 1.99 aus testing/sid getauscht werden.

Es könnte auch grub IN der boot-Partition versucht werden
(extfs bevorzugt, ohne "Spezialitäten" wie gpt oder lvm auch der grub-legacy),
per chainload von einem beliebigen MBR-Bootcode wie zBsp. GAG oder ein sonstiger Bootloader.

[hias]

Hallo Rendegast,

danke für Deine Bemühungen.

Stimmt nicht, im aufpoppenden Fenster ist auch eine Abfrage nach "Herunterladen mit einem Internet Browser".

Da hast Du natürlich recht, nur kommt dann zumindest bei mir im Firefox/Iceweasel eine Fehlermeldung. Aber egal, ich hab ein Windows in der VM.

Ansonsten tue ich mich leider etwas schwer, Deinen Ratschlägen zu folgen, zwischen unseren Computerkenntnissen liegen Welten .

freedos des grml reicht für den Zweck (kürzlich bei einem anderen DELL).

Ich weiß grad mal, was grml ist, mit freedos hab ich noch nie gearbeitet.

Die von Dir verlinkte Anleitung habe ich vorher auch gelesen und nicht wirklich gewusst, was ich hätte tun sollen. Aber gut, falls ich wirklich ein BIOS-Update machen will, werde ich grml und dessen freedos schon irgendwie nutzen können.

zudem der nvidia-Installer nur das nvidia.ko Modul gegen den Kernel linkt und in das Modulverzeichnis kopiert.
Mit dem Bootvorgang des kernel und grub hat das nichts zu tun.

Das macht das Ganze noch "mystischer" (gute Beschreibung), es ist völliger Zufall, ob es mit dem Workaround durch das Grub-Editiermenü geht oder nicht. Das heißt kompletter Zufall ist es nicht, nach mehreren Reboots/Hardresets wegen Hängern geht es meist gar nicht mehr, da hat man dann erst am nächsten Tag wieder ein Chance.

Die Grub-Version schließe ich als Ursache eigentlich aus. Ich hab im Juni schonmal Wheezy (allein) installiert, da war bereits Grub 1.99 dabei - gleiches Fehlerbild. Hab mich damals dann eben mit Xubuntu beholfen. Das benutzt aber auch Grub 1.99~rc1-13ubuntu3.

Es könnte auch grub IN der boot-Partition versucht werden
(extfs bevorzugt, ohne "Spezialitäten" wie gpt oder lvm auch der grub-legacy),
per chainload von einem beliebigen MBR-Bootcode wie zBsp. GAG oder ein sonstiger Bootloader.

Meinst Du damit, ich soll versuchen, einen bootloader in die Partition von Wheezy zu installieren ?

Und Nachtrag zu einer früheren Frage von Dir. Das ähnliche Problem in Squeeze, das die reboots betroffen hat, habe ich nie gelöst, reboots kann man mit ganz Herunterfahren und wieder Einschalten ja ganz gut umgehen.

Gruß und Danke
Hias

[rendegast]

und dann mit F10 starte

Das muß ich mir nochmal ansehen.

es ist völliger Zufall, ob es mit dem Workaround durch das Grub-Editiermenü geht oder nicht.

'F10' oder 'Ctrl-x' bootet einfach den (gerade editierten) Eintrag.
(Benutzte selber immer 'Ctrl-x', hatte das "F10" einfach überlesen)
Wird nichts editiert, wird eigentlich nur eine Pause eingelegt,
das könnte auch ein 'sleep ..' erledigen:

Code: Alles auswählen

menuentry 'blafasel....' {
  sleep 3
  insmod ....
  set ....
...

(wie das jedoch in update-grub eingebunden wird?)

In der grub-shell könnte die Funktionsfähigkeit geprüft werden,
zBsp Zugriff auf die kernel-Datei usw.

Code: Alles auswählen

> set
...
   root=(gluck,nick)
...

> cd (g <TAB> )/ <TAB>
(Bietet die entsprechenden Dateien/Verzeichnisse an?)
(ohne daß die grub-shell hängenbleibt?)

Keine Besonderheiten wie
- gpt, efi,
- zweite identische Festplatte
(grub-shell, 'irgendeinBefehl (hd <TAB>, <TAB>' zeigt immer die "richtige" Plattenfolge?)
(Ein (veralteter) MBR-grub auf der zweiten Festplatte kommt bei zufälliger Bios-Vertauschung zum Zuge?
Dort (zur Kontrolle) explizit einen grub mit veränderter Header-Zeile oder gleich einen ganz anderen Bootloader einrichten),
- eine angeschlossen USB-Platte (könnte die Plattenerkennung des grub ausbremsen/hängenlassen)
- mehrere aktive Grafik-Chips (verwirrt vielleicht die VGA-Erkennung des grub)
?

Bios-Features wie NX versuchsweise deaktivieren, insbesondere DELL-artige Spezialitäten?
(Bei mir kann ich zBsp. Kompatibilität ACPI1.0/2.0/3.0 wählen,
von der Güte der Implementationen keine Ahnung.)





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

Das heißt kompletter Zufall ist es nicht,
nach mehreren Reboots/Hardresets wegen Hängern geht es meist gar nicht mehr,
da hat man dann erst am nächsten Tag wieder ein Chance.

Jeder braucht mal eine Aus-Zeit

[hias]

Hallo rendegast,

Wird nichts editiert, wird eigentlich nur eine Pause eingelegt,
das könnte auch ein 'sleep ..' erledigen:

Das ist mir klar...Wie man ein 'sleep...' in Grub2 bekommt, weiß ich sogar, man kann es in der /etc/default/grub einstellen, hab ich probiert, bringt nichts.

In der grub-shell könnte die Funktionsfähigkeit geprüft werden,
z.B. Zugriff auf die Kernel-Datei usw.

Das muss ich mal in Ruhe machen, dazu muss ich mich erst in die Bedienung der grub-shell einlesen. Deinen Eintrag im Codeblock dazu verstehe ich leider nicht, weil ich mich zu wenig auskenne.

Keine Besonderheiten: GPT glaube ich nicht (wo sehe ich das ?), EFI sicher nicht. Eine einzige Festplatte verbaut (Western Digital WDC WD5000AAKS-7 - keine von denen, die ein Firmware-Update brauchen). Ein Grafikchip (NVidia G86 [GeForce 8300 GS]).

BIOS-Features muss ich mir mal anschauen.

Vielen Dank für Deine Geduld.

Gruß Hias

[rendegast]

<TAB> steht für die Command/Pfad-Completion der grub-shell.
Einfach ausprobieren.

GPT glaube ich nicht (wo sehe ich das ?)

'fdisk -lu' gibt nur eine primäre Partition aus.
'parted /dev/sdX print' zeigt es auch an.
Bei meinen bisherigen Versuchen in einer VM hatte ich aber keine Probleme damit.

[hias]

Hallo rendegast,

ich werde Deine Tipps mal in Ruhe testen und berichten.
Aber jetzt fahr ich erstmal eine Woche in die Berge...

Vielen Dank
Hias

[hias]

So,

nach einer sehr erholsamen (computerfreien - sieht man mal von den Digitalkameras ab) Woche im Pitztal sitze ich wieder vor der im Bezug auf Wheezy hartnäckig bockenden Kiste.

Ich bin mal in die Grub-Shell gegangen und habe die von rendegast vorgeschlagenen Sachen eingegeben (und die Ergebnisse abgeschrieben, ich weiß nicht, ob man das auch in eine Textdatei umlenken könnte) :

Code: Alles auswählen

grub> set
?=0
color_highlight=black/white
color_normal=black/white
default=0
gfxmode=auto
have_grubenv=true
lang=de_DE
linux_gfx_mode=keep
locale_dir=(hd0,msdos1)/boot/grub/locale
match=0
menu_color_highlight=black/light-gray
menu_color_normal=white/black
pager=
prefix=(hd0,msdos1)/boot/grub
root=hd0,msdos1(

Code: Alles auswählen

grub> g/              #cd (g <TAB> )/ <TAB>
Mögliche Dateien sind:

 lost+found/ var/ etc/ media/ bin/ boot/ dev/ home/ lib/ mnt/ opt/ proc/ root/ sbin/ selinux/ srv/ sys/ tmp/ usr/ vmlinuz initrd.img cdrom/ initrd.img.old vmlinuz.old

Mir sagt das leider nichts. Als nächstes schaue ich dann die BIOS-Einstellungen an.

Gruß Hias

[rendegast]

> set
...
root=(gluck,nick)
...

> cd (g <TAB> )/ <TAB>

Das war ein Beispiel, das mit sinnvollen Werten Deinserseits auszufüllen ist.
Also nach Deinem Output

Code: Alles auswählen

> cd (h     <TAB>

Nicht alle grub-blockdevices beginnen mit "hd",
es gibt auch "Name-des-lvm-Verbundes" / "Name-des-raid-Verbundes", "gpt" im Falle von GPT-Partitionierung usw.
(dafür müssen dann noch die entsprechenden Module geladen werden,
zBsp. raid.mod, lvm.mod, part_gpt.mod.
Normalerweise werden die benötigten Module beim Neuerstellen der initrd eingebunden).
Also könnte auch ein

Code: Alles auswählen

> cd (     <TAB>

weitere grub-blockdevices anzeigen.

In einer VM gerade ausprobiert

Code: Alles auswählen

> ls
(netbook-root) (hd0) (hd0,msdos5) (hd0,msdos1)

grub> set
locale_dir=(hd0,msdos1)/boot/grub/locale
prefix=(hd0,msdos1)/boot/grub
root=hd0,msdos1(

Was soll die offene Klammer am Ende?
Oder nur ein Abschreib-Fehler? Denn im Normalfall setzt der Admin diesen Wert nicht mehr,
er wird beim 'update-grub' dynamisch bestimmt.

grub> g/ #cd (g <TAB> )/ <TAB>
Mögliche Dateien sind:

Du hast das jetzt nicht so hingeschreiben?
Dennoch ein schönes Beispiel für die Completion:
grub erweitert hier einen Befehl um für ihn erscheinende Möglichkeiten,
in dem Fall Dateien oder Verzeichnisse als Argumente.






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

ob man das auch in eine Textdatei umlenken könnte

Wohl nein:

Code: Alles auswählen

> help > /boot/output.txt
error: syntax error.
error: Incorrect command.
error: syntax error.

Aber lesen geht:

Code: Alles auswählen

> cat /boot/grub/device.map
(....)  ...................

[hias]

Hallo rendegast,

danke für Deine große Geduld.

Die offene Klammer bei der Ausgabe von set ist ein Tippfehler, die Zeile heißt korrekt

Code: Alles auswählen

root=hd0,msdos1

Code: Alles auswählen

cd (h     <TAB>

und

Code: Alles auswählen

cd (     <TAB>

bringen in der Vervollständigung immer nur

Code: Alles auswählen

cd (hd0
Fehler: unknown command `cd'.

Drücke ich nochmal <TAB> kommt:

Code: Alles auswählen

Mögliche Partitionen sind:

Gerät hd0: Kein bekanntes Dateisystem - Gesamtgröße 976773168 Sektoren
       Partition hd0,msdos1: Dateisystemtyp ext2 - Letzte Änderungszeit 2011-09-05 12:12:39 Monday, UUID 0b4ca561-ddff-4e5e-b114-90c5eecc4c13 - Partitionsbeginn bei 2048 - Gesamtgröße 933793792 Sektoren
       Partition hd0,msdos2: Dateisystemtyp ext2 - Letzte Änderungszeit 2011-08-23 21:39:05 Tuesday, UUID ae7b114b-9109-4b16-afca-fe7993720c42 - Partitionsbeginn bei 933795840 - Gesamtgröße 34639872 Sektoren
      Partition hd0,msdos5: Kein bekanntes Dateisystem - Partitionsbeginn bei 968437760 - Gesamtgröße 8335360 Sektoren

Code: Alles auswählen

grub>  ls
(hd0)  (hd0,msdos5)  (hd0,msdos2)  (hd0,msdos1)

Das mit der Raute (wo Du gefragt hast, ob ich das so hingeschrieben habe) sollte nur der Verdeutlichung dienen, was ich eingetippt hab, ich hab es nicht so eingegeben.

Hab ins BIOS geschaut, finde da aber nichts von NX oder Wahlmöglichkeiten zwischen ACPI 1.0/2.0/3.0, wo sind die denn bei Dir ?

Bin mal ins Wheezy reingekommen, hab dann das Paket firmware-linux installiert. Beim nächsten Neustart ist er dann problemlos hochgekommen (hab mich schon gefreut), aber jetzt geht wieder gar nichts mehr - reines Glücksspiel . Sehr schade, denn wenn Wheezy läuft, ist es ganz unglaublich viel schneller als Xubuntu und macht keine Probleme.

Gruß Hias

[rendegast]

hab dann das Paket firmware-linux installiert. Beim nächsten Neustart ist er dann problemlos hochgekommen (hab mich schon gefreut), aber jetzt geht wieder gar nichts mehr

firmware-linux zieht fimrware-linux-free und firmware-linux-nonfree,
mit denen eine Handvoll Geräte ihre Funktion besser erfüllen können (radeon-Karten, e100, ++),
aber keines solcher Geräte scheint mir für einen Boot-Vorgang nötig,

Code: Alles auswählen

Mögliche Partitionen sind:

Gerät hd0: Kein bekanntes Dateisystem - Gesamtgröße 976773168 Sektoren
       Partition hd0,msdos1: Dateisystemtyp ext2 - .... - Partitionsbeginn bei 2048 - Gesamtgröße 933793792 Sektoren
       Partition hd0,msdos2: Dateisystemtyp ext2 - .... - Partitionsbeginn bei 933795840 - Gesamtgröße 34639872 Sektoren
      Partition hd0,msdos5: Kein bekanntes Dateisystem - Partitionsbeginn bei 968437760 - Gesamtgröße 8335360 Sektoren

Prima, sieht nach aligned-Partitionen aus, normale Partitionstabelle.
Wenn er da kernel und/oder initrd auf (hd0,msdos1) nicht findet, liegt es an anderen Problemen.

NX oder Wahlmöglichkeiten zwischen ACPI 1.0/2.0/3.0, wo sind die denn bei Dir ?

War irgendwo unter Chipsatz oder cpu (biostar A770 A2G+)

Sehr schade, denn wenn Wheezy läuft, ist es ganz unglaublich viel schneller als Xubuntu und macht keine Probleme.

Laß ich mal dahingestellt und glaube es nicht.
Kommt auf die installierten und aktivierten Dienste an,
wenn ich Xubuntus "Bremsklotz" in Deinem Wheezy aktiviere werden sich die Ergebnisse gleichen.






Weitere Diagnose läuft vielleicht auf einen glücklich detektierten Kernel-Parameter hinaus,
aber ein weites Feld und damit eine gehörige Portion Glück nötig.
Probiere wheezy mit dem problemlosen ubuntu-Kernel, um es zumindest als kernel-Problem festzulegen.

Verwende den ubuntu-kernel oder gleich ubuntu.
(Das System wirst Du abspecken können, das ist immer möglich).

[pferdefreund]

Wenns mal geht und mal nicht geht - ohne das was geändert wurde, sollte eventuell auch mal in Betracht gezogen werden,
daß es sich um ein Hardware-Problem handelt. Mal die Platte mit nem Livesystem auf badblocks testen, smart, MEMTEST
CPUBURN Netzspannung - eventuell braucht das Netzteil ne Weile, bis es richtig Strom liefert ?

[hias]

Laß ich mal dahingestellt und glaube es nicht.
Kommt auf die installierten und aktivierten Dienste an,
wenn ich Xubuntus "Bremsklotz" in Deinem Wheezy aktiviere werden sich die Ergebnisse gleichen.

Das ist mir klar und manche dieser Dienste (oder auch die dort eingesetzten umfangreicheren Programme wie den Network-Manager) schätze ich ja durchaus...

Weitere Diagnose läuft vielleicht auf einen glücklich detektierten Kernel-Parameter hinaus,
aber ein weites Feld und damit eine gehörige Portion Glück nötig.

Ja, in diese Richtung habe ich schon anfangs gedacht, denn mit acpi=off tritt das Phänomen ja auch nicht auf, nur ist der Rechner damit unbenutzbar langsam.

Probiere Wheezy mit dem problemlosen Ubuntu-Kernel, um es zumindest als Kernel-Problem festzulegen.

Das könnte ich mal versuchen. Bei dem System kann ich ja eh nicht viel kaputtmachen...
Was brauche ich da linux-image, linux-headers, was noch ?

@Pferdefreund: Ja, daran hab ich auch schon gedacht, nur läuft Xubuntu 11.04 halt absolut problemlos, das müsste von einem Hardware-Problem doch auch betroffen sein. Außerdem weiß ich von den ganzen Tests auf Anhieb nur, wie der MEMTEST geht, aber das kann ich ja rausfinden.

Gruß Hias

[rendegast]

http://packages.ubuntu.com/natty-updates/linux-image
die kernel 2.6.38-11, wohl als -generic oder -generic-pae.

Die Abhängigkeit auf ubuntus wireless-crda erledigt ein equivs-dummy:

Code: Alles auswählen

$ apt-cache show wireless-crda-dummy 
Package: wireless-crda-dummy
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 36
Maintainer: root <root@mymachine.at.home>
Architecture: all
Version: 1.0
Provides: wireless-crda
Description: dummy fuer ubuntus wireless-crda
  damit ubuntu-Kernel installierbar sind
  bla1
  bla2

Eine einfache control-Datei:

Code: Alles auswählen

# cat wireless-crda-dummy.control
Package: wireless-crda-dummy
Architecture: all
Provides: wireless-crda
Description: dummy fuer ubuntus wireless-crda
  damit ubuntu-Kernel installierbar sind
  bla1
  bla2

# aptitude install equivs
...

# equivs-build wireless-crda-dummy.control
...

# dpkg -i wireless-crda-dummy*deb
...

------------------------------------------------
xubuntu 11.04 läuft mit gdm und xfce4, upstart, gvfsd, belegt ~ 220MB.
Fühlt sich eigentlich nicht langsam an.

[hias]

Hallo rendegast,

habe es mal mit dem Kernel linux-image-3.0.4-030004-generic und den linux-headers-3.0.4-030004-generic versucht (hatte Deinen letzten Beitrag nicht gelesen). Statt Deiner schönen equivs-dummy-Lösung (die ich auch erst nachvollziehen muss - wo muss ich diese Angaben reinschreiben ?) hab ich einfach das Ubuntu-Paket wireless-crda installiert (mit dpkg -i, wie den Rest auch), das hat geklappt.

Bei der Installation des Kernel gibt es eine Fehlermeldung bei den linux-headers,

Code: Alles auswählen

Error! Bad return status for module build on kernel: 3.0.4-030004-generic (i686)
Consult /var/lib/dkms/nvidia/280.13/build/make.log for more information.

die sich bei der Installation des linux-image wiederholt. Wenig überraschend kommt dann auch der Xserver nicht hoch.

Code: Alles auswählen

root@dell530:/# cat /var/lib/dkms/nvidia/280.13/build/make.log
DKMS make.log for nvidia-280.13 for kernel 3.0.4-030004-generic (i686)
Di 6. Sep 23:14:34 CEST 2011
make: Entering directory `/var/lib/dkms/nvidia/280.13/build'
make -C /lib/modules/3.0.4-030004-generic/build  M=`/bin/pwd` modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.4-030004-generic'
  CC [M]  /var/lib/dkms/nvidia/280.13/build/nv.o
In file included from /var/lib/dkms/nvidia/280.13/build/nv.c:13:0:
/var/lib/dkms/nvidia/280.13/build/nv-linux.h:35:33: fatal error: generated/compile.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
make[2]: *** [/var/lib/dkms/nvidia/280.13/build/nv.o] Fehler 1
make[1]: *** [_module_/var/lib/dkms/nvidia/280.13/build] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-3.0.4-030004-generic'
make: *** [modules] Fehler 2
make: Leaving directory `/var/lib/dkms/nvidia/280.13/build'

Ich hab keine Ahnung, wie ich das reparieren kann, aber das ist erstmal auch nicht so wichtig. Interessant ist jedenfalls, dass er mit diesem Ubuntu-Kernel seltener hängen bleibt. 4 von 5 Startversuchen waren erfolgreich. Den Debian-pae und den Liquorix-Kernel bekomme ich heute nur dann einigermaßen verlässlich hoch, wenn ich in die Grub-shell gehe, da ein bisserl rumspiele und warte und dann starte.

Gruß Hias

[rendegast]

Bei der Installation des Kernel gibt es eine Fehlermeldung bei den linux-headers,
Error! Bad return status for module build on kernel: 3.0.4-030004-generic (i686)
Consult /var/lib/dkms/nvidia/280.13/build/make.log for more information.
die sich bei der Installation des linux-image wiederholt. Wenig überraschend kommt dann auch der Xserver nicht hoch.

Wenn Du das nvidia-Modul benutzt, werden natürlich auch die kernel-Header für dessen Erstellung gebraucht.

4 von 5 Startversuchen

Kann leider auch alles heißen,
und wären immer noch 20% Fehlerquote.
Ich schmeiße Festplatten schon bei 10/1000000000 badblocks raus.

bekomme ich heute nur dann einigermaßen verlässlich hoch, wenn ich in die Grub-shell gehe, da ein bisserl rumspiele und warte und dann starte.

Netzteil? Spannungswandler?
Vielleicht mal einige Komponenten über ein zweites Netzteil bedienen? Laufwerk(e), Grafikkarte.

Grafikkarte, Leistungsmodell testweise gegen (Energie)Sparvariante tauschen?
resp. interne (Chipsatz)Grafik gegen Kartenmodell und intern deaktivieren?
Sonstige Erweiterungskarten entfernen?
Laufwerke, insbesondere optische abklemmen?
Eventuelle Übertaktungen wieder zurücknehmen? (in solchen Maschinen eigentlich nicht vorgesehen)






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

(die ich auch erst nachvollziehen muss - wo muss ich diese Angaben reinschreiben ?)

?

Code: Alles auswählen

root@dell530:/# cat /var/lib/dkms/nvidia/280.13/build/make.log

equivs baut ein Paket, daß eigentlich nur aus dem control-Header besteht,
halt einen dummy.
Mittels der einfachen Anweisung 'Provides: bla, fasel, ...' können die meisten Abhängigkeiten befriedigt werden.

Komplizierter sind versionsbedingte Abhängigkeiten wie 'Depends: bla (= 1.1.1)', und zwar mehrfach:

• - da dies nicht mittels 'Provides: bla (= 1.1.1)' funktioniert, der dummy muß dann wirklich so heißen:

  Code: Alles auswählen

  Package: bla
  Version: 1.1.1
  Description: dummy fuer wirkliches bla
  

• - Beim Repo-seitigen Upgrade des Paketes würde der dummy wieder gegen das Original getauscht.

• - Ich mache die dummy gerne anhand Name, Version und Beschreibung, eventuell auch Section-Name, kenntlich.
  Bei einem 'Depends: bla (= ...)' fallen halt die ersten beiden weg.

[hias]

Hallo rendegast

Wenn Du das nvidia-Modul benutzt, werden natürlich auch die kernel-Header für dessen Erstellung gebraucht.

Klar, aber die habe ich doch installiert ?? Die Fehlermeldung kommt ja bei der Installation der linux-headers.

Netzteil? Spannungswandler?
Vielleicht mal einige Komponenten über ein zweites Netzteil bedienen?

Könnte ich mir vorstellen, nur habe ich kein zweites Netzteil. Wie kann ich meins testen ?

Grafikkarte, Leistungsmodell testweise gegen (Energie)Sparvariante tauschen?

Ich habe aber keine weitere Grafikkarte und möchte auch nicht unbedingt eine kaufen.

resp. interne (Chipsatz)Grafik gegen Kartenmodell und intern deaktivieren?

Eine interne (Chipsatz)Grafik hat mein Board nicht.

Sonstige Erweiterungskarten entfernen?

Gibt nur noch eine Soundkarte, weil sich der Onboard-Soundchip mal plötzlich verabschiedet hat, aber das war nach meiner ersten Testrunde mit Wheezy im Juni, wo das Problem auch schon bestanden hat.

Laufwerke, insbesondere optische abklemmen?

Hmmm, mein CD/DVD-ROM brauche ich aber eigentlich.

Eventuelle Übertaktungen wieder zurücknehmen? (in solchen Maschinen eigentlich nicht vorgesehen)

Übertaktungen habe ich nie gemacht.

Beim equivs ist mir das Vorgehen noch nicht klar: Ich muss zuerst das Paket equivs installieren. Dann mit

Code: Alles auswählen

equivs-build wireless-crda-dummy.control

diese Dummy-Datei erstellen (in welches Verzeichnis muss die ?). Und dann muss ich die bearbeiten, was da rein muss, hast Du ja geschrieben. Und dann ? (Es gibt dafür leider keine Anleitung im Ubuntuusers-Wiki, und ohne das bin ich verloren... )
Kann ich nach dieser Anleitung noch vorgehen ? http://www.debian.org/doc/manuals/apt-h ... rs.en.html

Ach ja, Xubuntu braucht bei mir im Leerlauf mit gdm und xfce4, upstart, gvfsd, network-manager und (kleiner) conky ~210 MB, mit geöffnetem Firefox, Evolution etc. werden es dann schnell über 400 MB und es fühlt sich träger an, als Wheezy, besonders beim Rechtsklick-Menü, aber ohne dass das wirklich ein Problem wäre.
Ich würde nur gern eine Zeitlang mit Debian Testing mitrollen und dann noch ein bisschen Stable genießen, denn bei den *buntus installiere ich ja doch bei jeder Version neu (dem Versions-Upgrade dort misstraue ich) .

[rendegast]

Code: Alles auswählen

/var/lib/dkms/nvidia/280.13/build/nv-linux.h:35:33: fatal error: generated/compile.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.

3.0.0-10, oneiric, eine compile.h befindet sich hier:
/usr/src/linux-headers-3.0.0-10-generic/include/config/cross/compile.h
Reicht ein einfacher Link nach generated/compile.h?

xubuntu 11.04 (natty) <-> 2.6.38-11
3.0.4-030004-generic, daily-build, woher ?

Klar, aber die habe ich doch installiert ?? Die Fehlermeldung kommt ja bei der Installation der linux-headers.

Code: Alles auswählen

dpkg -l | grep linux-

Ich habe aber keine weitere Grafikkarte und möchte auch nicht unbedingt eine kaufen.

So läuft das aber ohne Testlabor, try+error durch Tausch eventuell defekter Bauteile.

Hmmm, mein CD/DVD-ROM brauche ich aber eigentlich.

Testphase?
Vielleicht ist es ja kaputt, oder zieht zuviel(?) Strom vom (eventuell defekten) Netzteil und stockt den Bootvorgang?

Übertaktungen habe ich nie gemacht.

Vorbesitzer? Besucher?

weil sich der Onboard-Soundchip mal plötzlich verabschiedet hat,

???
Fortschreitender Board-Fehler?




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

Dann mit
equivs-build wireless-crda-dummy.control
diese Dummy-Datei erstellen (in welches Verzeichnis muss die ?)

Nein, die wird von Dir kreiert:

Code: Alles auswählen

# cat wireless-crda-dummy.control
# aptitude install equivs
# equivs-build wireless-crda-dummy.control
# dpkg -i wireless-crda-dummy*deb

und anhand derer wird ein deb erstellt, das mit dpkg installiert wird.
man-page hätte auch geholfen.

[hias]

Hallo rendegast,

ich hab die Sache jetzt ein paar Tage auf sich beruhen lassen - RL ist wichtiger (und ich hab ja ein laufenden Xubuntu-System).

3.0.4-030004-generic, daily-build, woher ?

Von hier: http://kernel.ubuntu.com/~kernel-ppa/mainline/
Ich wollte einen 3.0 Kernel, da ein solcher in Wheezy derzeit läuft.

Da aber die Vergleichbarkeit natürlich interessant ist, hab ich dann auch noch den 2.6.38-11 (eben den, der mit Xubuntu läuft) installiert.

Code: Alles auswählen

dpkg -l | grep linux-

sagt, dass alle Headers installiert sind. Trotzdem können beide Ubuntu-Kernel X nicht starten, aber das ist das geringste Problem und liegt an irgendeinem doofen Fehler von mir.

Mittlerweile verhalten sich nämlich auch beide Ubuntu-Kernel unter Wheezy wie die Debian-Kernel und brauchen eine laaaaaange Auszeit (von mehreren Minuten) bis sie starten können. Derselbe 2.6.38-11 startet unter Xubuntu zuverlässig sofort und unter Debian nicht.

weil sich der Onboard-Soundchip mal plötzlich verabschiedet hat,
???
Fortschreitender Board-Fehler?

Das kann ich mir mittlerweile gut vorstellen - nur warum kommt trotzdem Xubuntu (mit demselben Kernel !) hoch ?

Gruß Hias

[rendegast]

Mittlerweile verhalten sich nämlich auch beide Ubuntu-Kernel unter Wheezy wie die Debian-Kernel und brauchen eine laaaaaange Auszeit (von mehreren Minuten) bis sie starten können. Derselbe 2.6.38-11 startet unter Xubuntu zuverlässig sofort und unter Debian nicht.

Wenn die Kernel unter wheezy mucken, xubuntu aber funktioniert,
versuch es dochmal von der anderen Seite: Installiere den wheezy-Kernel unter xubuntu.

[hias]

Wenn die Kernel unter wheezy mucken, xubuntu aber funktioniert,
versuch es dochmal von der anderen Seite: Installiere den wheezy-Kernel unter xubuntu.

Eigentlich naheliegend. Das ist aber mein Hauptsystem, da muss ich erstmal wirklich alles sichern, eigentlich kann zwar nicht viel passieren, aber sicher ist sicher.
ich werde berichten.

Gruß Hias

[hias]

Mal wieder eine Statusmeldung und keine guten Nachrichten:

Die "Flucht" zu Ubuntu war wohl nur von kurzer Dauer. Die Beta von Ubuntu 11.10 (32-Bit) bringt dasselbe Phänomen hervor, wie Debian Wheezy - schöne Sch...

Vorher hab ich mal eine 64-Bit Wheezy Version getestet, die bootet einmal korrekt und dann nie wieder. Sie produziert aber andere Fehlermeldungen, vielleicht sollte ich in dieser Richtung weitertesten. Mein System sollte mit 64-Bit an sich ja keine Probleme haben.

Ich hab heut nacht memtest gefahren (über 8 Stunden), keine Fehler, meine DDR2 Bausteine sind dann wohl nicht der Übeltäter.

Netzteil und/oder Mainboard erwäge ich inzwischen ernsthaft auszutauschen (scheint normales Micro-ATX zu sein), ich hab nur eigentlich kein Geld dafür im Moment...

Vorher würde ich aber wegen dieser alten Geschichte https://bugs.launchpad.net/ubuntu/+sour ... bug/153702 noch gern testweise im BIOS den SATA-Mode auf Raid umstellen. Das hat damals bei Ubuntu 8.04 und 9.04 geholfen.
Kann ich das umstellen und das vorher installierte Test-System auf /dev/sda2 booten, oder zerschieße ich dann auch das laufende Xubuntu 11.04 auf /dev/sda1 (die Daten sichere ich eh vorher) ?

Gruß Hias