Hay veces en las que cuando reparamos algún equipo, todavía nos sorprende el PC con alguna acción que no nos esperábamos. Una de estas pequeñas sorpresas en el taller nos llevamos hace unas semanas, cuando terminamos de arreglar un ordenador con Linux.
El cliente nos avisa y nos indica, que el PC lo apago bien, pero que cuando unos días después (estaba de vacaciones) volvió a ponerlo en marcha, no consiguió que arrancase. Le pregunte si tenía copia de seguridad y me dijo que la última la había hecho hacía unos días y que pensaba que tenía todo guardado. Pero que si podíamos reparar sin perder los datos, pues mejor. En el PC estaba instalado Ubuntu.
Así que nos llevamos el PC al taller y nos pusimos a buscar la avería. Al final la placa base estaba rota (era un equipo ya veterano, con muchos años encima). Le pasamos al cliente un par de presupuestos. En uno, le cambiábamos solo la placa y si la Ram y el micro funcionaban, pues tema resuelto. En el otro, íbamos a un cambio total de tripas: placa, micro y Ram. Como el cliente hacia un año ya había puesto un disco SSD para el sistema operativo, si cambiaba placa, micro y Ram, junto con el SSD, el PC iba a funcionar muy bien. Eso si, el cambio era de chipset, micro y Ram, veríamos que pasaba con el sistema operativo que estaba instalado.
Al final nos acepta el presupuesto del cambio total. Y antes de hacer nada, puesto que el SSD era de 120 gigas, hicimos una imagen del mismo en el servidor de copias de seguridad del taller. Le cambiamos los componentes al PC y pinchamos un disco nuestro, para pasar los tests. Todo funcionaba bien, así que pinchamos el SSD de arranque del cliente. Y allí estaba la pantalla de inicio de Ubuntu,como si nada, pidiéndonos la contraseña de acceso. Avisamos al cliente y éste se paso por la tienda a recoger el PC. Entró al taller y tecleó su contraseña y de repente, empezaron a abrirse ventanas… el cliente empezó a moverse con el ratón y se quedo igual de sorprendido que nosotros. Resulta que no había apagado el PC, sino que lo había hibernado. Pues tras el cambio de micro, placa y Ram, el Ubuntu arrancó en el mismo sitio sin inmutarse.
No tuvimos que recurrir a nuestra copia, ni el cliente a su copia de seguridad. Le hicimos algunas pruebas y todo estaba funcionando sin problemas.
Anterior y Posterior
32 Comentarios
Comentarios Cerrados
¿Estoy leyendo que el equipo pudo arrancar desde una hibernación después de un cambio de hardware? ô_O
A mi me ha pasado incluso cambiando de AMD a Intel un equipo, eso no te funcionaria en Windows prácticamente nunca.
Y con un kernel linux mínimamente personalizado tampoco
Bueno si, estas cosas normalmente funcionan sobre todo con un “vanilla kernel”, pero también depende de que es lo que personalices en el kernel. Por ejemplo ahora esta muy de moda cambiar el ‘scheduler’ por defecto del kernel y eso no tendría porque dar problemas con este tipo de cambio.
Hombre, si tu personalización es “a la mierda los drivers que creo uqe no necesito” pues no, no funcionaría 😀
Si, estás leyendo bien, con un micro de cuatro generaciones más moderno que el que tenía…
Relativamente me sorprendería que hiciese un arranque en frio sin dar algún error buscando algún hardware y cargando drivers nuevos, pero el que entre en hibernación con una placa y salga de la hibernación en otra placa… lo mínimo que esperaría es un kernel panic porque tenía controladores cargados para hardware que ya no está ahí.
Lo que si te fallaría irremediablemente es un cambio de arquitectura de 64 bits a una de 32 bits empleando un kernel x64. Ante lo otro, he procedido a ‘despertar’ un servidor después de cambiar en caliente alguna pieza sin mayor problema.
Yo esperaba justamente lo que comentas…
Es que el estado de hibernación en linux es prácticamente un inicio del sistema, sólo que después se cargan las aplicaciones y el estado del sistema en el punto concreto en el que se hibernó. Esto hace que se cargue desde 0 el kernel y uno de los pasos que hace es detectar si hay hardware nuevo, elegir el driver más apropiado y ponerlo en funcionamiento.
En Windows muchas veces una hibernación funciona más como una suspensión en disco, cargándose la imagen de disco a memoria y, evidentemente, provocando todo tipo de fallos al más mínimo cambio en el hardware.
Ala, ya me has resuelto tu las dudas del tema. Yo pensaba que lo que hacía era directamente volcar a disco duro el contenido de la RAM.
Esto es un ejemplo muy bueno de lo comodo que es Linux.
A mi me ha pasado un par de veces, que mis Linux Box se rompen en algun momento en su hardware y el cambio es muy cómodo, inclusive de Intel a AMD lo soporta perfectamente.
Windows deberia poder hacer algo asi, sin embargo su tema es mas por Licenciamiento mas que porque no lo puedan hacer. De la unica manera que lo he podido lograr es con Acronis Universal Restore, sin embargo eso era hasta antes de UEFI, lo cual nos da un panorama completo de que el tema es mas el aspecto propietario que la funcionalidad.
Yo con Windows XP hacia esto continuamente, de hecho partía de imágenes de instalaciones previas casi siempre para los equipos nuevos de oficina. Solo daban la lata algunos drivers, sobre todo las tarjetas gráficas, pero casi siempre era subsanable.
Con las nuevas versiones ya no me peleo tanto, ahora me muevo mas con Linux y Unix, pero alguna vez me ha funcionado con algún Windows 7
Lo he hecho alguna que otra vez con Windows y a veces funciona y a veces no, aunque lo más normal es obtener una bonita pantalla azul.
Si el Windows es autentico y lo haces un par de veces, te puedes encontrar con la sorpresa de que a la tercera te diga que necesitas una nueva clave de Windows porque has superado el numero de instalaciones! sobre todo si el Windows es un OEM. Mas de una vez esto me ha dejado ojiplatico! Si el windows ya está instalado 🙂 es lo que tienen las conexiones del Windows a la red 🙂
Con Windows, llevando cuidado (y algo de suerte se puede hacer) pero no es así de natural y sencillo
Yo recuerdo que mi instalación de Debian Potato fue upgradeada hasta Debian Etch. Cuando cambiaba de ordenador no tenía más que poner el disco del viejo en el nuevo. Cuando cambiaba de disco no tenía más que copiar los datos con un “cp -a” y correr lilo o grub. Actualizaciones de sistema con un solo comando y mis preferencias, personalizaciones y datos durante años y años conmigo sin un sólo problema.
Esto es así normalmente con las distribuciones linux que aun usan los sistemas de arranque clásicos (System V, BSD e incluso el Upstart de Canonical). Pero con las distros que ya han adoptado el nuevo Systemd (Fedora, Ach, openSuse, Mageia, Mandriva, …) te puedes llevar una sorpresa en este sentido. Ya que emplea el UUID y si cambias el disco, la partición, etc… te puedes encontrar con que no te arranca, porque el proceso arranque va referenciado a ese UUID (bien la partición de /boot/, bien / o bien ambas), nada que no pueda ser solucionado, pero te puede dar un susto. Y como dice Eliot el arranque desde UEFI introduce una nueva variable que puede complicar este tipo de operaciones, aunque tampoco nada que no se pueda solventar.
Si mal no recuerdo, el UUID va por disco, así que si usaba el mismo disco no tiene que haber problemas. Es más, el uso de UUID evita problemas de tipo “mi sda ahora es sdb”.
No, el UUID no va por disco, si no por partición, bueno en realidad no, si no por sistema de ficheros. Si coges un disco, sin tocarle las particiones, pero formateas una de ellas, esa partición tendrá un UUID nuevo. De hecho puedes cambiar el UUID de una partición (en realidad del sistema de archivos) por uno nuevo aleatorio cuando desees, hay herramientas para ello.
Luego si usas el mismo disco, no tocas las particiones y no formateas ninguna de ellas o le cambias el UUID no tendrías que tener problemas. Pero si clonas el disco es muy posible que los tengas, puede que ya en el boot manager si referencias las particiones por UUID o bien en el proceso de arranque con systemd. Eso si, siempre puedes cambiar esa referencia para que apunte al nuevo UUID.
Hace poco menos de 1 año actualicé una PC vieja en casa (AMD Duron de 1ghz que nunca tuvo problemas mas allá de ser lentísimo) por un Athlon II X3 455 manteniendo la instalacion de XP que estaba hecha en el disco duro, solo necesité cambiar los drivers por genericos y luego instalar los del nuevo mother.
Parecia que no necesitaba hacer nada mas, hasta que me di cuenta que solo estaba utilizando 1 de los 3 nucleos del nuevo procesador, lo unico que pude hacer fue reinstalar XP.
Me parece increible que Ubuntu te haya arrancado sin problemas. Cada vez hay mas razones para hacer el salto.
Creo que podías haberte ahorrado la reinstalación poniendo un driver de AMD para el procesador (existe para XP)
Habia encontrado un driver que resolvia algunos problemas con los AMD Dual Cores pero no cambio nada (al igual que muchas actualizaciones de microsoft), lei por algun lado que una vez que windows se instala como single ó multi core y despues no hay mas vuelta que darle
Leche, en ubuntu los paquetes vienen compilados para el juego de instrucciones 386… jejeje
Venga, vamos con los temas escabrosos: ¿alguna ventana con porno? 😉 😀
No si no me falla la memoria empezó a sonar la música que estaba oyendo el cliente cuando hiberno
Esto a mi ya no me sorprende, lo he visto otras veces. Lo que si me sorprendió fue un caso similar con una versión de prueba (beta) de ThinPC, que es una version liviana de Windows 7 hecha por Microsoft solo disponible para corporaciones. Transplante de maquina virtual a PC real? Sin problemas. La versión final se comporta como cualquier Windows y da una BSOD.
Hace muy poco actualicé un viejo PC para un compañero de trabajo.
Me trajo un Pentium 4, un modelo de Fujitsu, y tan solo aproveché caja, disco y grabadora DVD.
Monté un AMD FX-4100 con DDR3, puse el mismo disco IDE que traía con Ubuntu (12.04), le di a arrancar y ahí estaba sin una sola queja o problema.
Ubuntu es un Linux muy bien hecho y preparado para cualquier eventualidad, y estas cosas bien lo demuestran.
Por cierto, al final formateé porque mi compañero quería aprovechar para ponerle W7, que se instaló rápido, pero luego estuvo bastantes hora actualizando el W7.
Cuando finalizó puse el CD de Ubuntu, marqué actualizar mientras instalaba y en menos de 1 hora estaba funcionando como si tal cosa.
De todas formas instalando de cero dos PCs con Ubuntu esta semana justamante las actualizaciones se han vuelto eternas, justo lo contrario que a ti, Windows en 20 minutos funcionando y Ubunto se paso tres horas… eso si, equipos de gama muy alta. Curioso, no le dimos más importancia, porque los clientes no se iban a quedar con nuestro Ubuntu, sino que iban a instalarse el Linux a su gusto, pero nos llamo la atención.
Lo de Ubuntu suele suceder cuando el mirror desde que se bajan los paquetes esta saturado o con problemas, a veces se llegan a cortar las actualizaciones. Por desgracia, lo normal es que esto solo me pasara con los mirror españoles, rara vez con los principales. Sobre todo cuando sale una nueva versión, aconsejo paciencia y comprobar los mirrors antes, mas de uno se ha quedado con una actualización interrumpida por la mitad por esto.
Yo tengo todavía por ahí una vieja maquina Pentium MMX 233 con Gentoo optimizado a tope. Los que conozcáis esta distribución sabréis que lo que se hace es bajar el código fuente y compilar con flags optimizados para tu procesador. El problema es que esto en una maquina tan veterana como esto puede tardar muchísimo. Pues lo que hago cuando quiero actualizar es poner el disco duro en mi phenom 2 X4, arranco, actualizo y vuelvo a poner el disco duro ya con la distro actualizada en el otro ordenador. Todo esto ademas sin ningún tipo de problemas