Dale al teclado

No me preguntéis por qué, pero, de un día para otro (debido, sin duda a la actualización de algún paquete), mi Debian Lenny dejó de reconocer los discos duros (son IDE normalitos) como /dev/hdX, pasando a ser /dev/sdX, con el consiguiente pánico en el arranque.

Afortunadamente, pude arrancar con un kernel anterior (actualmente tengo, por defecto, el 2.6.22-2, pero tengo guardado el 2.6.21-2, que sigue reconociendo los discos como /dev/hdX).

Precisamente porque mantengo ambos kernels, decidí que no podía cambiar directamente el fichero /etc/fstab poniendo sd donde antes ponía hd sin más, por lo que decidí utilizar la posibilidad de usar etiquetas identificativas únicas (UUID) de cada una de las particiones de mis discos duros. Esto permitiría arrancar el sistema tanto con un kernel como con el otro.

Para ello, lo primero que tenía que hacer es averiguar el UUID de cada una de mis particiones. Esto es fácil y se puede hacer de dos formas:

• Con el comando blkid. Al ejecutarlo en mi ordenador, la salida es la siguiente:

/dev/sda1: UUID="8121580a-584e-4700-907b-9b868acfe69e" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda2: TYPE="swap" UUID="09e26881-a3c1-426f-a01d-39f8fd2dfde7"
/dev/sda3: UUID="8fba1ffc-2af0-41b9-a71e-f2bd2a307cac" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdb2: UUID="eb9c1b22-2c10-45a3-adf6-2c8fd0fad253" SEC_TYPE="ext2" TYPE="ext3"

• Listando directamente los dispositivos mediante ls -l /dev/disk/by-uuid/. La salida del comando para mí es (dejo sólo la parte interesante):

09e26881-a3c1-426f-a01d-39f8fd2dfde7 -> ../../sda2
8121580a-584e-4700-907b-9b868acfe69e -> ../../sda1
8fba1ffc-2af0-41b9-a71e-f2bd2a307cac -> ../../sda3
eb9c1b22-2c10-45a3-adf6-2c8fd0fad253 -> ../../sdb2

Una vez identificadas las particiones, sólo queda editar el fichero /etc/fstab de la forma apropiada. En mi caso:

#/dev/sda3   /     auto   errors=remount-ro  0  1
UUID=8fba1ffc-2af0-41b9-a71e-f2bd2a307cac   /     auto   errors=remount-ro  0  1
#/dev/sda2   none  swap   sw                 0  0
UUID=09e26881-a3c1-426f-a01d-39f8fd2dfde7   none  swap   sw                 0  0
proc         /proc proc   defaults           0  0
#/dev/sda1   /boot auto   defaults           0  2
UUID=8121580a-584e-4700-907b-9b868acfe69e   /boot auto   defaults           0  2
#/dev/sdb2   /home auto   defaults           0  2
UUID=eb9c1b22-2c10-45a3-adf6-2c8fd0fad253   /home auto   defaults           0  2

¿Así de sencillo y de fácil? Nooooo. No cometáis el mismo error que yo. También hay que modificar el fichero /boot/grub/menu.lst del Grub. Es muy fácil, pero hay que hacerlo. En dicho archivo buscad las siguientes líneas:

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=/dev/hda3 ro

Pues bien, sólo hay que cambiar la última línea y dejarla (en mi caso) del siguiente modo (¡no olvidéis dejar la #!):

# kopt=root=UUID=8fba1ffc-2af0-41b9-a71e-f2bd2a307cac ro

Luego basta con ejecutar update-grub y el propio Debian se encargará de actualizar el resto del fichero.

Ahora ya sí podéis rearrancar el sistema sin miedo.

Añadido: No olvidar tampoco editar el fichero /etc/uswsusp.conf o reinstalar el paquete uswsusp.

Para forzar el chequeo de las particiones en un sistema GNU/Linux no es necesario, para nada, tocar el fichero /etc/fstab. Basta, simplemente, con crear un fichero en la raíz / con el nombre fsckcheck. Es decir:

touch /fsckcheck

Y rearrancar con reboot. En el arranque, serán verificadas todas las particiones antes de ser montadas y desaparecerá dicho fichero.

Ya lo había comentado en una actualización de un post anterior, pero creo que bien vale una entrada nueva: Ya está disponible el patch vmware-any-any-update114 para utilizar VMware con kernels hasta el 2.6.23.

Para instalarlo, as usual:

cd vmware-any-any-update114
./runme.pl

Gracias, Petr

Quizás la culpa sea mía por impaciente y pasarme al kernel 2.6.22, en lugar de quedarme, de momento, con el 2.6.21, con el cuál había conseguido hacer funcionar VMware.

El caso es que ya cansa que, aparte de tener que recompilar el módulo vmnet cada vez que se cambia de kernel, haya que buscarse la vida para parchear el código fuente tan a menudo.

Bueno, al menos esta vez ha sido relativamente rápido de encontrar. Todo se soluciona con el parche vmware-any-any-update113.tar.gz. Lo descomprimís:

tar xvfz vmware-any-any-update113.tar.gz

Y ejecutáis el script correspondiente:

cd vmware-any-any-update113
./runme.pl

Listo. Al menos hasta el próximo cambio de kernel…

Actualización 14/10/2007: Ya está disponible el patch vmware-any-any-update114 para kernels hasta el 2.6.23. Para instalarlo, hay que proceder igual que como se ha explicado más arriba.

Sí, ya sé que debería pasarme a QEMU, pero la inercia me lleva a seguir usando VMware, pues lo uso desde hace mucho tiempo y me da pereza volver a instalarme y configurar las máquinas virtuales que dispongo.

El caso es que recientemente en lenny (la actual testing de Debian) han liberado el kernel 2.6.21, por lo que he procedido a instalármelo.

Como viene siendo habitual tras un cambio en el kernel, he necesitado hacer algunos ajustes. Uno de ellos era recompilar los módulos de VMware para que encajen bien en el nuevo kernel. Eso se viene haciendo con el script vmware-config.pl sin mayores problemas. Pero esta vez la compilación fallaba. Indagando por ahí (bendito Google), conseguí encontrar un parche para el script (lo tenéis, entre otros sitios, aquí: vmware-any-any-update110.tar.gz). Lo descomprimís:

tar xvfz vmware-any-any-update110.tar.gz

Y ejecutáis el script correspondiente:

cd vmware-any-any-update110
./runme.pl

Pero… a mi no me funcionaba. A la hora de hacer insmod, me salía una Violación de segmento (Segmentation fault) que me partía el corazón.

Tras unos minutos más de Googleo, dí con el problema… y, esta vez, sin que sirva de precedente, la culpa no era de VMware, ¡sino de Debian! El caso es que hay un bug en el paquete module-init-tools (y, por tanto, en insmod) en su versión 3.3-pre11-1 (la que viene con testing). La solución: volver a instalar la versión estable module-init-tools_3.3-pre4-2_i386.deb

Una vez instalado, al volver a ejecutar vmware-config.pl, se solucionaron todos mis problemas.