(SOLUCIONADO) Mensaje error sobre udev y hal al arrancar

Imagen de Will Berg
0 puntos

Saludos.
Cuando tuve que cambiar de Raring a Saucy, me salió un mensaje diciendo que tal vez no hubiera quedado bien el cambio. Desde entonces, al arrancar veo este mensaje repetido muchas veces:
failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory.
Yo lo veía muy rápido, desaparecía y el sistema terminaba arrancando. Hasta hoy no he logrado averiguar en qué .log se escribía esta información (/var/log/dmesg).
He ido cambiando kernels Saucy, quité todos los de Raring, expurgué el origen de software, hice todo el proceso que proponía Gabriel_M en http://www.ubuntu-es.org/node/182646, reinstalé udev (con hal no me atreví) y alguna cosa más que no recuerdo. Desde el cambio, el sistema funciona en general, pero tiene "cosas" que fallan mucho (como Nemo y Docky, muchísimo más que antes) y otras que no tanto, pero te dejan sin saber si pasa algo o qué.
Una cosa que he encontrado hurgando es que tengo los siguientes enlaces rotos:
K20acpi-support en /etc/rc1.d que apunta a /etc/init.d/acpi-support donde sólo está acpid (programa)
S99acpi-support en /etc/rc2.d que apunta a /etc/init.d/acpi-support donde sólo está acpid (programa)
S99acpi-support en /etc/rc3.d que apunta a /etc/init.d/acpi-support donde sólo está acpid (programa)
S99acpi-support en /etc/rc4.d que apunta a /etc/init.d/acpi-support donde sólo está acpid (programa)
S99acpi-support en /etc/rc5.d que apunta a /etc/init.d/acpi-support donde sólo está acpid (programa)

En /lib/udev no hay socket que valga. La búsqueda de org/freedesktop/hal/udev_event no da resultados, lo más parecido que encuentro es dbus-org.freedesktop.Hal.service y org.freedesktop.Hal.service...

¿Puede alguien decirme qué puede estar pasando y, si es posible, cómo arreglarlo?
Muchas gracias anticipadas.
Will

Imagen de yosebilla
+1
-1
-1

Cuando instalas cierta clase de porqueria en el ordenador a la larga hay problemas, y en ubuntu la porqueria son drivers privativos, tipo nvidia, y plugins guarros, como flash. Se pasan las politicas de instalación y desinstalacion por el arco. Primero te digo las soluciones y luego te explico que ha pasado.

Desinstala y purga hal y libhal, estan obsoletas hace años y se mantienen por retrocompatibilidad con alguna cosa rara. Hace ya tiempo que entre udev y dbus asumieron todas las funciones. Si te pide que desinstales algo mas, tiene que ser forzosamente algun paquete que has añadido de algun ppa un poco desnortado que no se ha actualizado, mira lo que es y desinstala. El script de purga de hal deberia eliminar decentemente la linea udev. Si quieres hacerlo "a pelo" te abres un terminal y cambias o borras a pelo las reglas udev de hal, como todos los archivos de configuración general del sistema esta alojado en /etc no donde has buscado que es la carpeta para bibliotecas compartidas, /lib si se tratase de datos que varian, como el archivo log, estara en /var . Una vez le pillas la idea al sistema de archivos veras que es bastante logico y dejaras de revolver en /lib . Creo recordar que hal era el 90 en udev, pero echale un ojo a /etc/udev y /etec/udev/rules.d y fusilas el archivo hal, si mal no recuerdo:

sudo rm /etc/udev/rules.d/90-hal.rules

Explicacion larga, que me ha hecho gracia lo de que esta roto /etc/rc1.d y compañia. En su dia hal era una capa de abstración de hardware, valido para comunicar entornos de usuario sin privilegios con hardware. Cuando ponias ese pincho usb wifi, y saltaba el nm para decirtelo y que le dieses la clave, antes eran entre hal y hotplug quienes manejaban el tema. Luedo vino udev, hal se adapto a udev, luego entre los entornos de escritorio, notablemente entre kde y gnome, decidieron estandarizar un nuevo bus, dbus, para la comunicación interprocesos. Con eso el sitio de hal no existia, y en un acto de honradez intelectual realmente brutal, los desarrolladores de hal se pusieron a ayudar a udev a asumir todo. Durante cierto tiempo, como es costumbre, se mantuvo hal para dar tiempo a todos los programas que hacian uso migrasen sin problemas. Lo mas normal del mundo. Paso el tiempo y termino por adaptarse hasta el mas desnortado de los programadores. Udev se encontro con nuevas necesidades y tuvo que cambiar sus archivos de configuración, se adapto y listo.

