Compilar modulo del kernel

Imagen de danielGT
0 puntos

Hola gente.

Les explico: Necesito parchar un modulo del kernel. He buscado por internet y distintos foros y si bien las explicaciones son muy completas, pero tengo algunas dudas que no me quedan claras del todo.

Lo primero, debo conseguirme los fuentes de mi kernel, pero ¿para que si lo que quiero hacer es parchar un modulo? No el kernel completo.

Segundo, segun se, kernel-packages tiene algunas utilidades que hacen un poco mas sencilla la tarea de compilar el kernel, debo o conviene instalarlo para parchar/compilar el modulo?

Y por ultimo, como instalo el modulo? No me refiero a insmod o modprobe, sino a una vez que se compila, cual es el archivo resultante? un .o? un ejecutable?

Por favor, alguna ayuda, ya que ando bastante perdido, si conocen alguna guia se lo agradeceria bastante (tengo idea sobre el kernel, mi problema es parchar, compilar e instalar modulos).

Un saludo.

Imagen de cjadt
+1
0
-1

"Necesito parchar un modulo del kernel."
Weno, la cosa planteada así está mal, un módulo no se puede parchear, kizás estés leyendo foros donde no se expresan correctamente creyendo ke todos entendemos lo ke kieren decir.
Un "parche" no es otra cosa ke un archivo de texto plano ke lo genera el comando "diff", diff justamente busca diferencias entre los argumentos ke le damos, por ejemplo:
Sabiendo ke dos archivos son iguales diff nos devuelve algo así:
pingusa:~# diff -s arch1 arch2
Los ficheros arch1 y arch2 son idénticos
"diff" tiene muchas opciones entre las cuales podemos generar un tercer archivo ke contenga las diferencias, a este archivo se lo llama "parche", luego el comando "patch" lee este parche y vuelca las diferencias en el original, esto es "parchear", como todo en GNU/Linux es un archivo, podemos parchear directorios (carpetas), archivos, etc., lo ke nunca podemos parchear es un ejecutable, los ejecutables no se pueden modificar de manera convencional, si lo abrimos con un editor de textos lo único ke obtenemos son caracteres raros y si lo modificamos se corrompe y no se ejecuta.

"Lo primero, debo conseguirme los fuentes de mi kernel, pero ¿para que si lo que quiero hacer es parchar un modulo? No el kernel completo."
Ok, sabiendo ke no podemos modificar un módulo ya compilado, necesitamos forzosamente el código fuente, ke es texto plano, para poderlo parchear o editar a mano si conocemos algo de C y Assembler, luego compilarlo, entonces la pregunta es correcta, por ké todo el fuente si sólo kiero generar un módulo?, weno, dependemos de kien ha generado el parche, no todos los desarrolladores tienen ganas de hacer un buen "Makefile" y crear reglas para generar módulos, algunos lo ke hacen es simplemente generar con diff un parche ke debemos aplicar a todo el código fuente, los ke sí proveen de un Makefile nos piden ke tengamos sólo las "headers" o archivos con cabezeras de C del código fuente del kernel, estas headers notablemente pesan mucho menos y contienen la información suficiente para generar módulos, por suerte las distros más grandes nos proveen del fuente completo "kernel-source" y de las headers "kernel-headers".

"Segundo, segun se, kernel-packages tiene algunas utilidades que hacen un poco mas sencilla la tarea de compilar el kernel, debo o conviene instalarlo para parchar/compilar el modulo?"
Automatizar la tarea de parchear, compilar e instalar (en este orden) nunca es bueno, si algo falla no sabremos cómo retroceder o buscar errores.

"Y por ultimo, como instalo el modulo? No me refiero a insmod o modprobe, sino a una vez que se compila, cual es el archivo resultante? un .o? un ejecutable?"
Weno, un módulo es, estrictamente hablando "código objeto", digamos ke ya no es texto plano porke fué compilado o "traducido a lenguaje mákina", pero tampoco es ejecutado por la mákina, las características ke lo harían ejecutable no las tiene, las tiene sí el kernel, el kernel toma este código objeto y dinámicamente lo ejecuta, esto es "cargar un módulo", antes de la aparición de la serie 2.6 del kernel la extensión de los módulos era *.o (ojbect), pero objeto es muy usado en programación en C, objetos son también las librerías compiladas, así ke por convención y legibilidad desde el 2.6 se los nombra como *.ko (kernel object).
En líneas generales un módulo es una porción del kernel ke fué compilada fuera de éste para cargarlo cuando se necesita, así obtenemos un kernel más liviano y estable, el kernel debería ubicarse en el directorio "/boot" por ejemplo "/boot/vmlinuz-2.6.12-9-386", sus módulos en el directorio estándar "/lib/modules", ke para este ejemplo sería "/lib/modules/2.6.12-9-386", notemos la relación directa entre el nombre del kernel y su directorio de módulos, esto es así para ke, llegado el caso de tener varios kernels tengamos sus módulos en lugares separados.
Lo mejor será ke publikes el motivo por el cual tratas de recompilar o parchear, kizás falta de algún soporte de hard?.
Como sea, siempre es mejor plantear las dudas más especificamente para poder ayudar en algo concreto, porke este tema es bastante más largo de lo ke escribí, sólo te doy un empujón.

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Gracias por tu explicacion.

