[DebianBR-commits] r418 - /docs/trunk/traduzidos/release-notes/upgrading.dbk

[darkstar-guest at users.alioth.debian.org]

Author: darkstar-guest
Date: Tue Feb  8 20:26:46 2011
New Revision: 418

URL: http://svn.debian.org/wsvn/?sc=1&rev=418
Log:
Tradução do upgrading.dbk atualizada da linha 1 à 131 e 1028 à 1390

Modified:
    docs/trunk/traduzidos/release-notes/upgrading.dbk

Modified: docs/trunk/traduzidos/release-notes/upgrading.dbk
URL: http://svn.debian.org/wsvn/docs/trunk/traduzidos/release-notes/upgrading.dbk?rev=418&op=diff
==============================================================================
--- docs/trunk/traduzidos/release-notes/upgrading.dbk (original)
+++ docs/trunk/traduzidos/release-notes/upgrading.dbk Tue Feb  8 20:26:46 2011
@@ -125,10 +125,11 @@
 <title>Prepare for recovery</title>
 <para>
 Por conta das inúmeras mudanças no Kernel entre o &oldreleasename; e
-&releasename; dizem respeito a drivers, descoberta de hardware e nomeação e ordenação
-de arquivos de dispositivo, existe um risco real there is a real de você ter problemas
-reinciando o seu sistema após a atualização. Muitos potenciais problemas conhecidos são
-documentados nesse e nos próximos capítulos dessa Nota de Lançamento.
+&releasename; relativas a drivers, descoberta de hardware e a nomeação e
+ordenamento de arquivos de dispositivo, existe um risco real de você ter
+problemas reinicializando o seu sistema após a atualização. Muitos problemas
+possíveis conhecidos são documentados neste e nos próximos capítulos destas
+Notas de Lançamento.
 </para>
 <para>
 For that reason it makes sense to ensure that you will be able to recover if
@@ -1299,53 +1300,55 @@
 par o <systemitem role="package">udev</systemitem>.  Uma vez que estas regras
 já existiam no &oldreleasename;, nenhuma ação adicional deverá ser necessária
 quando fizer a atualização para o &releasename; para obter o benefício dos
-nomes fixos nos dispositivos de rede.  Por favor, note entretando que este
+nomes fixos nos dispositivos de rede.  Por favor, note entretanto que este
 mecanismo udev significa que um nome de determinado dispositivo de rede está
-ligado a uma determinada parte do hardware;
-
-if you, for instance, exchange ethernet adapters in a deployed &releasename;
-system, the new adapter will get a new interface name instead of using the
-existing one.  To reuse an existing device name for new hardware, you will
-need to delete the associated entry from
+ligado a uma determinada parte do hardware; se você, por acaso, permutar
+placas de rede em um sistema &releasename; implantado, a nova placa irá obter
+um novo nome de interface ao invés de usar o já existe.  para reutilizar um
+nome de dispositivo já existente para um novo hardware, você precisará 
+apagar a entrada associada do
 <filename>/etc/udev/rules.d/70-persistent-net.rules</filename>.
 </para>
 <para>
-For storage devices, you may be able to avoid this reordering by using
-<systemitem role="package">initramfs-tools</systemitem> and configuring it
-to load storage device driver modules in the same order they are currently
-loaded.  However, in light of other changes to the storage subsystem of the
-Linux kernel as described at <xref linkend="ide-pata-transition"/>, this is
-usually not worth the effort and it is recommended instead to use device
-names that are guaranteed to be stable over time, such as the UUID aliases
-<footnote><para>Some devices, such as those used by crypt, RAID
-or LVM have stable non-UUID identifiers. In these cases you should use the
-name of the devices, which are already unambiguous and stable.</para></footnote>
-in the <filename>/dev/disk/by-uuid/</filename> directory or LVM device names
-in <filename>/dev/mapper/</filename>.
+Para dispositivos de armazenamento, você pode evitar estas reordenação usando
+<systemitem role="package">initramfs-tools</systemitem> e o configurando
+para carregar os módulos do driver do dispositivo de armazenamento na mesma
+ordem em que estão atualmente carregados. Entretanto, à luz de outras
+mudanças no subsistema de armazenamento do kernel Linux, como descrito em
+<xref linkend="ide-pata-transition"/>, geralmente isto não merece o esforço
+e, ao invés disso, é recomendado usar nomes de dispositivos que sejam fixos
+ao longo do tempo, tais com os pseudônimos UUID<footnote><para>Alguns
+dispositivos, tais como aqueles usados pelo crypt, RAID ou LVM têm
+identificadores não-UUID fixos. Nestes casos, você deverá usar o nome dos
+dispositivos, que já são não-ambíguos e fixos.</para></footnote>
+no diretório <filename>/dev/disk/by-uuid/</filename> ou nomes de dispositivos
+LVM em <filename>/dev/mapper/</filename>.
 </para>
 </section>
 
 <!-- FIXME: REVIEW for Squeeze this was written for Lenny - drop? (jfs) -->
 <section id="boot-timing">
