[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ próximo ]
Nós sugerimos que antes de atualizar você também leia a informação em Problemas que você precisa conhecer no etch, Capítulo 5. O capítulo cobre potenciais problemas não diretamente envolvidos ao processo de atualização mas que podem ser relevantes.
Antes de atualizar seu sistema, recomenda-se fortemente que você faça uma cópia de segurança completa, ou pelo menos copie os dados ou informações de configuração que você não pode perder. As ferramentas de atualização e processos são bastante confiáveis, mas uma falha de hardware no meio de uma atualização pode resultar em um sistema bastante danificado.
As principais coisas que você precisará copiar são os conteúdos de
/etc, /var/lib/dpkg,
/var/lib/aptitude/pkgstates e a saída de dpkg
--get-selections "*" (as aspas duplas são importantes).
O processo de atualização por si só não modifica nada no diretório
/home. Porém, algumas aplicações (por exemplo, parte da suíte
Mozilla, os ambientes de área de trabalho GNOME e KDE) são conhecidas por
sobrescrever configurações de usuários com novos padrões quando uma nova versão
da aplicação é iniciada pela primeira vez pelo usuário. Como precaução, você
pode desejar fazer uma cópia de segurança dos arquivos e diretórios ocultos
("dotfiles") nos diretórios pessoais dos usuários, Essa cópia de
segurança pode ajudar a restaurar ou recriar as configurações antigas. Você
pode também desejar informar aos usuários sobre isso.
Quaisquer operações de instalação de pacotes devem ser executadas com
privilégios de superusuário, seja acessando o sistema como root ou usando
su ou sudo para obter os privilégios de acesso
necessários.
A atualização tem algumas pré-condições; você deveria verificá-las antes de executar a atualização.
É sábio informar todos os usuários antes de qualquer atualização que você
esteja planejando, embora usuários acessando seu sistema via uma conexão
ssh poderiam notar algo durante a atualização, e deveriam ser
capazes de continuar trabalhando.
Se você deseja tomar precauções extras, faça uma uma cópia de segurança ou
desmonte as partições dos usuários (/home) antes de atualizar.
Você provavelmente terá que atualizar o kernel quando atualizar para o etch, então uma reinizialização será necessária. Tipicamente, isto será feito após a atualização ser finalizada.
Por causa das várias mudanças no kernel entre o sarge e o etch com relação a drivers, detecção de hardware e a nomenclatura e ordem dos arquivos de dispositivos, há o risco real que você possa ter problemas reinicializando o seu sistema após a atualização. Vários potenciais problemas estão documentados neste e nos próximos capítulos das Notas de Lançamento.
Por esta razão faz sentido garantir que você será capaz de recuperar se o seu sistema falhar ao reinicializar ou, em sistemas gerenciados remotamente, falhar para levantar a rede.
Se você está atualizando remotamente via uma conexão ss é
altamente recomendado que você tome as precauções necessárias para ser capaz de
acessar o seu servidor através de um terminal serial remoto. Há uma chance de
que, após a atualização do kernel e reinicialização, alguns dispositivos sejam
renomeados (como descrito em Reordenação da
enumeração de dispositivos, Seção 4.6.4) e você terá que corrigir a
configuração do sistema através de um console local. Também, se o sistema for
reinicializado acidentalmente no meio da atualização há uma chance de que você
tenha que recuperar usando um console local.
A coisa mais óbvia a tentar primeiro é reinicializar com seu kernel antigo. No entanto, por várias razões documentadas em outras partes deste documento, não é garantido que isto funcione.
Se isto falhar, você precisará de uma forma alternativa de inicializar o seu sistema para que possa acessá-lo e repará-lo. Uma opção é usar uma imagem especial de recuperação ou um live CD Linux. Após inicializar de um destes meios, você deveria ser capaz de montar o seu sistema de arquivos raiz e acessá-lo via chroot para investigar e corrigir o problema.
Outra opção que gostaríamos de recomendar é o uso do modo de
recuperação ("rescue mode") do etch Debian Installer. A
vantagem de usar o instalador é que você pode escolher entre os vários métodos
de instalação para o que melhor atende sua situação. Para mais informações,
por favor, consulte a seção "Recuperando um Sistema Quebrado" no
capítulo 8 do Guia de
Instalação e no Debian Installer
FAQ.
O initramfs-tools inclui um shell de depuração[6] nos initrds que são gerados.
Se, por exemplo, o initrd é incapaz de montar seu sistema de arquivos raiz,
você cairá dentro deste shell de depuração que possui comandos básicos
disponíveis para ajudá-lo a rastrear o problema e possivelmente arrumá-lo.
Coisas básicas a serem verificadas: presença dos arquivos de dispositivos
corretos em /dev; quais módulos estão carregados (cat
/proc/modules); saída do dmesg por erros no carregamento de
módulos. A saída do dmesg também vai mostrar quais arquivos de
dispositivos foram atribuídos para quais discos; você deveria verificar isso
contra a saída do echo $ROOT para ter certeza de que o sistema de
arquivos raiz está no dispositivo esperado.
Se você conseguir resolver o problema, digitando exit sairá do shell de depuração e continuará o processo de inicialização no ponto em que ele falhou. Claro que você também precisará corrigir o problema encontrado e regerar o initrd para que na próxima inicialização ele não falhe novamente.
A atualização da distribuição pode ser feita localmente a partir de um console
virtual em modo texto (ou um terminal serial conectado diretamente), ou
remotamente através de um link ssh.
Para ganhar margem extra de segurança quando atualizaindo remotamente, nós
sugerimos que você execute os processos de atualização no console virtual
fornecido pelo programa screen, que permite habilitar uma
reconexão segura e garante que o processo de atualização não é interrompido
mesmo se o processões de conexão remota falhar.
Importante: Você não deve atualizar usando
telnet, rlogin, rsh ou de uma sessão X
gerenciada pelo xdm, gdm ou kdm etc na
máquina que você está atualizando. Isso ocorre porque cada um desses serviços
pode ser terminado durante a atualização, que pode resultar em um sistema
inacessível que esteja apenas parcialmente atualizado.
Caso você execute um kernel anterior a 2.4.1, você precisará atualizar para (no
mínimo) a série 2.4 antes de atualizar glibc, preferivelmente
antes de iniciar a atualização. É recomendado que você atualize diretamente
para o kernel 2.6.8 disponível no sarge ao invés de atualizar para um kernel
2.4.
O processo de atualização descrito nesse capítulo foi pensando para
atualizações de sistemas sarge "puros", sem pacotes de terceiros. Em
particular, há vários problemas com pacotes de terceiros que instalam programa
em /usr/X11R6/bin/ causando problemas com atualizações devido à
transição para o X.Org (Transição de
XFree86 para X.Org, Seção 5.3). Para maior confiança no processo de
atualização, você pode querer remover pacotes de terceiros do seus sistema
antes de iniciar a atualização.
Este procedimento também assume que seu sistema foi atualizado para o último lançamento pontual do sarge. Se você não fez isto ou não tem certeza, siga as instruções em Atualizando seu sistema sarge, Seção A.1.
Em alguns casos, o uso do apt-get para instalar pacotes ao invés
do aptitude pode fazer com que o aptitude considere
um pacote "não usado" e agente sua remoção. Em geral, você deveria
ter certeza de que o sistema está completamente atualizado e "limpo"
antes de prosseguir com a atualização.
Por causa disto você deveria rever se existem quaisquer ações pendentes no
gerenciador de pacotes aptitude. Se um pacote está agendado para
remoção ou atualização no gerenciador de pacotes, isto pode impactar
negativamente no processo de atualização. Note que corrigir isto só é possível
se o seu sources.list ainda apontar para sarge; e não
para stable ou etch; veja Verificando sua lista de fontes,
Seção A.2.
Para fazer isto, você terá que executar a interface do usuário do
aptitude e pressionar 'g' ("Go"). Se ele mostrar
quaisquer ações, você deveria revê-las e ou corrigí-las ou implementar as ações
sugeridas. Se nenhuma ação foi sugerida, você deveria ver uma mensagem dizendo
"Nenhum pacote está agendado para ser instalado, removido ou
atualizado".
Caso você tenha configurado o APT para instalar certos pacotes de uma
distribuição diferente da distribuição estável (por exemplo, da distribuição
testing) você pode ter que mudar sua configuração de pinagem do APT (armazenada
em /etc/apt/preferences) para permitir a atualização de pacotes
para as novas versões dos mesmos encontradas na nova versão estável da
distribuição. Maiores informações sobre a pinagem do APT podem ser encontradas
na página de manual apt_preferences(5).
Qualquer que seja o método usado para atualização, recomenda-se que você verifique o estado de todos os pacotes antes, e verifique se todos os pacotes estão em um estado atualizável. O comando seguinte exibirá qualquer pacote cujo estado seja de semi-instalado (Half-Instaled) ou falha na configuração (Failed-Config), e aqueles com qualquer estado de erro.
# dpkg --audit
Você também pode inspecionar o estado de todos os pacotes em seu sistema usando
o dselect, o aptitude ou com comandos como
# dpkg -l | pager
ou
# dpkg --get-selections "*" > ~/curr-pkgs.txt
É desejável remover quaisquer "holds" antes da atualização. Se algum pacote essencial para a atualização estiver em hold, a atualização falhará.
Note que o aptitude utiliza um método diferente para registrar
pacotes em "hold" (mantidos) do método utilizado pelo
apt-get e pelo dselect. Você pode identificar
pacotes em "hold" para o aptitude com
# aptitude search "~ahold" | grep "^.h"
Se você quiser conferir quais pacotes você tinha em "hold" para o
apt-get, você deverá usar
# dpkg --get-selections | grep hold
Se você mudou e recompilou um pacote localmente, e não mudou seu nome nem colocou uma data na versão, você deve colocá-lo em hold para evitar que ele seja atualizado.
O estado de pacote "hold" para o aptitude pode ser
mudado usando:
# aptitude hold nome_do_pacote
Substitua hold por unhold para remover o estado "hold").
Caso exista algo que você precise corrigir, é melhor certificar-se de que seu
arquivo sources.list ainda aponte para o sarge, como explicado em
Verificando sua lista de
fontes, Seção A.2.
Caso você possua qualquer pacote não-Debian em seu sistema você deverá estar
ciente de que esses pacotes poderão ser removidos durante a atualização devido
a dependências conflitantes. Caso esses pacotes tenham sido instalados
adicionando um repositório de pacotes extra em seu arquivo
/etc/apt/sources.list você deverá checar se esse repositório
também oferece pacotes compilados para o etch e mudar a linha da fonte
correspondente quando estiver mudando suas linhas de fontes para pacotes
Debian.
Alguns usuários podem possuir "novas" versões não oficiais de pacotes (backports) não oficiais que estão no Debian instalados em seu sistema sarge. Tais pacotes provavelmente causarão problemas durante uma atualização uma vez que eles podem resultar em conflitos de arquivos[7]. A seção Possíveis problemas durante a atualização, Seção 4.5.8 possui alguma informação sobre como lidar com conflitos de arquivos caso os mesmos aconteçam.
Para evitar que o aptitude remova alguns pacotes que foram puxados
através de dependências, você pode precisar manualmente desmarcá-los como
pacotes auto. Isto inclui OpenOffice e Vim para instalações de área
de trabalho:
# aptitude unmarkauto openoffice.org vim
E imagens de kernel 2.6 se você as instalou usando um metapacote kernel:
# aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)
Nota: Você pode rever quais pacotes estão marcados como auto no aptitude executando:
# aptitude search 'i~M <package name>'
Antes de iniciar a atualização você deve ajustar o arquivo de configuração do
apt para a lista de pacotes, /etc/apt/sources.list.
O apt considerará todos os pacotes que podem ser encontrados
através de qualquer linha "deb", e instalará o pacote
com o maior número de versão, dando prioridade para as linhas mencionadas
primeiro (assim, em caso de várias localizações em espelho, você nomearia
primeiro tipicamente um disco rígido, então CD-ROMs, e então espelhos
HTTP/FTP).
Uma versão pode frequentemente ser referenciada por ambos o seu codinome (por exemplo, sarge, etch) e por seu nome de estado (por exemplo, oldstable, stable, testing, unstable). Referenciar-se a uma versão pelo seu codinome possui a vantagem de você nunca ser surpreendido por uma nova versão e por essa razão esse é o método utilizado aqui. Isso, é claro, significa que você deverá ficar atento a anúncios de lançamentos. Caso você utilize nomes de estado, você somente verá uma grande quantidade de atualizações de pacotes disponíveis tão logo uma nova versão seja lançada.
A configuração padrão é ajustada para instalação a partir dos servidores Debian
principais da Internet, mas você pode desejar modificar o
/etc/apt/sources.list para usar outros espelhos, preferencialmente
um espelho que esteja mais próximo de você na rede.
Os endereços de espelhos HTTP ou FTP do Debian podem ser encontrados em
http://www.debian.org/distrib/ftplist
(veja a seção "Lista completa dos espelhos"). Espelhos HTTP são
geralmente mais rápidos que espelhos FTP.
Por exemplo, suponha que seu espelho Debian mais próximo seja http://mirrors.kernel.org/debian/. Ao inspecionar esse espelho com um navegador web ou um programa de FTP, você notará que os diretórios principais são organizados assim:
http://mirrors.kernel.org/debian/dists/etch/main/binary-powerpc/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-powerpc/...
Para usar esse espelho com o apt, adicione esta linha em seu
arquivo sources.list:
deb http://mirrors.kernel.org/debian etch main contrib
Note que o `dists' é adicionado implicitamente, e os argumentos depois do nome da versão são usados para expandir o caminho para vários diretórios.
Depois de adicionar suas novas fontes, desabilite as linhas
"deb" previamente existentes em
sources.list colocando uma cerquilha (#) na frente
delas.
Ao invés de usar espelhos de pacotes HTTP ou FTP, você pode desejar modificar o
/etc/apt/sources.list para usar um espelho em um disco local
(possivelmente um montado via NFS).
Por exemplo, seu espelho de pacotes pode estar sob
/var/ftp/debian/, e ter diretórios principais como esses:
/var/ftp/debian/dists/etch/main/binary-powerpc/...
/var/ftp/debian/dists/etch/contrib/binary-powerpc/...
Para usá-los com o apt, adicione essa linha em seu arquivo
sources.list:
deb file:/var/ftp/debian etch main contrib
Note que o `dists' está adicionado implicitamente e os argumentos depois do nome da versão são usados para expandir o caminho para vários diretórios.
Depois de adicionar suas novas fontes, desabilite as linhas
"deb" previamente existentes no
sources.list colocando uma cerquilha (#) na frente
delas.
Se você quer usar apenas CD's, comente as linhas
"deb" no /etc/apt/sources.list colocando
uma cerquilha (#) na frente delas.
Certifique-se de que há uma linha em /etc/fstab que habilita a
montagem de sua unidade de CD-ROM no ponto de montagem /cdrom (é
necessário exatamente o ponto de montagem /cdrom para o
apt-cdrom). Por exemplo, se /dev/hdc é sua unidade
de CD-ROM, o /etc/fstab deve conter uma linha como:
/dev/hdc /cdrom auto defaults,noauto,ro 0 0
Note que não pode haver nenhum espaço entre as palavras defaults,noauto,ro no quarto campo.
Para verificar se funciona, insira um CD e tente executar
# mount /cdrom # isto montará o CD no ponto de montagem
# ls -alF /cdrom # isto deve exibir o diretório raiz do CD
# umount /cdrom # isto desmontará o CD
A seguir, execute:
# apt-cdrom add
para cada CD-ROM Debian Binário que tiver, para adicionar os dados sobre cada CD na base de dados do APT.
O método recomendado para atualizar a partir de versões anteriores do Debian
GNU/Linux é utilizar a ferramenta de gerenciamento de pacotes
aptitude. Essa programa toma decisões mais seguras sobre
instalações de pacotes do que executar o apt-get diretamente.
Não esqueça de montar todas as partições necessárias (notavelmente as partições
raiz e /usr) como leitura e escrita, com um comando como:
# mount -o remount,rw /ponto_de_montagem
O próximo passo é se certificar duplamente se as entradas de fontes APT (em
/etc/apt/sources.list) se referem à distribuição
"etch" ou a "stable". Nota:
linhas de fontes para um CD-ROM normalmente irão referenciar a
"unstable"; apesar de parecer confuso, você não
deverá mudar isso.
É altamente recomendado que você utilize o programa
/usr/bin/script para gravar uma transcrição da sessão de
atualização. Assim, caso aconteça algum problema, você terá um log do que
aconteceu e, caso necessário, poderá fornecer informações exatas em um
relatório de bug. Para iniciar a gravação da sessão, digite:
# script -t 2>~/upgrade-etch.time -a ~/upgrade-etch.script
ou similar. Não coloque o arquivo typescript em um diretório temporário como
os diretórios /tmp ou /var/tmp (arquivos nesses
diretórios podem ser apagados durante a atualização ou durante uma
reinicialização).
O arquivo typescript também lhe permitirá rever informações que rolaram para fora da tela. Somente mude o segundo terminal (usando Alt-F2) e, após se autenticar, use less -R ~root/upgrade-etch.script para visualizar o arquivo.
Após ter finalizado a atualização, você pode parar o script
digitando exit no prompt de comandos.
Se você usou a opção -t para o script você pode usar o
programa scriptreplay para repetir toda a sessão:
# scriptreplay ~/upgrade-etch.time ~/upgrade-etch.script
Primeiro, a lista de pacotes disponíveis para a nova versão precisa ser obtida. Isso é feito executando:
# aptitude update
Executando isto pela primeira vez com novas fontes sendo atualizadas exibirá alguns avisos relacionados à disponibilidades das fontes. Estes avisos são inofensivos e não aparecerão se você executar o comando novamente.
Você tem que se assegurar antes da atualização de que seu sistema tem espaço
suficiente no disco rígido quando você iniciar a atualização completa do
sistema descrita em Atualizando o restante do
sistema, Seção 4.5.6. Primeiro, qualquer pacote necessário para a
instalação é armazenado em /var/cache/apt/archives (e o
subdiretório partial/, durante o download) então você precisa ter
certeza de que tem espa´co suficiente na partição do sistema de arquivos que
contém /var/ para temporariamente baixar os pacotes que são
instalador no seus sistema. Após baixá-lo, você provavelmente precisará de
mais espaço em outras partições tanto para instalar os pacotes atualizados (que
podem conter binário maiores ou mais dados) e novos pacotes que serão puxados
para a atualização. Se o seu sistema não tem espaço suficiente você pode
acabar com uma atualização incompleta que pode ser difícil de recuperar.
Ambos aptitude e apt mostrarão informações detalhadas
do espaço em disco necessário para a instalação. Antes de executar a
atualização, você pode ver esta estimativa executando:
# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX pacotes atualizados, XXX novos instalados, XXX a serem removidos e 0 não atualizados.
É preciso obter xx.xMB/yyyMB de arquivos. Depois do desempacotamento, AAAMB serão usados.
Faria o download/instalaria/removeria pacotes.
[8]
Se você não tem espaço suficiente para a atualização, tenha certeza de liberar espaço de antemão. Você pode:
Remover pacotes que foram previamente baixados para instalação (em
/var/cache/apt/archive). Limpar o cache de pacotes executando
apt-get clean ou aptitude clean removerá todos os
arquivos de pacotes previamente baixados.
Remover pacotes antigos que você não usa mais. Se você tem
popularity-contest instalado, você pode usar
popcon-largest-unused para listar os pacotes que você não usa no
sistema e ocupam mais espaço. Você também pode usar deborphan ou
debfoster para encontrar pacotes obsoletos (veja Pacotes obsoletos, Seção 4.10). Alternativamente você
pode iniciar o aptitude no "modo visual" e encontrar
pacotes obsoletos sob "Pacotes Obsoletos e Criados Localmente".
Remover pacotes tomando muito espaço, que não são atualmente necessários (você
sempre pode reinstalá-los depois da atualização). Você pode listar os pacotes
que tomam mais espaço do disco com dpigs (disponível no pacote
debian-goodies) ou com wajig (executando wajig
size).
Temporariamente mover para outro sistema, ou permanentemente remover, logs de
sistema localizados sob /var/log/.
Note que para remover pacotes com segurança, é aconselhável mudar o seu
sources.list de volta para sarge como descrito em Verificando sua lista de fontes,
Seção A.2.
Por causa da necessidade de certos conflitos de pacotes entre sarge e etch executar aptitude dist-upgrade diretamenta irá, com freqüência, remove um grande número de pacotes que você quer manter. Portanto, nós recomendamos um processo de atualização em duas partes, primeiro uma atualização mínima que passa estes conflitos, então um dist-upgrade completo.
Primeiro, execute:
# aptitude upgrade
Isto tem o efeito de atualizar os pacotes que podem ser atualizados sem requerer que quaisquer outros pacotes sejam removidos ou instalador.
Siga a atualização mínima com:
# aptitude install initrd-tools
Este passo irá atualizar automaticamente a libc6 e o
locales e irá puxar as bibliotecas de suporte SELinux
(libselinux1). Neste ponto, alguns serviços serão iniciados,
incluindo xdm, gdm e kdm. Como
conseqüência, sessões X11 locais serão desconectadas.
O próximo passo irá variar dependendo do conjunto de pacotes que você tem instalado. Estas notas de lançamento dão um console genérico sobre qual método deveria ser usado, mas em dúvida, é recomendado que você examine as remoções de pacotes propostas para cada método antes de continuar.
Algunas pacotes comuns que são esperados que sejam removidos incluem
base-config, hotplug, xlibs,
netkit-inetd, python2.3, xfree86-common,
e xserver-common. Para uma lista mais completa de pacotes
obsoletos em etch, veja Pacotes obsoletos, Seção
4.10.
Este caminho de atualização foi verificado e funciona em sistema com a tarefa desktop do sarge instalada. É provavelmente o método que dará os melhores resultados em sistema com a task desktop instalado ou com os pacotes gnome ou kde instalados.
É provável que não seja o método correto a ser usado se você já não
tem os pacotes libfam0c102 e o xlibmesa-glu
instalados:
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Se você tem um sistema de área de trabalho completo instalado, execute:
# aptitude install libfam0 xlibmesa-glu
Sistemas com alguns pacotes X instalados, mas não com a tarefa
desktop completa, requerem um método diferente. Este método se
aplica em geral a sistema com xfree86-common instalado, incluindo
alguns sistemas servidores que tem as tarefas tasksel server
instaladas pois algumas destas tarefas incluem ferramentas de gerenciamento
gráfico. É provável que o método correto a ser usado em sistema que executam o
X, mas não tem uma tarefa desktop completa instalada.
# dpkg -l xfree86-common | grep ^ii
Primeiro, verifique se você tem os pacotes libfam0c102 e
xlibmesa-glu instalados.
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Se você não tem o libfam0c102 instalado, não inclua o
libfam0 na seguinte linha de comando. Se você não tem o
xlibmesa-glu instalado, não o inclua na seguinte linha de comando.
[9]
# aptitude install x11-common libfam0 xlibmesa-glu
Note que instalando o libfam0 também instalará o File Alteration
Monitor (fam) assim como o RPC portmapper (portmap)
se já não estiver instalado no seu sistema. Ambos os pacotes habilitarão um
novo serviço de rede no sistema embora ambos possar ser configurados para
conexões ao dispostivo de rede loopback (interno).
Num sistema sem X, nenhum comando aptitude install adicional deveria ser requerido, e você pode seguir para o próximo passo.
A versão do udev no etch não suporta versões de kernel anteriores
a 2.6.15 (o que inclui os kernels 2.6.8 do sarge) e a versão do
udev no sarge não funcionará apropriadamente com os últimos
kernels. Em adição, instalando a versão do udev do etch forçará
uma remoção do hotplug, usado pelos kernels Linux 2.4.
Como uma conseqüência, o pacote do kernel anterior provavelmente não
inicializará apropriadamente após a atualização. Similarmente, há uma janela
de tempo durante a atualização em que udev foi atualizado mas o
último kernel ainda não foi instalado. Se o sistema for reinicializado neste
ponto, no meio da atualização, ele pode não inicializar por causa dos drivers
não serem apropriadamente detectados e carregados. (Veja Preparar um ambiente seguro para a atualização,
Seção 4.1.4 para recomendações na preparação para esta possibilidade se
você estiver atualizando remotamente).
A menos que seu sistema tenha a tarefa desktop instalada, ou outros pacotes que causariam um número inaceitável de remoções de pacotes, é recomendado que você fa´ca atualização do próprio kernel neste ponto.
Para seguir com a atualização do kernel, execute:
# aptitude install linux-image-2.6-flavor
Veja Instalando o novo metapacote kernel, Seção 4.6.1 para ajuda em determinar qual "flavor" do pacote kernel você deveria instalar.
No caso do desktop, infelizmente não é possível garantir que o novo pacote
kernel seja instalado imediatamente após o novo udev ser
instalado, portanto há uma janela de tempo indeterminado na qual seu sistema
não terá um kernel instalado com suporte completo a "hotplug". Veja
Atualizando seu kernel e pacotes relacionados, Seção
4.6 para informações sobre configuração do seus sistema para não depender
do hotplug para a inicialização.
Você agora está pronto para continuar com a parte principal da atualização. Execute :
# aptitude dist-upgrade
Isso irá executar uma atualização completa do sistema, ou seja, instalar as versões mais novas de todos os pacotes e resolver todas as possíveis mudanças de dependências entre pacotes em diferentes versões da distribuição. Caso necessário, novos pacotes serão instalados (normalmente novas versões de bibliotecas ou pacotes renomeados) e será feita a remoção de quaisquer pacotes obsoletos conflitantes.
Quando atualizando a partir de CD-ROMs, será pedido que você insira CDs específicos em vários momentos durante a atualização. Você pode ter que inserir o mesmo CD várias vezes; isso ocorre devido aos pacotes inter-relacionados que foram dispostos ao longo dos CDs.
Novas versões de pacotes já instalados que não podem ser atualizados sem mudar
o estado de instalação de outro pacote serão deixados na versão atual (exibidos
como "held back" ou "mantidos"). Isso pode ser resolvido
usando o aptitude para selecionar esses pacotes para instalação ou
tentando o comando aptitude -f install pacote.
Após a atualizaçao, com a nova versão do apt você agora pode
atualizar suas informações de pacotes, o que incluirá o novo mecanismo de
checagem de assinaturas de pacotes:
# aptitude update
A atualização já terá obtido e habilitado as chaves de assinatura para os
repositórios de pacote Debian. Se você adicionar outras fontes de pacotes (não
oficiais), apt irá exibir avisos relacionados à inabilidade de
confirmar se os pacotes baixados destas fontes são legítimos e não foram
mexidos. Para mais informações por favor, veja Gerenciamento de pacotes, Seção
2.2.1.
Você vai notar que, desde que você está usando a nova versão do
apt, ele fará download de arquivos de diferença de pacotes
(pdiff) ao invés de listas compeltas de índice de pacotes. Para
mais informações sobre este recurso, por favor leia Atualizações lentas dos arquivos
de índice de pacotes APT, Seção 5.1.4.
Caso uma operação que utilize o aptitude, apt-get ou
dpkg falhe com um erro
E: Dynamic MMap ran out of room
o espaço de cache padrão é insuficiente. Você pode solucionar esse problema
removendo ou comentando linhas que você não precise no arquivo
/etc/apt/sources.list ou aumentando o tamanho do cache. O tamanho
do cache pode ser aumentando definindo APT::Cache-Limit no arquivo
/etc/apt/apt.conf. O comando a seguir irá definir essa variável
para um valor que deve ser suficiente para a atualização:
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
Esse comando assume que você ainda não possui essa variável definida nesse arquivo.
Algumas vezes é necessário habilitar a opção APT::Force-LoopBreak
no APT para poder remover temporariamente um pacote essencial devido a um loop
de Conflitos/Pré-Dependências. O aptitude o alertará sobre isso e
abortará a atualização. Você pode resolver isso especificando a opção -o
APT::Force-LoopBreak=1 na linha de comando do aptitude.
É possível que a estrutura de dependências de um sistema possa estar tão
corrompida que a ponto de requerer intervenção manual. Geralmente isso
significa usar o aptitude ou
# dpkg --remove nome_do_pacote
para eliminar alguns dos pacotes problemáticos, ou
# aptitude -f install
# dpkg --configure --pending
Em casos extremos você pode ter que forçar a reinstalação com um comando como
# dpkg --install /caminho/para/nome_do_pacote.deb
Conflitos de arquivos não deverão ocorrer caso você atualize a partir de um sistema sarge "puro", mas podem ocorrer caso você possua backports não oficiais instalados. Um conflito de arquivo resultará em um erro como:
Unpacking <package-foo> (from <package-foo-file>) ...
dpkg: error processing <package-foo> (--install):
trying to overwrite `<some-file-name>',
which is also in package <package-bar>
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
<package-foo>
Você pode tentar solucionar um conflito de arquivo forçando a remoção do arquivo mencionando na última linha da mensagem de erro:
# dpkg -r --force-depends nome_do_pacote
Depois de consertar as coisas, você deve ser capaz de terminar a atualização repetindo os comandos aptitude previamente descritos.
Durante a atualização, serão feitas perguntas para configurar ou reconfigurar
vários pacotes. Quando questionado se algum arquivo nos diretórios
/etc/init.d ou /etc/terminfo, ou o arquivo
/etc/manpath.config devem ser substituídos pela versão do
desenvolvedor do pacote, geralmente é necessário responder `yes' (sim) para
garantir a consistência do sistema. Você sempre poderá reverter para as
versões antigas, já que as mesmas serão guardadas com uma extensão
.dpkg-old.
Se você não souber bem o que fazer, escreva o nome do pacote ou arquivo, e resolva isso depois. Você pode procurar no arquivo typescript para rever a informação que estava na tela durante a atualização.
Note que o kernel Linux não foi atualizado por esses procedimentos.
Você pode desejar fazê-lo manualmente, instalando um dos pacotes
linux-image-* ou compilando um kernel personalizado a partir dos
fontes.
Note que um muita informação nesta seção é baseada na suposição de que você
estará usando um dos kernels modulares do Debian, junto com o
initramfs-tools e udev. Se você optar por usar um
kernel personalizado que não requer um initrd ou se você usa um gerador de
initrd diferente, algumas das informações podem ser irrelevantes para você.
Note também que se udev não está instalado no seus
sistema, ainda é possível usar hotplug para a detecção de
hardware.
Se você atualmente está usando um kernel 2.4, você deveria ler também Atualizando para um kernel 2.6, Seção 5.2 cuidadosamente.
Quando você faz dist-upgrade a partir do sarge para o etch, é fortemente recomendado que você instale um novo metapacote linux-image-2.6-*. Este pacote pode ser instalado automaticamente pelo processo de dist-upgrade. Você pode verificar executando:
# dpkg -l "linux-image*" | grep ^ii
Se você não vê nenhuma saída, então você precisa instalar um novo pacote linux-image manualmente. Para ver uma lista de metapacotes linux-image-2.6 disponíveis, execute:
# apt-cache search linux-image-2.6- | grep -v transition
Se você não tem certeza sobre qual pacote selecionar, execute uname
-r e procure por um pacote com um nome similar. Por exemplo, se você
ver '2.4.27-686', é recomendado que você instale
linux-image-2.6-686. Você também pode usar apt-cache
para ver a descrição longa de cada pacotes para ajudar a escolher a melhor
opção disponível. Por exemplo:
# apt-cache show linux-image-2.6-686
Você deveria então usar aptitude install para instalá-lo. Uma vez que este novo kernel esteja instalado você poderia reinicializar na próxima oportunidade disponível para obter os benefícios fornecidos pela nova versão de kernel.
Para os mais aventurados há uma forma fácil de compilar seu próprio kernel
personalizado no Debian GNU/Linux. Instale a ferramenta
kernel-package e leia a documentação em
/usr/share/doc/kernel-package.
Se você está atualmente executando um kernel da série 2.6 a partir do sarge esta atualização acontecerá automaticamente após você realizar uma atualização completa dos pacotes do sistema (conforme descrito em Atualizando pacotes, Seção 4.5).
Se possível, é para a sua vantagem a atualização do pacote do kernel separadamente do dist-upgrade principal, para reduzir as chances de um sistema não-inicializável temporariamente. Veja Atualizando o kernel, Seção 4.5.5 para uma descrição deste processo. Note que isto deveria ser feito somente após o processo mínimo de atualização descrito em Atualização mínima do sistema, Seção 4.5.4.
Você também pode tomar este passo se você está usando seu próprio kernel
personalizado e quer usar o kernel disponível em etch. Se a sua versão de
kernel não é suportada pelo udev então é recomendado que você
atualize depois da atualização mínima. Se sua versão é suportada pelo
udev você pode seguramente aguardar até a atualização completa do
sistema.
Se você tem um kernel 2.4 instalado, e seu sistema se apóia no
hotplug para a detecção de hardware, você deveria primeiro
atualizar para um kernel da série 2.6 do sarge antes de tentar a atualização.
Tenha certeza que o kernel da série 2.6 inicializa em seu sistema e que todo o
hardware é apropriadamente detectado antes de realizar a atualização. O pacote
hotplug é removido do sistema (em favor do udev)
quando você faz uma atualização compelta do sistema. Se você não quer
atualizar o kernel antes disto o seu sistema pode não inicializar adequadamente
a partir deste ponto. Uma vez que você tenha atualizado para um kernel da
série 2.6 no sarge você pode atualizar o kernel como descrito em Atualizando de um kernel 2.6, Seção 4.6.2.
Se seu sistema não se apóia no hotplug[10] você pode adiar a
atualização do kernel para depois que você tiver realizado a atualização
completa do sistema, como descrito em Atualizando
o restante do sistema, Seção 4.5.6. Uma vez que seu sistema esteja
atualizado você pode então fazer o seguinte (mudando o nome do pacote do kernel
para o que melhor se encaixa para o seu sistema substituindo
<flavor>:
# aptitude install linux-image-2.6-<flavor>
O etch possui um mecanismo mais robusto de detecção de hardware que as versões anteriores. No entanto, isto pode causar algumas mudanças na ordem em que os dispositivos são descobertos no seu sistema, afetando a ordem com que os nomes dos dispositivos são atribuídos. Por exemplo, se você tem dois adaptadores de rede que estão associados a dois drivers diferentes, os dispositivos eth0 e eth1 a que se referem podem ser trocados. Por favor, note que o novo mecanismo significa que se você e.g. trocar os adaptadores de rede em um sistema etch em funcionamento, o novo adaptador também irá pegar um novo nome de interface.
Para dispositivos de rede, você pode evitar este reordenamento usando as regras
do udev, mais especificamente, através de definições em
/etc/udev/rules.d/z25_persistent-net.rules[11]. Alternativamente, você
pode usar o utilitário ifrename para forçar dispositivos físicos
para nomes específicos no momento da inicialização. Veja
ifrename(8) e iftab(5) para mais informações. As
duas alternativas (udev e ifrename) não deveriam ser
usados ao mesmo tempo.
Para dispositivos de armazenamento, você pode evitar este reordenamento usando
initramfs-tools e configurando-o para carregar os módulos do
driver do dispositivo de armazenamento na mesma ordem em que estão atualmente
carregados. Para fazer isto, identifique a ordem que os módulo de
armazenamento no seu sistema foram carregados olhando para a saída do
lsmod. lsmod lista módulo na ordem inversa a que
eles foram carregados, i.e., o primeiro módulo na lista foi o último a ser
carregado. Note que isto somente funcionará para dispositivos que o kernel
enumera numa ordem estável (como dispositivos PCI).
No entanto, remover e recarregar módulo após a inicialização pode afetar esta
ordem. Além disso, seu kernel pode ter alguns drivers ligados estativamente, e
estes nomes não vão aparecer na saída do lsmod. Você pode ser
capaz de decifrar os nomes desses drivers e a ordem de carregamento olhando em
/var/log/kern.log, ou para a saída do dmesg.
Adicione estes nomes de módulo em /etc/initramfs-tools/modules
para que eles sejam carregados na inicialização. Alguns nomes de módulos podem
ter mudado entre o sarge e o etch. Por exemplo, sym53c8xx_2 passou a ser
sym53c8xx.
Você terá que regerar suas imagens initramfs executando update-initramfs -u -k all.
Uma vez que você esteja executando um kernel do etch e o udev,
você pode reconfigurar o seus sitema para acessar os discos por um apelido que
não é dependente da ordem de carregamento do driver. Estes apelidos residem na
hierarquia /dev/disk/.
Se um initrd criado com initramfs-tools é usado para inicializar o
sistema, em alguns casos a criação dos arquivos de dispositivos pelo
udev pode acontecer tarde demais para que os scripts de
inicialização atuem.
Os sintomas usuais são que a inicialização irá falhar porque o sistema de
arquivos raiz não pode ser montado e você será deixado em um shell de
depuração, mas quando você verifica na seqüência, todos os dispositivos
necessários estão presentes em /dev. Isto pode ser observado em
casos onde o sistema de arquivos raiz está em um disco USB ou em um RAID,
especialmente se o lilo for usado.
Um possível contorno para este problema é usar o parâmetro de inicialização rootdelay=9. O valor para o "timeout" (em segundos) pode precisar ser ajustado.
O driver PCILynx está horrivelmente quebrado e pode resultar em "travamentos" no PowerPC. Nós encorajamos os usuários que precisam de FireWire que adquiram uma das placas OHCI1394 baratas e coloquem o driver PCILynx na lista negra ("blacklist").
Quando o aptitude dist-upgrade tiver acabado, a atualização "formal" estará completa, mas há algumas outras coisas que devem receber atenção antes da próxima reinicialização.
Os kernels Debian não mais incluem suporte para o devfs, então os usuários do devfs precisam converter seus sistemas manualmente antes de inicializar um kernel do etch.
Se você vê a string 'devfs' em /proc/mounts, você provavelmente
está usando devfs. Quaisquer arquivos de configuração que
referenciam nomes estilo devfs precisarão ser ajustados para usar
nomes estilo udev. Arquivos que provavelmente se referem a nomes
de dispositivos no estilo devfs incluem /etc/fstab,
/etc/lilo.conf, /boot/grub/menu.lst, e
/etc/inittab.
Mais informação sobre problemas em potencial estão disponíveis no relatório de
bug #341152.
O mdadm agora precisa de um arquivo de configuração para reunir os arrays MD
(RAID) a partir do ramdisk inicial e durante a seqüência de inicialização do
sistema. Por favor, tenha certeza de ler a atuar conforme as instruções em
/usr/share/doc/mdadm/README.upgrading-2.5.3.gz depois do pacote
ter sido atualizado e antes de você reinicializar. A última
versão deste arquivo está disponível em http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file;
por favor, consulte-o em caso de problemas.
Após a atualização há várias coisas que você pode fazer para preparar-se para o próximo lançamento.
Se estiver usando grub, edite /etc/kernel-img.conf e
ajuste o local do programa update-grub mudando de
/sbin/update-grub para /usr/sbin/update-grub.
Se o novo metapacote de imagem do kernel foi puxado como uma dependência do antigo, ele será marcado como automaticamente instalado, o que deveria ser corrigido:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
Remover os metapacotes do kernel do sarge executando:
# aptitude purge kernel-image-2.6-<flavor>
Mover quaisquer opções de configuração de /etc/network/options
para /etc/sysctl.conf. Por favor, veja
/usr/share/doc/netbase/README.Debian para detalhes.
Remover pacotes obsoletos e não usados como descrito em Pacotes obsoletos, Seção 4.10. Você deveria rever quais arquivos de configuração eles usam e considerar expurgar estes pacotes para remover seus arquivos de configuração
Com o lançamento do Lenny um número maior de pacotes para servidores se tornará obsoleto, portanto atualizar para versões mais novas desses pacote agora salvará você de problemas quando atualizar para o Lenny.
Isto inclui os seguintes pacotes:
apache (1.x), sucessor é o apache2
bind8, sucessor é o bind9
php4, sucessor é o php5
postgresql-7.4, sucessor é o postgresql-8.1
exim 3, sucessor é o exim4
Introduzindo diversos milhares de novos pacotes, o etch também retira e omite mais de dois mil pacotes que estiveram no sarge. Não é fornecido um caminho de atualização para pacotes obsoletos. Apesar de nada impedir que você continue utilizando esses pacotes obsoletos se você assim desejar, o projeto Debian normalmente irá descontinuar o suporte a atualizações de segurança para os mesmos um ano após o lançamento do etch[12], e normalmente não irá fornecer outro suporte nessa faixa de tempo. Substituí-los por alternativas disponíveis, caso existam, é recomendado.
Existem muitas razões pelas quais pacotes podem ter sido removidos da distribuição; eles podem não estar mais sendo desenvolvidos pelos desenvolvedores originais e pode não existir mais um Desenvolvedor Debian interessado em mantê-los; a funcionalidade que eles fornecem pode ter sido substituída por um software diferente (ou uma nova versão); ou os mesmos não serem mais considerados adequados para o etch devido a bugs existentes. No último caso, esses pacotes podem ainda estar presentes na distribuição "unstable".
Detectar quais pacotes em um sistema atualizado são "obsoletos" é
fácil uma vez que as ferramentas de gerenciamento de pacotes irão marcá-los
como obsoletos. Caso você esteja usando o aptitude, você verá uma
listagem desses pacotes na entrada "Pacotes Obsoletos e Criados
Localmente". O dselect fornece uma seção similar mas a
listagem que o mesmo apresenta pode ser diferente. Adicionalmente, caso você
tenha utilizado o aptitude para instalar pacotes manualmente no
sarge o mesmo irá manteve um registro dos pacote que você instalou manualmente
e será capaz de marcar como obsoletos aqueles pacotes instalados somente como
dependências e que não são mais necessários caso os pacotes que dependiam deles
tenham sido removidos. O aptitude, diferentemente do
deborphan, não irá marcar como obsoletos os pacotes que você
instalou manualmente, ao invés daqueles que foram instalados através de
dependências.
Existem ferramentas adicionais que podem ser utilizadas para encontrar pacotes
obsoletos, como o deborphan, o debfoster ou o
cruft. O deborphan é altamente recomendado, apesar
de (no modo padrão) relatar somente bibliotecas obsoletas: pacotes nas seções
"libs" e "oldlibs" que não são utilizados por outros
pacotes. Não remova cegamente os pacotes que essas ferramentas lhe
apresentarem como obsoletos, especialmente caso você esteja utilizando opções
não padrão agressivas que são passíveis de reprodução de falsos positivos. É
altamente recomendado que você revise manualmente os pacotes sugeridos para
remoção (por exemplo, o conteúdo, tamanho e descrição dos mesmos) antes de
removê-los.
O Sistema de Acompanhamento de
Bugs geralmente fornece informação adicional sobre o motivo da
remoção de um pacote. Você deverá revisar antes os relatórios de bugs arquivos
para verificar o próprio pacote e os relatórios de bugs arquivados para o
pseudo-pacote
ftp.debian.org.
Alguns pacotes do sarge foram divididos em diversos pacotes no etch, geralmente para melhorar a sustentabilidade do sistema. Para facilitar o caminho de atualização nesses casos, o etch geralmente fornece pacotes "dummy": pacotes vazios que possuem o mesmo nome do pacote antigo no sarge com dependências que fazem com que os novos pacotes sejam instalados. Esses pacotes "dummy" são considerados pacotes obsoletos após a atualização e podem ser facilmente removidos.
A maioria (se não todas) das descrições dos pacotes "dummy" indicam
seu o propósito dos pacotes. Porém, descrições de pacotes para pacotes
"dummy" não são uniformes, portanto você pode achar útil o uso do
deborphan com o opção --guess para detectá-los em seu
sistema. Note que alguns pacotes "dummy" não foram criados para
serem removidos após uma atualização mas, ao invés disso, para serem usados
para manter co controle da versão disponível de um programa durante o tempo.
[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ próximo ]
Notas de Lançamento para o Debian GNU/Linux 4.0 ("etch"), PowerPC
$Id: release-notes.pt_BR.sgml,v 1.23 2007-08-13 15:12:45 jseidel Exp $debian-doc@lists.debian.org