Lo mejor será ke publikes el motivo por el cual tratas de recompilar o parchear, kizás falta de algún soporte de hard?.

Si, efectivamente es para solucionar un problema de hardware, veras, ocurre que intento instalar una alfombra de estas de baile al estilo dance dance revolution, pero dicha alfombra no es mas que un joystick de playstation. Esa alfombra/joystick va conectada al puerto paralelo de la PC. El modulo "gamecon" en conjunto con el modulo "joydev" es quien da soporte para joysticks de diferentes consolas, sin embargo, como en los juegos de baile tienes que saltar y presionar 2 flechas a la vez, el driver (es decir joydev) no reconoce la pulsacion de 2 flechas simultaneamente, es como si en un joystick normal intentaras moverte arriba y abajo, o a la izquierda y derecha simultaneamente, lo que obviamente es imposible en un joystick. Pero dicho modulo no tiene una manera de indicarle que quieres que te detecte pulsaciones en modo digital en vez de analogo. Joydev no admite parametros, pero encontre un parche para ese modulo, para que al joydev se le pueda pasar el parametro analog_to_digital=1 y asi reconozca correctamente la pulsacion de 2 direcciones a la vez, es decir arriba/abajo e izquierda/derecha simultaneamente.

Entonces, como veras, es para agregar una funcionalidad de hardware no soportada por defecto en modulo joydev, la cual es arreglada por medio de ese parche.

En el articulo no se explica como instalarlo, porque claro no es su especialidad (es una pagina de juegos), pero si se indica que da lo mismo compilarlo como parte del kernel o como modulo, yo creo que lo mejor es compilarlo como modulo ya se asi se carga cuando se necesite, pero eso es lo que no se como hacer. Supongo que al compilar tendre una nueva version de joydev, pero eso es lo que no se como hacer para que el kernel diga "aahhh... ahora tengo que cargar la version que DanielGT compilo y no la que yo traigo por defecto"

Ojala puedas ayudarme, o alguna otra persona que pueda ayudar.

Un saludo.

+1
0
-1
Imagen de cjadt
+1
0
-1

Necesito:
- La dirección de la página donde leiste acerca del parche.
- La salida de los comandos:
pingusa:~# cat /proc/version
pingusa:~# gcc --version | grep -i ubuntu
Pero te adelanto ke no es cosa fácil, este patch seguramente es para los kernels "vanilla", los ke bajamos de kernel.org, no para los kernels de las distros ke parchean a los vanilla, pero como decimos los ke usamos Perl "hay más de un camino para hacerlo", es cuestión de intentar...

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Bueno, aqui van las cosas que me pediste

La direccion es http://www.stepmania.com/wiki/Joystick_Axes_Problem#Hack_for_Linux

