Autor Tema: Problema de limitación de número de modulos cargados Wifislax 4.11.1 Live (Leído 14778 veces)

trax69 · « **en:** 07-09-2015, 23:07 (Lunes) »

Hola, he detectado una incompatibilidad con el modulo Gparted (no se si conocida). Estoy tratando de averiguar si es solo el modulo en cuestión o si genera conflicto con algún otro.

Describo lo que ocurre.

Tengo wifislax 4.11.1 con módulos bajados desde el propio live,otros del foro, y otros creados por mi.

He ido metiendo 1 a 1 desde que detecté el problema y al meter Gparted junto con otros modulos termina todo el proceso de arranque la distro y cuando debería ejecutar el comando para iniciar la interface gráfica simplemente queda el guión a principio de linea parpadeando sin nada más con la pantalla en negro.

Aun estoy en proceso de averiguar si es por incompatibilidad con algún otro modulo(lo mas posible) o por que.

Posteo esto por si a alguien más le pasa que podamos dar con la solución.

Saludos.

sol666 · « **Respuesta #1 en:** 08-09-2015, 00:22 (Martes) »

a mi me pasaba igual,al meter unos veinte modulos no me arrancaba,lo solucione juntandolos todos en uno.

trax69 · « **Respuesta #2 en:** 08-09-2015, 00:33 (Martes) »

Crees que eso podría solucionar mi problema ? como haga eso y siga fallando no sabré cual es el que causa el error >.< hahaha y luego será un caos cuando quiera quitar alguno especifico hahaha.

¿Existe alguna limitación por así decirlo a cuanto numero de módulos activos?

EDITO: he detectado que Django y otro mas también me causan incompatibilidad. Me esta empezando a mosquear el tema -.-

sol666 · « **Respuesta #3 en:** 08-09-2015, 01:30 (Martes) »

haz la prueba,copialos todos en algun sitio y con la copia cojes y los juntas,asi sabras si es por lo mismo que a mi.

trax69 · « **Respuesta #4 en:** 10-09-2015, 02:09 (Jueves) »

Son muchos modulos y he estado unos dias liado estoy probando, ahora con el resultado que salga edito este post a ver si se soluciona así.

Gracias !

Edito: he juntado todos los modulos que supuestamente pensaba que tenian incompatibilidad como me dijiste y por un extraño motivo ya no me dan error. Supongo que era por eso entonces. Muchas gracias !

sol666 · « **Respuesta #5 en:** 10-09-2015, 18:01 (Jueves) »

esto de tener que juntarlos me pasa con la 4.11 y la 4.11.1,antes me iban bien sin juntarlos.

USUARIONUEVO · « **Respuesta #6 en:** 10-09-2015, 18:12 (Jueves) »

pues si mirarais un poquito , veríais al arrancar algo del tipo

NO SE PUEDE LEER EL MODULO TAL ...

los últimos sobretodo ..

hay un numero limite de modulos.

sol666 · « **Respuesta #7 en:** 10-09-2015, 18:43 (Jueves) »

pues con la 4.10.1,con el mismo numero de modulos no me pasaba.

USUARIONUEVO · « **Respuesta #8 en:** 10-09-2015, 22:10 (Jueves) »

Cita de: sol666 en 10-09-2015, 18:43 (Jueves)

pues con la 4.10.1,con el mismo numero de modulos no me pasaba.

lo se , habia una opcion que podias definir el maximo de loops para montar modulos y estaba a tope

36000 si no recuerdo mal

pero esa opcion desaparecio, en los kernel 4.x , no se si habra forma de recuperarlo,actualmente no se cuantos loops se pueden usar a la vez.

trax69 · « **Respuesta #9 en:** 11-09-2015, 00:19 (Viernes) »

Luego cuando tenga un tiempo indago sobre el tema aunque creo que se por donde van los tiros... no tenia ni idea de que el kernel limitaba el numero de carga de modulos.

Voy a probar y ahora os cuento

USUARIONUEVO · « **Respuesta #10 en:** 11-09-2015, 00:37 (Viernes) »

