Hallo zusammen,
und allen hier nochmal schöne Feiertage und einen geten Rutsch!
Nun sind schon zwei Wochen um, seit dem ich versuche mir korrekt konfigurierte kernel- Sourcen zu schaffen... Probiert man doch am Besten aus, indem man die Sourcen übersetzt und den kernel dann ausprobiert...
Ich benutze Sarge mit einem kernel 2.6.8-1-686 habe die Quellen und das kernel-package installiert und für den Anfang das "originale" /boot/config-2.6.8-1-686 nach /usr/src/linux/.config kopiert danach ein make menuconfig und erstmal NICHTS verstellt make-kpkg kernel_image --revision=vdr.1 hat das Paket gebaut danach cd .. und dpkg -i kernel-image-2.6.8_vdr.1_386.deb hat es dann installiert danach noch schnell mkinitrd -o /boot/initrd.img-2.6.8 2.6.8, alles zusammen in /boot/grub/menu.lst entsprechend aktualisiert und probehalber reboot
der neue Kernel bootet, sieht auch möglicherweise so aus, wie der "originale" 2.6.8 ( kann man das eigentlich überprüfen ? ) ABER
bei dem "originalen" Kernel funktioniert ein vga=791, bei dem selbst kompilierten NICHT! Der Bildschirm bleibt nach der Umschaltung zum Frame Buffer Device SCHWARZ?!
Auch die Install Tips, die Google so zu Tage fördert haben mich nicht weiter gebracht?! fest einkompiliert: [*] Support for frame buffer devices [*] ATI Radeon display support [*] VGA 16-color graphics support [*] VESA VGA graphics support [*] Framebuffer Console support
Im "originalen" config sind das alles Module?!
Nun bin ich ratlos!
Wieso entsteht mit dem originalen config-file ein anderer kernel? Oder besser gesagt, wieso funktioniert er nicht genauso?
Wenn ich danach etwas im config verstelle und ein neues kern-image.deb bauen will, bringt: make-kpkg kernel_image --revision=vdr.2 einen Fehler wegen des vorher benutzten vdr.1 Soll ich das ./debian/changelog einfach löschen?
Mir ist jeder Hinweis willkommen...
bis dann Thomas
Am Sonntag, den 26.12.2004, 21:43 +0100 schrieb Mötzing Thomas:
Hallo zusammen,
und allen hier nochmal schöne Feiertage und einen geten Rutsch!
Danke. Gleichfalls.
bei dem "originalen" Kernel funktioniert ein vga=791, bei dem selbst kompilierten NICHT! Der Bildschirm bleibt nach der Umschaltung zum Frame Buffer Device SCHWARZ?!
Ich vermute mal das die Module für das framebuffer device nicht im initrd sind.
Auch die Install Tips, die Google so zu Tage fördert haben mich nicht weiter gebracht?! fest einkompiliert: [*] Support for frame buffer devices [*] ATI Radeon display support [*] VGA 16-color graphics support [*] VESA VGA graphics support [*] Framebuffer Console support
Probier es mal ohne den ATI und ohne VGA-16. Dann bleibt nur noch VESA, welches dann automatisch beim booten benutzt wird.
Im "originalen" config sind das alles Module?!
Das ist auch gut so, denn die werden mit ins initrd gepackt. Fest einkopiliert geht das nicht.
Nun bin ich ratlos!
Wieso entsteht mit dem originalen config-file ein anderer kernel? Oder besser gesagt, wieso funktioniert er nicht genauso?
Ich vermute mal das beim bauen des initrd-images Module vergessen werden. Das kann man sicher irgendwo konfigurieren. Wo? - keine Ahnung ich nutze das nicht.
Wenn ich danach etwas im config verstelle und ein neues kern-image.deb bauen will, bringt: make-kpkg kernel_image --revision=vdr.2 einen Fehler wegen des vorher benutzten vdr.1 Soll ich das ./debian/changelog einfach löschen?
Nein das richtige wäre: make-kpkg clean
Dann wird der komplette Baum geleert und ist wieder im Urzustand.
Ich hoffe ich war eine kleine Hilfe.
MfG Carsten
On 27.12.04 Carsten Luedtke (acid_man@gmx.net) wrote:
Am Sonntag, den 26.12.2004, 21:43 +0100 schrieb Mötzing Thomas:
Moin,
bei dem "originalen" Kernel funktioniert ein vga=791, bei dem selbst kompilierten NICHT! Der Bildschirm bleibt nach der Umschaltung zum Frame Buffer Device SCHWARZ?!
Ich vermute mal das die Module für das framebuffer device nicht im initrd sind.
Möglich. Das könnte daran liegen, daß die Programme zum Erzeugen der initrd nicht installiert sind. Schau mal in die Build-Depends.
Wieso entsteht mit dem originalen config-file ein anderer kernel? Oder besser gesagt, wieso funktioniert er nicht genauso?
Ich vermute mal das beim bauen des initrd-images Module vergessen werden. Das kann man sicher irgendwo konfigurieren. Wo? - keine Ahnung ich nutze das nicht.
Ich weiß jetzt nicht, wie das bei sarge ist, aber bei woody wird die initrd während des Baus des deb-Paketes erzeugt und dort eingefügt. Glaube kaum, daß sich das geändert hat. Daß ein loopback-Treiber vorhanden ist (jnd auch fest im Kernel) steht dann in der Config.
make-kpkg clean
Dann wird der komplette Baum geleert und ist wieder im Urzustand.
Oder ein ganz normales Mr. Proper und dann dann subdir debian/ löschen.
H.
Am 28 Dec 2004 um 10:01 hat Hilmar Preusse geschrieben:
bei dem "originalen" Kernel funktioniert ein vga=791, bei dem selbst kompilierten NICHT! Der Bildschirm bleibt nach der Umschaltung zum Frame Buffer Device SCHWARZ?!
Ich vermute mal das die Module für das framebuffer device nicht im initrd sind.
Möglich. Das könnte daran liegen, daß die Programme zum Erzeugen der initrd nicht installiert sind. Schau mal in die Build-Depends.
aber mkinitrd erzeugt das initrd.img und läuft ohne Fehlermeldung auch make-kpkg --initrd --revision=neu kernel_image läuft problemlos durch und das dpkg -i kernel-image... installiert das initrd.img ohne Fehlermeldung?!
wieso funktioniert ALLES, bis auf das Frame Buffer Device???
Oder ein ganz normales Mr. Proper und dann dann subdir debian/
---------------
wozu brauche ich den Flaschengeist???
bis dann Thomas ------------- ratlos
Am 27 Dec 2004 um 18:09 hat Carsten Luedtke geschrieben:
Wieso entsteht mit dem originalen config-file ein anderer kernel? Oder besser gesagt, wieso funktioniert er nicht genauso?
Ich vermute mal das beim bauen des initrd-images Module vergessen werden. Das kann man sicher irgendwo konfigurieren. Wo? - keine Ahnung ich nutze das nicht.
OK, aber woher weiß ich mit Sicherheit, was ich fest einkompilieren muß, damit ich kein initrd brauche?
Wenn ich danach etwas im config verstelle und ein neues kern-image.deb bauen will, bringt: make-kpkg kernel_image --revision=vdr.2 einen Fehler wegen des vorher benutzten vdr.1 Soll ich das ./debian/changelog einfach löschen?
Nein das richtige wäre: make-kpkg clean
OK, das funktioniert...
Dann wird der komplette Baum geleert und ist wieder im Urzustand.
Ich hoffe ich war eine kleine Hilfe.
Danke
bis dann Thomas
On 28.12.04 Mötzing Thomas (t_moetzing@gmx.de) wrote:
Am 27 Dec 2004 um 18:09 hat Carsten Luedtke geschrieben:
Moin,
Ich vermute mal das beim bauen des initrd-images Module vergessen werden. Das kann man sicher irgendwo konfigurieren. Wo? - keine Ahnung ich nutze das nicht.
OK, aber woher weiß ich mit Sicherheit, was ich fest einkompilieren muß, damit ich kein initrd brauche?
Ganz einfach: alles, was Du zum Mounten des Root-Filesystems brauchst muß fest in den Kernel. Dazu gehört:
- Plattentreiber (IDE, SCSI etc.) - Treiber fürs Filesystem (ext2, ext2, reiser etc.)
. Alles andere kann modularisiert werden, auch der Framebuffer. Den kann man später mit modprobe aktivieren.
H.
On 28.12.04 Mötzing Thomas (t_moetzing@gmx.de) wrote:
Am 28 Dec 2004 um 10:01 hat Hilmar Preusse geschrieben:
Moin,
Möglich. Das könnte daran liegen, daß die Programme zum Erzeugen der initrd nicht installiert sind. Schau mal in die Build-Depends.
aber mkinitrd erzeugt das initrd.img und läuft ohne Fehlermeldung auch make-kpkg --initrd --revision=neu kernel_image läuft problemlos durch und das dpkg -i kernel-image... installiert das initrd.img ohne Fehlermeldung?!
OK, OK, war 'ne Vermutung.
Oder ein ganz normales Mr. Proper und dann dann subdir debian/
---------------wozu brauche ich den Flaschengeist???
clean target beim Kernelbau:
make mrproper
-> Kernel-HOWTO
H.
Hilmar Preusse hille42@web.de:
On 28.12.04 Mötzing Thomas (t_moetzing@gmx.de) wrote:
Am 27 Dec 2004 um 18:09 hat Carsten Luedtke geschrieben:
Moin,
Ich vermute mal das beim bauen des initrd-images Module vergessen werden. Das kann man sicher irgendwo konfigurieren. Wo? - keine Ahnung ich nutze das nicht.
OK, aber woher weiß ich mit Sicherheit, was ich fest einkompilieren muß, damit ich kein initrd brauche?
Ganz einfach: alles, was Du zum Mounten des Root-Filesystems brauchst muß fest in den Kernel. Dazu gehört:
- Plattentreiber (IDE, SCSI etc.)
- Treiber fürs Filesystem (ext2, ext2, reiser etc.)
. Alles andere kann modularisiert werden, auch der Framebuffer. Den kann man später mit modprobe aktivieren.
Auch einen native framebuffer console? Ich ging bisher davon aus, wenn ich bei meiner ATI-Karte native framebuffer consolen haben möchte, muss diese Unterstützung fest in den Kernel "CONFIG_FB_ATY128=y"
und mit Bootoption z.B. "video=aty128fb:1024x768@85" beim Booten aktiviert werden.
Gibt's da andere Erkenntnisse?
Freundlich grüßend,
Erik
On 29.12.04 Erik Schanze (schanzi_@gmx.de) wrote:
Hilmar Preusse hille42@web.de:
Moin,
Ganz einfach: alles, was Du zum Mounten des Root-Filesystems brauchst muß fest in den Kernel. Dazu gehört:
- Plattentreiber (IDE, SCSI etc.)
- Treiber fürs Filesystem (ext2, ext2, reiser etc.)
. Alles andere kann modularisiert werden, auch der Framebuffer. Den kann man später mit modprobe aktivieren.
Auch einen native framebuffer console?
Ich ging bisher davon aus, wenn ich bei meiner ATI-Karte native framebuffer consolen haben möchte, muss diese Unterstützung fest in den Kernel "CONFIG_FB_ATY128=y"
IIRC hab ich bei mir im Kernel einen Framebuffer für ATI. Nachdem der Bootvorgang beendet wurde kann ich modprobe modulname tippen und erst dann wird der Framebuffer aktiv. Diese Vorgehensweise bringt mich natürlich um den mördergeilen Pinguin links oben in der Ecke beim Booten. Die ATI Karte ist von 1998. Ich kann mal nachschauen, welche genau, wenn Du willst.
H.
lug-dd@mailman.schlittermann.de
-
Carsten Luedtke -
Erik Schanze -
Hilmar Preusse -
Mötzing Thomas