La salida de cat /proc/version
Linux version 2.6.17-10-386 (root@vernadsky) (gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #2 Fri Oct 13 18:41:40 UTC 2006 (Ubuntu 2.6.17-10.33-386)

Y la salida de gcc --version | grep -i ubuntu
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

Un saludo.

+1
0
-1
Imagen de cjadt
+1
0
-1

Ya lo tengo hecho pero me olvidé de preguntar por las salidas de:
pingusa:~# ls /boot/config*
pingusa:~# ls /boot/vmlinuz*
pingusa:~# sudo modinfo joydev | grep vermagic
De todas formas vamos bajando lo siguiente:
ftp://ftp.um.es/mirror/ubuntu/pool/main/l/linux-source-2.6.17/linux-sour...
Y
http://rushbase.net/linux/linux-2.6.16-joydev_analogtodigital.patch
En cuanto a este parche es ideal bajarlo desde Ubuntu y no desde Win, porke Win le cambia los saltos de línea y retorno de carro al detectar ke es un archivo de texto plano.
Asegurarnos de tener instalado el pakete libncurses5-dev o similar para poder utilizar el "make menuconfig".
Llegados hasta akí tenemos dos opciones:
1- Generar una réplica de los módulos con el joydev.ko modificado.
2- Generar una réplica del kernel y módulos con otro nombre y con el joydev.ko modificado.
Con 1 luego de compilar se puede reemplazar el joydev original por el parcheado.
Con 2 luego de compilar se genera un kernel y módulos totalmente completo y funcional y con otro nombre para no sobreescribir al anterior, la única ventaja es ke si no funciona siempre podemos arrancar con el original.
En cualkier caso no podemos evitar el compilar todo el código fuente al tratarse de un parche.
Luego de esto seguimos...

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Hola de nuevo XD

Disculpa por tardarme tanto en responder, es que estuve muy ocupado con unos temas personales, jejeje.

Bueno, aqui van las cosas que me pediste en tu ultimo post.

La salida de ls /boot/config*
/boot/config-2.6.15-26-386 /boot/config-2.6.17-10-386
/boot/config-2.6.15-27-386

La salida de ls /boot/vmlinuz*
/boot/vmlinuz-2.6.15-26-386 /boot/vmlinuz-2.6.17-10-386
/boot/vmlinuz-2.6.15-27-386

Y la salida de sudo modinfo joydev | grep vermagic
vermagic: 2.6.17-10-386 mod_unload 486 REGPARM gcc-4.1

He bajado lo que me indicaste, aunque aun no he hecho nada con ellos. Ojala puedas seguir ayudandome, pero desde ya te lo agradezco mucho :)

Un saludo.

+1
0
-1
Imagen de cjadt
+1
0
-1

Weno escribo arriba porke no hay suficiente espacio para líneas largas.

+1
0
-1
Imagen de cjadt
+1
0
-1

Weno, supongo ke lo mejor es crear un kernel completo junto con todos sus módulos, así podemos optimizar algunas cosas, además de tener el joydev.ko parcheado.
Digo ke es mejor porke si no tienes experiencia en esto de compilar kernels, cualkier error nos dejaría el kernel actual sin funcionar, además, si tenemos uno nuevo y completo, ya no nos importa la vermagic ni la versión del gcc, luego podemos seguir compilando futuras versiones más optimizadas basadas en el nuevo kernel.
1- Ingresamos en una consola con la combinación de teclas [Ctrl]+[Alt]+[F1], nos logueamos con usuario contraseña y descomprimimos las fuentes del kernel:
pingusa:~# sudo dpkg -i /ruta/hacia/el/linux-source-2.6.17_2.6.17-10.33_all.deb
Con esto se "supone" ke se instalan las fuentes en el directorio "/usr/src", pero si ingresamos en él:
pingusa:~# cd /usr/src
pingusa:/usr/src# ls
Vemos ke las fuentes siguen comprimidas [*.tar.bz2], los de Ubuntu kieren complicar las cosas pero no podrán:
pingusa:/usr/src# sudo bzip2 -dc linux-source-2.6.17.tar.bz2 | tar x
Ahora sí:
pingusa:/usr/src# ls
Y volamos las comprimidas:
pingusa:/usr/src# sudo rm -fv *.bz2
2- Creamos un enlace simbólico para nuestra comodidad:
pingusa:/usr/src# sudo ln -sfv linux-source-2.6.17 linux
pingusa:/usr/src# ls -l
Vemos ke linux apunta a las fuentes.
3- Copiamos el parche:
pingusa:/usr/src# sudo cp -fv /ruta/hacia/linux-2.6.16-joydev_analogtodigital.patch parche
O lo renombramos antes para ke sea más corto el nombre y luego lo copiamos en "/usr/src".
4- Ingresamos en las fuentes con sólo ingresar en el enlace:
pingusa:/usr/src# cd linux
pingusa:/usr/src/linux#
Y parcheamos:
pingusa:/usr/src/linux# sudo patch -p1 < ../parche
Se parchean dos archivos:
drivers/input/Kconfig
drivers/input/joydev.c
Si no da error, estamos listos para configurar y compilar.
5- Limpiamos todo resto de basura y código objeto ke pueda molestar:
pingusa:/usr/src/linux# make mrproper
Con esto también vuela todo rastro de configuración, más precisamente un archivo oculto llamado ".config", este ".config" guarda la selección de configuración, por ejemplo si keremos un driver como módulo, esta selección se guarda en el ".config", este archivo oculto se crea haciendo:
pingusa:/usr/src/linux# make menuconfig
Pero para usar menuconfig debemos tener instalado el pakete libncurses5-dev o similar.
6- Como tenemos las fuentes del kernel ke estamos corriendo usamos el backup del archivo de configuración guardado en "/boot":
pingusa:/usr/src/linux# sudo cp -fv /boot/config-2.6.17-10-386 .config
El punto delante de config es importante porke significa oculto, ahora tenemos la selección original ke hicieron los de Ubuntu con respecto al kernel, osea ke tenemos la misma selección de drivers como módulos y la misma selección de drivers como parte del kernel.
Nos aseguramos ke ".config" esté haciendo:
pingusa:/usr/src/linux# ls -a
7- Editamos el archivo "/usr/src/linux/Makefile" con permisos de root, donde en las primeras líneas encontramos:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = .13-ubuntu1
NAME=Crazed Snow-Weasel

