Habia actualizado hace una o dos semanas el sistema xorg ..

con sus drivers y tal, todo va oerfecto , pero ayer me puse a trastear con los drivers ati oficiales..y

no se muy bien por que ... tanto firefox como chrome , al quere ejecutarlos el sistema se sale, y se va a la pantalla tipica de login de acceso.


es raro , puesto que incluso hashcat funciona bien ... solo tengo problema con los navegadores ,,,

de momento volvere al sistema xorg que tenia... que se que es estable , y ya ire mirando este tema con calma...

deberia mirar con los drivers nvidia , para descartar que sea realmente algo del sistema...


puede ser el xorg ... o el driver ati ... probe incluso el driver ati beta mas nuevo , y me petaba igualmente , con el xorg viejo todo perfecto.

_________________________

y en otro orden pero relacionado con lo comentado ...

he escrito un "mecanismo"  , ... DE MOMENTO SOLO DRIVERS ATI , ... para que el mismo modulo de drivers ati , valga para siempre ....  ( o al menos mientras hashcat no pida de uno mas nuevo ) , ... independientemente del kernel , o incluso si lo actualizais,


este es el code , ..ahora os lo explico mejor...

##### Function by USUARIONUEVO -->> www.seguridadwireless.net
# Para modulos extras de drivers
# ATI
kernel_ati=/lib/modules/$(uname -r)/kernel/drivers/char/drm/fglrx.ko
if [ ! -f $kernel_ati ]; then
if [ -f /usr/bin/aticonfig ]; then
echo "[+] Detectado driver ATI ... intentando crear fichero fglrx.ko"
ati_rebuild &>/dev/null
fi
fi
if [ -f /etc/X11/xorg.conf ]; then
if grep -wq fglrx /etc/X11/xorg.conf ; then
rm -r /etc/X11/xorg.conf
fi
fi
if [ ! -f $kernel_ati ]; then
if [ -f /etc/modprobe.d/blacklist-fglrx.conf ]; then
rm -r /etc/modprobe.d/blacklist-fglrx.conf
fi
fi
if [ -f $kernel_ati ]; then
echo "[+] Detectado driver ATI ... reconfigurando sistema"
aticonfig --initial &>/dev/null
cat > /etc/modprobe.d/blacklist-fglrx.conf << "EOF"
blacklist radeon
EOF
fi

bueno ..pues, el sistema empieza a cargar drivers, justo en ese punto donde en el arranque veis lo de udev trigering..y se autoajusta la resolucion de pantalla...

mi handicap ,estaba en que el sistema se diera cuenta antes de ese momento, de la existencia del modulo de driver ati ,,, y entonces on the fly .. compilar el fichero  fglrx.ko  ... ese es el name del driver ..se genera al vuelo ...se blacklistea el radeon que es el basico de sistema ... y  se genera el org.conf ... por ultimo ya el sistema llama a udev ..



voy a intentar explicar facil, el asunto ..

se mira si el fichero .ko ya existe ... SI NO ES ASI
se mira si existe el aticonf --> si esto existe el modulo esta cargado ..con lo que debera intentar generar el driver al vuelo

el driver para funcionar usa dos ficheros de configuracion , uno es el xorg.conf y el otro es blacklist para driver basico radeon


con lo que si el fichero .ko no existiese pero esos ficheros si , se eliminarian,por que si no  el sistema no arranca..al estar configurado con esos ficheros para fglrx y el sistema no tenerlo e intentra usar el basico radeon.


en casi de la SI EXISTENCIA DEL FICHERO fglrx.ko  .. en ese caso ..se genera de nuevo el xorg.conf ,con el comando

aticonfig --initial

eso genera el xorg.conf

y esto regenera el blacklist del radeon para funcionar el fglrx

cat > /etc/modprobe.d/blacklist-fglrx.conf << "EOF"
blacklist radeon
EOF

es la primera vez que enlazo un if ..dentro de otro if, y la verdad es bastante util.


con esto ,como el .ko se genera a cada arranque ...( si ya existe no lo regenra ni toca nada de nada ) ..funcionara sea el kernel que sea...

¿ como sabe el sistema, a cada vez y momento el kernel que va a usar y si el fichero esta dentro ?

/lib/modules/$(uname -r)/kernel/drivers/char/drm/fglrx.ko

lo unico que varia en la ruta de los kernels es su name y numero ..en rojo , esta el argumento , que descubre cual se va a usar ...

y el script  ati_rebuilder

que es el que intentara generar el  fglrx al vuelo ...

tenia implementada la funcion de incluso generar el xzm ... pero solo serviria para confundir ..

si es live , se genera a cada arranque ( penalizacion de unos 3-5 segundos ) ... no es mucho penalizacion me refiero a que tarda unos 3 segundos mas en arrancar por este tema.

si esta en hdd ... pues se verificara al arranque ... el kernel..y en caso de cambios por update , el script entrara al trapo ..generara el .ko  y no notaremos absolutamente nada..habremos actualizado  el kernel y no perderemos el driver oficial ati.
#!/bin/bash

NAME=ati
KERNEL=$(uname -r)
DESTDIR=$HOME/Desktop/$NAME-$KERNEL/lib/modules/$KERNEL/kernel/drivers/char/drm
DRIVER=/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko

