[eside-ghost] VM a máquina real

[Jon Urionaguena]

Jon Ander Hernández escribió:
> Aupi!!
> 
> On Wed, 2006-09-13 at 20:18 +0200, Jon Urionaguena wrote:
>> Jon Urionaguena escribió:
>>> zgor escribió:
>>>> Aupi Jon,
>>>>> Me preguntaba como respondería un sistema de máquina virtual Linux (que
>>>>> ya está montado y te ahorra toda la instalación) pasado a un disco
>>>>> físico con dd (o algo así) y montarle un lilo para que arranque... Es
>>>>> que se lleva mucho eso de que los fabricantes publiquen VMs de prueba
>>>>> con los sistemas ya montados para que los pruebes...
>>>>>
>>>>> Entiendo que el kernel puede dar problemas para arrancar dependiendo de
>>>>> la máquina real en la que se quiere montar... ¿no?
>>>>>
>>>>> ¿Alguien tiene experiencia con esto? ¿Algún axioma que diga, "no, esto
>>>>> no se puede hacer, por que bla, bla, bla..."?
> 
> Yo entiendo que en teoría no tendría que haber más problema que el que
> te puedes encontrar con una distribución normal instalada en un sistema
> y que al llevarlo a otro equipo de algún problema, por ejemplo porque
> tenga un kernel específico para la CPU, porque use kudzu para el
> reconocimiento de hardware y te habrá algún asistente raro, que intente
> cargar modulos de hardware que no tienes porque están especificados
> en /etc/modules, etc...
> 
>>> A ver,
>>>
>>> Lo he hecho todo y algo falla...
>>>
>>> Tengo una VM arrancada en red con rsync instalado
>>> Pincho un disco como secundario en un sistema arrancado, en red y con
>>> rsync. Lo monto...
>>> Copio disco completo con rsync, no problem...
>>> Chroot al disco montado y le instalo lilo, no problem...
>>> Quito el chroot (si no no puede acceder a este disco secundario, en mi
>>> caso /dev/hdc) y ejecuto "lilo -C /mnt/xxx/etc/lilo.conf" con está
>>> entrada en el lilo.conf:
>>> ##################################
>>> lba32
>>> boot = /dev/hdc
>>> disk=/dev/hdc bios=0x80		--> Importante para que lo ejecute en el disco
>>> correcto!!
>>> map = /mnt/disco/boot/System.map-2.6.15-1-686
>>> default=XXX
>>> menu-scheme=Wb
>>> prompt
>>> timeout=50
>>> delay=50
>>> vga=normal
>>>
>>> #LILO bootable partitions
>>>
>>> image = /mnt/disco/boot/vmlinuz-2.6.15-1-686
>>>         root = /dev/hda1
>>>         label=XXX
>>>         read-only
>>> ####################################
> 
> No se si te habrás percatado de este detalle, pero en lo que nos has
> copy/pasteado estas pasándole como parámetro del kernel root /dev/hda1
> cuando entiendo que debería ser /dev/hdc1.
> 
>>> Así hace arrancable (MBR y partición primaria) dicho disco.
>>>
>>> Cambio el /etc/fstab del nuevo disco para que coincidan los montajes de /.
> 
> Por lo que yo entiendo y además tal como lo comprobamos en los cursillos
> de Julio que tuvimos un divertido problemilla, a pesar de que este mal
> el / en fstab pasa, porque una vez que ha arrancado el user-space
> entiendo que no se puede desmontar y volver a montar /.
> 
>>> Pincho el disco como primario maestro en otra maquina. Arranca lilo,
>>> selecciono sistema y ...taraaaa... Kernel Panic:
>>>
>>> "VFS: Cannot open root device "1601" or unknown-block..."
>>>
>>> Bueno, ahora a desbarrar:
>>> - Me da que no puede montar los fs's correctamente...
>>> - Al pincharlo en otra máquina como primario maestro, como lo detectará
>>> linux...? /dev/hda? Yo había puesto mis referencias (lilo.conf y fstab)
>>> a /dev/hdc... Y aún cambiando las de fstab a /dev/hda no ayuda nada
>>> - Si lo pincho en el IDE 2 sin nada en el IDE 1, lo detecta como
>>> /dev/hda o /dev/hdc?
> 
> Debería ser /dev/hdc
> 
> Si tienes udev un truco chulo para ver que es y que puede que la mayoría
> no lo conozca es el de : 
> 
> $ ls -l /dev/disk/by-id/
> total 0
>  9 Sep 13 22:22 ata-Maxtor_6Y120L0_Y36H72BE -> ../../hda
> 10 Sep 13 22:22 ata-Maxtor_6Y120L0_Y36H72BE-part1 -> ../../hda1
> 10 Sep 13 22:22 ata-Maxtor_6Y120L0_Y36H72BE-part2 -> ../../hda2
> 10 Sep 13 22:22 ata-Maxtor_6Y120L0_Y36H72BE-part4 -> ../../hda4
> 10 Sep 13 22:22 ata-Maxtor_6Y120L0_Y36H72BE-part5 -> ../../hda5
> 10 Sep 13 22:22 ata-Maxtor_6Y120L0_Y36H72BE-part6 -> ../../hda6
> 
> Bueno la verdad es que no sirve para pasarlo como argumento al kernel,
> porque esto lo hace udev y no el kernel, y tampoco podríamos pasarle
> un /dev/hd* o /dev/disk/by-id/*maxtor* porque el kernel tampoco hace
> pathname-expasion... aunque yo supongo que no es descabellado que esto
> se pueda hacer con un initrd muy poderoso que tenga udev dentro y muchos
> truquis (como el initrd de ubuntu que tiene udev dentro :D).
> 
>>> - Y una tontería... VFS será Virtual File System... Hay capa de
>>> abstracción del HW desde la VM. En la VM eran discos SCSI, pero yo he
>>> copiado todo el contenido a un IDE y luego lo monto todo... Tiene el
>>> kernel creado alguna referencia más a SCSI y por eso no arranca??
> 
> Yo diría que no tiene nada que ver con el hecho de que el HDD sea IDE o
> SCSI, yo creo que es porque le estas pasando como parámetro del kernel
> root=/dev/hda1 y eso es un dispositivo inválido porque el dispositivo
> debería ser hdc.
> 
> Y bueno ya que has mencionado lo de IDE y SCSI, como curiosidad
> divertida que la capa IDE del kernel va a desaparecer, y en su lugar se
> va a usar libata. Libata es el driver SATA de Linux (que esta siendo
> extendida para soporta PATA aka IDE/ATA), y si os fijáis los
> dispositivos son sd*, es decir que son funcionan bajo el subsistema SCSI
> como también lo hace el usb mass storage, el firewire sbp-2 (el mass
> storage del firewire), con lo cual el ide también pasará a ser
> virtualmente SCSI :-D.
> 
> Estado del port de Alan Cox de los drivers PATA a libata :
> http://zeniv.linux.org.uk/~alan/IDE/STATUS.txt
> 
> Página de información de libata y el soporte sata de Linux :
> http://linux-ata.org/
> 
>>> - Liada de booting y kernels...
> 
> Otra cosa que se me ocurre es que el kernel de la distro necesitara y no
> lo estés cargando, es decir, si el kernel no tiene el soporte para leer
> ese sistema de archivos, lo típico es que el soporte este dentro del
> initrd.
> O prueba con otro kernel [+ initrd] de otra distro.
> 
>> A ver si alguien me aclara algo!!!
> 
> A ver si tienes suerte ;-)
> 
> Un saludete!!
> 
> JonAn.
> 
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost
> 

Gracias JonAn

El caso es que cuando ejecuto LILO el disco en el que lo quiero ejecutar
es hdc (en ese momento...). Pero al pincharlo en su nueva máquina pasará
 a ser hda...

El caso es que os he pasteado un lilo.conf concreto, pero he hecho
múltiples pruebas (la mayoría cambiando hdc por hda en cada uno de los
parámetros y viceversa)

Por esto tengo liada en los parámetros de lilo.conf...

La primera parte especifica parámetros globales... Los importantes son
(importantes en cuanto a mi liada)-->
boot
disk
map
install

Luego el boot de cada sistema que quieras que LILO lance
image
root

En estos parámetros, a qué se refiere cada uno?... a los dispositivos y
ficheros que hay en el momento de ejecutar LILO (hdc y /mnt/.../boot)? o
a los que habrá cuando arranque el disco (hda y /boot)?

Esa es mi verdadera liada...

Porque luego, que el kernel arranque o no en el HW nuevo pues dará sus
Kernel Panic por motivos diversos... Y vete a saber, será que le falta
modulo tal o cosa cual... Pero mi fallo es por que no monta bien el
sistema de fitxs raiz... Debido a:

-Que se lo pasa mal LILO (mi liada de parametros)
-Que el kernel descomprimido no puede leer ese tipo de discos (¿?),
falta de soporte IDE o algo así... (¿Estoy diciendo burradas?)
-Alguna otra razon (¿Cuál?)

De todas maneras, esta noche o mañana hago una prueba más... Tengo
kernel, map y archivos boot.X que sé que arrancan bien el HW y leen bien
los discos finales (de hecho está instalado y rula en la máquina de
pruebas en la que voy a poner el HD con la VM pasada a máquina real...).
Voy a probarla cambiando los que le he pasado de la VM por estos y
vuelvo a ejecutar LILO a ver que tal... Os comento...

Saludos,

-- 

Jon