ifdef UBUNTUBUILD
EXTRAVERSION =
endif
Así se construye el nombre del kernel "2.6.17.13-ubuntu1", nosotros keremos algo mejor como "2.6.17-daniel-01" porke es la primer versión, luego en otras compilaciones puede llamarse "2.6.17-daniel-02" y así, para esto sólo cambiamos la variable EXTRAVERSION y volamos el "ifdef..endif" agregando un numeral "#":
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = -daniel-01
NAME=Crazed Snow-Weasel

#ifdef UBUNTUBUILD
#EXTRAVERSION =
#endif
8- Lanzamos el menuconfig, ya no crea el archivo ".config" porke lo encuentra y lo utiliza:
pingusa:/usr/src/linux# sudo make menuconfig
Nos aseguramos ke el encabezado figure como:
Linux Kernel v2.6.17-daniel-01 Configuration
Entonces sabemos ke los cambios en el Makefile funcionaron, así se llamará el kernel.
Para movernos a través del menú usamos las flechas del teclado, para seleccionar usamos la tecla espaciadora o [enter].
Otro dato: <M> significa módulo, <*> significa dentro del kernel.
Hagamos pocos cambios por ahora para ke este kernel arranke, seleccionamos:
En: Processor type and features --> Procesor family -->
Y elegimos el tipo de nuestro procesador.
En: Device Drivers --> Input device support -->
Vemos Joystick interface como módulo y debajo aparece:
Analog to Digital [fix for the Joy Axes Problem] (NEW)
Lo seleccionamos porke éste es el parche.
En: File system
Nos aseguramos ke ext3 esté seleccionado como módulo o como parte del kernel, siempre ke ext3 sea el formato de tus particiones de Ubuntu.
Al salir nos pregunta si guardar los cambios y contestamos "Yes".
9- Compilamos el kernel:
pingusa:/usr/src/linux# sudo make bzImage
Se tomará su tiempo.
10- Luego compilamos los módulos:
pingusa:/usr/src/linux# sudo make modules
Se tomará su tiempo.
11- Instalamos los módulos:
pingusa:/usr/src/linux# sudo make modules_install
12- Hacemos una copia del "/boot/grub/menu.lst" por las dudas y luego:
pingusa:/usr/src/linux# sudo make install
Verificamos ke en el directorio "/boot" exista el kernel "vmlinuz-2.6.17-daniel-01" y "config-2.6.17-daniel-01", el backup de tu ".config":
pingusa:/usr/src/linux# ls /boot/config*
pingusa:/usr/src/linux# ls /boot/vmlinuz*
Además se supone ke se agregó una entrada al Grub, pero si no la hizo, simplemente la agregamos copiando otra entrada ke ya exista en "/boot/grub/menu.lst", luego la modificamos mas o menos así:
_______________________
title Ubuntu, kernel 2.6.17-daniel-01
root (hd0,1)
kernel /boot/vmlinuz-2.6.17-daniel-01 root=/dev/hda2 ro quiet splash
initrd /boot/initrd.img-2.6.17-daniel-01
boot
_______________________
13- Notamos ke aparece un initrd, esto es una imágen de arranke ke el kernel necesita si ext3 fué compilado como módulo, de todas formas la generamos ke no cuesta nada:
pingusa:/usr/src/linux# sudo mkinitrd -o /boot/initrd.img-2.6.17-daniel-01 2.6.17-daniel-01
14- Reiniciamos y probamos el nuevo kernel.

Si algún paso no sale o no se entiende postea.

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Hola, tuve un pequeño contratiempo, el linux source no esta en la direccion ftp que me indicaste.

Da lo mismo si en vez del ftp, lo descargo desde Sinaptic o apt-get desde repositorio de Edgy, verdad?