# Primero limpiamos
cd /lib/modules/fglrx/build_mod/2.6.x/
make clean
rm -Rf /lib/modules/fglrx/build_mod/fglrx.ko
rm -Rf /lib/modules/fglrx/*ko
rm -Rf /lib/modules/fglrx/*log

# Recompilamos driver e instalamos
cd /lib/modules/fglrx/build_mod &> /dev/null
./make.sh
cd /lib/modules/fglrx/ &> /dev/null
./make_install.sh
#mkdir -p $DESTDIR &> /dev/null
#cp $DRIVER $DESTDIR &> /dev/null
#echo "Generando modulo xzm ..."
#dir2xzm $HOME/Desktop/$NAME-$KERNEL $HOME/Desktop/$NAME-$KERNEL.xzm -n &> /dev/null
#rm -Rf $HOME/Desktop/$NAME-$KERNEL &> /dev/null
#exit 0

creo que NO HAY NINGUN OTRO SISTEMA LINUX , con un mecanismo similar ...

bueno , pues después de 3 días hechandole muchas horas , y tras muchos cabreos con ganas de reventarlo todo , ... he dado con el asunto.


es un poco largo de explicar , pero intentare ser breve ,,,

en el sistema como sabeis , hay varios xzm , y van cargando uno tras otro en cierto orden NECESARIO , ..por eso llevan números.

pues por ejemplo ..

001 tiene el fichero  CADENAME

y a lo mejor en el

003 tengo el mismo fichero , pero retocado por algo ... (el modulo wifislax-desktop) , es casi exclusivo de ficheros ajustados y salvados lejos de updates y demás...


un fichero , puede sobreescribir un fichero
un enlace simbolico puede sobreescribir un enlace simbolico


pero ni un fichero puede sobreescribir un enlace ni un enlace sobreescribir un fichero

al igual con carpetas...

si tienes un fichero en 001 solo puede ser sobreescrito por un fichero llamado igual
si tienes un simbolico en 001 solo puede ser sobreescrito por un simbolico llamado igual
si tienes una carpeta en 001 solo podría ser sobreescrito por una carpeta igual

___________________________________________________________

¿ queda claro lo anterior ?

pues la aceleración 3d (librería mesa)  tiene los siguientes ficheros

libGL.so.0         -->> simbolico hacia  libGL.so.1
libGL.so.1         -->> simbolico hacia  libGL.so.1.2.0
libGL.so.1.2.0   -->> FICHERO REAL FINAL

Y el driver ati intentada hacer esto

libGL.so.0         -->> simbolico hacia  libGL.so.1
libGL.so.1         -->> simbolico hacia  libGL.so.1.2.0
libGL.so.1.2.0   -->> SIMBOLICO HACIA UNA DE SUS LIBRERIAS

Y ES HAY en el 1.2.0 estaba el fallo ... al ser un simbolico no se podía hacer y entonces el simbolico

libGL.so.1

seguía apuntando hacia el fichero real del sistema 1.2.0

¿ solución ?

en el driver ati ...

coger el simbolivo 1.2.0 y borrarlo ..

ese apuntaba hacia  /usr/lib/fglrx/fglrx-libGL.so.1.2.0

pues directamente del tiron

copiamos fglrx-libGL.so.1.2.0  en  /usr/lib

renombrándola como la original del sistema

fglrx-libGL.so.1.2.0  copiada a /usr/lib ,eliminamos el original 1.2.0 y renombramos la fglrx, como el original


fglrx-libGL.so.1.2.0 -->>  libGL.so.1.2.0


con lo que al ser FICHERO , podrá SOBREESCRIBIR EL ORIGINAL DEL SISTEMA ...


esta jilipollez me ha tenido amargado 3 días , instalando slackwares al hdd y viendo que allí funcionaba bien ..
después instalando wifislax al hdd e instalándole el driver funcaba bien

en modo live NO ...por el royo este de un simbolico que intentaba sustituir un fichero real... 

claro , en el hdd no hay problema...por que el driver al instalarse , ... elimina el fichero original , y después crea el enlace..asi si ...  en live la historia es diferente.

____________________________________________________

además de eso , ya por fin puedo decir que tengo 100x100 funcional ,el tema del driver que servirá para mas de una versión ( hasta que hashcat pida un driver mas nuevo y haya que reconstruir el modulo, servirá el mismo aunque actualiceis kernel)

en live me funcionaba bien ,por que el initrd monta el sistema como rw  ( read write , lectura/escritura ) ..

cuando la instalaba a disco duro , NO FUNCIONABA ,por que el grub de los coj0nes , mete en el arranque "ro"

ro = Read Only

con lo que no podía escribir sobre la marcha ...

no encontré como eliminar que el grub añada eso ...y necesitaba rw

con lo que el grub , de una forma no muy elegante después de ro vga=788  ,añade un rw , con lo que como la ultima orden en rw queda como lectura/escritura y ya si entonces funciona todo.

resumiendo , .. movidas de las que no se ven , y me tienen atrapado durante días

estoy subiendo una iso ... pero no os vale la pena bajarla, por que no hay nada nuevo en ella ... solo se mantiene el xorg-server nuevo ... los scripts updaters esta todo parado , por que estuve con este royo estos 3 días.

Miedo me da , el driver nvidia  ... aunque sabiendo donde esta el problema, la solución es fácil.

tema zanjado , cierro el post ,y dejo la chapa, para quien quiera leer.