Windows 7 64 bits no iMac com Snow Leopard - BootCamp 3.0

A vida não é facil para quem tem um iMac e quer instalar o Windows 7 64 bits. A Apple decidiu que os drivers de 64 bits não poderiam ser instalados nos iMacs, só nos MacPros, mas tudo tem jeito :-D. Neste outro post, eu descrevi como instalar a versão 32 bits do Windows 7 RC, mas com o Boot Camp 2.1 do velho Leopard.

O problema é que eu gostei do novo brinquedo e comprei o Windows 7 Edição Familiar Premium. Eu já sabia que o RC seria destruído, então comecei preparado. A caixa chegou na segunda-feira, comprei por 56€ numa super-promoção ainda em Julho na PixMania.be! Por 56€ é uma opção muito interessante, não sei se teria feito o mesmo se tivesse que pagar os 99 que a Microsoft pede hoje. Backup feito, começa a aventura!

Usando a mesma partição do meu Windows 7 RC, eu apenas pedi ao BootCamp 3.0 do Snow Leopard para iniciar o CD de instalação Windows. Fiz o boot e instalei normalmente, usando o setup do Windows. O Windows 7 vem com dois DVDs, um com a versão 32 bits e outro com a versão 64. É bom olhar antes de dar o boot, porque não lembro de nenhum indicador visual de qual dos dois estava instalando (salvo no próprio DVD!).

Instalei o Windows 7 64 bits na mesma partição do Windows 7 32 bits RC, mas para minha surpresa o instalador disse que estaria movendo tudo para uma pasta Windows.OLD. Eu já estava preparado para começar do zero, aguardando a formatação do disco, coisa que não aconteceu. Tudo do Windows 7 RC antigo foi movido para a Windows.Old, inclusive o Program Files e outros diretórios.

Terminada a instalação, não tive qualquer problema no Mac, até precisar instalar o boot camp. A mensagem que apareceu é que a versão 64 bits dos drivers não é suportada na minha máquina: Boot Camp x64 is unsupported on this computer model.

Uma rápida visita no site da Apple, revela que os iMacs não estão na lista dos equipamentos suportados para os drivers de 64 bits do Windows Vista ! Uma rápida busca no Google, revela este artigo. Eu já havia lido outros, mas poucos sobre o problema da restrição do iMac. Meu iMac é modelo 2008. Antes disso, nem adianta tentar. Nao precisa baixar nada de sites estranhos, tudo que você precisa está no DVD do Snow Leopard. Um dos comentários do artigo diz que conseguiu instalar o BootCamp pelo arquivo .msi. Aparentemente é o setup.exe que verifica a restrição aos iMacs. O problema é que clicando no Boot Camp\Drivers\Apple\BootCamp64.msi no Windows Explorer ele não instala. O comentário também diz para executar em linha de comando privilegiada. Aí a coisa ficou esquisita, pois eu já era administrador do sistema. Lembrei que o Windows 7 é um primo próximo do Vista, chato mesmo.

O que precisa fazer:

• A partir do menu iniciar, abra a pasta de acessórios e clique com o botão direito no Command Prompt. Escolha a opção de executar em modo privilegiado.
• Na janela de comandos que abriu, vá para o diretório do BootCamp64, no meu caso o drive D: é o DVD-ROM:

d:
cd "\Boot Camp\Drivers\Apple"
msiexec /i BootCamp64.msi

Depois é só prender o fôlego e ter fé. A instalação do Boot Camp é assustadora. Telas pretas e piscadas alucinantes aconteceram no meu caso, mas é coisa rápida, bips também acontecem. Nada que não assuste durante a instalação de um novo Windows, principalmente instalando drivers do Vista 64 no Windows 7... mas já da para aguardar até os drivers nativos do Windows 7 serem lançados.

Um boa é que mesmo antes do Boot Camp ser instalado eu já tinha rede. Rede com cabo e sem fio funcionaram de primeira após a instalação. O som, o eject e a camera só funcionaram depois de instalar o BootCamp. Alias, o som não está tão bom assim. Uma dica é que o eject funciona pelo Windows Explorer, mesmo antes de instalar o Boot Camp. É só clicar no drive de DVD com o botão direito e selecionar ejetar.