Segun Sinaptic, tengo disponibles 2 versiones para instalar:

1. linux-source Version 2.6.17.10 Linux kernel source with Ubuntu patches.
2. linux-source-2.6.17 Version 2.6.17.33 Linux kernel source for version 2.6.17 with Ubuntu patches.

Segun me explicaste en un post mas arriba, creo que aprendi y que no por nada me pediste la salida de cat /proc/version, por lo tanto me imagino que la que debo instalar es la segunda opcion, no?

La salida era Linux version 2.6.17-10-386 (root@vernadsky) (gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #2 Fri Oct 13 18:41:40 UTC 2006 (Ubuntu 2.6.17-10.33-386)

+1
0
-1
Imagen de cjadt
+1
0
-1

Supongo ke:
2. linux-source-2.6.17 Version 2.6.17.33
Es la correcta, en realidad no importa mucho porke vas a compilar un kernel completo, por lo tanto no necesitamos nada del anterior, si eliges crear solamente un módulo para agregar al kernel en curso, entonces sí necesitamos las salidas de "cat /proc/version" y demás porke debemos hacer coincidir la versión del compilador gcc, arkitectura, etc. para ke el kernel no lo rechase.
De todas formas, entre más nos acerkemos a las versiones originales mejor, tenemos el mismo compilador así ke sólo faltan las mismas fuentes para hacer una réplica exacta del kernel en uso, con joydev parcheado claro, y esto nos asegura ke se va a compilar, lo digo por experiencia, no se puede compilar cualkier fuente de un kernel con cualkier versión del gcc, sobre todo si a las fuentes se le aplican parches, en este caso "with Ubuntu patches" y kien sabe ke cosas agregaron o kitaron, para ke arriesgarse y perder tiempo probando, y por último, ya apliké el parche en las fuentes ke te pasé y funciona, funciona el parcheado y compilación, si funciona o no la alfombra? mmm...

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Me mando un monton de errores al descomprimir, parece que no va bien lo que instala Sinaptic, pero ahorita mismo estoy bajando el mismo archivo de los fuentes que me indicaste, pero desde un mirror de security.ubuntu.com

La direccion es esta

http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.17/

y el archivo es linux-source-2.6.17_2.6.17-10.33_all.deb

Espero que resulte.

Ya te contare como me va

+1
0
-1
Imagen de cjadt
+1
0
-1

1- Esas fuentes son las correctas.
2- Necesitas esas fuentes para aprovechar el archivo de configuración "/boot/config-2.6.17-10-386", cosa ke se me había olvidado.
3- Corrijo un par de errores, en el punto "5":
Donde dice:
pingusa:/usr/src/linux# make mrproper
Debió decir:
pingusa:/usr/src/linux# sudo make mrproper
Donde dice:
pingusa:/usr/src/linux# make menuconfig
Debió decir:
pingusa:/usr/src/linux# sudo make menuconfig
4- Éxitos.

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Hola.

Compile todo y aparte de algunos warnings y errores ignorados (digo ignorados porque igual siguio la compilacion y me genero correctamente, creo, tanto el nuevo kernel, vmlinuz, como el config), funciono todo bien.

Casi me resulta el paso 4 XDD... no tenia instalado mkinitrd, ya que me salio este error

sudo mkinitrd -o /boot/initrd.img-2.6.17-daniel-01 2.6.17-daniel-01
sudo: mkinitrd: command not found

Asi que instale initrd-tools, pero al ejecutarlo me salio esto

desktop:/usr/src/linux-source-2.6.17$ sudo mkinitrd -o /boot/initrd.img-2.6.17-daniel-01 2.6.17-daniel-01
File descriptor 3 left open
File descriptor 4 left open
File descriptor 5 left open
File descriptor 6 left open
File descriptor 7 left open
Finding all volume groups
No volume groups found
/usr/sbin/mkinitrd: 253:0: Cannot find LVM device

Por las dudas reinicie igual el compu aun cuando me mando error, pero al iniciar con el kernel nuevo me salio Error 15: File not found.

Que puede ser?

+1
0
-1
Imagen de cjadt
+1
0
-1

...Un tremendo bug en Ubuntu, deberías acostumbrarte ja ja ja...
Ok, vamos por partes, si todo lo hiciste exactamente como te dije, usaste correctamente el /boot/config-2.6.17-10-386 copiándolo como ".config" en el directorio de las fuentes y lo tomó, ya tienes una réplica exacta del kernel y sus módulos, el único fallo ya no es mío, es de Ubuntu al crear la imágen de arranke "initrd", esto se nota porke la salida de error "15" de Grub significa ke no encontró algún archivo ke le pasaste, no encontró /boot/initrd.img-2.6.17-daniel-01 porke no existe.
Tenemos dos opciones:
1- Iniciar todo desde cero y seleccionar el sistema de archivos "ext3" como parte del kernel y no como módulo, así no necesitamos la initrd, siempre ke ext3 sea el formato de la partición raíz de Ubuntu.
2- Arreglar el bug.
Weno, elijo la 2 porke es más rápido, otra vez tenemos dos opciones:
A) Si tenemos en el "/etc/fstab" el nuevo estilo para nombrar las particiones:
UUID=bla_bla_bla
Es problable ke mkinitrd esté buscando algo como /dev/xxx y no lo encuentra, podemos editar la línea ke hace referencia a la raíz y volver al viejo estilo:
/dev/hda1 / ext3 defaults...
B) Abrimos para editar y con permisos de root el archivo "/etc/mkinitrd/mkinitrd.conf":
Buscamos la línea:
ROOT=probe
Y la editamos para dejarla así:
ROOT="/dev/hda1"
Por supuesto ke /dev/hda1 es sólo un ejemplo, debemos indicar la partición raíz de Ubuntu.
Te recomiendo la opción "B".
Luego del cambio, generamos la imágen:
pingusa:# sudo mkinitrd -o /boot/initrd.img-2.6.17-daniel-01 2.6.17-daniel-01
Y verificamos ke exista:
pingusa:# ls /boot/initrd*
Reiniciamos con el nuevo kernel.

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Pues... si, arranco XDD, pero como ya me decias, hay que acostumbrarse: No me arrancaron las X jajaja. Si no es una cosa es otra, pero es divertido eh XDDD jajaja.

