[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ siguiente ]
Le sugerimos que antes de actualizar lea también la información en Problemas que debe conocer para etch, Capítulo 5. Ese capítulo cubre problemas que se pueden dar y que no están directamente relacionados con el proceso de actualización, pero que aún así podría ser importante conocer antes de empezar.
Es recomendable realizar una copia de seguridad completa o al menos una de los datos o información de configuración que no pueda permitirse perder antes de actualizar su sistema. Las herramientas y el proceso de actualización son bastante fiables, pero un fallo de hardware a mitad de una actualización podría resultar en un sistema muy dañado.
Los elementos principales que podría querer salvaguardar son los contenidos de
/etc, /var/lib/dpkg,
/var/lib/aptitude/pkgstates así como la salida de «dpkg
--get-selections "*"» (las comillas son importantes).
El proceso de actualización no modifica nada dentro del directorio
/home. Algunas aplicaciones (como es el caso de algunas partes de
el conjunto de aplicaciones Mozilla y el de los entornos de escritorio de KDE y
GNOME) sí sobreescribirán la configuración del usuario con los nuevos valores
por omisión cuando el usuario arranque una nueva versión de la aplicación.
Como medida preventiva quizás desee realizar una copia de seguridad de los
directorios y ficheros ocultos («dotfiles», ficheros que comienzan por punto,
N. del T.) en los directorios personales de los usuarios. Esta copia de
seguridad le será útil para restaurar o recrear la configuración previa a la
actualización. Quizás quiera también avisar a los usuarios de este asunto.
Cualquier operación de instalación de paquetes debe ser ejecutada con
privilegios de superusuario, bien accediendo al sistema como root o usando los
programas su o sudo para obtener los derechos de
acceso necesarios.
La actualización tiene unas cuantas condiciones previas, así que debería revisarlas antes de ponerse a ello.
Es aconsejable informar a los usuarios con antelación de cualquier
actualización que esté planeando realizar, aunque los usuarios que accedan al
sistema mediante ssh no deberían apenas notar nada durante la
actualización, y deberían poder seguir trabajando.
Si desea tomar precauciones adicionales, haga una copia de respaldo, o desmonte
las particiones de usuario (/home) antes de actualizar.
Posiblemente deberá hacer una actualización del núcleo cuando se actualice a etch, por lo que será necesario reiniciar el sistema. Generalmente hará esto después de que haya terminado con el proceso de actualización.
Existe un riesgo real de que experimente problemas al reiniciar el sistema tras la instalación debido a los muchos cambios introducidos en el núcleo entre sarge y etch relacionados con los controladores, el descubrimiento de hardware y la forma de nombrar y ordenar los ficheros de dispositivos. En este capítulo y en los siguientes se describen muchos de los problemas conocidos.
Por esta misma razón tiene sentido asegurarse que es capaz de recuperar el sistema en el caso que éste no pudiera reiniciarse o, para aquellos sistemas gestionados de forma remota, no pudiera arrancar correctamente la configuración de red.
Si está actualizando de forma remota a través de un enlace con ssh
es altamente recomendable que tome las debidas precauciones para poder acceder
al servidor a través de un terminal serie remoto. Existe la posibildiad de que
tras actualizar el núcleo y reiniciar algunos de los dispositivos se renombren
(como se indica en Reordenación de la numeración de
dispositivos, Sección 4.6.3) y tenga que arreglar la configuración del
sistema a través de una consola remota. Es posible que tenga que recuperar con
una consola local en caso de que el sistema se reinicie accidentalmente a la
mitad de la actualización.
La primera cosa que puede probar es intentar reiniciar con su antiguo núcleo. Sin embargo, debido a las distintas razones que se documentan más adelante, es posible que esto no funcione.
Necesitará un mecanismo alternativo para arrancar su sistema y poder acceder al mismo y repararlo si esto falla. Una opción es utilizar una imagen especial de rescate o un CD «vivo» de Linux («live CD», N. del T.). Una vez haya arrancado con cualquiera de éstos debería poder montar su sistema de ficheros raíz y utilizar chroot para acceder a éste, investigar y solucionar el problema.
Otra opción que nos gustaría recomendarle es utilizar el modo de
rescate del Instalador de Debian de etch. La ventaja en el caso de
utilizar el instalador es que puede utilizar, de entre los distintos métodos de
instalación, el más apropiado para su situación. Si desea más información,
consulte la sección «Recuperar un sistema roto» en el capítulo octavo de la
Guía de
instalación y las PUF del Instalador de
Debian.
El programa initramfs-tools incluye un intérprete de línea de
órdenes para depuración[5] en los
«initrds» que genera. Por ejemplo, si el initrd es incapaz de montar su
sistema de ficheros raíz vd. accederá a este sistema de depuración. En este
sistema podrá utilizar algunas órdenes básicas que pueden ayudarle a trazar el
problema y quizás incluso arreglarlo.
Algunas de las cosas básicas a comprobar son: la existencia de los ficheros de
dispositivos correctos en /dev, los módulos cargados (cat
/proc/modules), y la salida de dmesg para ver si se
producenerrores al cargar los controladores de dispositivos. La salida de
dmesg también muestra qué ficheros de dispositivos se han asignado
a qué discos, debería comparar esa información con la salida de echo
$ROOT para asegurarse que el sistema de ficheros está en el dispositivo
que esperaba.
En el caso de que arregle el problema puede escribir exit para salir del entorno de depuración y continuar el proceso de arranque a partir del punto que falló. Por supuesto, tendrá que arreglar el problema subyacente y regenerar el «initrd» para que no vuelva a fallar en el siguiente arranque.
La actualización de la distribución debería hacerse de forma local, frente a
una consola virtual en modo texto (o conectado de forma directa mediante un
terminal por puerto serie), o de forma remota mediante una conexión
ssh.
Para poder tener un margen de seguridad mayor cuando actualiza de forma remota
le sugerimos que realice su proceso de actualización en una consola virtual
como la que ofrece el programa screen, lo que permite una
reconexión segura y asegura que el proceso de actualización no se interrumpe
aunque falle el proceso de conexión remota.
¡Importante!: No debería actualizar usando
telnet, rlogin, rsh, ni desde una sesión
de X controlada por xdm, gdm o kdm en la
máquina que esté actualizando. Esto se debe a que cada uno de esos servicios
puede cerrarse durante la actualización, y podría hacer que el sistema se
volviese inaccesible y que está sólo actualizado a la mitad.
En el caso de que esté utilizando un núcleo anterior a la versión 2.4.1,
necesitará actualizar a alguno de la serie 2.4 como mínimo antes de actualizar
el paquete glibc. Esto debería hacerlo antes de empezar a
actualizar. Le recomendamos que actualice su núcleo directamente al núcleo
2.6.8 disponible en sarge, en lugar de actualizar a uno de la serie 2.4.
Se ha diseñado el proceso de actualización descrito en este capítulo para
actualizaciones de sistemas sarge «puros», en los que no existe ningún paquete
de otros proveedores. De forma específica, hay problemas conocidos en paquetes
de terceros que instalan programas bajo /usr/X11R6/bin/ lo que
provoca problemas con las actualizaciones debido a la transición a X.Org
(consulte Transición de XFree86 a
X.Org, Sección 5.2). Puede ser sensato eliminar paquetes de este tipo
antes de empezar para asegurarse que el proceso de actualización puede
funcionar correctamente.
Se supone que su sistema se ha actualizado a la última revisión de sarge. Debe seguir las instrucciones descritas en Actualizar su sistema sarge, Sección A.1 si su sistema no está actualizado o no está seguro de que lo esté.
En algunos casos, utilizar apt-get para instalar paquetes en lugar
de aptitude puede hacer que aptitude considere que un
paquete no está siendo utilizado (marcado como «unused») y lo marcará para su
eliminación. Por regla general debería asegurarse que su sistema está
totalmente actualizado y «limpio» antes de empezar la actualización.
Por ello, es necesario que revise si existe alguna acción pendiente en el
gestor de paquetes aptitude. El procedimiento de actualización
puede verse afectado negativamente si algún paquete está marcado para
eliminarse o actualizarse. Tenga en cuenta que sólo podrá corregir esto si su
fichero de configuración sources.list apunta a sarge y no
a stable o etch, consulte Comprobar su lista de fuentes,
Sección A.2.
Para verificar esto debería ejecutar el interfaz de usuario de
aptitude y pulsar 'g' («Go», o «Instalar/eliminar paquetes» en el
menú). Si se muestra cualquier acción, debería revisarla y o bien arreglarlas
o llevar a cabo las acciones que se le sugieran. Se le presentará el mensaje
«No hay ningún paquete planificado para instalar, eliminar o actualizar.» si no
hay ninguna acción pendiente.
Si ha configurado APT para que instale ciertos paquetes de una distribución
distinta de stable, por ejemplo la distribución testing (en
pruebas, N. del T.), puede ser que haya cambiado la configuración de bloqueo
(o pinning) de APT (almacenada en /etc/apt/preferences)
para permitir que se actualicen paquetes con versiones más recientes que en la
distribución estable. Puede encontrar más información sobre el bloqueo de APT
en apt_preferences(5).
Independientemente del método que se use para actualizar, se recomienda que compruebe el estado de todos los paquetes primero, y que verifique que todos los paquetes se encuentran en un estado actualizable. La siguiente orden mostrará cualquier paquete que se haya quedado a medio instalar (estado Half-Installed) o en los que haya fallado la configuración (estado Failed-Config), así como los que tengan cualquier estado de error.
# dpkg --audit
También puede inspeccionar el estado de todos los paquetes de su sistema usando
dselect, aptitude , o con órdenes tales como:
# dpkg -l | paginador
(donde «paginador» es cualquier programa que controle la salida de pantalla,
como less o more), o
# dpkg --get-selections "*" > ~/paqu-actuales.txt
Es deseable eliminar cualquier paquete retenido (paquete en estado «hold», N. del T.) antes de actualizar. El proceso fallará si un paquete esencial para la actualización está bloqueado.
Tenga en cuenta que aptitude utiliza un método para registrar los
paquetes retenidos distinto del que utilizan apt-get y
dselect. Puede utilizar la siguiente orden para identificar los
paquetes que están retenidos en aptitude:
# aptitude search "~ahold" | grep "^.h"
Si quiere comprobar los paquetes que tiene retenidos con apt-get
debería utilizar:
# dpkg --get-selections | grep hold
Si ha cambiado y recompilado un paquete de forma local, y no le ha cambiado el nombre o marcado con una época («epoch», N. del T.) en la versión, debería retenerlo (ponerlo en hold) para evitar que se actualice.
Se puede cambiar el estado de un paquete (si está o no retenido) con la siguiente orden:
# aptitude hold nombre_paquete
Cambie hold por unhold para marcar o no el paquete como retenido, respectivamente)
Si hay algo que debe arreglar es mejor que se asegure de que su fichero
sources.list incluye referencias a sarge tal y como se explica en
Comprobar su lista de fuentes,
Sección A.2.
Debe tener en cuenta que si tiene paquetes en el sistema que no sean de Debian
es posible que éstos se eliminen durante la actualización debido a dependencias
que entren en conflicto. Si el paquete se instaló después de añadir un
repositorio de paquetes extra en su fichero /etc/apt/sources.list
debería asegurarse de que ese repositorio también ofrece paquetes compilados
para etch y cambiar la línea de la fuente al mismo tiempo que cambia otras
líneas de las fuentes de los paquetes Debian.
Algunos usuarios tienen versiones más «nuevas» de paquetes que sí están en Debian a través de recompilaciones no oficiales («backports», N. del T.) que están instaladas en su sistema sarge. Es muy probable que estos paquetes causen problemas durante la actualización y que den lugar a conflictos de archivos[6]. Puede encontrar más información sobre los conflictos de ficheros y su resolución en la sección Posibles problemas durante o después de la actualización, Sección 4.5.8
Debe desmarcar de forma manual algunos paquetes para impedir que
aptitude los elimine por haberlos instalado a través de
dependencias. La marca a eliminar es la marca auto. Los paquetes
marcados de esta forma incluyen a OpenOffice y a Vim en las instalaciones de
escritorio:
# aptitude unmarkauto openoffice.org vim
Si ha instalado imágenes del núcleo 2.6 a través del metapaquete del núcleo deberá hacer lo mismo con éstas:
# aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)
Nota: Puede revisar qué paquetes están marcados como auto en
aptitude ejecutando:
# aptitude search 'i~M <nombre paquete>'
Antes de comenzar la actualización, debe modificar las listas de paquetes en el
archivo de configuración de apt:
/etc/apt/sources.list.
apt tomará en consideración todos los paquetes que pueda encontrar
mediante una línea que empiece por «deb», e instalará el paquete
con el mayor número de versión, dando prioridad a las líneas mencionadas
primero. De esa manera, en el caso de utilizar distintos repositorios de
paquetes, habitualmente se indicará primero el disco duro local, luego los
CD-ROM, y por último las réplicas HTTP y FTP.
Una versión se puede designar tanto por su código (por ej. sarge, etch) como por su nombre de estado (esto es, «oldstable», «stable», «testing», «unstable»). Referirse a la distribución por su código tiene la ventaja de que nunca se sorprenderá si se produce una nueva versión y por esa razón es el acercamiento que aquí se describe. Esto significa que va a tener que estar atento a nuevas versiones. Sin embargo, si utiliza el nombre del estado verá un número muy elevado de actualizaciones de paquetes en el mismo momento en el que la publicación de una nueva versión se haya realizado.
La configuración por omisión para la instalación escoge los principales
servidores de Debian en Internet, pero puede que desee modificar
/etc/apt/sources.list para usar otras réplicas, preferentemente
una que esté cerca (en términos de red) de usted.
Encontrará la lista de direcciones de las réplicas en HTTP o FTP de Debian en
http://www.debian.org/distrib/ftplist
(busque en la sección «Lista de completa de sitios de réplica»). Las réplicas
HTTP suelen ser más rápidas, en general, que las FTP.
Por ejemplo, suponga que su réplica más cercana es http://mirrors.kernel.org/debian/. Si observa su contenido mediante un navegador web o un programa FTP, comprobará que los directorios principales están organizados así:
http://mirrors.kernel.org/debian/dists/etch/main/binary-amd64/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-amd64/...
Deberá añadir esta línea a su fichero sources.list para usar esta
réplica con apt:
deb http://mirrors.kernel.org/debian etch main contrib
Fíjese que «dists» se añade de forma implícita, y los parámetros tras el nombre de la versión se usan para expandir la ruta a varios directorios.
Tras añadir sus nuevas fuentes, desactive las líneas «deb» que
había en sources.list, colocando el símbolo de sostenido
(#) delante de ellas.
En lugar de usar réplicas de paquetes HTTP ó FTP, puede que desee modificar
/etc/apt/sources.list para usar una réplica existente en su disco
local (posiblemente montada mediante NFS).
Por ejemplo, su réplica puede encontrarse en /var/ftp/debian/, y
tener directorios como estos:
/var/ftp/debian/dists/etch/main/binary-amd64/...
/var/ftp/debian/dists/etch/contrib/binary-amd64/...
Para usar esta ubicación con apt debe añadir esta línea a su
fichero sources.list:
deb file:/var/ftp/debian etch main contrib
Fíjese que «dists» se añade de forma implícita, y los parámetros tras el nombre de la versión se usan para expandir la ruta a varios directorios.
Tras añadir sus nuevas fuentes, desactive las líneas «deb» que
habían previamente en sources.list, colocando el símbolo de
sostenido (#) delante de ellas.
Si sólo desea usar CDs, comente todas las líneas «deb» existentes
en /etc/apt/sources.list colocando delante de ellas un símbolo de
sostenido (#).
Asegúrese de que existe una línea en /etc/fstab que permita montar
la unidad lectora de CD-ROMs en el punto de montaje /cdrom
(apt-cdrom necesita este punto de montaje en particular). Por
ejemplo, si su lector de CD-ROM se encuentra en /dev/hdc, el
fichero de configuración /etc/fstab debería contener una línea
como:
/dev/hdc/ cdrom auto defaults,noauto,ro 0 0
Fíjese que no debe haber espacios entre las palabras defaults,noauto,ro en el cuarto campo.
Para verificar que esto funciona, inserte un CD e intente ejecutar
# mount /cdrom # ésto montará el CD en el punto de montaje
# ls -alF /cdrom # ésto debería mostrar el directorio raíz del CD
# umount /cdrom # ésto desmontará el CD
Después, ejecute:
# apt-cdrom add
para añadir los datos a la base de datos de APT. Repita esta operación para cada CD-ROM de binarios de Debian que tenga.
El método recomendado para actualizar desde versiones anteriores de Debian
GNU/Linux es usar la herramienta de gestión de paquetes aptitude.
Este programa toma decisiones más seguras sobre la instalación de paquetes que
la ejecución directa de apt-get.
No olvide montar todas las particiones que necesite (en particular la raíz y
/usr) en modo lectura y escritura, con una orden como:
# mount -o remount,rw /puntodemontaje
A continuación asegúrese de que las entradas con las fuentes de APT (en el
archivo /etc/apt/sources.list) hacen referencia a la distribución
«etch» o a estable («stable»). No debería haber
ninguna entrada que haga referencia a «sarge». Nota: las líneas
de fuentes de un CD-ROM habitualmente hacen referencia a inestable
(«unstable»), aunque esto le parezca confuso no debería
cambiarlo.
Se recomienda encarecidamente que utilice el programa
/usr/bin/script para guardar una transcripción de la sesión de
actualización. Así, si ocurre algún problema, tendrá un registro de lo que ha
sucedido y, si fuera necesario, podrá proporcionar la información detallada
cuando envíe un informe de fallo. Para iniciar la transcripción, teclee:
# script -t 2>~/actualiza-a-etch.time -a ~/actualiza-a-etch.typescript
o similar. No ponga el archivo de transcripción en un directorio temporal como
/tmp o /var/tmp (los ficheros que hay en esos
directorios se pueden borrar durante la actualización o durante el reinicio del
sistema).
La transcripción también le permitirá revisar la información que se haya salido fuera de la pantalla. Simplemente acceda al terminal VT2 (utilizando Alt-F2) y, después de acceder al sistema, utilice less -R ~root/actualiza-a-etch.typescript para leer el fichero.
Después de completar la actualización puede terminar con la transcripción de
script escribiendo exit en el indicador de línea de
órdenes.
Si ha utilizado la opción -t para script puede utilizar
el programa scriptreplay para reproducir la sesión completa:
# scriptreplay ~/actualiza-a-etch.time ~/actualiza-a-etch.script
En primer lugar, tiene que descargar la lista con los paquetes disponibles para la nueva versión. Logrará esto si ejecuta:
# aptitude update
La primera vez que ejecute esto se actualizarán las nuevas fuentes y se mostrarán algunos mensajes de aviso relacionados con la disponibilidad de las fuentes. Estos avisos son inocuos, no volverán a aparecer si vuelve a ejecutar la orden.
Antes de actualizar su sistema tiene que estar seguro de que tiene suficiente
espacio libre en su disco duro para poder seguir las instrucciones de una
actualización completa del sistema que se describen en Actualizar el resto del sistema, Sección 4.5.6.
Primero, cualquier paquete que deba descargarse para la instalación se
almacenará en /var/cache/apt/archives (y en el subdirectorio
partial/, mientras se está descargando) por lo que necesitará
suficiente espacio libre en la partición donde se encuentre /var/,
para así descargar temporalmente los paquetes que instalarán en su sistema.
Después de la descarga, probablemente necesitará más espacio en las otras
particiones del sistema para poder instalar tanto las actualizaciones de los
paquetes (que podrían contener ficheros más grandes) como los paquetes nuevos
que se necesiten en la actualización. Si su sistema no tiene suficiente
espacio podría terminar con una actualización incompleta de la cual podría ser
difícil recuperarse.
Tanto aptitude como apt le mostrarán información
detallada del espacio libre necesario para la instalación. Puede consultar esa
estimación, antes de proceder con la actualización, si ejecuta:
(Se reproduce a continuación la salida de aptitude en español)
# aptitude -y -s -f --with-recommends dist-upgrade
[...]
XXX paquetes actualizados, XXX nuevos instalados, XXX para eliminar y XXX sin actualizar.
Necesito descargar xx.xxMB/yyyMB de ficheros. Después de desempaquetar se usarán zzzMB.
Descargará/instalará/eliminará paquetes.
[7]
Si no tiene espacio suficiente para la actualización, asegúrese de hacer sitio antes de proceder. Puede hacer lo siguiente:
Elimine paquetes descargados previamente para su instalación de la caché del
sistema (que puede hallar en /var/cache/apt/archive). Puede
utilizar la orden apt-get clean o aptitude clean para
borrar todos los archivos de paquetes previamente descargados.
Elimine paquetes antiguos que ya no usa. Si tiene instalado
popularity-contest, puede usar popcon-largest-unused
para listar los paquetes que no usa en el sistema y que ocupan un mayor espacio
en disco. También puede usar deborphan o debfoster
para encontrar paquetes obsoletos (vea también Paquetes
obsoletos, Sección 4.10). También puede ejecutar aptitude en
«modo visual» y buscar los paquetes obsoletos bajo «Paquetes obsoletos y
creados localmente».
Elimine paquetes que ocupan demasiado espacio de disco y que no va a necesitar
actualmente (siempre puede reinstalarlos después de la actualización). Puede
crear una lista de los paquetes que se llevan la mayoría del espacio en disco
con dpigs (disponible en el paquete debian-goodies) o
con wajig (ejecutando wajig size).
Mueva los registros del sistema de forma temporal a otro sistema o elimínelos,
dado que residen en /var/log/.
Tenga en cuenta que para poder eliminar los paquetes con seguridad debería
cambiar su sources.list a sarge como se describe en Comprobar su lista de fuentes,
Sección A.2.
Debido a distintos conflictos necesarios entre paquetes de sarge y de etch, la ejecución de aptitude dist-upgrade directamente generalmente recomendaría la eliminación de un buen número de paquetes que seguramente quiera conservar. Le recomendamos por tanto un proceso de actualización en dos pasos. En primer lugar una actualización mínima para resolver estos conflictos, seguido de una actualización completa con dist-upgrade.
En primer lugar, debe ejecutar:
# aptitude upgrade
Esto tiene como consecuencia que se actualicen los paquetes que se puedan actualizar en el sistema sin que sea necesario eliminar ni instalar ningún otro paquete.
A continuación de esta actualización mínima ejecute:
# aptitude install initrd-tools
Este paso actualizará automáticamente libc6 y locales
e instalará las bibliotecas de soporte de SELinux (libselinux1).
Algunos de los servicios que se ejecutan en el sistema se reiniciarán tras este
paso, lo que incluye a xdm, gdm y kdm.
Las sesiones X11 locales se desconectarán a consecuencia de esto.
El siguiente paso a dar depende del conjunto de paquetes que tenga instalado. Estas notas de publicación proporcionan recomendaciones generales sobre el método a utilizar pero, si tiene dudas, se recomienda que revise los paquetes que se van a eliminar al seguir el método antes de continuar.
Algunos paquetes que generalmente se eliminarán incluyen:
base-config, hotplug, xlibs,
netkit-inetd, python2.3, xfree86-common,
y xserver-common. Puede encontrar una lista de los paquetes
obsoletos en etch en Paquetes obsoletos, Sección
4.10.
Se ha verificado el funcionamiento de este método de actualización en sistemas sarge con un la tarea de escritorio instalada. Por regla general es el método que dará mejores resultados en aquellos sistemas que tengan la tarea escritorio o los paquetes gnome o kde instalados.
Probablemente no es el mejor método a utilizar si no tiene los
paquetes libfam0c102 y xlibmesa-glu instalados. Lo
que puede verificar ejecutando:
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Ejecute lo siguiente si tiene un sistema con el entorno de escritorio completo:
# aptitude install libfam0 xlibmesa-glu
Es necesario un método distinto para aquellos sistemas que tienen algunos
paquetes X instalados, pero que no tienen instalada la tarea de
escritorio. Este método aplica, de forma general, a todos los
sistemas que tienen instalado el paquete xfree86-common,
incluyendo algunos sistemas servidores con tareas de servidor de
tasksel instaladas, ya que algunas de estas tareas incluyen
herramientas de gestión gráficas. Es posiblemente el método correcto a
utilizar en los sistemas que ejecutan X pero que no tienen la tarea de
escritorio instalada. Puede verificar esto ejecutando:
# dpkg -l xfree86-common | grep ^ii
En primer lugar, debe comprobar si tienen los paquetes libfam0c102
y xlibmesa-glu instalados:
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
Si no tiene libfam0c102 instalado no incluya libfam0
en la siguiente orden. Si no tiene instalado xlibmesa-glu, no lo
incluya en la ejecución de la siguiente orden. [8]
# aptitude install x11-common libfam0 xlibmesa-glu
Tenga en cuenta que si instala libfam0 también se instalará el
monitor de alteración de ficheros («File Alteration Monitor», fam)
así como el asignador de puertos RPC (portmap) si estos no estaban
todavía instalados en su sistema. Cada uno de estos paquetes activará un nuevo
servidor de red en el sistema, aunque pueden configurarse para asociarse sólo a
la interfaz de red (interna) «loopback».
No debería ser necesario ejecutar ninguna orden aptitude install en estos sistemas, puede pasar al siguiente paso.
La versión de udev en etch no da soporte a las versiones del
núcleo anteriores a la 2.6.15 (lo que incluye a los núcleos 2.6.8 de sarge), y
la versión de udev en sarge no funciona correctamente con los
núcleos más recientes. Además, la instalación de la versión de
udev en etch forzará al borrado de hotplug, utilizado
por los núcleos Linux versión 2.4.
Como consecuencia de esto, el paquete del núcleo utilizado previo a la
actualización posiblemente no arrancará correctamente tras éstas. De forma
similar, existe una ventana de tiempo durante la actualización en la que se
habrá actualizado udev pero no se ha instalado aún la última
versión del núcleo. Si el sistema se reiniciara en este punto, a la mitad de
la actualización, podría no arrancar debido a que los controladores no se
detectaran y cargaran correctamente (Encontrará en Preparar un entorno seguro para la
actualización, Sección 4.1.4 algunas recomendaciones para prepararse para
esta eventualidad si está actualizando de forma remota).
Se recomienda que actualice el núcleo por sí solo en este punto, a no ser que tenga la tarea de escritorio instalada, o cualquier otro paquete que hiciera que se eliminarán un número inaceptable de paquetes al intentarlo.
Ejecute lo siguiente para llevar a cabo esta actualización del núcleo:
# aptitude install linux-image-2.6-variante
Para saber qué variante del paquete del núcleo debería instalar consulte Actualización del metapaquete del núcleo, Sección 4.6.1.
En el caso de los sistemas con escritorio, lamentablemente no es posible
asegurar que se pueda instalar el nuevo paquete del núcleo antes de instalar
udev, por lo que existirá una ventana de tiempo de tamaño
desconocido en la que no tendrá un núcleo instalado con soporte de conexión de
dispositivos en caliente («hotplug»). Para obtener información de cómo
configurar su sistema para no depender de «hotplug» para el arranque consulte
Actualización de su núcleo y paquetes relacionados,
Sección 4.6.
Ahora puede seguir con la parte principal de la actualización. Ejecute:
# aptitude dist-upgrade
Se realizará una actualización completa del sistema, esto es, se instalarán las versiones más recientes de los paquetes y se resolverán todos los posibles cambios de dependencias entre los paquetes de diferentes versiones. Si fuera necesario, se instalarán nuevos paquetes (normalmente, nuevas versiones de las bibliotecas o paquetes que han cambiado de nombre), y se eliminarán los paquetes obsoletos conflictivos.
Se le pedirá que inserte CDs específicos en varios momentos durante la actualización cuando actualice desde un conjunto de CD-ROMs. Puede que tenga que insertar el mismo CD varias veces; esto se debe a paquetes interrelacionados que estén dispersos en varios CD.
Las versiones nuevas de los paquetes ya instalados que no se puedan actualizar
sin cambiar el estado de la instalación de otro paquete se dejarán en su
versión actual (en cuyo caso se mostrarán como «held back», es decir,
«retenidos»). Se puede resolver esta incidencia usando aptitude
para elegir esos paquetes para que se instalen o intentando ejecutar
aptitude -f install <paquete>.
Una vez haya actualizado puede actualizar la información de paquetes utilizando
la nueva versión de apt, que ya dispondrá del mecanismo para
comprobar las firmas de paquetes:
# aptitude update
El proceso de actualización se habrá encargado de descargar y activar las
claves utilizadas para firmar los repositorios de paquetes de Debian. El
programa apt presentará algunos mensajes de aviso si añade otras
fuentes de paquetes (no oficiales), ya que no será capaz de confirmar que los
paquetes descargados de estas fuentes son legítimos y no han sido manipulados.
Para más información puede consultar Gestión de paquetes, Sección 2.1.1.
Al hacer esto podrá observar que, dado que está utilizando la nueva versión de
apt, se descargarán los ficheros de diferencias de paquetes
(pdiff) en lugar de la lista de índices de paquetes completa.
Puede encontrar más información de esta funcionalidad en Descarga más lenta de los ficheros de
índice de APT, Sección 5.1.3.
Si falla alguna operación de aptitude, apt-get o
dpkg con el error:
E: Dynamic MMap ran out of room
esto se debe a que el espacio de caché por omisión es insuficiente. Puede
resolver esto eliminando o comentando aquellas líneas de
/etc/apt/sources.list que no necesite, o bien incrementando el
tamaño de la caché. Puede incrementar el tamaño de la caché fijando un valor
para APT::Cache-Limit en /etc/apt/apt.conf. La
siguiente orden fijará un valor para éste que debería ser suficiente para la
actualización:
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
Esta orden asume que no tiene aún definida esta variable en ese fichero.
Algunas veces se hace necesario activar la opción «APT::Force-LoopBreak» en APT
para permitir el borrado temporal de un paquete esencial debido a un bucle
entre conflictos y dependencias previas. aptitude le alertará de
esta situación y abortará la actualización. Puede resolver esto especificando
la opción -o APT::Force-LoopBreak=1 en la línea de órdenes de
aptitude.
Es posible que la estructura de dependencias del sistema esté tan dañada que
precise de intervención manual. Normalmente, implica usar
aptitude o
# dpkg --remove nombre_de_paquete
para eliminar algunos de los paquete problemáticos, o
# aptitude -f install
# dpkg --configure --pending
En casos extremos, puede que necesite forzar la reinstalación con una orden como:
# dpkg --install /ruta/al/nombre_de_paquete.deb
No deberían producirse conflictos entre ficheros si actualiza de un sistema sarge «puro», pero sí pueden producirse si ha instalado versiones nuevas no oficiales («backports», N. del T.). Si se produce un conflicto entre ficheros se mostrará con un error similar al siguiente:
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>
Puede intentar resolver los conflictos entre ficheros forzando a que se elimine el paquete mencionado en la última línea del mensaje de error:
# dpkg -r --force-depends nombre_de_paquete
Debería poder continuar la instalación donde la dejó tras corregir el problema repitiendo las órdenes de aptitude descritas previamente.
Se le harán preguntas sobre la configuración o reconfiguración de diversos
paquetes durante la actualización. Cuando se le pregunte si debería
reemplazarse algún fichero en los directorios /etc/init.d o
/etc/terminfo, o el fichero /etc/manpath.config con
la versión que propone el mantenedor del paquete, normalmente deberá responder
«sí» para asegurar la consistencia del sistema. Siempre puede volver a las
versiones antiguas más adelante, ya que quedan guardada con extensión
.dpkg-old.
Si no está seguro de lo que debe hacer, anote el nombre del paquete o fichero, y revise la situación más adelante. Recuerde que podrá buscar en el fichero de transcripción de la instalación y revisar la información que apareció en pantalla durante la actualización.
Esta sección explica cómo actualizar su núcleo e identifica los posibles
problemas que pueden darse con relación a esta actualización. Puede o bien
instalar uno de los paquetes linux-image-* que ofrece Debian o
compilar un núcleo personalizado desde las fuentes del mismo.
Tenga en cuenta que gran parte de la información de esta sección está basada en
la suposición de que está utilizando uno de los núcleos modulares de Debian
conjuntamente con initramfs-tools y udev. Parte de
la información aquí presentada puede no ser relevante para vd. si utiliza un
núcleo a medida que no necesita un initrd o si utiliza un generador de initrd
distinto.
Tenga en cuenta que puede utilizar hotplug para el descubrimiento
de hardware si no tiene instalado udev en su sistema.
Cuando realice «dist-upgrade» desde sarge a etch, le recomendamos encarecidamente que instale uno de los nuevos metapaquetes linux-image-2.6-*. Este paquete puede que se instale automáticamente en el proceso de actualización. Puede verificarlo con la siguiente orden:
# dpkg -l "linux-image*" | grep ^ii
Si no observa ningún mensaje, entonces necesitará instalar uno de los paquetes linux-image a mano. Para ver una lista de los metapaquetes linux-image-2.6 disponibles, ejecute:
# apt-cache search linux-image-2.6- | grep -v transition
Si no está seguro de qué paquete instalar, utilice la orden uname
-r y busque un paquete con un nombre similar. Por ejemplo, si ve
«2.4.27-3-686», le recomendamos que instale linux-image-2.6-686.
También puede utilizar apt-cache para ver una descripción más
larga de cada uno de los paquetes para así ayudarle a realizar una mejor
elección de entre los que hay disponibles. Por ejemplo:
# apt-cache show linux-image-2.6-686
Luego debería usar aptitude install para instalarlo. Debería reiniciar en cuanto le sea posible una vez que haya instalado el núcleo nuevo para empezar a beneficiarse de las características que proporciona el nuevo núcleo.
Los más avezados tienen un modo sencillo de compilar su propio núcleo en Debian
GNU/Linux. Instale la herramienta kernel-package y lea la
documentación que encontrará en /usr/share/doc/kernel-package.
Esta actualización se realizará de forma automática una vez haga una actualización completa de los paquetes del sistema (tal y como se describe e Actualizar los paquetes, Sección 4.5) si está ejecutando un núcleo de la serie 2.6 de sarge.
Es mejor para vd. si actualiza el paquete del núcleo de forma independiente a la actualización principal con dist-ugprade, si puede hacerlo, para reducir las posibilidades de tener durante un cierto periodo de tiempo un sistema que no puede arrancar. Para más información de este proceso consulte Actualizar el núcleo, Sección 4.5.5. Tenga en cuenta que sólo debería hacer esto después de haber realizado el proceso de actualización mínima del sistema que se describe en Actualización mínima del sistema, Sección 4.5.4.
También puede dar este paso si está utilizando su propio núcleo a medida y
quiere utilizar el núcleo disponible en etch. Se le recomienda que actualice
el núcleo después de la actualización mínima si su versión del núcleo no está
soportada por udev. Puede hacer esto una vez haya actualizado el
sistema completo si su versión sí está soportada por udev.
etch ofrece un mecanismo para descubrir hardware más robusto que en versiones anteriores. Sin embargo, éste puede provocar cambios en el orden en el que los dispositivos se buscan en el sistema, afectando por tanto al orden asignado a los mismos. Por ejemplo, si tiene dos adaptadores de red asociados a dos controladores diferentes, los dispositivos a los que «eth0» y «eth1» hacen referencia puede que estén cambiados uno por otro. Sepa además que el nuevo mecanismo conlleva que si, por ejemplo, cambia los adaptadores de red en un sistema etch que esté funcionando, el nuevo adaptador también tendrá un nombre de interfaz nuevo.
En los dispositivos de red, puede evitar que este reordenamiento se produzca
usando reglas de udev. Más específicamente, a través de las
definiciones en /etc/udev/rules.d/z25_persistent-net.rules[9]. También puede utilizar la
herramienta ifrename para asociar dispositivos físicos a nombres
específicos en el momento del arranque. Vea ifrename(8) y
iftab(5) para más información. No debería utilizar las dos
alternativas (udev y ifrename) al mismo tiempo.
En los dispositivos de almacenamiento, puede evitar este reordenamiento usando
initramfs-tools y configurándolo para cargar dispositivos de
almacenamiento en el mismo orden en el que se cargan actualmente. Para
hacerlo, identifique el orden en el que los módulos de almacenamiento se
cargaron, mediante la salida de la orden lsmod.
lsmod lista los módulos en orden inverso de carga; es decir, el
primer módulo de la lista es el último que se ha cargado. Tenga en cuenta que
esto sólo funcionara para aquellos dispositivos que el núcleo enumera en un
orden estable (como es el caso de los dispositivos PCI)
Sin embargo, retirar y cargar de nuevo módulos después del arranque inicial
afecta a este orden. Asimismo, su núcleo puede tener algunos controladores
enlazados estáticamente, y sus nombres no aparecerán en la salida de
lsmod. Puede ser capaz de descifrar estos nombres de
controladores y el orden de carga mirando en el fichero
/var/log/kern.log, o la salida de dmesg.
Añada esos nombres de módulos al fichero
/etc/initramfs-tools/modules en el orden en el que deberían
cargarse en el arranque. Algunos módulos puede que hayan cambiado de nombre
entre sarge y etch. Por ejemplo, sym53c8xx_2 ahora se llama sym53c8xx.
Necesitará entonces regenerar su(s) imagen(es) de initramfs con la orden
update-initramfs -k all.
Una vez que esté ejecutando un núcleo de etch y udev, podrá
reconfigurar su sistema para acceder a los discos con un nombre abreviado que
no dependa del orden de carga de los controladores. Estos nombres abreviados
(también llamados «alias») se encuentran en el árbol de directorios
/dev/disk/.
Si utiliza un initrd creado con initramfs-tools para arrancar el
sistema, en algunos casos la creación de los ficheros de dispositivos por parte
de udev pueden producirse demasiado tarde para que los programas
de arranque actúen sobre estos.
El síntoma habitual es que el arranque fallará porque el sistema de ficheros
raíz no puede montarse y se accede a un intérprete de línea de órdenes de
depuración. Sin embargo, cuando mira a continuación observa que todos los
dispositivos necesarios existen en /dev. Se ha observado este
problema en sistemas en los que el sistema de ficheros raíz estaba en un disco
USB o en un RAID, especialmente cuando se está utilizando lilo.
Para evitar este problema puede utilizar el parámetro de arranque rootdelay=9. Puede tener que ajustar el valor del retardo (en segundos) para su propio sistema.
La actualización «formal» habrá terminado cuando lo haga aptitude dist-upgrade, pero hay algunas otras cosas que debería tener en cuenta antes del próximo reinicio del sistema.
Los núcleos de Debian ya no tienen soporte de devfs, por lo que los usuarios de devfs deberán convertir sus sistemas manualmente antes de arrancar con un núcleo de etch.
Está utilizando seguramente devfs si observa la cadena «devfs» en
/proc/mounts. Cualquier fichero de configuración que referencie
los nombres de dispositivos que devfs utilizaba deberá ajustarse
para utilizar referencias a los nombres que udev utiliza. Entre
los ficheros más proclives a tener referencias a los nombres de dispositivo de
devfs están /etc/fstab, /etc/lilo.conf,
/boot/grub/menu.lst, y /etc/inittab.
Puede encontrar más información sobre algunos de los posibles problemas en el
informe de error #341152.
Si utiliza el cargador de arranque lilo (que es el cargador de
arranque para algunas instalaciones de sarge) se le recomienda encarecidamente
que vuelva a ejecutar lilo después de la actualización:
# /sbin/lilo
Tenga en cuenta que es necesario hacer esto aunque no actualizara el núcleo de
su sistema, dado que la segunda fase de lilo cambiará por la
actualización del paquete.
Debería revisar también los contenidos de su fichero de configuración
/etc/kernel-img.conf y asegurarse que tiene la opción
do_bootloader = Yes en él. De esta forma se ejecutará el cargador de
arranque tras cualquier actualización del núcleo.
Si se encuentra con cualquier problema en la ejecución de lilo,
debe revisar los enlaces simbólicos en / de vmlinuz e
initrd así como los contenidos /etc/lilo.conf para
detectar cualquier inconsistencia.
Su sistema puede no llegar a arrancar si no pudo ejecutar lilo
antes de reiniciar el sistema o si el sistema se reinició de forma accidental
antes de que pudiera hacerlo. En lugar del indicador de lilo cuando arranque
el sistema, sólo observará LI[10]. Para más información de cómo recuperarse ante este error
consulte Prepararse para la recuperación, Sección
4.1.3.
mdadm ahora necesita un fichero de configuración para ensamblar los grupos MD
(RAID) del disco RAM inicial y durante la secuencia de inicio del sistema. Por
favor, asegúrese de leer y actuar según las instrucciones del fichero
/usr/share/doc/mdadm/README.upgrading-2.5.3.gz una vez que el
paquete haya sido actualizado y antes de que reinicie. La
última versión de este fichero está disponible en http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file;
por favor, consúltela en caso de problemas.
Una vez hecha la actualización hay ciertas cosas que puede hacer para prepararse para la siguiente versión de la distribución.
Si utiliza grub, edite /etc/kernel-img.conf y cambie
la localización del programa update-grub cambiando
/sbin/update-grub por /usr/sbin/update-grub.
Si se ha instalado el metapaquete con la imagen del núcleo como una dependencia automática del anterior, éste estará marcado como instalado de forma automática. Debería corregir esto haciendo:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
Elimine los metapaquetes del núcleo de sarge ejecutando:
# aptitude purge kernel-image-2.6-<variante>
Mueva cualquier valor de configuración que se encuentre en
/etc/network/options a /etc/sysctl.conf. Para más
información consulte /usr/share/doc/netbase/README.Debian.
Elimine los paquetes obsoletos y no utilizados tal y como se describe en Paquetes obsoletos, Sección 4.10. Debería revisar qué ficheros de configuración utilizan estos y considerar como opción purgarlos para eliminar sus ficheros de configuración.
Con la publicación de Lenny se descontinuará el soporte de un alto número de paquetes de servidores por lo que si actualiza a las versiones más recientes de estos programas le ahorrarán problemas a la hora de actualizarse a Lenny.
Esto incluye los siguientes paquetes:
apache (1.x), lo sustituye apache2
bind8, lo sustituye bind9
php4, lo sustituye php5
postgresql-7.4, lo sustituye postgresql-8.1
exim 3, lo sustituye exim4
La versión etch, aunque introduce miles de nuevos paquetes, también retira o deja de distribuir más de tres mil quinientos paquetes antiguos que estaban disponibles en sarge. No existe un mecanismo de actualización de estos paquetes obsoletos. Aunque nada le impide que siga usando paquetes obsoletos si así lo desea, el proyecto Debian deja de dar soporte de seguridad a estos un año después de la publicación de etch[11] y no se ofrecerá otro tipo de soporte durante este tiempo. Lo recomendable es reemplazar dados paquetes con las alternativas disponibles, si es que existen.
Hay muchas razones por las que un paquete puede haberse eliminado de la distribución, a saber: no hay mantenimiento por parte de los desarrolladores originales, no hay ningún desarrollador en Debian que esté interesado en mantener los paquetes, la funcionalidad que ofrecen la ofrece ahora otros programas (o una nueva versión), o ya no se consideran aptos para distribuirse en etch debido a los errores que presentan. En este último caso los paquetes puede que sigan estando presentes en la distribución «inestable».
Es fácil detectar qué paquetes de un sistema actualizado están «obsoletos»,
dado que las interfaces de gestión de paquetes los marcarán como tal. Si está
utilizando aptitude podrá ver el listado de dichos paquetes en la
entrada «Paquetes obsoletos y creados localmente». dselect
también ofrece una sección similar pero el listado de paquetes puede diferir.
Además, si ha utilizado aptitude para instalar manualmente
paquetes de sarge, la herramienta hará un seguimiento de los paquetes que haya
instalado y podrá marcar como obsoletos aquellos paquetes que se obtuvieron
sólo para cumplir las dependencias pero que ya no se necesitan cuando el
paquete se ha eliminado. Además, aptitude, a diferencia de
deborphan, no marcará como obsoletos aquellos paquetes que ha
instalado manualmente, en contraste con aquellos paquetes que se instalaron
automáticamente para cumplir dependencias.
Existen herramientas adicionales que puede utilizar para encontrar paquetes
obsoletos como es el caso de deborphan, debfoster o
cruft. Le recomendamos deborphan aunque sólo
informará (en su modo normal) sobre las bibliotecas obsoletas: paquetes en las
secciones «libs» o «oldlibs» que no está utilizando ningún otro paquete. No
elimine a ciegas los paquetes que le indiquen estas herramientas, especialmente
si utiliza opciones distintas de las de por omisión que pueden dar lugar a
falsos positivos. Se le recomienda encarecidamente que revise los paquetes que
éstas le sugieren eliminar (esto es: sus contenidos, su tamaño y descripción)
antes de eliminarlos
A menudo podrá encontrar más información de por qué un paquete fue eliminado en
el sistema de seguimiento de fallos de
Debian. Debería consultar tanto los informes de fallos del propio
paquete como los informes de fallos archivados del pseudo-paquete
ftp.debian.org.
Se han divido algunos paquetes de sarge en más de un paquete en etch, generalmente para mejorar la mantenibilidad del sistema. Para facilitar el proceso de actualización en estos casos se ofrecen paquetes «dummy» (tontos, N. del T.) dentro de etch. Éstos son paquetes vacíos que tienen el mismo nombre que el anterior paquete en sarge con un conjunto de dependencias que asegura que se instalen los nuevos paquetes. Estos paquetes se consideran obsoletos y puede eliminarlos una vez haya actualizado el sistema.
La mayoría (pero no todas) de las descripciones de los paquetes «dummy» indican
su propósito. Sin embargo, las descripciones de estos paquetes no son
uniformes así que puede que encuentre útil utilizar deborphan con
la opción --guess para detectar los que están instalados en su
sistema. Tenga en cuenta que algunos paquetes «dummy» no están pensados para
ser eliminados después de una actualización sino que se utilizan para poder
seguir a lo largo del tiempo la versión actual de un programa.
[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ siguiente ]
Notas de la publicación de Debian GNU/Linux 4.0 («etch»), AMD64
$Id: release-notes.es.sgml,v 1.65 2007/08/10 20:53:00 jfs Exp $debian-doc@lists.debian.orgdebian-l10n-spanish@lists.debian.org