A melhor surpresa foi poder acessar a partição do Mac pelo Windows Explorer. Isso é muito legal, principalmente quando você procura um arquivo que está no outro sistema.

Em relação a utilização de memória, aqui eu perdi uns 200 MB de cara, só trocando de 32 para 64 bits. O Windows 32 pedia uns 400 MB para mostrar o Desktop :-)... o 64 ja começa com 600MB. Era a desculpa que eu precisava para colocar mais 2G :-D

Capturando a saída interativa do interpretador Python em Python

Tudo tem que ser automatizado. Como estou escrevendo um pequeno livro sobre Python já há muito tempo, tenho que atualizar a versão da linguagem todo ano :-D. Com o Python 3.1 o problema ficou mais sério, pois agora tenho que testar os exemplos do livro com essa nova versão que não é totalmente compatível. O livro está sendo escrito em Latex, usando o TextMate e o Skim no Mac OS X. Eu fiz a besteira de inserir manualmente o código fonte Python no texto Latex, agora tenho que revisar os scripts um a um. Como vou revisar, aproveito para consertar e desta vez gravar os programas Python em arquivos separados.

Resolvi então utilizar o SCONS para ajudar na tarefa. Para isso, um builder customizado precisa ser criado. No SConstruct:

PYTHON_BIN="/opt/local/bin/python2.6"

python_output=Builder(action= '$PYTHON_BIN capture.py $SOURCE $TARGET',
                  suffix     = '.pyt',
                  src_suffix = '.py')

env = Environment(BUILDERS = {'python_output': python_output})
env["PYTHON_BIN"]=PYTHON_BIN

env.python_output("p1")

e depois o programa em Python que faz a captura, capture.py:

import pexpect
import sys

PYTHON_BIN="/opt/local/bin/python3.1"

interacao = file(sys.argv[1], "r").readlines()

python = pexpect.spawn(PYTHON_BIN)
python.logfile_read = file(sys.argv[2], "w")

for l in interacao:
   python.expect([">>> ", "... "])
   python.send(l)

python.sendline("exit()")
python.expect(pexpect.EOF)

O script capture.py recebe dois parâmetros: o nome do arquivo Python e o nome do arquivo de saida.
Para testar, crie um arquivo p1.py:

a=5
b=10
print(a+b)
c = a + b
d = c * a / 100
print(c,d)
for x in range(3):
    print ("Oi")

#Erro:
=d=d
rrrrr

Deve produzir a seguinte saída em p1.pyt:

Python 3.1.1 (r311:74480, Oct 24 2009, 17:11:04) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a=5
>>> b=10
>>> print(a+b)
15
>>> c = a + b
>>> d = c * a / 100
>>> print(c,d)
15 0.75
>>> for x in range(3):
...     print ("Oi")
... 
Oi
Oi
Oi
>>> #Erro:
... =d=d
  File "", line 2
    =d=d
    ^
SyntaxError: invalid syntax
>>> rrrrr
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'rrrrr' is not defined
>>> 
>>> exit()

Se você utilizar este arquivo, não esqueça de modificar as variaveis PYTHON_PATH. Eu uso MacPorts e devo especificar o caminho completo da versão de Python que quero utilizar. Isso evita problemas com outras versões instaladas no sistema, como o Python da Apple. Eu utilizei o Python 3.1 nos exemplos do livro, mas ainda uso o 2.6 para instalar meus módulos no Mac Ports.

Eu espero que isto ajude alguém com o mesmo tipo de problema: capturar a saída interativa de um programa como se fosse um terminal comum.

Aventuras com FSCK

Back-ups sempre vão bem... essa semana acabei perdendo 2 HDs. Um no PC, consegui retirar todos os dados e transferir para um servidor remoto. O outro, meu Ubuntu, Tambaqui de guerra.