Me dice que hubo un fallo al cargar el modulo de kernel de Nvidia.

Al respecto, 3 preguntas.

1/ El que compilaste tu lograste arrancarlo normalmente y con Gnome?

2/ Hasta ahora nos hemos ido por el camino de generar un kernel completamente nuevo..... y que hay de meter el joydev que compilamos al hacer make modules y make modules_install, pero en el kernel ya existente? (se puede hacer dicha barbaridad? XDD)

3/ A esta altura como que el post ya se desvirtuo, no? XD

+1
0
-1
Imagen de cjadt
+1
0
-1

Ke las X no arrancasen ya no es asunto mío, debiste decir desde un principio ke instalaste los drivers propietarios de NVidia, éstos no vienen en el source de ningún kernel, además NVidia crea unos archivos de configuración ke se leen en el arranke, un source original no tiene nada de esto, por lo tanto tienes ke repetir el proceso de instalación de NVidia desde sus fuentes bajadas de su página, no desde los repositorios, en los repositorios ya está el driver compilado para la versión del kernel original de Ubuntu "2.6.17-10-386", pero tú tienes el nuevo "2.6.17-daniel-01" y no coinciden.
Problema: NVidia NO se puede instalar si existe una versión anterior en el sistema porke sus archivos de configuración se sobreescriben, habria ke desinstalar todo lo referente a NVidia, compilar NVidia para el original y luego compilar para el nuevo porke el driver es un módulo.
1- El ke compilé arranca las X y no uso Gnome, uso Debian estable, Fluxbox o WindowMaker con el driver "nv".
2- No se puede copiar el joydev.ko sin ke el kernel lo rechase, para esto necesitamos ke la versión mágica coincida, cosa ke kise evitar al hacer un nuevo kernel, comparamos la vermagic del original ke ya la tienes:
pingusa:~# sudo modinfo /lib/modules/2.6.17-10-386/kernel/drivers/input/joydev.ko | grep magic
vermagic: 2.6.17-10-386 mod_unload 486 REGPARM gcc-4.1
Y la del nuevo:
pingusa:~# sudo modinfo /lib/modules/2.6.17-daniel-01/kernel/drivers/input/joydev.ko | grep magic
vermagic: 2.6.17-daniel-01 ???? ?? ???? gcc-4.1
Ya desde el vamos el nombre del kernel no coincide es evidente, no podemos cargarlo sin forzarlo, el forzado puede traer problemas de inestabilidad general, así ke olvídalo.
Pero todavía podemos seguir intentando algo si coinciden por lo menos los parámetros "mod_unload 486 REGPARM", el gcc ya sé ke coincide.
3- Si, se está haciendo un poco largo, pero le puede servir a los demás, así saben el esfuerzo ke significa tener las X con NVidia, compilar un kernel completo, cambiar su nombre, arreglar los bugs de Ubuntu y una alfombra funcionando, todo en el mismo post :-).

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Oh si, no te preocupes ;) supuse que el problema era del driver propietario, y que cualquier cosa relacionada con Nvidia ya escapa al tema original de este post, puesto que para el problema en si ya habia logrado lo que queria: Compilar un kernel y parchar uno de sus modulos.

