{"id":63,"date":"2011-08-30T17:36:12","date_gmt":"2011-08-30T20:36:12","guid":{"rendered":"http:\/\/www.maurom.com\/wp\/?p=63"},"modified":"2012-05-11T14:49:11","modified_gmt":"2012-05-11T17:49:11","slug":"waiting-for-dev-to-be-fully-populated","status":"publish","type":"post","link":"https:\/\/maurom.com\/blog\/2011\/08\/30\/waiting-for-dev-to-be-fully-populated\/","title":{"rendered":"Waiting for \/dev to be fully populated…"},"content":{"rendered":"

Desde hace algunos meses me ven\u00eda mordiendo un bug extra\u00f1o en la m\u00e1quina de trabajo donde a partir del kernel linux 2.6.39 e incluyendo la versi\u00f3n 3.0.0 el sistema se bloqueaba al inicio (el cl\u00e1sico freeze on boot<\/em>) justo despu\u00e9s del mensaje<\/p>\n

Waiting for \/dev to be fully populated<\/pre>\n
Y luego de eso, nada. Curioso, ya que con 2.6.38 el arranque iba de lo m\u00e1s normal, adem\u00e1s que el equipo es un clon de los m\u00e1s comunes:<\/p>\n
Procesador: Intel(R) Pentium(R) D CPU 2.80GHz<\/a>\r\nMotherboard: Intel Corp. D102GGC2<\/a>\r\nVGA: ATI Technologies Inc RC410 [Radeon Xpress 200]\r\nMemoria: 1 GB<\/pre>\n
Obviamente a esa altura del arranque no hay muchos dispositivos disponibles, por lo que logs como para diagn\u00f3stico no ten\u00eda ninguno, as\u00ed que por un tiempo desist\u00ed la investigaci\u00f3n y me mantuve con el 2.6.38, ya que hab\u00eda que trabajar.<\/p>\n
\"\"El primer sospechoso fue naturalmente udev, <\/em>al fin y al cabo era el emisor del \u00faltimo mensaje que ve\u00eda en pantalla. Diagnosticar problemas con udev<\/em> es, digamos, un poco tedioso. Si leen el manual de udev<\/a> encontrar\u00e1n que en \/etc\/udev\/udev.conf<\/em> puede establecerse la variable udev_log<\/em> en err<\/em>, info<\/em> o debug<\/em> para definir la prioridad de los mensajes que ser\u00e1n mostrados en pantalla. Una vez hecho el cambio basta con reiniciar el equipo para ver los mensajes de informaci\u00f3n o diagn\u00f3stico correspondientes.Pero recientemente, aprovechando un d\u00eda que llegu\u00e9 demasiado temprano, le dediqu\u00e9 unos minutos a este inconveniente que ya me ten\u00eda inc\u00f3modo.<\/p>\n
Desde ya es todo un pergamino de eventos el que va sucediendo en el arranque. Tantos eventos (y sin logging ni forma de recuperar los que ya pasaron) que me result\u00f3 imposible encontrar un patr\u00f3n extra\u00f1o o una pista siquiera de qu\u00e9 es lo que estaba sucediendo. Opt\u00e9 entonces por el cl\u00e1sico diagn\u00f3stico del pobre: conociendo d\u00f3nde almacena udev las reglas (\/lib\/udev\/rules.d\/<\/em>), fui desactivando las reglas y reiniciando el sistema tras cada cambio. Si el sistema continuaba el arranque luego del mensaje “Waiting for \/dev …”<\/em> entonces las reglas activadas eran inocentes; si no, alguna de las reglas activadas es la culpable. En algunos inicios no ten\u00eda gr\u00e1fica, en otros no ten\u00eda disco, y en la mayor\u00eda ni siquiera teclado.<\/p>\n
Una especie de b\u00fasqueda dicot\u00f3mica<\/a> me llev\u00f3, en pocos reinicios, a encontrar el archivo presuntamente culpable: 80-drivers.rules.<\/em> Incluso llegu\u00e9 a determinar que la l\u00ednea responsable era la s\u00e9ptima. Sin embargo el avance no fue mucho, ya que esta l\u00ednea carga un mont\u00f3n de m\u00f3dulos en el kernel entre los cuales estan los de teclado y rat\u00f3n: se ampliaba la lista de sospechosos.<\/p>\n
Hasta ac\u00e1, apenas si mov\u00ed un paso, pero al menos llegaba a arrancar y controlar el sistema mediante SSH. Entonces un gran compa\u00f1ero de laburo (hat tip a Leandro), iluminado por el conocimiento (o quiz\u00e1 cansado de mis improperios) me recomend\u00f3: “\u00bfy si prob\u00e1s cargando los m\u00f3dulos que faltan, uno a uno?”<\/em>.<\/p>\n
Entonces iniciamos el diagn\u00f3stico del pobre parte II. Haciendo un diff casero entre el lsmod<\/em> del equipo iniciando con kernel 2.6.38 y uno iniciando con kernel 2.6.39 (sin 80-drivers.rules<\/em>) llegamos a una lista de unos doce o quince m\u00f3dulos faltantes. All\u00ed, tan cerca, login ssh y a probar cada uno de los m\u00f3dulos… pcspkr, evdev, psmouse, snd_hda_intel<\/em>, todos cargaban bien… parport, fuse<\/em>, ok… processor<\/em>… chan! ah\u00ed se tild\u00f3 todo<\/strong>.<\/p>\n
AHA! El m\u00f3dulo processor<\/em>!<\/strong> Pero \u00bfqu\u00e9 funci\u00f3n cumple ese m\u00f3dulo? O mejor, \u00bfpor qu\u00e9 sigue andando el sistema sin \u00e9l?. Bueno, resulta que es el ACPI Processor Driver<\/a>, que no es realmente necesario pero maneja cuestiones \u00fatiles tales como los estados de energ\u00eda del procesador<\/a>. Si lo recuerdan ACPI ya nos viene dando dolores de cabeza desde hace bastante<\/a>.<\/p>\n
Ya con esos datos, una b\u00fasqueda en Google revel\u00f3 un dato fundamental<\/a>, aunque se ve que no es nuevo<\/a>: en ciertos equipos el sistema se cuelga a menos que uno cargue el m\u00f3dulo processor<\/em> con el par\u00e1metro nocst=1<\/em><\/strong>.<\/p>\n
As\u00ed que, de momento, agregu\u00e9 la l\u00ednea<\/p>\n
processor.nocst=1<\/pre>\n
a los par\u00e1metros de inicio del sistema y con eso estoy andando actualmente. \u00bfA qu\u00e9 se debe el bug? Ni idea, habr\u00eda que hacer un bisect entre las versiones de kernel 2.6.38 y 2.6.39 para determinar cual es el commit jodido. En cualquier caso, queda como tarea para vacaciones…<\/p>\n","protected":false},"excerpt":{"rendered":"
Desde hace algunos meses me ven\u00eda mordiendo un bug extra\u00f1o en la m\u00e1quina de trabajo donde a partir del kernel linux 2.6.39 e incluyendo la versi\u00f3n 3.0.0 el sistema se bloqueaba al inicio (el cl\u00e1sico freeze on boot) justo despu\u00e9s del mensaje Waiting for \/dev to be fully populated Y luego de eso, nada. Curioso, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[5,17,3],"_links":{"self":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/posts\/63"}],"collection":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/comments?post=63"}],"version-history":[{"count":0,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/posts\/63\/revisions"}],"wp:attachment":[{"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/media?parent=63"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/categories?post=63"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/maurom.com\/blog\/wp-json\/wp\/v2\/tags?post=63"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}