Caminhos...

Nunca precisei de flash no notebook, por isso nem notava a sua falta, mas hoje reparei que não conseguia ver slideshows do Flickr com o Gnash ou com o Swfdec.

No desktop, também com x86 64 tudo corria bem, pelo que tive de investigar o que faltava aqui.

Como o plugin da Adobe já estava instalado, só tive de fazer:

Code:

Depois, foi só fazer

Code:

e iniciar o Firefox.

iPhone, iPhone... bahhhh!
Isto sim, é uma coisa interessante! Um "brinquedo" voador, com Fedora a ajudar a controlar!

Há problemas com a instalação de RAID por software no Fedora 9, e parece que está a demorar a resolver.
O Fedora 8 e anteriores usavam o rc.sysinit para correr o "mdadm -A -s" e iniciar os arrays do mdadm.conf.
A versão 9 do Fedora removeu esse código e usa as regras udev para correr o "mdadm --incremental".
O problema está reportado muito explicitamente aqui e aqui e não tão explicitamente aqui, mas tarda em ser resolvido.
Assim, para ter um sistema utilizável, tive de fazer o seguinte:
1 - remover o ficheiro /etc/udev/rules.d/70-mdadm.rules
2 - adicionar ao rc.sysinit, na linha 321, o código que foi removido e que era:

Code:

Basta isto para o sistema ficar funcional.

O Live USB Creator é uma ferramenta que permite criar live flash drives USB (vulgo pen drives) com um sistema operativo de confiança (vulgo Fedora) on the fly.

Windows Live USB Creator (imagem retirada do site)

A grande vantagem de ter um live usb flash stick é a de podermos atribuir espaço para guardar alterações (persistent overlay creation, suportado apenas no Fedora 9), tornando este objecto muito útil para transportarmos connosco para qualquer lado onde não haja o nosso sistema operativo de eleição, permitindo ter todas as nossas coisas, favoritos, documentos, etc.

É muito útil também, para salvar o computador daquele amigo que insiste em usar aquele SO vulnerável a virus e afins, bastando para tal, instalar um anti-virus e fazer a sua actualização regular.

Esta ferramenta é para quem usa MS Windows, os utilizadores de linux podem ver no Fedora LiveCD USB HowTo como proceder para criar o seu Live USB.

Fiz ontem o upgrade para Fedora 9 ao meu Thinkpad e ao novo desktop que está em fase de testes com RAID.

Como o portátil não tem DVD, optei por fazer o upgrade online, bastando para tal fazer o download do release-notes-9.0.0-1.noarch.rpm e do fedora-release-9-2.noarch.rpm.
Depois de instalar, basta fazer o yum upgrade.

Ficou tudo funcional, excepto o HDAPS que não há forma de instalar. Já na versão 8, cada vez que havia uma nova release do kernel, eu tinha de compilar manualmente o Tp smapi com suporte ao HDAPS, mas desta vez...
Sem HDAPS não há rotação automática do ecrã, mas será de certeza temporário.

Como tenho a partição /home encriptada com dm-crypt/luks, e é necessário chamar o script de arranque para a montagem da partição, tive de editar o /etc/rc.d/rc.sysinit, uma vez que o upgrade substituiu este ficheiro por um novo, guardando o anterior como /etc/rc.d/rc.sysinit.rpmsave.
A última acção para tornar o sistema utilizável, passou por alterar o fundo do ecrã, porque muito sinceramente, o fundo padrão desta release é, no mínimo, de mau gosto, uma situação nada habitual no Fedora, que tem wallpapers bem bonitos.

No desktop, a coisa foi mais complicada.
Já tinha tentado instalar o Fedora 9 Preview, mas sem exito, pois após a instalação, o RAID não funcionava de forma alguma. Colocado o bug report, disseram que já havia uma versão mais recente do mdadm, a versão do preview era a mdadm-2.6.4-3. Estupidez minha, bastava ter arrancado com o rescue disk e fazer um yum update.
Entretanto, já tinha instalado o Fedora 8 na máquina, e estava tudo perfeito.
Com o lançamento da versão final, lá queimei o dvd e fiz o upgrade, mas com maus resultados, o mdadm continua sem funcionar.
Arrancando com o rescue disk funciona perfeitamente, todos os arrays são iniciados. Arrancando normalmente, surge a mensagem "mdadm failed to RUN_ARRAY /dev/md1: invalid argument" e prontos, nem com todos os updates feitos isto funciona.
Continuo a aguardar um update ou solução. Em última análise, lá terei de novo o trabalho de tentar uma instalação total a ver se o mdadm rola como deve.

A ideia era instalar o Fedora 9 Preview Release numa máquina nova, mas como o mdadm estava com problemas em funcionar após a instalação e parava no boot, optei pelo Fedora 8, deixando o 9 para testar mais tarde numa VM.

Com o disk druid do Fedora, criei uma partição /boot que coloquei em RAID 1 (partição de boot só pode ser RAID 1) nos 4 discos. Crei depois a partição do sistema e uma /home em RAID 10.

Backup de partições
Após a instalação, é conveniente guardar a informação das partições de todos os discos, para que, caso haja mais tarde algum "acidente", seja fácil a sua substituição e reconstrução de arrays.
Assim, criei uma pasta raidinfo em /root e copiei a partição com:
# /sbin/sfdisk -d /dev/sda > partitions.sda

Fazendo isto para todos os drives do sistema, fiquei com backups de todas as partições, e caso tenha de substituir algum drive, só terei de carregar a tabela de partições com o comando:

Code:

Instalação do GRUB
Quando se faz a instalação do sistema, o grub é colocado apenas em id0, no caso de serem drives scsi, ou em /dev/sda para os drives ide. Assim, se algum desses drives falha, ficamos impedidos de arrancar com o sistema, parando o mesmo no grub.

A solução é executar o grub e fazer a sua instalação em todos os drives que fazem parte do RAID e que tenham uma partição /boot, no meu caso, os 4 discos.

Na linha de comandos, escrever grub leva-me para a shell do grub:
#grub
grub>

Agora procuro a localização de todos os ficheiros de configuração do grub com
grub>find /grub/stage1

Esta acção devolve-me todos os discos do meu raid, pois a partição boot está nos 4 discos:
(hd0,0)
(hd1,0)
(hd2,0)
(hd3,0)

Agora tenho de assegurar que o grub seja instalado no MBR de todos os drives raid, para que, no caso de falha do drive hd0, o MBR do drive seguinte seja lido, colocando o grub a funcionar. O sistema segue automaticamente a ordem de drives e usa o primeiro MBR e partição activa que encontra. Assim, caso o hd0 esteja desactivado, ele tenta carregar o MBR do hd1, depois do hd2, e assim sucessivamente.

Colocando em prática o atrás escrito, e sabendo que o hd0 tem o grub no MBR, executo:

Grub>device (hd0) /dev/sdb
Grub>root (hd0,0)
Grub>setup (hd0)

depois

Grub>device (hd0) /dev/sdc
Grub>root (hd0,0)
Grub>setup (hd0)

e finalmente

Grub>device (hd0) /dev/sdd
Grub>root (hd0,0)
Grub>setup (hd0)

Ter em atenção que usei sempre hd0, só alterando o /dev/sdX, uma vez que o drive 0 é o que tem o MBR, pelo que, passando esses comandos para o grub, colocam o drive seguinte como 0 no caso de falha do anterior.

Acabei de instalar com sucesso o grub no MBR de todos os mirrors do meu sistema e marquei a partição de boot como activa em todos eles, assegurando que, caso o hd0 falhe, consiga carregar o sistema a partir do hd1 (ou do hd2 ou hd3, caso o hd1 também falhe!) sem qualquer problema.

Alguns comandos para mais tarde recordar:

Estado do RAID - # cat /proc/mdstat
Personalities : [raid10] [raid6] [raid5] [raid4] [raid1]
md0 : active raid1 sdb1[1] sda1[0] sdd1[3] sdc1[2]
104320 blocks [4/4] [UUUU]

Detalhe de um array - # /sbin/mdadm --detail /dev/md3

Adicionar um array - # /sbin/mdadm /dev/md0 -a /dev/sdb1
mdadm: re-added /dev/sdb1

Iniciar array - # /sbin/mdadm -A --run /dev/md1
mdadm: device /dev/md1 already active - cannot assemble it

Tentava configurar uma impressora CUPS em Windows e estava a seguir (erradamente, claro) as instruções do wizard de adição de impressora, colocando "\\192.168.1.6:631\" no endereço.

Após alguns erros e uma simples pesquisa, vi que (uma vez mais), não se deve seguir as sugestões do Windows. O passo correcto era adicionar http://hostname:631/printers/printername, que no meu caso deu algo como http://192.168.1.6:631/printers/Business_Inkjet

[diogo@link 1] ~ > history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
464 w (alias para whois)
154 ping
54 s1 (alias para uma ligação ssh)
51 su
34 *
30 locate
21 gedit
19 telnet
14 ssh
11 qemu

[root@link ~]# history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -nr|head
78 yum
43 gedit
36 cd
32 /usr/sbin/tripwire
26 nano
24 chcon
23 rkhunter
22 locate
17 /sbin/restorecon
17 cp

[diogo@x61 1] ~ > history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
168 su
111 ./windex
45 ls
38 cd
37 ping
31 locate
27 make
24 *
23 w
16 igal

[root@x61 3] ~ > history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -nr|head
131 gedit
115 make
52 cd
51 yum
42 locate
23 /usr/bin/vmware-config.pl
20 nautilus
20 h
20 echo
17 /etc/init.d/network

A próxima release Fedora está agendada para o dia 29, o Fedora 9 "Sulphur".

É altura de começar a contagem decrescente, o que, graças ao já habitual e excepcional trabalho do Nicu Buculei, é feito com este bonito trabalho gráfico.

Ele tem um ficheiro tarball com imagens já renderizadas e com o SVG original.

Esta nova release trás novidades como suporte a encriptação do sistema de ficheiros, full virtual kernel boot, ext4 filesystem, melhoria na inicialização do X, LTSP, KDE4... enfim, argumentos interessantes pelo menos para fazer o download do LiveCD e experimentar.

O Windex é um script que permite a criação de indexes HTML de imagens de forma simples.

O nome engana um pouco, pois o programa faz um uso extensivo de todas as facilidades do Unix, sendo pouco provável que execute de forma fácil em Windows.

O Windex torna muito fácil a pesquisa de imagens. Após fazer o scan á lista de imagens que indicar a partir da linha de comando, ele prepara um documento HTML com o índice de todas as imagens, com os devidos thumbnails e link para a localização das mesmas.

./windex -a -B -W -S -u -w 150 -Y 100 /home/diogo/Imageg
ns/torneio/encerramento/*
cria algo como isto:

Conforme afirma Marcel Gagné "Os utilizadores de Linux fazem-no de um sem número de formas diferentes, e, ao contrário dos utilizadores de Windows, não temos de pagar por isso."