Cita de: trax69 en 11-09-2015, 00:19 (Viernes)

Luego cuando tenga un tiempo indago sobre el tema aunque creo que se por donde van los tiros... no tenia ni idea de que el kernel limitaba el numero de carga de modulos.

Voy a probar y ahora os cuento

en realidad es el sistema de ficheros aufs ... el que permite cargar cada xzm en un loop distinto.

la cuestion es que cambio el numero limite de loops , y no se puede reconfigurar como antes que podia elegir

128
512
1024
36000 (o algo asi una burrada)

trax69 · « **Respuesta #11 en:** 11-09-2015, 18:00 (Viernes) »

Llevo toda la fucking noche empapandome sobre el tema y haciendo pruebas pero no consigo nada. Intento modificar los parámetros del arranque pero se los pasa por ahí... He estado empapandome sobre los kernel. Sigo sin avanzar... A ver si consigo averiguar algo...

Edito:

Añado un enlace donde hablan de una distro Porteus aclarando algunas cosas que quizás nos sirvan
http://forum.porteus.org/viewtopic.php?f=42&t=975

Cuando llegue a casa reviso y miro a ver que puedo hacer -.-

USUARIONUEVO · « **Respuesta #12 en:** 11-09-2015, 20:20 (Viernes) »

pero que no vas a poder hacer naaaaaaaaaaa

se ha suprimido , el poder decidir "cuantos" , modulos puede montar el kernel.

Solo nos queda saber "donde" , esta el limite actual ...

Si aufs soporta 30 , no vas a poder cargar mas..por mucho que quieras

Si un monitor soporta resolución 1024x768 ..por mucho que quieras no va a alcanzar 1080 , para que se entienda.

No se si enviar algún ticket al desarrollador de aufs ... tened en cuenta que normalmente las distros usan un solo fichero squashfs ,,, hay muy pocos que dividen en trozos ...

slax
porteus
wifislax

¿solución ... pues tal vez usando un kernel mas viejo? ... pero .. no es lo ideal.

vk496 · « **Respuesta #13 en:** 11-09-2015, 21:26 (Viernes) »

Mmmmm.....

Puede sonar a locura... Pero.... Y si hacemos trampas?

Si descubrimos el límite que tiene, cuando en el arranque se detecte más de X módulos, hacer un merge de todos ellos menos los del sistema y cargarlos on the fly

Salu2

USUARIONUEVO · « **Respuesta #14 en:** 11-09-2015, 22:19 (Viernes) »

No , lo de hacer merge no creo que puedas ya que el sistema aun no se ha montado ... y deberia ser algo en el initrd , por no hablar de que si tienes modulos grandes ..hacer el merge puede ser eterno y el arranque durar 1 hora

El asunto esta asi ...

Antes se podia definir un numero MINIMO y un numero MAXIMO de loops.

un loop es como una unidad virtual , en cada loop se monta un xzm ..por orden alfabetico.

Ahora no hay donde definir el MAXIMO , pero si que hay un "MINIMO" , con lo que ese minimo podria ser 512 o el numero mas alto que dejse antes.

Pero para hacer pruebas antes hay que encontrar el limite ,para saber si moviendo esa parte se solucionara o no.

CONFIG_BLK_DEV_LOOP_MIN_COUNT=8

trax69 · « **Respuesta #15 en:** 11-09-2015, 22:58 (Viernes) »

Si, se que no lo soporta el maximo, pero estuve leyendo sobre alguna forma de "parchear" eso....

De todos modos entiendo lo que dices sobre que no se puede pero soy muy tozudo en esto y me entocino hasta encontrar solución que bien podria ser la que planteas. Por el momento estoy haciendo pruebas y sin resultado pero llegará hahaha.

Lo que me extraña es que el limite real sea 8, modificando eso ultimo que comentaste podria dar solución ?

sol666 · « **Respuesta #16 en:** 11-09-2015, 23:10 (Viernes) »