Ahora al lio, flash player, ademas de chupar recursos cosas mala, usa algunas estrategias muy guarras, entre otras borrar inmediatamente pulsas al play el archivo del video, como linux detecta que esta abierto sigue tanto descargando como viendose, pero no lo encuentras si lo buscas. Para usar drm de algunos sitios usa hal, y añade en la configuración antigua una linea en halr.rules del udev, como has seguido la historia de antes, efectivamente la configuración que instala flash es la vieja de udev, que cualquier udev moderno rechaza por mal formada, y te salta el mensaje de error, nada serio por otra parte, de que no puede abrir el conector con el sistema de comunicación interprocesos dbus. lo cual es normal. Eso que te pone despues de socket no es realmente un archivo de tu disco, sino un identificador para el conector entre programas. Se va a pasar dbus al kernel en breve, para que veas que estas cosas se suelen mover bastante, pero se anuncia y se da tiempo, solo que adobe y nvidia y algun otro se pasan todo por el arco del triunfo y hacen una chapuza.

Los mantenedores de los instaladores de estos programas, por ejemplo flashplugin-nonfree o como se llame en ubuntu, mantienen esos paquetes de forma que corrige algunas cagadas , le asigna el sitio correcto en el sistema de archivos, y el sistema de desinstalacion borra correctamente todo. Es el debian-way, la idea de que los programas se instalen y desinstalen limpiamente sin pisarse entre ellos es sagrada. Pero los nuevos tendeis a instalar de forma algo chapucera algunas cosas, en plan me bajo de adobe directamente el instalador que tienen, en vez de usar debidamente el sistema de paquetes. No tiene por que ser tu caso, al ser un programa privado que hace guarradas, no se puede controlar perfectamente todo, sabemos positivamente que puede abrir tanto el micro como la webcam, que comparte información de navegacion mediante "cookies binarias" y alguna cosa mas. No te asustes, lo pone todo bien clarito en su EULA, que por supuesto nadie lee. Asi que entre los anuncios en flash y el youtube, te hacen un seguimiento. Google tambien pero son mas honestos con eso.

En fin que me lio, espero que hayas comprendido la curiosa secuencia de acontecimientos que ha llevado a darte ese fallo, por otra parte no es mas que un aviso sin importancia. Respecto a lo de "los enlaces rotos" que me hecho sonreir, es o una instalación incorrecta o una desinstalación incorrecta, nuevamente de algun paquete mal llevado, o una instalación a pelo de algun driver privativo. por supuesto TODOS los paquetes de /etc/rc0.d y sucesivos son enlaces a /etc/init.d , es politica de todas las distribuciones y estandar lsb. Como has leido antes en /etc esta la configuración del sistema en general, y esos archivos son los archivos de configuracion de los "runlevel" del inicio, indican el orden de carga de los diversos demonios del sistema, y en /etc/init.d/ estan los script o que tienen todas las ordenes, start, stop, y todo el rollo obligatorio. Asi cuando el sistema de arranque llega al runlevel 5 en decimoseptimo lugar inicia lo que tengas como S17loquesea (s de start) y cuando va al apagado en tercer lugar parara lo que tengas en rc6.d K03otracosa (k de kill) que no sera mas que un enlace a init.d. Si sabes que o quien te ha podido hacer esa guarrada, hay que mandar fallo que es una violacion gravisima de la jerarquia de archivos. Si la has liado tu la solucion es sencilla,

#sudo update-rc.d acpi-support

elimina y reordena tus enlaces a init, mas majo el que las pesetas. Y por supuesto cumpliendo a rajatabla el estandar lsb.