En si el kernel funciono, el que no haya arrancado las X es un cuento aparte... imagino que entonces debo instalar el driver oficial de Nvidia y luego repetir el proceso.

Bueno...... ahi tendre en que entretenerme ahora XDDD :)

Te agradezco mucho tu ayuda, en verdad hay poca gente que se toma la molestia de explicar detalladamente como tu lo haces, y que mas aun le tenga tanta paciencia a los novatos como uno.

Saludos.

+1
0
-1
Imagen de cjadt
+1
0
-1

...Se puede hacer un módulo y enchufárselo al kernel original, para esto necesito la vermagic de los módulos del kernel daniel-01, arrancamos con él y en la consola tipeamos:
pingusa:~# sudo modinfo joydev | grep magic

Se viene el Joydev Mini-Jautú II, paciencia...

Christian

+1
0
-1
Imagen de cjadt
+1
0
-1

... necesito la vermagic de los módulos de 2.6.17-daniel-01

Christian

+1
0
-1
Imagen de Anónimo
+1
0
-1

Si, no habia leido tus post. Es que no estaba en casa.

Ahorita no estoy en el compu, en cuanto vuelva obtengo los vermagic y te cuento ;)

+1
0
-1
Imagen de danielGT
+1
0
-1

La vermagic:

sudo modinfo joydev|grep magic

vermagic: 2.6.17-daniel-01 mod_unload K8 REGPARM gcc-4.1

Arranque con el kernel nuevo, no?

+1
0
-1
Imagen de cjadt
+1
0
-1

Ja, me gustó lo de "K8", parece ke le vas agarrando el gustito a la cosa :-)
Weno, pero tenemos ke ir para atrás, empezamos otra vez, la idea es ke las versiones mágicas coincidan:
2.6.17-10-386 mod_unload 486 REGPARM gcc-4.1 (original)
2.6.17-daniel-01 mod_unload K8 REGPARM gcc-4.1 (nuevo)

1- Hacemos un backup del módulo original, primero creamos un directorio en la casa del usuario:
Si no estoy seguro de estar en mi casa:
pingusa:~# pwd
/home/daniel
Luego:
pingusa:~# mkdir -m 777 joydev-bkp
pingusa:~# sudo cp -fvp /lib/modules/2.6.17-10-386/kernel/drivers/input/joydev.ko joydev-bkp
Ya tenemos el módulo copiado por las dudas.

2- Editamos con permisos de root el archivo "/usr/src/linux-source-2.6.17/Makefile"
Otra vez cambiamos esto:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = -daniel-01
NAME=Crazed Snow-Weasel

Por esto:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = -10-386
NAME=Crazed Snow-Weasel
La vermagic ahora será:
2.6.17-10-386 mod_unload K8 REGPARM gcc-4.1

3- Ingresamos en las fuentes:
pingusa:~# cd /usr/src/linux
Doy por hecho ke pudiste hacer el link "linux", no?
Si no:
pingusa:~# cd /usr/src/linux-source-2.6.17
Renombramos el ".config" para ke durante la limpieza no se borre:
pingusa:/usr/src/linux# sudo mv -fv .config confy
pingusa:/usr/src/linux# sudo make -s mrproper
"-s" en silencio.
pingusa:/usr/src/linux# sudo mv -fv confy .config
pingusa:/usr/src/linux# sudo make menuconfig
Nos aseguramos ke el encabezado figure como:
Linux Kernel v2.6.17-10-386 Configuration
En: Processor type and features --> Procesor family -->
Elegimos 486, aunke no nos guste.
La vermagic ahora será:
2.6.17-10-386 mod_unload 486 REGPARM gcc-4.1
Exactamente igual ke la otra, el nuevo módulo no será rechazado por el kernel original.

4- Compilamos los módulos:
pingusa:/usr/src/linux# sudo make -s modules
Esperamos un buen rato, tal vez hubiera sido mejor desmarcar muchos drivers como módulos para ke tarde menos, pero esto de elegir ke sacar también lleva tiempo.