-<title>Boot timing issues</title>
-<para>
-If an initrd created with <systemitem
-role="package">initramfs-tools</systemitem> is used to boot the system, in some
-cases the creation of device files by <systemitem
-role="package">udev</systemitem> can happen too late for the boot scripts to
-act on.
-</para>
-<para>
-The usual symptoms are that the boot will fail because the root file system
-cannot be mounted and you are dropped into a debug shell. But if you
-check afterwards, all devices that are needed are present in
-<filename>/dev</filename>. This has been observed in cases where the root file
-system is on a <acronym>USB</acronym> disk or on <acronym>RAID</acronym>, especially if <acronym>LILO</acronym><indexterm><primary>LILO</primary></indexterm> is used.
-</para>
-<para>
-A workaround for this issue is to use the boot parameter
-<literal>rootdelay=<replaceable>9</replaceable></literal>.  The value for the
-timeout (in seconds) may need to be adjusted.
+<title>Problemas com o tempo de inicialização</title>
+<para>
+Se uma initrd criada com <systemitem
+role="package">initramfs-tools</systemitem> for usada para inicializar o
+sistemas, em alguns casos a criação dos arquivos de dispositivo pelo
+<systemitem role="package">udev</systemitem> pode ocorrer muito tarde para
+que os scripts inicialização atuem.
+</para>
+<para>
+Os sintoma mais comum é que a inicialização irá falhar porque o sistema de
+arquivos raiz não pode ser montado e você é deixado em uma shell de depuração.
+Mas se você verificar posteriormente, todos os dispositivos que são necessários
+estão presentes em <filename>/dev</filename>. Isto foi observado em casos onde
+o sistema de arquivos raiz está em um disco <acronym>USB</acronym> ou em um
+<acronym>RAID</acronym>, especialmente se for usado <acronym>LILO</acronym>
+<indexterm><primary>LILO</primary></indexterm>.
+</para>
+<para>
+Uma forma de contornar este problema é usar o parâmetro de inicialização
+<literal>rootdelay=<replaceable>9</replaceable></literal>.  O valor para o
+timeout (em segundos) talvez precise ser ajustado.
 </para>
 </section>
 
@@ -1355,31 +1358,33 @@
 No tasks left in this section, so comment the whole thing out.
 -->
 <section id="nownownow" condition="fixme">
-<title>Things to do before rebooting</title>
-<para>
-When <literal>apt-get dist-upgrade</literal> has finished, the <quote>formal</quote> upgrade
-is complete, but there are some other things that should be taken care of
-<emphasis>before</emphasis> the next reboot.
+<title>Coisas para fazer antes de reinicializar</title>
+<para>
+Quando o <literal>apt-get dist-upgrade</literal> terminar, a atualização
+<quote>formal</quote> estará completa, mas existem algumas outras coisas 
+com as quais deve-se ter cuidado <emphasis>antes</emphasis> da próxima
+reinicialização.
 </para>
 
 <!-- FIXME: Probably dropable since lilo is no longer setup in Lenny -->
 <programlisting condition="fixme">
-There is probably no need at all to run lilo manually on upgrade anymore,
-/etc/kernel/postinst.d/zz-lilo runs lilo unconditionally on kernel upgrade;
-but don't throw this all away until the lilo maintainers confirm this
-isn't required on upgrade for the second-stage bootloader.
+Provavelmente, não há mais necessidade alguma de executar o lilo manualmente
+na atualização, o /etc/kernel/postinst.d/zz-lilo executa o lilo
+incondicionalmente na atualização do kernel; mas não jogue tudo isso fora
+até que os mantenedores do lilo confirmem que isso não é necessário na
+atualização para o gerenciador inicialização do segundo estágio.
 </programlisting>
 
 <!-- FIXME: REVIEW for Squeeze this was written for Lenny - drop? (jfs) -->
 <section arch="i386;amd64" id="rerunlilo" condition="fixme">
-<title>Rerun lilo</title>
-<para>
-If you are using <systemitem role="package">lilo</systemitem> as your
-bootloader (it is the default bootloader for some installations of &oldreleasename;) it is
-strongly recommended that you rerun <command>lilo</command> after the
-upgrade.  The <systemitem role="package">lilo</systemitem> package will
-offer to do this for you as part of the upgrade, but if you decline or don't
-see the prompt, you should run lilo by hand:
+<title>Re-execute o lilo</title>
+<para>
+Se você estiver usando o <systemitem role="package">lilo</systemitem> como 
+seu gerenciador de inicialização (que é o padrão para algumas instalações do
+&oldreleasename;), é fortemente recomendado que você re-execute o
+<command>lilo</command> após a atualização.  O pacote <systemitem role="package">
+lilo</systemitem> irá se oferecer para fazer isto por você, mas caso você
+recuse ou não veja o aviso, você deverá executar o lilo manualmente:
 </para>
 <screen>
 # /sbin/lilo
@@ -2104,5 +2109,7 @@
 -->
 <!-- LocalWords:  udev initrd dist upgrade dpkg grep ii apt cache search uname
 -->
-<!-- LocalWords:  transition show
+<!-- LocalWords:  transition show reordenamento shell dev USB RAID LILO timeout
 -->
+<!-- LocalWords:  rootdelay get lilo driver UUID crypt LVM scripts
+-->