Cheguei de manhã ao trabalho e vi que computador estava desligado. Como o Tambaqui é um pequeno servidor também, eu já o deixo ligado. Liguei o peixe e o boot ocorreu normalmente (eu sempre digo que só dá problema o que antes estava funcionando perfeitamente :-), senão ninguém viria com aquela desculpa-esfarrapada-padrão-de-quem-não-tem-backup: ontem estava bonzinho!).Olhando os arquivos depois do boot, vi que haviam vários arquivos com nomes estranhos com ??? e !!!!... sinal de problemas no sistema de arquivos, mas o fsck jurava que estava tudo bem :-)

Rodei então o init 1 para inicializar em usuário único. E lá rodei o fsck no menu do Ubuntu... que detectou vários problemas. Terminada a análise, fiz o boot e para minha surpresa o disco estava vazio !

Como já havia perdido um HD no dia anterior, disse: de novo! :-( Vi que a raiz tinha ido pro saco. Eu precisava apenas de dois diretórios com meus dados, prática que sigo já há alguns anos. Bom, dei uma olhada rápida no disco e constatei que estava mesmo vazio. Eu só consegui dar o boot com o CD do Ubuntu, mas não tive problemas em montar a tal partição. Começei a me preparar para reinstalar o Ubuntu quando vi que a partição não estava vazia.

Eu nunca acreditei muito no lost+found. Toda vez que tive problemas no Linux, encontrei apenas pedaços dos meus arquivos dentro do lost+found. Mas desta vez a coisa estava diferente. Entre estes pedaços estavam diretórios com nomes como #xxxxxx, milhares deles. Logo descobri aonde meus arquivos haviam ido parar.

Iniciei então o seguinte procedimento para procurar meus arquivos:

ls -laR lost+found > bigls.txt

O fsck havia recortado meus diretórios e deixado tudo em um só nível! A opção de gerar o arquivo bigls.txt era de justamente poder procurar com calma tudo que eu poderia salvar. O arquivo final tinha mais de 40MB ! Mas isso não é nada para o less. Utilizando a / para pesquisar, pude navegar no pequeno ls monstro que havia criado e logo detectar o que precisava ser salvo.

Depois, ficou fácil de mover os diretórios mais importantes para um disco de rede. O nome do arquivo eu pegava no bigls.txt, aberto em outra janela com o less. Simples e prático. Ainda estou recuperando as instalações que havia feito na máquina, pois não consegui quase nada do meu /etc (tomcat com ldap é chato).

Nessa nova instalação vou deixar um rsync rodando para o disco de rede... pelo menos dos dados e do /etc :-)

Quanto ao outro disco, rodando Windows XP... no meu velho notebook (2HDs perdidos em 2 meses e contando !)... também consegui montar o disco que nem boot mais tinha usando também o CD do Ubuntu. Ficou tudo muito simples porque o Ubuntu já identifica o disco Windows e é ultra fácil montá-lo, bastando clicar no volume correspondente no menu. Eu gosto muito de usar a linha de comando, mas confesso que gostei desta vez de utilizar as ferramentas gráficas no Ubuntu. Abri dois navegadores, um com a partição Windows e outro com um disco remoto usando Samba. A cópia foi tranqüila, bastando arrastar e soltar! Quem diria um dia fazer isso no Linux :-)

Um programa que ajuda a ver os problemas de boot no Windows é o testdisk. Ele detecta as partições e ajuda a reconstruir o setor de boot entre outras coisas. Pena que ele não está disponível pelo apt-get do Ubuntu 9.04. Mas no link acima tem uma opção para download. Basta baixar e desempacotar a versão binária. Um executável pronto (linkado estaticamente) já está pronto para ser utilizado.

Outro programa para o cinto de utilidades é o SmartMonTools. Ele acessa as informações do S.M.A.R.T. do seu HD e ajuda a decidir o que aconteceu. Claro que é melhor usar essa ferramenta antes de ter problemas, mas meu Windows XP resolveu morrer sem último suspiro. Cheguei de manhã e ele já estava morto, mas sem perda de dados. Nunca se sabe se é um problema de vírus ou simplesmente um defeito no HD que você não havia percebido. Esses utilitários ajudam a executar os testes mesmo post mortem. Claro, dependendo do estado do seu HD, porque se ele nem liga ou nem mesmo é detectado... esqueça.