[solved] Problem mit Kernelupdate / Sourcen

[longman]

Hallo zusammen,

ich habe heute folgendes Problem festgestellt:

Als ich meinen vmware-server neu konfigurieren wollte, kam die Fehlermeldung das die
Sourcen nicht gefunden werden konnten (das ist schon seltsam und noch nicht da gewesen).


The path "/usr/src/linux/include" is a kernel header file directory, but it
does not contain the file "linux/version.h" as expected. This can happen if
the kernel has never been built, or if you have invoked the "make mrproper"
command in your kernel directory. In any case, you may want to rebuild your
kernel.


NaJa, kein Problem dachte ich und machte über yast ein Kernelupdate mit Update der
Sourcen, um sowohl den Kernel als auch die Sourcen auf den neuesten Stand zu bringen.

Hierbei kommen aber jetzt folgende Fehler:

Subprocess failed. Error: RPM failed: Free diskspace below /boot: 183628936 blocks
Setting up /lib/modules/2.6.22.12-0.1-default

Kernel image: /boot/vmlinuz-2.6.22.12-0.1-default
Initrd image: /boot/initrd-2.6.22.12-0.1-default
Root device: /dev/disk/by-id/scsi-SATA_SAMSUNG_SP1614CS01XJ10Y137427-part5 (/dev/sdb5) (mounted on / as ext3)
Resume device: /dev/sdb3
Device sdb not found in sysfs
Script /lib/mkinitrd/setup/72-block.sh failed!
/sbin/mkinitrd failed
error: %post(kernel-default-2.6.22.12-0.1.i586) scriptlet failed, exit status 1


Frage: Kann jemand von Euch was mit dem Fehler anfangen und mir einen Tipp gben ?

Danke schonmal...

 

[Gimpel]

Du brauchst vermutlich ein any-any update für VMware.

Zu dem Fehler beim kernel update.. keine Ahnung..
Was sagt dmesg, gibts sdb wirklich?

 

[longman]

Der any-any patch ist nicht mehr notwendig, bzw.

Ich sehe das Problem eher in meiner Kernelumgebung, da ja jetzt auch das Kernelupdate
mit yast fehlschlägt, unabhängig von vmware.

/dev/sdb5 ist vorhanden und dort ist /

Eventuell liegt das Problem bei /dev/sdb3,
aber ich bin mir nicht sicher wie ich mit dem Fehler:
Resume device: /dev/sdb3
Device sdb not found in sysfs
Script /lib/mkinitrd/setup/72-block.sh failed!
/sbin/mkinitrd failed
error: %post(kernel-default-2.6.22.12-0.1.i586) scriptlet failed,
exit status 1


umgehen soll. An sich läuft hier ja alles, ausser Kernelupdate.

 

[jengelh]

The path "/usr/src/linux/include" is a kernel header file directory, but it does not contain the file "linux/version.h" as expected. This can happen if the kernel has never been built, or if you have invoked the "make mrproper" command in your kernel directory. In any case, you may want to rebuild your kernel.

Richtig (nö), weil version.h in /lib/modules/versionhier/build/include/linux/ liegt.

 

[longman]

Richtig (nö), weil version.h in /lib/modules/versionhier/build/include/linux/ liegt.

Kann ich nicht ganz nachvollziehen. Die version.h ist ja x-fach vorhanden.
(mach mal im / ein find -iname version.h)

Aber es gibt hier 2 Tatsachen die ich schon oben in fett erwähnt hatte.
Erstens meckert vmware den fehlenden Pfad an
(war bei allen ca. 10 Updateinstallationen noch nie der Fall)

und zweitens (aus meiner Sicht viel schlimmer) meckert yast bei der Kernelupdateinstallation und bricht mit oben schon geschriebener Meldung ab.

 

[jengelh]

Dass VMware das nicht finden kann liegt meist daran, dass kernel-source nicht installiert ist.

 

[longman]

Das ist ja gerade das Problem,
dass trotz der installierten Kernelsources das Problem auftritt.

Deshalb habe ich ja per yast versucht, die Kernelsourcen und den Kernel upzudaten
(obwohl sie schon auf dem Stand 2.6.22.12-0.1 sind) und bin dabei auf das
geschilderte Problem mit sdb3 usw. (siehe oben) gestoßen.

 

[longman]

So ich habs raus gefunden.

Es lag gar nicht direkt an den Kernelsourcen bzw. am Kernelupdate, sondern an einem
fehlerhaften Eintrag in der grub Konfiguration. Dort war ein Eintrag, das /dev/sdb3 als
resume Partition benutzt werden soll. Diese Partition existiert aber nicht mehr.


Bei jedem Kernelupdate hat dann vermutlich mkinitrd die initrd nicht schreiben können
und deshalb in obiger Meldung auch sdb3 angemeckert. Aus diesem Grund haben dann
die Pfade der aktuellen Kernelsourcen nicht zum wirklich benutzten Kernel gepasst und
deshalb hat vmware dann auch gemeckert.

Lösung:
1,
Ich habe jetzt in der boot Konfiguration den Eintrag noresume eingefügt anstatt
"resume /dev/sdb3"
2. per yast ein Kernelupdate
3. Neustart mit neuem Kernel
4. vmware-config.pl -> alles okay
5. ab ins Bett in 4 Stunden klingelt mein Wecker