yo con esto me ralle bastante y acabe haciendo merge con todos mis modulos extras y se me quedo uno de casi 900 megas,pero creo que en poner mas de 6 o 8,aparte de los que hay en ya en la iso me daba el error de zram o algo asi.

USUARIONUEVO · « **Respuesta #17 en:** 11-09-2015, 23:18 (Viernes) »

CONFIG_BLK_DEV_LOOP_MIN_COUNT=8

eso esta en la config del kernel .. quiere decir que el kernel inicia con un soporte de 8 loops

pero eso se puede cambiar , no se si habra algun limite

si se deja, con poner 512 bastaria o 1024

trax69 · « **Respuesta #18 en:** 11-09-2015, 23:20 (Viernes) »

Voy a comprobar y comento

USUARIONUEVO · « **Respuesta #19 en:** 11-09-2015, 23:24 (Viernes) »

Cita de: trax69 en 11-09-2015, 23:20 (Viernes)

Voy a comprobar y comento

pero ese cambio te lleva a recompilar el kernel .. no va a ser un momento

por muchos modulos que pongo, siempre me arranca ... he arrancado hasta con 31

eso si , a partir de cierto numero , me hace cosas raras , no es capaz de arrancar como debe con kernel smp

sin embargo en el mismo escenario , el kernel normal si arranca bien.

podeis probar cuando os quedais en negro , de arrancar el kernel normal.

creo hay un bug en el kernel , referente a la opcion HIGHMEM ,

[ 15.045019] vmap allocation for size 905216 failed: use vmalloc=<size> to increase size.
[ 15.045027] vmalloc: allocation failure: 898756 bytes
[ 15.045031] modprobe: page allocation failure: order:0, mode:0xd2
[ 15.045038] CPU: 1 PID: 2117 Comm: modprobe Not tainted 4.1.6-smp-wifislax #1
[ 15.045041] Hardware name: ASUSTeK Computer Inc. K54C/K54C, BIOS K54C.204 01/20/2012
[ 15.045044] 00000000 c1423898 00000001 c10990c0 c1512f82 f3f320cc 00000000 000000d2
[ 15.045055] e8395e98 c1514ecc e8395e70 00000000 000000d2 000db6c4 c10b83cb 000000d2
[ 15.045065] 00000000 c1514ecc 000db6c4 f43b4738 f43b4738 ff9fe000 f81fe000 e8395fa0
[ 15.045074] Call Trace:
[ 15.045085] [<c1423898>] ? dump_stack+0x45/0x65
[ 15.045091] [<c10990c0>] ? warn_alloc_failed+0xc5/0xd6
[ 15.045099] [<c10b83cb>] ? __vmalloc_node_range+0x1ac/0x1b9
[ 15.045106] [<c10b8419>] ? __vmalloc_node+0x41/0x47
[ 15.045111] [<c107ca1c>] ? copy_module_from_fd+0x53/0xe5
[ 15.045117] [<c10b8454>] ? __vmalloc_node_flags+0x18/0x1c
[ 15.045121] [<c107ca1c>] ? copy_module_from_fd+0x53/0xe5
[ 15.045125] [<c107ca1c>] ? copy_module_from_fd+0x53/0xe5
[ 15.045132] [<c107ed52>] ? SyS_finit_module+0x3d/0x54
[ 15.045138] [<c14283ce>] ? syscall_call+0x7/0x7
[ 15.045142] Mem-Info:
[ 15.045152] active_anon:4058 inactive_anon:1218 isolated_anon:0
active_file:20907 inactive_file:57337 isolated_file:0
unevictable:0 dirty:1 writeback:0 unstable:0
slab_reclaimable:4009 slab_unreclaimable:38157
mapped:6066 shmem:1658 pagetables:184 bounce:0
free:1373203 free_pcp:546 free_cma:0

Noticias:

Autor Tema: Problema de limitación de número de modulos cargados Wifislax 4.11.1 Live (Leído 14778 veces)

trax69

sol666

trax69

sol666

trax69

sol666

sol666

trax69

trax69

vk496

trax69

sol666

trax69