Manual de Gentoo: X86/Instalación/Stage
Instalar el Stage empaquetado (tarball)
Ajustar la Fecha/Hora correcta
Antes de instalar Gentoo, es una buena idea asegurarse de que la fecha y la hora estén configuradas correctamente. Un reloj mal configurado puede generar problemas extraños con la instalación: los archivos del sistema base deben extraerse con marcas de tiempo correctas. De hecho, debido a que los servicios web de Gentoo utilizan certificados de seguridad, es posible que no sea posible descargar los archivos de instalación si el reloj del sistema está demasiado desfasado. Un reloj ajustado es un requisito para proceder con la instalación.
Verifique la fecha y hora actuales ejecutando el comando date:
root #dateMon Oct 3 13:16:22 PDT 2021
Si la fecha/hora que se muestra está desfasada por más de unos minutos, debe actualizarse con precisión mediante uno de los métodos que se indican a continuación.
Automático
La mayoría de los lectores desearán que su sistema actualice la hora automáticamente utilizando un servidor horario.
Algunas placas base no incluyen un reloj de tiempo real (RTC), que mantendrá una hora relativamente precisa incluso cuando el sistema esté apagado. Es muy importante que estos sistemas sincronicen automáticamente el reloj del sistema con un servidor horario en cada inicio del sistema y de manera regular a partir de entonces. Esto es igual de importante para los sistemas que incluyen un RTC, pero tienen una batería defectuosa.
Los entornos live oficiales de Gentoo incluyen el comando ntpd (disponible en el paquete net-misc/ntp) y un fichero de configuración que apunta a los servidores de hora en ntp.org. Esta orden se puede utilizar para sincronizar automáticamente el reloj del sistema al horario UTC usando un servidor ntp. Usar este método requiere una configuración de red funcionando y puede no estar disponible en todas las arquitecturas.
La configuración automática de la hora tiene su precio. Revelará la dirección IP del sistema e información de red relacionada a un servidor ntp (en el ejemplo a continuación, a ntp.org). Los usuarios con preocupaciones acerca de su privacidad deben ser conscientes de esto "antes" de configurar el reloj del sistema utilizando dicho método.
root #ntpd -q -gManual
Para los sistemas que no tienen acceso a un servidor horario, el comando date también se puede usar para configurar el reloj del sistema. Utilizará el siguiente formato como argumento: sintaxis MMDDhhmmYYYY (Month, Day, hour, minute y Year).
Se recomienda el horario UTC para todos los sistemas Linux. Una zona horaria se definirá más adelante en la instalación que modificará el reloj para mostrar la hora local.
Por ejemplo, para ajustar la fecha y hora a las 13:16 horas del 3 de octubre del 2021, ejecute:
root #date 100313162021Elegir un empaquetado de stage
No todas las arquitecturas tienen una opción multilib. Muchas solo ejecutan código nativo. Multilib se aplica más comúnmente a amd64.
Multilibrería (32 y 64 bits)
Elegir un archivo base de empaquetado para el sistema, puede ahorrar una cantidad de tiempo considerable más tarde durante el proceso de instalación, específicamente cuando es el momento de elegir un perfil del sistema. La selección de un archivo de empaquetado de stage afectará a la configuración futura del sistema y puede evitar más de un dolor de cabeza en el futuro. El empaquetado multilibrería utiliza librerías de 64 bits cuando es posible y únicamente hace uso de las versiones de 32 bits cuando es necesario por compatibilidad. Esta es una excelente opción para la mayoría de instalaciones ya que ofrece una gran flexibilidad de personalización en el futuro. Aquéllos usuarios que desean que sus sistemas puedan conmutar fácilmente entre perfiles querrán descargar la opción del empaquetado multilibrería para su arquitectura de procesador.
La mayoría de los usuarios no deberían utilizar las opciones 'avanzadas' de los archivos de empaquetado ya que se utilizan para configuraciones específicas de software o de hardware.
No multilibrería (64 bits puros)
La selección de un empaquetado no multilib para que sea la base del sistema proporciona un entorno de sistema operativo completo de 64 bits. Esto hace que la capacidad de cambiar a perfiles multilib sea improbable, aunque técnicamente sigue siendo posible.
Los lectores que acaban de empezar con Gentoo no deben elegir un empaquetado sin multilib a menos que sea absolutamente necesario. Migrar de un sistema sin multilib a uno multilib requiere un conocimiento extremadamente bueno de Gentoo y de la cadena de herramientas de nivel inferior (incluso puede hacer que nuestros desarrolladores de la cadena de herramientas se estremezcan un poco). No es para miedosos y está más allá del alcance de esta guía.
OpenRC
OpenRC es un sistema de inicio basado en dependencias (responsable de iniciar los servicios del sistema una vez que se ha iniciado el núcleo) que mantiene compatibilidad con el programa de inicio proporcionado por el sistema, que normalmente se encuentra en /sbin/init. Es el sistema de inicialización nativo y original de Gentoo, pero también lo implementan algunas otras distribuciones de Linux y sistemas BSD.
OpenRC no funciona como reemplazo del archivo /sbin/init por defecto y es 100% compatible con los guiones de inicio de Gentoo. Esto significa que puede ser una solución para ejecutar las docenas de daemons en el repositorio de ebuilds de Gentoo.
systemd
systemd es un reemplazo moderno de init y rc de estilo SysV para sistemas Linux. La mayoría de las distribuciones Linux lo utilizan como sistema de inicio principal. systemd es totalmente compatible con Gentoo y funciona para el propósito previsto. Desafortunadamente, las secciones correspondientes del Manual de instalación para el sistema aún deben escribirse o están en proceso. Parece que aun falta un poco en el Manual para una guia de instalación con systemd, revise el artículo de systemd antes de solicitar ayuda.
Técnicamente es posible cambiar una instalación de Gentoo en ejecución de OpenRC a systemd y viceversa. Sin embargo, cambiar requiere algo de esfuerzo y está fuera del alcance de este manual de instalación. Antes de descargar un empaquetado de stage decida si usará OpenRC o systemd como sistema de inicio y descargue el empaquetado de stage correspondiente.
Descargar el empaquetado de stage (tarball)
Vaya al punto de montaje de Gentoo en el que ha montado el sistema de archivos raíz (probablemente /mnt/gentoo):
root #cd /mnt/gentooLos usuarios que utilicen entornos con navegadores web gráficos no tendrán problema en copiar el URL de un fichero stage desde la sección de descargas del sitio web principal. Simplemente seleccione la pestaña apropiada, haga clic con el botón secundario del ratón en el fichero stage, entonces Copiar la ruta del enlace para copiar el enlace al portapapeles, a continuación pegue el enlace para la utilidad wget en la lína de órdenes para descargar el archivo comprimido stage:
root #wget <URL_DEL_STAGE_PEGADA>Los usuarios de Gentoo más tradicionales o los 'históricos' que trabajen exclusivamente con la línea de órdenes puede que prefieran utilizar links (www-client/links), un navegador no gráfico dirigido por menús. Para descargar un stage, navegue a la lista de servidores réplica de Gentoo de esta forma:
root #links https://www.gentoo.org/downloads/mirrors/Para usar un proxy HTTP con links, pase la URL con la opción -http-proxy:
root #links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/Junto a links existe también el navegador lynx (www-client/lynx). Al igual que links es un navegador de consola pero sin menús.
root #lynx https://www.gentoo.org/downloads/mirrors/Si necesita pasar a través de un proxy, exporte las variables http_proxy y ftp_proxy:
root #export http_proxy="http://proxy.server.com:port"
root #export ftp_proxy="http://proxy.server.com:port"Seleccione un servidor réplica cercano. Normalmente bastará con los servidores HTTP, sin embargo también están disponibles otros protocolos. Entre en el directorio releases/x86/autobuilds/. En él deberían aparecer todos los archivos de stage disponibles (quizá almacenados en subdirectorios con el nombre de cada subarquitectura). Seleccione uno y pulse d para descargarlo.
Una vez haya finalizado la descarga del fichero stage, es posible verificar la integridad y validar los contenidos del stage comprimido. Los interesados pueden ir a la siguiente sección.
Para los que no estén interesados en verificar y validar el archivo stage pueden el navegador de línea de comandos pulsando q e ir directamente a la sección Extraer el stage comprimido.
Verificar y validar
La mayoría de los stages ahora tienen sufijo explícitamente con el tipo de sistema de inicio (openrc o systemd), aunque en algunas arquitecturas aún pueden faltar por ahora.
Al igual que con los CDs minimalistas de instalación, hay descargas disponibles para verificar y validar el archivo stage. Aunque estos pasos se pueden omitir, estos archivos se ofrecen a aquéllos usuarios que se preocupan por la legitimidad del archivo o archivos que se acaban de descargar.
- Un archivo .CONTENTS que contiene un listado de todos los archivos contenidos dentro del empaquetado stage.
- Un archivo .DIGESTS que contiene sumas de comprobación del archivo stage utilizando diferentes algoritmos.
- Un archivo .DIGESTS.asc que, al igual que .DIGESTS, contiene sumas de comprobación del archivo stage utilizando diferentes algoritmos, y además está firmado criptográficamente para asegurar que es el proporcionado por el proyecto Gentoo.
Use openssl y compare la salida con la suma de comprobación proporcionada por el archivo .DIGESTS o .DIGESTS.asc.
Por ejemplo, para validar la suma de comprobación SHA512:
root #openssl dgst -r -sha512 stage3-x86-<release>-<init>.tar.?(bz2|xz)Otra forma es usar la orden sha512sum:
root #sha512sum stage3-x86-<release>-<init>.tar.?(bz2|xz)Para validar la suma de comprobación Whirlpool:
root #openssl dgst -r -whirlpool stage3-x86-<release>-<init>.tar.?(bz2|xz)Compare la salida de estas órdenes con el valor registrado en los archivos .DIGESTS(.asc). Los valores deben coincidir, de lo contrario, los archivos descargados podrían estar corruptos (o el propio archivo digests).
Al igual que con el archivo ISO, puede también verificar la firma criptográfica del archivo .DIGESTS.asc mediante gpg para asegurarse de las sumas de comprobación no se han manipulado:
root #gpg --verify stage3-x86-<release>-<init>.tar.?(bz2|xz){.DIGESTS.asc,} Las huellas digitales de las claves OpenPGP utilizadas para firmar los medios de lanzamiento se pueden encontrar en la página de firmas de medios de lanzamiento del servidor web Gentoo.
Extraer el stage comprimido
Ahora desempaquete el stage descargado en el sistema. Use la utilidad tar para hacerlo:
root #tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-ownerVerifique que usa las opciones indicadas (xpf y --xattrs-include='*.*') en el comando. La x se usa para desempaquetar (extract), la p para preservar (preserve) los permisos y la f para decir que extraemos desde un archivo (file), no desde la entrada estándar. La opción --xattrs-include='*.*' es para que se incluyan también los atributos extendidos almacenados en todos los espacios de nombres en el archivo. Por último, --numeric-owner se utiliza para asegurarse de que los IDs del usuario y grupo de los ficheros que se extraen del fichero comprimido son los mismos que incluyó el equipo de ingeniería de liberaciones de Gentoo, incluso si algún usuario aventurero no está utilizando los entornos live oficiales de Gentoo.
Ahora que el fichero stage está desempaquetado, continúe con Configurar las opciones de compilación.
Configurar las opciones de compilación
Introducción
Para optimizar el sistema, es posible establecer variables que afecten al comportamiento de Portage, el administrador de paquetes con soporte oficial de Gentoo. Todas esas variables se pueden configurar como variables de entorno (usando export), pero la configuración a través de export no es permanente.
Técnicamente, las variables se pueden exportar a través del perfil de shell o archivos rc, sin embargo, esa no es la mejor manera para la administración básica del sistema.
Portage lee el archivo make.conf cuando se ejecuta, lo que cambiará su comportamiento durante su ejecución dependiendo de los valores guardados en el archivo. make.conf puede considerarse el archivo de configuración principal de Portage, así que trate su contenido con cuidado.
Puede encontrar una lista comentada de todas las variables posibles en /mnt/gentoo/usr/share/portage/config/make.conf.example. Se puede encontrar documentación adicional sobre make.conf ejecutando man 5 make.conf.
Para una instalación exitosa de Gentoo, solo se deben configurar las variables que se mencionan a continuación.
Use su editor favorito (en esta guía usaremos nano) para modificar las variables de optimización que discutiremos en adelante.
root #nano -w /mnt/gentoo/etc/portage/make.confObservando el archivo make.conf.example es obvio cual es su estructura: las líneas que son comentarios comienzan con #, el resto definen variables usando la sintaxis VARIABLE="valor". Varias de estas variables se discuten a continuación.
CFLAGS y CXXFLAGS
Las variables CFLAGS y CXXFLAGS definen los parámetros de optimización para los compiladores GCC de C y de C++ respectivamente. Aunque generalmente se definen aquí, obtendrá el máximo rendimiento si optimiza estos parámetros para cada programa por separado. La razón es que cada programa es diferente. Sin embargo, no es manejable definir estos indicadores en el archivo make.conf.
En make.conf deberá definir los parámetros de optimización que se ajusten a su sistema de forma general. No coloque parámetros experimentales en esta variable; un nivel demasiado alto de optimización puede hacer que los programas funcionen mal (cuelgues, o incluso peor, funcionamientos erróneos).
No explicaremos todas las opciones posibles de optimización. Si quiere conocerlas todas, lea los Manuales en línea GNU o la página información de gcc (info gcc sólo es válido en un sistema Linux funcional). El archivo make.conf.example también contiene una gran cantidad de ejemplos e información; no olvide leerlo también.
El primer parámetro es -march= o -mtune=, el cual especifica el nombre de la arquitectura destino. Las posibles opciones se describen en el archivo make.conf.example (como comentarios). Un valor frecuentemente utilizado es native ya que indica al compilador que seleccione la arquitectura destino del sistema actual (en el que se está realizando la instalación).
Seguida de esta, está el parámetro -O (que es una O mayúscula, no un cero), que especifica la clase optimización de gcc. Las clases posibles son s (para tamaño optimizado), 0 (cero - para no optimizar), 1, 2 o incluso 3 para la optimización de velocidad (cada clase tiene los mismos parámetros que la anterior, más algunos extras). -O2 es la recomendación por defecto. Es conocido que -O3 provoca problemas cuando se utiliza globalmente en el sistema, por esto se recomienda quedarse con -O2.
Otros parámetros de optimización bastante populares son los -pipe (usar tuberías en lugar de archivos temporales para la comunicación entre las diferentes etapas de compilación). No tiene ningún impacto sobre le código generado, pero usa más memoria. En sistemas con poca memoria, el proceso del compilador podría ser terminado. En ese caso, no use este parámetro.
Usar -fomit-frame-pointer (el cual no mantiene el puntero de marco en un registro para aquellas funciones que no lo necesiten) podría tener graves repercusiones en la depuración de errores en aplicaciones.
Cuando defina las variables CFLAGS y CXXFLAGS, debería combinar varios parámetros de optimización en una sóla cadena. Los valores por defecto que trae el archivo stage3 una vez descomprimido deberían ser suficientemente buenos. Lo siguiente es simplemente un ejemplo:
# Configuraciones del compilador a aplicar en cualquier lenguaje COMMON_CFLAGS="-O2 -march=i686 -pipe" # Use los mismos valores en ambas variables CFLAGS="${COMMON_FLAGS}" CXXFLAGS="${CFLAGS}"
A pesar de que el artículo sobre la optimización de GCC contiene más información sobre cómo las distintas opciones de compilación pueden afectar a un sistema, el artículo sobre CFLAGS seguras puede resultar más práctico para los que se inician en la optimización de su sistema.
MAKEOPTS
La variable MAKEOPTS define cuántas compilaciones paralelas deben ocurrir al instalar un paquete. Una buena opción es la menor de: la cantidad de hilos de procesamiento tiene la CPU o la RAM total del sistema dividida por 2 GiB.
A good choice is the smaller of: the number of threads the CPU has, or the total amount of system RAM divided by 2 GiB.
El uso de una gran cantidad de trabajos puede afectar significativamente el consumo de memoria. Una buena recomendación es tener al menos 2 GiB de RAM para cada trabajo especificado (por ejemplo,
-j6 requiere al menos 12 GiB). Para evitar quedarse sin memoria, reduzca el número de trabajos para que se ajusten a la memoria disponible.Cuando se utilizan emerges en paralelo (
--jobs), la cantidad efectiva de trabajos ejecutados puede crecer exponencialmente (hasta hacer que los trabajos se multipliquen por los trabajos de los emerges). Esto se puede solucionar ejecutando una configuración distcc solo para localhost que limitará el número de instancias del compilador por host.
MAKEOPTS="-j2"
Search for MAKEOPTS in man 5 make.conf for more details.
Preparados, listos, ¡ya!
Actualice /mnt/gentoo/etc/portage/make.conf con sus propios parámetros y guarde los cambios (los usuarios de nano deben usar Ctrl + x).
Continúe con Instalar el sistema base de Gentoo.