Para finalizar, me has hecho reirme a gusto, me has recordado todas las perrerias que hice yo cuando empece con el linux, con el tiempo le pillas el punto a como se reparten los datos en el sistema de archivos, y es brutalmente logico. ¿donde estaran los datos de la base de datos? es servicio del sistema y son datos variables, en /var , ¿y si quiero compilar un programa propio? ejecutable a /usr/local , que es el espacio que tengo reservado para mi. Tambien con el tiempo terminas apreciando de veras que sean asquerosamente picajosos con los archivos de instalación y desinstalación, que te tienen el sistema niqueladito durante años de orgias de instalacion y des-instalacion. Y empiezas a odiar con saña esos archivos .run que te encasquetan en ati o nvidia que te desastran todo.

+1
-1
-1
Imagen de Will Berg
+1
+1
-1

Para yosebilla:
Ante todo, gracias por tu respuesta. He tardado en responder porque he estado alejado de Internet varios días.
Debo decirte que me abruman tus explicaciones (no soy estrictamente novato en Linux, pero tampoco estoy muy puesto). Nunca he tenido flash player instalado (que yo sepa), ni en Raring ni en Saucy, tengo a Adobe lo más lejos posible; si no puedo ver un vídeo, o lo que sea, de otro modo, paso de verlo y en paz, pero no quiero Adobe invadiéndolo todo.
Tengo que leerme despacio tu largo texto y ver qué puedo probar a hacer; muchas cosas me suenan a chino. Me lo copio, lo digiero, probaré alguna cosa y te respondo lo antes posible.
Gracias de nuevo.
Will

+1
+1
-1
Imagen de Will Berg
+1
0
-1

Añadido para yosebilla:
Actualicé de Raring a Saucy con el botoncito de Ubuntu cuando dijeron que ya no soportaban Raring. Luego, que yo sepa, no he tocado nada a la ligera, sólo con las herramientas del sistema y siguiendo "tutoriales". Tengo muy pocos repositorios "libres" añadidos, Nemo, Docky, Easytag, LibreOffice y smplayer(éste, después de empezar los mensajes del inicio).
Synaptic me confirma que no tengo nada de Adobe o flash player instalado.
Will

+1
0
-1
Imagen de Will Berg
+1
+1
-1

Yosebilla, por fin he podido meterme con el asunto.
90-hal.rules no estaba en /etc/udev/rules.d/ sino en /lib/udev/rules.d y contenía el mensaje:
# pass all events to the HAL daemon
RUN+="socket:@/org/freedesktop/hal/udev_event"
Lo he borrado y al reiniciar ya no ha salido el mensaje de error. Por ese lado ¡listo!
Respecto a los enlaces rotos, he ejecutado "sudo update-rc.d acpi-support" pensando que haría algún tipo de comprobación y reajustaría los valores correctamente. Ya he visto que no. Me dices que los reordene, pero no sé qué hacer exactamente ni cómo. Si pudieras especificarme esto, te lo agradecería mucho (cuando intento ver el contenido de uno de estos archivos, no me sale nada visible y gedit me dice que el contenido ha cambiado y pregunta si quiero guardarlo; me confunde).
Sobre eliminar hal sin más, veo que tiene instalados un montón de archivos por casi todas partes y me da algo de yuyu hacerlo. Si me confirmas que puedo quitarlo sin problema, lo hago. En Synaptic he probado a marcar para desinstalar completamente hal y libhal1; sólo me añade otra cosa de hal, no apunta a ninguna aplicación diferente (por si hubiera sido ése el origen del problema con las "rules"). Sobre quitarlo todo, espero, pues, lo que me digas.
Me ha surgido otra puñetería, que te cuento por si puedes orientarme: con Raring, opté por que hibernara cuando la batería alcanza una carga crítica (me era muy útil); con Saucy, no puedo hacerlo y se apaga. ¿Hay solución?
Renovando el agradecimiento, espero tus noticias.
Will

+1
+1
-1
Imagen de yosebilla
+1
0
-1

Hablaba de memoria en las reglas de hal, si te ha servido de orientación, genial.