5- Ahora debemos encontrar el joydev, y para ke no lo buskes:
pingusa:/usr/src/linux# sudo modinfo drivers/input/joydev.ko | grep magic
vermagic: 2.6.17-10-386 mod_unload 486 REGPARM gcc-4.1
Debe ser ésta la salida.

6- Copiamos el módulo:
pingusa:/usr/src/linux# sudo cp -fv drivers/input/joydev.ko \
> /lib/modules/2.6.17-10-386/kernel/drivers/input/joydev.ko
En Bash cuando usamos la barra invertida "\" y luego [enter] nos permite seguir escribiendo debajo en una segunda línea como si fuese parte de la primera, esto sirve cuando tenemos líneas largas como éstas.
Nos aseguramos del dueño y los permisos:
pingusa:/usr/src/linux# sudo chown root.root \
> /lib/modules/2.6.17-10-386/kernel/drivers/input/joydev.ko
pingusa:/usr/src/linux# sudo chmod 644 \
> /lib/modules/2.6.17-10-386/kernel/drivers/input/joydev.ko

7- Sin cargar ni descargar el módulo, reiniciamos con el kernel original.

FIN?

+1
0
-1
Imagen de danielGT
+1
0
-1

Antes de hacer todo esto, me asalta una duda:

Si salen nuevas versiones de kernels (de hecho ya salio un nuevo kernel en el repositorio de Ubuntu), es lo mismo verdad? Es decir, me aseguro de tener el kernel 2.6.17-10.33 actualizado ahora a 2.6.17-10.34, y tener los fuentes obviamente actualizados tambien y luego empiezo desde cero la explicacion que me acabas de dar, no?

Bueno, ahora pondre manos a la obra (no actualizare kernel aun).

+1
0
-1
Imagen de danielGT
+1
0
-1

Otra duda mas:

Por motivos de mi responsabilidad (acabo de estropear la distro XDDD) tuve que formatear de nuevo.

Esta todo casi igual excepto que salio una nueva version del kernel (2.6.17-10.34), por lo que ya no tengo ninguna version mia ni tampoco existe un 2.6.17-daniel01.

Entonces ahora la unica diferencia es que, debo primero debo parchar de nuevo el modulo y seguir con el Joydev Mini-"Jautú" 2, verdad? XDDDD

+1
0
-1
Imagen de cjadt
+1
0
-1

Lo importante es entender bien las cuestiones generales, no se justifica actualizar un kernel a cada rato a menos ke necesitemos soporte de hard ke sólo tiene la última versión, la mayoría de las actualizaciones del kernel son parches de seguridad ke no hacen gran diferencia en una mákina de escritorio, sí lo hacen en servidores donde la seguridad es importante.
Cuando instalamos drivers ke están directamente relacionados con el kernel, en realidad ya no se los nombra como drivers sino como módulos, porke son eso exactamente, el típico caso de NVidia ke genera un nvidia.ko en el directorio "/lib/modules/mikernel/".
Este driver es especialmente problemático no porke genera un módulo, sino ke genera también archivos de configuración ke se leen durante el arranke, cuando haces un kernel customizado y no tiene soporte de NVidia, la distro lee los archivos de configuración, no encuentra NVidia y no se inician las X.
Tendrías ke asegurarte ke la nueva versión del kernel tiene soporte de NVidia ya precompilado, "restricted modules", porke de lo contrario tenemos ke bajar las fuentes desde su página y compilar para el nuevo kernel.
Cada vez ke cambiamos de kernel se genera un nuevo "/boot/config-nuevokernel" donde se guardó la selección de configuración de éste durante su compilación, este archivo lo aprovechamos como ".config".
Sea cual sea el kernel ke tengas, si ya tienes soporte de NVidia no podemos hacer uno customizado por la razones anteriores, debemos seguir con el ke tenemos y parchear el joydev.
1- El Mini-Jautú II está basado en la versión mágica del kernel ke tenías, si coincide con este nuevo kernel de la "reinstalación" se puede aplicar.
2- Si no coincide hay ke empezar de nuevo.
3- Si hay ke empezar de nuevo, ya sabes:
Tienes NVidia? si/no.
cat /proc/version ?
gcc --version ?
sudo modinfo joydev | grep magic ?
4- El parche era para la versión 2.6.16 y probé ke funciona en 2.6.17, no será así en futuras versiones.

Christian

+1
0
-1
Imagen de danielGT
+1
0
-1

Comprendo..

Empezare de nuevo entonces... creo que no tendre problemas. Ya te contare como me va.

Un saludo.

PD: Empezare a manejar respaldos, esto ya empieza a ser peligroso :)

+1
0
-1