[eside-ghost] VM a máquina real

[Jon Ander Hernández]

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.