Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'módulos'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 10 resultados

  1. Hacía tiempo que quería escribir algo parecido, pero he de reconocer que me había olvidado por completo y hasta hoy no me ha venido de nuevo a la memoria y viendo que hay por ahí quien ya se me ha adelantado ¿Por qué no? El initrd (Init Ram Disc) o, en la actualidad, initramfs, es un sistema temporal de archivos utilizado durante el arranque del sistema y tiene como misión cargar en ram aquellos módulos y otros elementos necesarios para el arranque del sistema y que son necesarios antes de que haya sido montado el directorio raíz. Es decir, suministra al kernel aquellos módulos que no han sido incluido en él pero que son necesarios para poder arrancar el equipo. Sin embargo, puede ocurrir que las imágenes de arranque por defecto de un disco de instalación, en este ejemplo Debian, no tengan los módulos que necesitamos para que el sistema arranque o que no lo haga como es debido, así que no nos queda otra que remangarnos y poner manos a la obra No me voy a parar a describir el proceso de compilación de módulos del kernel, eso es otro tema, sólo la parte que corresponde a la modificación de la imagen y posterior "reempaquetado". COmpilar Kernels y módulos ya lo hemos tratado antes: Como era de esperar, necesitaremos la imagen o imágenes de arranque para poder trabajar con ellas. Lo habitual es que estén incluidas en la imagen iso de Debian, pero la versión más reciente y actualizada la encontraremos también en la ftp de Debian junto con dichas imágenes de instalación. En este caso me interesan las imágenes de arranque de una Debian Testing Amd64, por lo que me voy a buscar las imágenes del installer-amd64 actuales http://ftp.debian.org/debian/dists/testing/main/installer-amd64/current/images/ Vemos que aquí tenemos 3 opciones distintas Neetbot Cdrom Hd-media Depende de la imagen de instalación que queramos modificar, nos decantaremos por una o por otra. Yo me iré a por la Netboot, que me hace ilusión axel http://ftp.de.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz axel http://ftp.de.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux Vemos que me he descargado ambas, tanto la imagen de Linux como la initrd.img Descomprimirla para trabajar con ella no requerirá demasiado esfuerzo, pero puede no resultar tan intuitivo como cabría esperar, ya que se trata de una archivo cpio comprimido y teniendo en cuenta que nos va a descomprimir un gran número de directorios separados, lo mejor que podemos hacer es trabajar dentro de una carpeta aislada para no volvernos locos después. mkdir initrd cp initrd.gz initrd cd initrd gzip -cd initrd.gz | cpio -id El resultado de descomprimir la imagen será parecido al directorio raíz de un sistema instalado root@Shiba:/home/shiba/initrd# ls -la total 24240 drwxr-xr-x 17 shiba shiba 4096 abr 21 12:35 . drwxr-xr-x 36 shiba shiba 24576 abr 21 12:34 .. drwxr-xr-x 2 root root 4096 abr 21 12:35 bin drwxr-xr-x 2 root root 4096 abr 21 12:36 dev drwxr-xr-x 12 root root 4096 abr 21 12:35 etc -rwxr-xr-x 1 shiba shiba 456 abr 21 12:35 init drwxr-xr-x 2 root root 4096 abr 21 12:35 initrd -rw-r--r-- 1 shiba shiba 24719513 abr 21 12:34 initrd.gz drwxr-xr-x 14 root root 4096 abr 21 12:35 lib drwxrwxr-x 2 root root 4096 abr 21 12:35 lib64 drwxr-xr-x 2 root root 4096 abr 21 12:35 media drwxr-xr-x 2 root root 4096 abr 21 12:35 mnt drwxr-xr-x 2 root root 4096 abr 21 12:35 proc drwxr-xr-x 2 root root 4096 abr 21 12:35 run drwxr-xr-x 2 root root 4096 abr 21 12:35 sbin drwxr-xr-x 2 root root 4096 abr 21 12:35 sys drwxrwxr-x 2 root root 4096 abr 21 12:35 tmp drwxrwxr-x 6 root root 4096 abr 21 12:35 usr drwxrwxr-x 6 root root 4096 abr 21 12:35 var En este punto ya estaríamos en disposición de compilar los módulos que necesitamos incluir y colocarlos en los directorios correspondientes, que como cualquier sistemas debería ser /lib/modules/Versión-arquitectura/kernel. Eso sí, tengamos en cuenta precisamente lo que he marcado en rojo, la versión y arquitectura del kernel en el que está basado la imagen. Por ejemplo, sustituir el módulo ath9k para una tarjeta wifi muy nueva que blablabla no nos interesa la historia... root@Shiba:/lib/modules# find . -name ath9k.ko ./4.9.0-1-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko ./4.9.0-2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko Pues compilamos por separado la versión funcional del módulo y lo sustituimos ahí para que luego sea cargado por el instalador. Así de sencillo cp ath9k.ko ~/initrd/lib/modules/4.9.0-2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko Puede ocurrir y ocurre que cuando nos enfrentamos a la tarea de compilar un módulo para una versión de Linux concreta, el sistema desde el que lo hacemos trabaja con otra diferente y las cosas se ponen un poco complicadas. Una forma un poco bruta pero funcional de lidiar con esto e modificar el archivo make para modifica o añadir la opción de compilar para la versión concreta a la que apuntamos: Si no se trata de sustituir sino de incluir un módulo que no está incluido en la imagen initrd original, el proceso es idéntico, copiaríamos el módulo en el lugar que le correspondería dentro de /lib/modules, creando los directorios necesarios, pero tendríamos también que modificar el archivo init para que sea tenido en cuenta y cargado durante el arranque. Dicho archivo lo encontraremos en lo que sería el directorio raíz de la imagen initrd, en mi caso: root@Shiba:/home/shiba/initrd# nano init #!/bin/sh -e # used for initramfs export PATH . /lib/debian-installer/init-debug debugshell "just booted" mount /run mkdir -p /run/lock mount /proc mount /sys /lib/debian-installer/start-udev init='/bin/busybox init' for i in $(cat /proc/cmdline); do case $i in init=/init|init=init) # Avoid endless loop : ;; init=*) init=${i#init=} ;; noshell) sed -i '/^tty[23]/s/^/#/' /etc/inittab ;; esac done debugshell "before init" exec $init Y no nos complicamos en absoluto, simplemente cargamos dicho módulo, con la ruta recién creada bien definida, haciendo uso de modprobe Pero como ya he dicho, mi intención es no pararme a describir el proceso de compilar un módulo para el kernel sino otros menesteres y ya que estoy metido en faena y era una tarea que tenía pendiente, voy a modificar los banners que se muestran en el instalador de Debian para ajustarlos a GNU/Linux Vagos y que todo se vea más bonito ¿Qué les parece? Que por cierto, se encuentra dentro del directorio install o install-arquitectura y ya que los banners que quiero cambiar son para la versión gráfica, será la imagen initrd GTK, la otra es para el modo texto. Y sí, así de complicado es esto Una vez descomprimida, para encontrar los banners del instalador debemos mirar dentro de /usr/share/graphics y sustituirlos por los que queremos incluir con el nombre de logo_debian.png o logo_debian_dark.png, depende de si luego fijamos el tema claro u oscuro Los he hecho deprisa y corriendo, tampoco se pongan muy exigentes Evidentemente, los temas gtk2 los encontraremos, como es de esperar, en /usr/share/themes y por defecto habrán dos, Clearlooks y Dark. Quien quiera ponerse con el aspecto de la ventana del instalador, tiene vía libre para modificar los archivos gtrkc como si no hubiera mañana para que luzca como mejor le parezca. Yo me limitaré a poner el oscuro por defecto y poco más, que saben que a mí las cuestiones de personalización no me atraen mucho que digamos Y una vez nos hayamos quedado a gusto añadiendo y modificando módulos y poniendo paras arriba el instalador ha llegado la hora de volver a comprimir la imagen de arranque para incluirla en la imagen iso de instalación de Debian. En definitiva, comprimamos la imagen initrd que es a lo que venimos find . | cpio -o -H newc | gzip > ../initrd.gz Y reempaquetamos la imagen iso de instalación de Debian, que también está perfectamente descrito en el foro, as que no me hagan repetirme Si no la he cagado demasiado ahora, cuando arranque la imagen de instalación de Debian, se cargarán los banners y el tema que he definido en la imagen de arranque y el instalador de Debian que dará precioso y cuco O bueno... que conste yo ya avisé que las cuestiones de personalización no eran precisamente mi fuerte Vamos a intentar arreglarlo como buenamente se pueda, pero no prometo nada
  2. Pasadas las fiestas, volvemos a la carga con una nueva versión de Linux, que llega, como siempre, con interesantes novedades, mejoras y correcciones. Entre las novedades destacadas de la 4.4 tenemos: Soporte para las futuras APUs de AMD Stoney Graphics Comienzan los trabajos para integrar el nuevo controlador AMDGPU para gráficas Carrizo, Tonga y Fiji, habilitando el planificador AMDGPU por defecto, añadiendo nuevos opcodes AtomBIOS, aunque aún sin administrador de energía. Controlador KMS para Raspberry Pi, gracias al trabajo de Eric Anholt, de Broadcom. Desafortunadamente aún no es capaz de lidiar con la aceleración gráfica 3D o la administración de energía Código para VirtiO VirGL en Gallium 3D Mejoras en la administración de la memoria Un dispositivo de bucle más delgado y más rápido que soporta entradas y salidas asíncronas y directas Mejoras en estabilidad y Re-Clocking para los controladores Nouveau. El controlador MSM Freedreno nos brinda soporte para el nuevo socket de Qualcomm, el Snapdragon 820 Mejoras y correcciones para el controlador DRM de Intel para GPUs Skylake y Broxton Mejoras en el soporte UEFI 2.5, incluyendo EFI ARM64 y AArch64 Soporte para los nuevas tarjetas Wifi Realtek rtl8xxxu Soporte para programas eBPF No-Root Soporte para mapas/programas persistentes con eBPF Soporte para sonido Lewisburg de Intel Mejor soporte para los touchpads de precisión Skylake de Win8, el nuevo teclado Corsair Vengeance K90 y soporte para el volante Logitech G29 Soporte para el cntrol remoto de la TV Goole Fiber Mejor soporte para los portátiles Toshiba Numerosos cambios para KVM x86 Mejor soporte TPM 2.0 (Trusted Platform Module 2) Actualizaciones para la plataforma Chrome, que incluye trabajos para el Pixel 2015 Manejo espacial para dar soporte a la tecla ESC de los nuevos portátiles Lenovo Importantes correcciones para la encriptación de sistemas de ficheros EXT4 Más correcciiones para RAIDs 5/6 Btrfs Mejor estabilidad y rendimiento de Flash-Friendly File-System (F2FS) Soporte para SSD Open-Channel a través de LightNVM El código de ensamblado de x86 continúa siendo reescrito en C Soporte SHA Optimizado utilizando las extensiones SHA de Intel La utilidad Kconfig de ha sido portada a QT5 El código fuente, como es habitual, está disponible en Kernel.org, para todos aquellos que quieran echarle un vistazo o empezar a trastear con él inmediatamente
  3. Después del cambio de numeración en las versiones del kernel engendrado por el finlandés Linus Torlvalds y que nos llevó de la 3.x a la 4.0, ya tenemos una nueva e interesante versión, la 4.1, que, como siempre, nos trae novedades, grandes mejoras y numerosas correcciones. Entre lo más destacado de Linux 4.1 tenemos: Aumento significativo de rendimiento para ciertos componentes de hardware, especialmente los Intel Atom y los AMD Bulldozer Mejora en el consumo energético y eficiencia del hardware de Intel, con los cambios de P-State para los Bay Trail y Cherry Trail Mejoras en el controlador libre Nouveau, que ahora cuenta con soporte para las Geforce 750 Soporte para Intel XenGT vGPU Soporte para Radeon DisplayPort MST Encriptación del sistema de ficheros EXT4 llevada a cabo por Google en un intento de añadir niveles de cifrado Ext4 en Android Mejoras en el soporte para RAID 5/6 con MD RAID Mejoras generales para los portátiles de todos los fabricantes, pero en especial de los Chromebook Pixel 2, Dell y Toshiba. Se sigue trabajando en el soporte para Intel Skylake, que será lanzado a finales de año Soporte ACPI para arquitecturas AArch64 y ARM 64 Introducción de vGEM (virtual GEM graphics driver) Se añade TraceFS al kernel Soporte para la "Lightbar" de Chrome OS Soporte para Force feedback / rumble para el gamepad de xbox One Nuevo driver PMEM Soporte para Wacom HID Mejoras sustanciales para los sistemas de ficheros F2FS, XFS y BTRFS Modernización del sistema de sonido con un bus estándar para ALSA en el secuenciador y el núcleo de HD-audio code Como siempre, podemos descargar el código fuente desde Kernel.org Y consultar con más detalle todos los cambios que se han producido en esta versión en Kernel newbies
  4. "Diseased Newt" que es como ha sido apodada la última versión estable del kernel Linux, ha sido lanzada hoy mismo, convirtiéndose en la primera versión estable en ser liberada este año. Como es habitual, viene cargado de correcciones, pero sobre todo de novedades que incluyen soporte para gran cantidad de hardware nuevo: Intel Soporte inicial para la arquitectura Skylake (Aún no a la venta) Se corrigen varios problemas con el chip gráfico i830M PPGTT (Per-Process Graphics Translation Tables) función que permite el aislamiento de los procesos de la GPU en arquitecturas Ivy Bridge, Haswell y Broadwell, vuelve a estar habilitado por defecto. Se unifica los trabajos de suspensión, hiber, despertar e hibernar. Se añade la posibilidad de rotar cursores 180º Mejoras en el soporte de Cherryview en los Atoms de nueva generación. Se ha iniciado la eliminación del soporte para DRI1 y UMS. Mejoras en el control de la retroiluminación para el Dell Vostro 3546. Soporte de MPX (Memory Protection Extensions System Architecture) para x86. AMD Mejoras de rendimiento en la gestión de memoria TTM (Translation Table Manager). Parches para la gestión de energía en modelos actuales. Se incorpora finalmente el controlador AMDKFD que da soporte a HSA (Heterogeneous System Architecture). Se añade la posibilidad de habilitar el control de ventiladores para las arquitecturas South Islands y Sea Islands. Mejoras en el rendimiento GPUVM multi-ring. Se solucionan algunos problemas con los cursores. Nvidia Soporte para el control de tensión en los Tegra K1. Soporte para el chip GM204. Mejoras en el control de cambio de frecuencia de la memoria en los modelos GM21x. Otros fabricantes El controlador libre para las GPUs de Qualcomm Adreno incluye ahora soporte para la serie A4. El controlador para los gráficos de STMicroelectronics ahora tiene soporte para la selección del adaptador HDMI por i2c. Dispositivos de entrada y salida Soporte para más dispositivos multitáctiles. El controlador para dispositivos Logitech ahora soporta el protocolo específico del fabricante HID++. Soporte para el modelo Wireless Touchpad T650 de Logitech. Soporte para el Surface Pro 3 Type Cover de Microsoft. Mejoras en el soporte de RMI. Mejoras en el controlador para dispositivos Wacom. Se añaden dos nuevos controladores para el touchpad I2C y la pantalla táctil que se encuentran muchos Chromebooks y otros dispositivos. Se incluye un controlador para el panel tactil Goodix. Sistemas de archivos El sistema de archivos OverlayFS, un servicio del kernel que da la posibilidad de montar varios sistemas de archivos distintos a la vez aparentando ser un sólo sistemas de archivos. Mejoras en F2FS Ext4 gran cantidad de correcciónes. Además se optimiza la utilización de la CPU. XFS recibe cambios relacionados con el formato del encabezado. Se han movido a la biblioteca libxfs algunas estructuras compartidas con el espacio de usuario. Btrfs, se ha mejorado el soporte para RAID 5 y 6. SquashFS ahora cuenta con soporte para compresión con LZ4. CephFS, soporte para datos inline. Se han solucionado también algunos fallos. Gestión de energía Se introduce una interfaz unificada para acceder a las propiedades de los dispositivos que ofrece el firmware. De esa forma, los controladores no tienen que preocuparse sobre de dónde vienen dichas propiedades. Se inluye soporte para P-States en el controlador intel_pstate de Linux 3.19. Usará CPUID para detectar si el procesador soporta la característica y en cuyo caso, se habilita por defecto. P-States se puede deshabilitar manualmente. Esta técnica para regular la frecuencia en procesadores recientes de Intel, consigue un rendimiento superior frente al clásico método ofrecido por CPUfreq. Mejoras en la gestión de energía de las plataformas de Intel Baytrail-T y Baytrail-T-CR. Soporte para _DEP. El controlador para los ventiladores de ACPI ahora crea interfaces de dispositivos de refrigeración con nombres que reflejan las identificaciones de los dispositivos ACPI a los que están asociados. Otros Dispositivos Mejoras de rendimiento en controladores RAID6 en device mapper. Soporte para el audio de los nuevos SoCs x86 de Intel y los adaptadores USB de audio de Focusrite Scarlett, Digidesign Mbox1, los DACs de Denon/Marantz y Zoom R16/24. También se añade soporte para los auriculares con ASoC TI TS3A227E. La arquitectura MIPS recibe una gran cantidad de cambios entre los que destacan la mejora de las trazas inversas en sistemas multiprocesador, cambio a la plataforma ATH79 para usar la biblioteca del firmware, mejoras en la documentación de GIC, mejoras en el código de la plataforma Loongson 3, arreglo de fallos en la plataforma Loongson 1B, optimizaciones en el soporte para microMIPS, se añade soporte para plataformas ATH25 y muchos otros cambios. El controlador thinkpad-acpi soluciona problemas relacionados con el silenciado del audio y ahora se realiza mediante software. El controlador dell-laptop para portátiles dobla su tamaño para dar soporte a la retroiluminación del teclado. Se solucionan numerosos fallos en los codecs de HD-audio de Realtek. Otros cambios Se incluye soporte completo para dispositivos no coherentes en ARM. En las máquinas virtuales x86 PVHVM, se usa APIC para las interrupciones si se han virtualizado por hardware. Como es habitual, a través de http://kernel.org, aquellos que no se resistan a compilarlo con sus propias manos pueden obtener el código fuente de esta nueva versión Y en Kernel newbies tendremos en detalle todos y cada uno de los cambios introducidos en Linux 3.19
  5. El pingüino sigue avanzando y ya tenemos en nuestras manos una nueva versión recién salida del horno. Linux 3.15 llega con fuerza y cargado de novedades, entre las que destacan: Soporte para el modo mixto EFI pensado para correr sistemas de 64bits en sistemas UEFI de 32 bits. Tiempos de suspensión y restauración más rápidos. Soporte inicial para GPUs Nvidia Maxwell. Soporte para codificación VCE 2.0 para gráficas Radeon recientes. Soporte para el DualShock 4 de Sony. Soporte para las extensiones de CPU AVX-512 y RDSEED. Se ha mejorado los controladores de sonido, además de añadir soporte DPCM para Intel Haswell y Bay Trails. Mejoras de rendimiento para Btrfs. Dejan de tener soporte las siguientes plataformas x86: SGI Visual Workstation Sequent Computer Systems NUMAQ IBM Summit/EXA Unisys ES7000 Soporte para DisplayPort a 5.4 Ghz. Soporte Fastboot para procesadores Haswell y Broadwell. Soporte las APUs Mullins de AMD Soporte el chipset WiFi Realtek RTL8723AU Se deshabilita la gestión de energía para las GPUs RV770 AMD. Como es habitual, todos los cambios están recogidos en el portal de Kernel Newbies Y podemos obtener el código fuente desde: Kernel.org https://lkml.org/lkml/2014/6/8/70
  6. Fiel a su cita, la nueva versión de Linux, 3.12, ya ha alcanzado el estado estable y nos trae numerosas mejoras a los usuarios. Especialmente para los poseedores de tarjetas AMD y aquellos con portátiles con doble GPU Entre las novedades de esta nueva versión del Kernel pingüino destacan: Soporte para deduplicación Offline de datos en Btrfs (El traductor se quedará hoy sin cobrar) Mejoras sustanciales de rendimiento para las AMD Radeon GPU Switching o cambio automático de GPU para equipos con más de una tarjeta gráfica (Optimus/PowerExpress) RAID5 multithreading Mejorado el soporte timerless multitasking Mejor manejo del estado Out-Of-Memory (Memoria ram/swap al 100%) Mejoras para el sistema de ficheros XFS Como siempre, el código fuente lo podemos obtener desde https://www.kernel.org/ Y para una lista más detallada de todas las novedades http://kernelnewbies.org/LinuxChanges
  7. Si bien Linux, como kernel, cumple de sobra con los requisitos que podemos tener con cualquier equipo y su hardware, hay situaciones en las que los módulos incluidos en el kernel de nuestra distribución no son suficientes y debemos recurrir a instalar y o compilar algún módulo externo. Esto ocurre muy a menudo con los controladores privativos de Nvidia o AMD y también con muchos periféricos que bien por su carácter privativo o por no haber entrado todavía en la línea de desarrollo del kernel, no pueden ser incluidos en éste. Desde hace ya varios años, existe DKMS (Dynamic Kernel Module Support), que nos permite gestionar los módulos ajenos al kernel de manera sencilla o, como su propio nombre indica, dinámica. Para los que solemos compilar las últimas versiones de Linux antes de que lleguen a nuestra distribución o configuradas de alguna manera especial, los que instalamos algún controlador de hardware manualmente porque no está incluidos en repositorios o queremos tener una versión concreta del mismo, podemos valernos de DKMS para que, ante cualquier cambio o actualización del kernel, los controladores ajenos a este sigan funcionando sin tener que volver a instalarlos o compilarlos por nuestra propia mano una y otra vez. El proceso llevado a cabo por DKMS, explicado un poco por encima para entendernos, es básicamente una comprobación durante el arranque del sistema de los módulos instalados y el Kernel en ejecución. En caso de detectar cambios, automáticamente se compilarán de nuevo los módulos externos que hayan dejado de funcionar para la versión de Linux con la que estamos arrancando. De esta manera, podremos tener diferentes versione del kernel en la misma máquina sin temor a que los módulos funcionen para unas versiones y al arrancar con otras no lo hagan, así como también nos servirá para evitar perder los controladores compilados/instalados a mano cada vez que aparece una actualización del kernel oficial de nuestra distribución o cualquier otra situación similar ¿Cómo podemos aprovecharnos de todas las ventajas que DKMS nos ofrece? A día de hoy, la mayoría de las distribuciones tienen paquetes preparado para hacer uso de la "magia" de dkms para los módulos externos incluidos en sus repositorios o en las ramas no-libres de estos. Siendo así, sólo tendríamos que instalar dkms (si no lo tenemos ya) y los paquetes correspondientes al módulo que queremos instalar/automatizar, ya sea nvidia-kernel-dkms, fglrx-modules-dkms, virtualbox-dkms, etc Por poner un ejemplo sencillo, veamos cómo se instalarían los controladores de Nvidia en varias distribuciones, haciendo uso de los paquetes preparados para dkms provisto por cada una ellas. Sin olvidar en ninguno de los casos, que necesitaremos las cabeceras del kernel para poder compilar los módulos, ya sea el kernel oficial de la distribución que usamos o el código fuente compilado por nosotros. Debian aptitude install dkms linux-headers-`uname -r` nvidia-kernel-dkms Fedora En este caso concreto, vamos a hacer una excepción. En lugar de dkms, Fedora se decanta más por aKmod, que es muy similar dkms y cumple el mismo objetivo, automatizar la instalación de controladores ajenos al kernel. Simplemente instalamos el paquete creado para tal fin yum install akmod-nvidia Arch Para Arch no existe ningún paquete dkms en el repositorio principal de la distribución, salvo los de Virtuabox y Open-VM, por lo que tendremos que valernos de los paquetes de AUR. Necesitaremos nvidia-hook que nos permitirá automatizar el proceso, y también nvidia-dkms para tener el código fuente que vamos a compilar luego. Como es habitual, en la wiki de Arch está muy bien explicado por si queremos profundizar aún más o realizar toda la configuración/compilación manualmente yaourt -S nvidia-dkms nvidia-hook ¿Y si el módulo cuya compilación queremos automatizar no se encuentra en ningún paquete de los repositorios de nuestra distribución? Como hemos visto en el ejemplo, cada distribución tiene su propia manera de hacer las cosas y no ofrecen los mismos paquetes o, a veces, ni siquiera los mismos métodos. Este es realmente el punto de este pequeño tutorial, porque instalar un paquete que ya ha sido preparado para trabajar con dkms es muy sencillo, no hay ninguna diferencia con instalar otro paquete o la versión "convencional" sin dkms. Para posteriores ejemplos no lo volveré a escribir, pero vuelvo a recordar que es imperativo que tengamos las cabeceras del kernel instaladas o, si hemos compilado una versión concreta de Linux por nuestra cuenta tener las cosas en su lugar y bien enlazadas. También se cae de maduro que para poder hacer uso de Dkms tendremos que tener instalados los paquetes del mismo y dicho servicio habilitado en el arranque (Los que trabajen con systemD pongan especial atención a esto último) Procedimiento Lo primero y posiblemente lo más importante, es contar con el código fuente o instalador del módulo que vamos a compilar, sin eso no podemos hacer nada Como todo se entiende mejor con un ejemplo, ya que antes fueron controladores gráficos, ahora vamos a por controladores Wireless. Supongo que todos, en alguna ocasión hemos tenido que lidiar o hemos oído hablar de los Compat-Wireless, actualmente renombrados como Compat-Drivers. Simplemente ir a la página de descarga y conseguir la versión que corresponde a nuestro caso. Personalmente me decantaré por la 3.11, que es la versión de Linux que estoy utilizando en estos momentos, teniendo en cuenta que las fuentes y el archivo de configuración deben ir siempre en /usr/src, así que lo descargaré directamente ahí: cd /usr/src wget http://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.11-rc3/backports-3.11-rc3-1.tar.bz2 tar xvf backports-3.11-rc3-1.tar.bz2 Una vez hemos descargado y descomprimido el material en /usr/src, empieza el verdadero trabajo. La clave de todo será el archivo de configuración dkms.conf, que como no lo tenemos, tendremos que crearlo manualmente. Aunque no es necesario que completemos todos los datos, cuanto más específico lo hagamos, mejores resultados podremos obtener. Así, en este caso, un archivo de configuración que nos podría servir sería algo parecido a esto: ##Archivo de configuración dkms.conf para la instalación automática de los controladores compat-drivers haciendo uso de dkms PACKAGE_NAME="backports" PACKAGE_VERSION="3.11-rc3-1" MAKE[0]="make; make install" BUILT_MODULE_NAME[0]="${PACKAGE_NAME}" BUILT_MODULE_LOCATION[1]="drivers/net/ethernet/${PACKAGE_NAME}/" DEST_MODULE_NAME[0]="${PACKAGE_NAME}" DEST_MODULE_LOCATION[0]="/extra/${PACKAGE_NAME}/" AUTOINSTALL="yes" Como vemos, es bastante específico, tenemos nombre y versión del módulo que, si se fijan bien, coinciden con lo que está indicado en el nombre de la carpeta que contiene el código fuente que hemos descomprimido en /usr/src. Esto es importante para que luego dkms pueda dar con ella. También hemos usado el nombre y la versión para llevar a cabo el resto de pasos, tanto para definir rutas como comandos para compilar el módulo, así como el nombre que tendrá el módulo compilado, dónde estará localizado una vez termine el proceso. Una cuestion de simple comodidad. Por supuesto, hemos puesto la autoinstalación como "yes" para que cumpla con lo que nos hemos propuesto Aún sin ser necesario, crear un buen archivo de configuración dkms.conf puede resultar muy útil. En el caso de este ejemplo, podríamos querer compilar únicamente un controlador o familia de controladores de los compat-drivers y no todos los controladores a la vez. Tan sólo habría que hacer una pequeña modificación en la línea de compilado (Make[x]), con los cambios que queremos introducir, que vamos a suponer que para este ejemplo es la instalación de la familia de controladores iwlwifi Sabemos que para este menester, los compat-drivers permiten seleccionar el controlador con la orden "make defconfig-`modulo`" (Con los compat wireless se utilizaba el script "driver-select"), así que nos valdremos de ella y la incluiremos en el archivo de configuración. ##Archivo de configuración dkms.conf para la instalación automática de los controladores iwlwifi pertenecientes al conjunto de los compat-drivers haciendo uso de dkms PACKAGE_NAME="backports" PACKAGE_VERSION="3.11-rc3-1" MAKE[0]="make defconfig-iwlwifi" MAKE[1]="make; make install" BUILT_MODULE_NAME[0]="${PACKAGE_NAME}" BUILT_MODULE_LOCATION[1]="drivers/net/ethernet/${PACKAGE_NAME}/" DEST_MODULE_NAME[0]="${PACKAGE_NAME}" DEST_MODULE_LOCATION[0]="/extra/${PACKAGE_NAME}/" AUTOINSTALL="yes" Como ven, lo único que he hecho es añadir la parte de driver-select a las instrucciones de compilado/instalación La localización de destino del módulo no es realmente necesaria salvo que sustituamos algún módulo Si observamos otros ejemplos, vemos que es siempre el mismo procedimiento e incluso más sencillo. Volviendo al ejemplo inicial, si consultamos el archivo dkms.conf de Nvidia, veremos que es bastante escueto: Y a modo de ejemplo general, tal y como figura en la wiki de Debian: También podremos consultar ejemplos más complejos provistos con el propio paquete dkms y que encontraremos en /usr/share/doc/dkms/examples que muestran configuraciones más complejas, incluyendo el parcheado de módulos antes de compilarlos e instalarlos Una vez tengamos la configuración en función de los requisitos del módulo a compilar, nombre, versión y todos los ajustes que hayamos hecho, nos queda la parte de añadir y compilar: dkms add -m <nombre> -v <versión> dkms build -m <nombre> -v <versión> dkms install -m <nombre> -v <versión> || true No es necesario que nos posicionemos en la carpeta correspondiente al módulo que queremos compilar, dkms asumirá que ésta se encuentra en /usr/src y que el nombre y la versión que le hemos suministrado son los que figuran en dicha carpeta. Una vez en ella, dkms seguirá los pasos que le hemos marcado en el archivo de configuración dkms.conf Que si nos ceñimos al ejemplo de los compat-drivers: dkms add -m backports -v 3.11-rc3-1 dkms build -m backports -v 3.11-rc3-1 dkms install -m backports -v 3.11-rc3-1 || true Resultado root@Shiba87:/usr/src# dkms add -m backports -v 3.11-rc3-1 Creating symlink /var/lib/dkms/backports/3.11-rc3-1/source -> /usr/src/backports-3.11-rc3-1 DKMS: add completed. NOTA Si en algún momento queremos que dkms deje de tener en cuenta el módulo que hemos incluido, porque queremos cambiarlo por una versión diferente, dejemos de utilizar ese hardware o lo que sea, sólo tendremos que realizar el proceso a la inversa: dkms remove nombre/version all O en caso de querer impedir que se compile para un kernel específico dkms remove nombre/version -k version-del-kernel Para nuestro ejemplo dkms remove backports/3.11-rc3-1 all ó dkms remove backports/3.11-rc3-1 -k 3.11.0 Y eliminar la carpeta del módulo de /usr/src para que no queden restos: rm -R /usr/src/backports-3.11-rc3-1 Generando nuestro paquete Deb DKMS Aunque el proceso de configuración, compilado e instalación del nuevo módulo con dkms ya habría terminado, veamos cómo podríamos preservar todo ese trabajo en un cómo paquete deb. Los comandos siguen en la misma línea que los anteriores, sólo que esta vez no añadiremos, compilaremos o instalaremos sino le indicaremos que lo que queremos es empaquetar el código fuente y la configuración que acabamos de utilizar: Empezando por el paquete que contiene el código fuente dkms mkdsc -m nombre -v versión --source-only Seguido del que contiene el binario y configuración pertinentes dkms mkdeb -m nombre -v versión --source-only Al completarse el proceso nos indicará dónde se han guardado los respectivos paquetes, que no será otro lugar sino: /var/lib/dkms/nombre/versión/deb y /var/lib/dkms/nombre/versión/dsc NOTA Podría ser necesario eliminar la carpeta en la que hemos estado trabajando /var/lib/dkms/nombre/versión/ para no generar conflictos a la hora de instalar el paquete deb. En el caso del ejemplo con Compat-drivers con el que hemos estado trabajando hasta ahora: dkms mkdeb -m backports -v 3.11-rc3-1 --source-only dkms mkdsc -m backports -v 3.11-rc3-1 --source-only Como ven, no es algo tan complicado y seguramente los responsables de nuestra distribución ya se habrán ocupado de todo el trabajo por nosotros, pero en caso de necesitarlo, en cuestión de unos minutos podemos tener el problema resuelto. SalUnix
  8. Una vez más, cumpliendo con su cita trimestral con los linuxeros, la nueva versión del Kernel creado por Linus Torvalds y desarrollado por una enorme comunidad, ha alcanzado su versión 3.11 que cuenta con algunas mejoras muy interesantes. Como novedades destacadas de esta nueva versión del kernel Linux tenemos: Soporte para las tarjetas Radeon HD 8000 "Sea Islands" El administrador de energía dinánico Radeon Un nuevo Driver DRM para los SoC Reneses R-Car Mejor soporte para los Intel Haswllv Soporte para Intel Bay Trail (Valley View) Soporte para decodificación H.264/MPEG-2 con los controladores Nouveau Soporte preliminar para los últimas chips GK110 de Nvidia Soporte para compresión LZ4 Mejoras para el sistema de ficheros XFS Mejoras para el sistema de rendimiento para Btrfs Actualizaciones para el sistema de ficheros Ext4 Actualizaciones para el sistema de ficheros F2FS Zswap entra a formar parte oficial del kernel después de muchísimo tiempo de desarrollo. Cliente para el sistema de ficheros Lustre Optimizaciones de las inscrucciones AVX2 Mejoras para la arquitectura ARM Mejoras para la arquitectura PowerPC Soporte para virtualización Xen y KVM para procesadores ARM de 64 bits Soporte para los dispositivos táctiles Cypress de 4ª generación Nuevo controlador para proveer soporte al protocolo PS/2 en los OLPC Parches para el MacBook Air Haswell (2013) Soporte para más de 32 tarjetas de sonido Soporte para la HDS ALC5505 DSP Soporte para la Yamaha/Roland USB Numerosas correcciones para AC'97 Además, con las nuevas mejoras con respecto a la arquitectura en Linux 3.11 y las nuevas características de Wine, éste sería capaz de lidiar con aplicaciones propias de WIndows RT Como es habitual, podemos obtener el código fuente de Linux desde https://www.kernel.org/ Y, si esperamos un poco, podremos ver todos los cambios con mayor profundidad en http://kernelnewbies.org/
  9. Aunque una semana más tarde de lo previsto, la versión 3.9 del kernel Linux ya ha sido liberada y llega con numerosas mejoras (Kernel Newbies está caído desde anoche, luego intentaré mejorarlo): El mapeador de unidades del kernel incluye ahora dm-cache para unidades de almacenamiento como discos SSD Btrfs ahora soporta RAID 5 y 6 Corregidos algunos problemas de rendimiento en la capa JBD2 journalling usada por ext4 Se ha añadido soporte para user namespaces a CIFS, NFS y otros sistemas de ficheros Los controladores Radeon ahora soportan los chips Oland usados en las series Radeon HD 8500 y 8600. También se añade soporte para la generación de APUs Richland de AMD Nouveau incluye ahora soporte para control automático y manual de la velocidad de los ventiladores para los chips NV40 y NV50 usados por las Nvidia GeForce 6xxx a 9xxx y los chips gráficos desde la generación 1xx a la 3xx. Prime helpers, el sistema usado por los controladores beta de Nvidia para dar soporte oficial a Optimus Mejorado el consumo de los procesadores gráficos Intel Haswell. Controladores para las tarjetas Wifi de la serie 7000 de Intel Cambios importantes en la configuración de Codecs de audio HD Libata soporta ahora ZPODD (Zero Power optical device drives) para unidades ópticas que pueden deshabilitarse completamente (consumo cero) cuando no están en uso. Soporte para procesadores Synopsys ARC, Meta ATP (Meta 1) y HTP (Meta 2 Mejora significativa de la compresión/descompresión LZO (casi el doble de rápida en algunos casos) KVM soporta ahora las capacidades de virtualización de los ARM Cortex A15 Soporte para modos de suspensión "lightweight suspend" o "suspend freeze" que ponen los componentes de hardware en su modo más profundo de reposo. Como es habitual, la lista completa de cambios la podemos ver en Kernel Newbies Y el código fuente lo podemos obtener en Kernel.org
  10. El soporte para módulos firmados no es nada nuevo, fue introducido por Red Hat en el año 2004 como CONFIG_MODULE_SIG, pero no se habían considerado incluirla en el kernel hasta ahora. Esta opción de configuración del kernel hace que los módulos sean firmados durante el proceso de compilado y el kernel resultante los compruebe durante el proceso de carga. El el proceso de firma de módulos permite los hashes criptográficos SHA1, SHA224, SHA256, SHA384 y SHA512. También se ha añadido una opción CONFIG_MODULE_SIG_FORCE, la cual exige que cualquier módulo del kernel esté firmado con la clave compilada en el kernel. Si el módulo no está firmado, no podrá cargarse. Los parches del desarrollador de Red Hat David Hollews no había sido aceptados por no considerarlos necesarios, pero la presión que ejerce la llegada inminente de UEFI Secure Boot ha hecho que hayan sido incluidos para ser integrados en el próximo kernel. De esta forma, el Kernel podrá por sí mismo rechazar cualquier módulo no firmado, que podría representar una amenaza si se trata de código malicioso o simplemente blobs no firmados. the web-based Git viewer.
×
×
  • Crear Nuevo...