Sobre desinstalar hal, hazlo. Los paquetes deb se reparten por toda la jerarquia de archivos y se borran de toda la jerarquia de archivos, es la gran virtud del sistema de paquetes, tanto desde apt como desde synaptic, desinstalara correctamente. Es innecesario y obsoleto, en general no tengas miedo a desinstalar nada, siempre con el sistema de paquetes, por que si algun otro programa necesita hal, en este caso, al solicitar la desinstalación te informa y te pregunta. Como idea, si va a desinstalar trescientos paquetes, pues es algo importante. Si no, ala, a limpiar. En el synaptic por ejemplo en "estado" pulsa sobre "local o obsoleto" y borra tres cosas viejas, sin miedo. El sistema de paquetes es muy robusto.

Sobre los enlaces de /etc/init.d si tras el update.rc no toca nada esta todo bien. Si quieres estudiar el sistema, olvidate de los rcX que no es mas que un "truco", los archivos reales estan en /etc/init.d con todas las funciones. Abre por ejemplo /etc/init.d/cups con gedit en modo usuario, no root, que te permite leerlo pero no lo puedes romper. Veras que es un archivo de texto con funciones definidas, start y luego una parrafada, stop y otra parrafada. Al inicio por ejemplo en /etc/rc3.d tendras un enlace "S17cups" eso le indica al arranque que llame a la funcion "start" del /etc/init.d/cups en el tercer runlevel el numero 17. En general es algo que los usuarios no necesitan ni saber ni tocar.

En resumen, no tocar /etc/init.d , y confia en el sistema de paquetes, es bueno. Sobre invernar, lo siento, nunca lo he usado. No se puede saber de todo.

Y solia ser flash el causante de los problemas, pero tambien dije lo de "algun ppa ". Flash es el culpable habitual, por eso lo supuse sin mas.

+1
0
-1
Imagen de Will Berg
+1
0
-1

Ante todo, muchísimas gracias por tu constancia. Llevo días y días sin Internet y hasta ahora no he podido leerte. Me copio tu información, borraré hal, veré despacio lo de los enlaces rotos y te diré algo (si aún tienes paciencia para mirar la respuesta).
Averigüé lo de la hibernación. En alguna página se decía cómo activarla, había que meter lo que sigue en el archivo vacío com.ubuntu.enable-hibernate.pkla (/etc/polkit-1/localauthority/50-local.d):
[Re-enable hibernate by default in logind]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate
ResultActive=yes

Con eso, se activaba la hibernación en general, pero la opción de hibernar con la batería en estado crítico no se activaba (que es lo que yo consultaba).
En ese archivo antedicho hay que meter en realidad dos "textos", como sigue:
[Re-enable hibernate by default in upower]
Identity=unix-user:*
Action=org.freedesktop.upower.hibernate
ResultActive=yes

[Re-enable hibernate by default in logind]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate
ResultActive=yes

La cosa es que logind sustituye a upower, pero no en todo, y de hecho mi sistema abre upower pero no logind (como proceso vivo). En cuanto haces el añadido al archivo, la opción hibernar con batería crítica está accesible.

Lo dicho, hago mis "deberes" y contesto en cuanto pueda. Gracias de nuevo.
Will

+1
0
-1
Imagen de Will Berg
+1
0
-1

Saludos de nuevo, yosebilla. Ahora he tardado menos.
Efectivamente, desinstalé hal sin problemas, synaptic no me dijo nada de particular. Las diversas cosas que he usado van normales, así que creo que todo está bien.
Sobre los enlaces rotos, creo que tienes razón y mejor no me meto a tocar nada (suponiendo que pudiera). Por lo único que me preocupaban era porque al arrancar tarda bastante más que cuando empecé a usar Raring y hace varias pantallas negras hasta que está operativo; pensé que quizá esos enlaces rotos pudieran obligar a hacer bucles, esperas, etc.
Si te parece, en unos días doy el asunto por solucionado para el buen orden del foro.
Gracias de nuevo.
Will

+1
0
-1
Imagen de Will Berg
+1
0
-1

Saludos, yosebilla.
Encontré una aplicación, symlinks, con la que he eliminado los enlaces rotos y todo parece marchar bien, así que creo que todos mis problemillas están arreglados. Al final, no eran nada serio, pero cuando no sabes el alcance que pueden tener te mosqueas un poco.
Doy esta consulta por solucionada. Gracias otra vez.
Will

+1
0
-1
Imagen de Will Berg
+1
0
-1

Consulta solucionada.

+1
0
-1