Acabo de instalar un sistema como este:
ubuntu@ubuntu:~$ ls -l /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 10 2012-01-22 18:49 Boot -> ../../sda1
lrwxrwxrwx 1 root root 10 2012-01-22 18:49 ubuntu32 -> ../../sda2
lrwxrwxrwx 1 root root 10 2012-01-22 18:28 ubuntu64 -> ../../sda3
lrwxrwxrwx 1 root root 10 2012-01-22 18:49 Home -> ../../sda5
ubuntu@ubuntu:~$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 3582d70f-f4a5-484c-b14c-45cd740346b9 -> ../../sda1
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 741182a8-3f15-4dfd-994d-654c8a57a9e4 -> ../../sda2
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 1c415472-a770-4d76-be9f-27b8c1408e2a -> ../../sda3
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 3515d523-72a2-4e04-b7da-cb6a1fd572ef -> ../../sda5
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 f1f1cd7e-30cb-44e7-9ef6-986a589e0045 -> ../../sda6
Necesito 32 y 64 bits separados para poder probar el rendimiento del controlador en cada uno, el directorio de inicio se comparte y cada versión de ubuntu se monta como /ubuntuXX en la otra versión. /boot también apunta a /dev/sda1 en ambos.
Cuando ejecuto sudo update-grubdesde ubuntu32, funciona bien pero aparece un error al iniciar ubuntu64. initfalla y supongo que se debe al tipo de bit incorrecto. ¿No debería la sonda del sistema operativo de grub tener en cuenta los bits? ¿Cómo puedo hacer que estos dos arranquen correctamente?
Ejecuté grub-customizer desde un disco activo, elegí /dev/sda3 como root, seleccioné todas las particiones en el segundo paso y luego eliminé todas las particiones excepto OS-Prober y memtest. El resultado es el grub.cfg adjunto. Ahora enumera /dev/sda2 como la única opción del sistema operativo. Grub.cfg tiene el UUID raíz configurado en /boot para cada entrada.
grub.cfg:http://pastebin.com/Dkdxian4
fstab (ambos):http://pastebin.com/3sUabYRY
Sé que grub2 se genera automáticamente y tiene menús y jazz, pero ¿cómo puedo eliminar todo eso y agregar manualmente elementos completos (no mantendré esta instalación por mucho tiempo para que no haya que preocuparse por las actualizaciones del kernel)?
Intenté replicar a ciegas la /dev/sda2entrada, pero ajustándola para /dev/sda3que no saliera bien. Sin embargo, logré obtener el mismo error que en mi primer intento (es la línea justo antes del pánico del kernel run-init) .
parte actualizada de grub.cfg:http://pastebin.com/DvfBhrBF
(null)
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom: ... done.
[ 3.402989] request_module: runaway loop modprobe binfmt-464c
run-init: /sbin/init: Exec format error
[ 3.406303] Kernel panic - not syncing: Attempted to kill init!
[ 3.406394] Pid: 1, comm: run-init Not tainted 3.0.0-15-generic #25-Ubuntu
[ 3.408290] [<c151a922>] ? printk+0x2d/0x2f
[ 3.408338] [<c151a800>] panic+0x5c/0x151
[ 3.408388] [<c104b564>] forget_original_parent+0x1e4/0x1f0
[ 3.408440] [<c10d3a48>] ? perf_cgroup_attach_task+0x20/0x20
[ 3.408489] [<c104b583>] exit_notify+0x13/0x140
[ 3.408536] [<c104bd8d>] do_exit+0x1ad/0x3a8
[ 3.408585] [<c1313850>] ? tty_write+0x228/0x228
[ 3.408632] [<c104c098>] sys_exit+0x18/0x28
[ 3.408680] [<c152e424>] syscall_call+0x7/0xb
Estoy empezando a pensar que tiene que ver con las imágenes del kernel que están en el directorio /boot.
Bien, ahora estoy seguro de que se debe al hecho de que una partición es de 32 bits y la otra de 64 bits.
Figura 1: ejercicio desde /boot/grub/grub.cfg:
linux /vmlinuz-3.0.0-12-generic root=/dev/sda2
initrd /initrd.img-3.0.0-12-generic
Figura 2: Listados de /ubuntu64/vm* y /ubuntu32/vm*
me@GAMMA:~$ ls -l /vm*
lrwxrwxrwx 1 root root 29 2012-01-23 20:41 /vmlinuz -> boot/vmlinuz-3.0.0-15-generic
lrwxrwxrwx 1 root root 29 2012-01-22 13:05 /vmlinuz.old -> boot/vmlinuz-3.0.0-12-generic
me@GAMMA:~$ ls -l /ubuntu32/vm*
lrwxrwxrwx 1 root root 29 2012-01-22 12:41 /ubuntu32/vmlinuz -> boot/vmlinuz-3.0.0-15-generic
lrwxrwxrwx 1 root root 29 2012-01-22 12:22 /ubuntu32/vmlinuz.old -> boot/vmlinuz-3.0.0-12-generic
Figura 3: Tipo de archivo mágico de /boot/vmlinuz-3.0.0-12-generic
/boot/vmlinuz-3.0.0-12-generic: Linux kernel x86 boot executable bzImage, version 3.0.0-12-generic (buildd@creste, RO-rootFS, root_dev 0x801, swap_dev 0x4, Normal VGA
/boot/vmlinuz-3.0.0-15-generic: Linux kernel x86 boot executable bzImage, version 3.0.0-15-generic (buildd@creste, RO-rootFS, root_dev 0x801, swap_dev 0x4, Normal VGA
Ahora aquí está elrealpateador:
me@GAMMA:~$ sudo find / -name "vmlinuz*"
/boot/vmlinuz-3.0.0-12-generic
/boot/vmlinuz-3.0.0-15-generic
/vmlinuz.old
/vmlinuz
/ubuntu32/vmlinuz.old
/ubuntu32/vmlinuz
¡Ese es el único núcleo en mi sistema! ¿Cómo es eso posible? ¡Estoy ejecutando 64 bits en este momento ( /dev/sda3es /e unameinforma 64 bits)!
Revisé el contenido del paquete en packages.ubuntu.com y la versión am64 de las listas linux-image-3.0.0.15-generic /boot/vmlinuz-3.0.0-15-genericcomo un archivo, así que ejecuté lo siguiente:
me@GAMMA:~$ sudo openssl dgst -md5 /boot/vmlinuz-3.0.0-15-generic > ~/3.0.0.15x86
me@GAMMA:~$ sudo apt-get install --reinstall linux-image-3.0.0-15-generic
(Output Omitted)
me@GAMMA:~$ sudo openssl dgst -md5 /boot/vmlinuz-3.0.0-15-generic
MD5(/boot/vmlinuz-3.0.0-15-generic)= f56839a4642eb97e06e5efb0bc74f4dc
me@GAMMA:~$ cat ~/3.0.0.15x86
MD5(/boot/vmlinuz-3.0.0-15-generic)= f56839a4642eb97e06e5efb0bc74f4dc
me@GAMMA:~$ sudo openssl dgst -md5 /boot/vmlinuz-3.0.0-15-generic > ~/3.0.0.15x86
Entonces, el kernel de Linux actúa de manera muy similar al Kernel Mach en OSX en el sentido de que es un ejecutable de 32 bits que cambia al modo de 64 bits cuando es necesario. La pregunta entonces es ¿por qué recibo un error sobre "Error de formato Exec"?
Esta publicaciónsin embargo, parece indicar que runaway loop modprobeKernel Panic indica que se trata de un problema de 32/64 bits. Grub debe tener alguna forma de decirle al kernel la longitud de bits, tal vez esté en un archivo asociado en /boot, y lo investigaremos mañana.
Actualización rápida:
los kernels de 32 y 64 bits tienen un hash diferente, pero el archivo informa que ambos son x86.
< MD5(/boot/vmlinuz-3.0.0-15-generic)= f56839a4642eb97e06e5efb0bc74f4dc
---
> MD5(/boot/vmlinuz-3.0.0-15-generic)= cee6cd7db9016ee8531be92504ac802b
Así que necesito determinar cómo instalar el kernel en algún lugar que no sea /boot para que los dos kernels no se golpeen entre sí...
Respuesta1
(no probado) Solución:
Monte /dev/sda1 solo en /boot para una partición, deje /boot para la otra partición en su lugar. Los núcleos no se golpearán entre sí y entonces tal vez grub no se confunda en cuanto a por qué hay dos sistemas operativos pero un núcleo.