Acabei de instalar um 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
Preciso de 32 e 64 bits separados para poder testar o desempenho do driver em cada um, o diretório Home é compartilhado e cada versão do Ubuntu é montada como /ubuntuXX na outra versão. /boot também aponta para /dev/sda1 em ambos.
Quando executo sudo update-grubo ubuntu32 ele funciona bem, mas recebo um erro ao inicializar o ubuntu64. initfalha e presumo que seja por causa do tipo de bit errado. A investigação do sistema operacional do grub não deveria ter reconhecimento de bits? Como posso fazer com que esses dois inicializem corretamente.
Executei o grub-customizer a partir de um disco ativo, escolhi /dev/sda3 como root, selecionei todas as partições na segunda etapa e removi todas as entradas, exceto OS-Prober e memtest. O resultado foi o grub.cfg anexado. Agora lista /dev/sda2 como a única opção de sistema operacional. O grub.cfg tem o UUID raiz definido como /boot para cada entrada.
grub.cfg:http://pastebin.com/Dkdxian4
fstab (ambos):http://pastebin.com/3sUabYRY
Eu sei que o grub2 é todo gerado automaticamente, menus e jazz, mas como faço para destruir tudo isso e adicionar itens inteiros manualmente (não vou manter esta instalação por muito tempo, então não há preocupação com atualizações do kernel)
Tentei replicar a /dev/sda2entrada de maneira simples, mas ajustei-a para /dev/sda3o caso, mas não deu certo. No entanto, consegui obter o mesmo erro da minha primeira tentativa (é a linha logo antes do kernel panic run-init)
parte atualizada do 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
Estou começando a pensar que isso tem a ver com as imagens do kernel que estão no diretório/boot.
Ok, agora tenho certeza de que é devido ao fato de uma partição ser de 32 bits e a outra de 64 bits.
Figura 1: exercício de /boot/grub/grub.cfg:
linux /vmlinuz-3.0.0-12-generic root=/dev/sda2
initrd /initrd.img-3.0.0-12-generic
Figura 2: Listagens de /ubuntu64/vm* e /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 arquivo mágico /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
Agora aqui está orealchutador:
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
Esse é o único kernel no meu sistema! Como isso é possível? Estou executando 64 bits agora ( /dev/sda3é /e unamerelata 64 bits)!
Verifiquei o conteúdo do pacote em packages.ubuntu.com e a versão am64 das listas linux-image-3.0.0.15-generic /boot/vmlinuz-3.0.0-15-genericcomo um arquivo, então executei o seguinte:
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
Portanto, o kernel do Linux atua de maneira muito semelhante ao Mach Kernel no OSX, pois é um executável de 32 bits que muda para o modo de 64 bits quando necessário. A questão então é por que estou recebendo um erro sobre "Erro de formato Exec"?
Esta postagemno entanto, parece indicar que runaway loop modprobeo Kernel Panic indica que este é realmente um problema de 32/64 bits. O Grub deve ter alguma maneira de informar ao kernel o comprimento de bits, talvez esteja em um arquivo associado em /boot, analisando isso amanhã.
atualização rápida:
os kernels de 32 e 64 bits têm hash diferente, mas o arquivo informa que ambos são x86.
< MD5(/boot/vmlinuz-3.0.0-15-generic)= f56839a4642eb97e06e5efb0bc74f4dc
---
> MD5(/boot/vmlinuz-3.0.0-15-generic)= cee6cd7db9016ee8531be92504ac802b
Então eu preciso determinar como instalar o kernel em algum lugar diferente de /boot para que os dois kernels não se sobreponham...
Responder1
(não testado) Solução:
monte /dev/sda1 apenas em /boot para uma partição, deixe /boot para a outra partição no lugar. Os kernels não se sobrepõem e talvez o grub não fique confuso sobre o motivo de haver dois sistemas operacionais, mas um kernel.