20 Preguntas de Práctica de Arranque, kernel y dispositivos con Respuestas

1. 1. Un administrador documenta lo que ocurre entre pulsar el botón de encendido y ver el aviso de inicio de sesión en un servidor Linux con firmware UEFI. ¿Cuál es la secuencia correcta?

   • A.El firmware ejecuta GRUB desde su entrada de arranque, GRUB carga el kernel y el initramfs en memoria, el kernel arranca desde el initramfs, carga los controladores y cambia a la raíz real, y ejecuta systemd como PID 1✓ Respuesta
   • B.El firmware ejecuta GRUB, GRUB monta por sí mismo el sistema de archivos raíz real y se lo entrega ya montado al kernel, el kernel genera después un initramfs en memoria, cambia a él y ejecuta systemd como PID 1
   • C.El firmware carga el kernel directamente desde su entrada de arranque, el kernel carga GRUB para obtener sus parámetros, monta la raíz real, descomprime el initramfs y por último ejecuta systemd como PID 1
   • D.El firmware ejecuta GRUB, GRUB inicia systemd como PID 1 desde la partición de arranque, systemd carga el kernel y el initramfs, el kernel monta la raíz real y systemd arranca las demás unidades

   El firmware solo sabe ejecutar el gestor de arranque indicado en su entrada de arranque; GRUB carga entonces la imagen del kernel y el initramfs en RAM. El kernel usa el initramfs como raíz temporal para disponer de los módulos que necesita para alcanzar el dispositivo raíz real, después hace switch_root y ejecuta /sbin/init, que en una distribución con systemd es systemd como PID 1.

   Ref. QB-HRGTGAFuente: bootup(7) systemd boot process documentation; CompTIA Linux+ objectives, System Management: basic boot processReportar un problema con esta pregunta

2. 2. En un servidor basado en RPM, un administrador debe lograr que el parámetro de kernel transparent_hugepage=never se aplique en cada arranque. ¿Cuál es la forma admitida de hacerlo?

   • A.Editar a mano la línea linux16 dentro del archivo generado /boot/grub2/grub.cfg, porque es el archivo que el gestor de arranque lee al iniciar
   • B.Añadir el parámetro a GRUB_CMDLINE_LINUX en /etc/default/grub y regenerar la configuración con grub2-mkconfig -o /boot/grub2/grub.cfg✓ Respuesta
   • C.Escribir el parámetro en /proc/cmdline, porque el kernel vuelve a leer ese archivo en cada arranque para reconstruir su línea de comandos
   • D.Colocar el parámetro en un archivo nuevo bajo /etc/sysctl.d/ y cargarlo con sysctl --system para que se aplique en cada arranque

   grub.cfg es un archivo generado: la siguiente actualización del kernel o cualquier ejecución del generador sobrescribe las ediciones manuales. La fuente real es /etc/default/grub junto con los scripts de /etc/grub.d/, y grub2-mkconfig reescribe grub.cfg a partir de ellos. /proc/cmdline es salida de solo lectura del kernel y sysctl es otro mecanismo distinto.

   Ref. QB-Y8YAR8Fuente: GNU GRUB manual, simple configuration handling (/etc/default/grub and grub-mkconfig); grub2-mkconfig(8)Reportar un problema con esta pregunta

3. 3. Un servidor se reinició tras cambiar un parámetro del kernel y el administrador quiere confirmar qué parámetros recibió realmente el kernel en ejecución. ¿Qué fuente lo muestra?

   • A./etc/default/grub, porque el gestor de arranque copia los valores de ese archivo al kernel al entregarle el control
   • B./boot/grub2/grub.cfg, porque la entrada de menú seleccionada registra lo que el kernel acabó recibiendo
   • C./proc/cmdline, porque el kernel publica en ese archivo la línea de comandos exacta con la que fue iniciado✓ Respuesta
   • D./etc/sysctl.conf, porque systemd escribe en ese archivo los parámetros de kernel usados en el arranque

   El archivo de procfs /proc/cmdline es el propio kernel informando de la línea de comandos con la que arrancó, tal como se la entregó el gestor de arranque. Los archivos de GRUB solo describen lo que debería haberse pasado, por lo que difieren de la realidad si la configuración no se regeneró o se arrancó otra entrada.

   Ref. QB-GR5GB9Fuente: proc(5) manual page, /proc/cmdlineReportar un problema con esta pregunta

4. 4. Un servidor arranca en un inicio de sesión gráfico, pero el administrador necesita un shell mínimo de un solo usuario solo para este arranque, sin cambiar nada de forma permanente. ¿Qué debe hacer?

   • A.En el menú de GRUB pulsar e, añadir systemd.unit=rescue.target a la línea linux y arrancar esa entrada una vez✓ Respuesta
   • B.Ejecutar ahora systemctl isolate rescue.target, que además cambia el objetivo predeterminado de los arranques siguientes
   • C.Editar /etc/inittab y poner la línea initdefault en 1, porque systemd sigue leyendo ese archivo en cada arranque
   • D.Ejecutar systemctl set-default rescue.target desde un medio de rescate y reiniciar el servidor en ese modo

   Editar la entrada de menú resaltada en el gestor de arranque cambia solo la línea de comandos de ese arranque, y systemd respeta systemd.unit= como objetivo a activar. set-default reescribe el enlace default.target y por tanto persiste, isolate conmuta el sistema en marcha en lugar de elegir un modo de arranque, y systemd no usa /etc/inittab.

   Ref. QB-392B9CFuente: systemd(1) kernel command line option systemd.unit=; GNU GRUB manual, editing menu entries at bootReportar un problema con esta pregunta

5. 5. En una distribución con systemd, después de que el kernel cambia al sistema de archivos raíz real, ¿qué determina qué servicios se levantan?

   • A.GRUB entrega a systemd una lista de servicios tomada de /etc/default/grub y systemd inicia cada servicio nombrado en esa lista
   • B.El kernel lee el campo de nivel de ejecución de /etc/inittab y ejecuta en orden los scripts del directorio /etc/rc?.d correspondiente
   • C.El kernel ejecuta systemd como PID 1 y systemd activa las unidades que arrastra default.target, un enlace simbólico en /etc/systemd/system✓ Respuesta
   • D.El initramfs sigue ejecutándose como PID 1 y lanza los servicios listados en /etc/initramfs-tools antes de entregar la raíz

   El último acto de arranque del kernel es ejecutar el primer proceso de espacio de usuario, PID 1, que en estas distribuciones es systemd. systemd resuelve entonces default.target, un enlace simbólico que sigue hasta los directorios de unidades, y activa todo lo que ese objetivo requiere.

   Ref. QB-KR7GUCFuente: systemd(1) and bootup(7); systemd.special(7) description of default.targetReportar un problema con esta pregunta

6. 6. ¿Por qué una distribución incluye un sistema de archivos inicial en RAM en lugar de dejar que el kernel monte directamente la raíz?

   • A.Porque el kernel no puede ejecutar ningún programa de espacio de usuario hasta que una imagen en RAM le entrega una copia de systemd
   • B.Porque el gestor de arranque solo direcciona una parte pequeña del disco, así que la imagen en RAM aporta el resto del kernel
   • C.Porque el sistema de archivos raíz debe revisarse en busca de errores y solo el código de la imagen en RAM puede ejecutar fsck
   • D.Porque el conjunto de módulos para alcanzar el dispositivo raíz, como los de almacenamiento y volúmenes, no está en la imagen del kernel✓ Respuesta

   Un kernel de uso general se distribuye pequeño y modular, por lo que los controladores del controlador concreto, del destino de device mapper o del volumen cifrado que contiene la raíz son módulos cargables que viven en esa misma raíz. El initramfs rompe ese círculo: se descomprime en RAM, aporta esos módulos, ensambla el dispositivo raíz y cambia a él.

   Ref. QB-29PY3BFuente: Linux kernel documentation, initrd/initramfs (admin-guide); dracut(8) description of the initramfs roleReportar un problema con esta pregunta

7. 7. En un servidor basado en Debian se instaló un controlador de almacenamiento nuevo y, tras reiniciar, el arranque se detiene en un shell de emergencia indicando que el dispositivo raíz no existe. ¿Cuál es la solución más probable?

   • A.Reinstalar el gestor de arranque con grub-install, porque el shell de emergencia indica que perdió su mapa de dispositivos
   • B.Reconstruir el initramfs con update-initramfs -u -k all para que el controlador nuevo esté presente al montar la raíz✓ Respuesta
   • C.Recrear el área de intercambio con mkswap y activarla, porque el kernel no termina de arrancar sin intercambio activo
   • D.Ejecutar e2fsck sobre la raíz desde un medio de rescate, porque un dispositivo raíz ausente apunta a un superbloque dañado

   El initramfs es una instantánea: un controlador instalado después en /lib/modules no está dentro, así que el entorno de arranque temprano no ve el dispositivo raíz y cae al shell de emergencia. Regenerar la imagen, que en sistemas basados en Debian se hace con update-initramfs, incluye el módulo nuevo; en sistemas RPM el paso equivalente es dracut -f.

   Ref. QB-JRU5PBFuente: update-initramfs(8) and initramfs-tools(7)Reportar un problema con esta pregunta

8. 8. Un administrador ejecuta lsmod y ve: Module Size Used by nvme_core 155648 3 nvme loop 32768 0 Luego el comando rmmod nvme_core falla. ¿Qué indica aquí la tercera columna?

   • A.El módulo sigue en uso, con tres referencias y con el módulo nvme dependiendo de él, así que no se descarga hasta liberarlas✓ Respuesta
   • B.El módulo se compiló dentro de la imagen del kernel, así que aparece en la lista pero nunca puede descargarse mientras el sistema funciona
   • C.El módulo está en la lista negra de /etc/modprobe.d y un módulo así no se puede descargar hasta quitar esa entrada
   • D.El módulo se cargó desde una ruta fuera de /lib/modules, por lo que rmmod se niega a descargarlo y hay que usar insmod

   lsmod imprime el contenido de /proc/modules: nombre del módulo, tamaño, contador de uso y los módulos que dependen de él. rmmod solo descarga un módulo inactivo, así que un contador distinto de cero lo hace fallar; hay que liberar primero el módulo dependiente o usar modprobe -r para descargarlo junto con sus dependencias ya sin uso.

   Ref. QB-59RYKEFuente: lsmod(8) and proc(5) /proc/modules; rmmod(8) and modprobe(8) -rReportar un problema con esta pregunta

9. 9. Cargar un controlador con insmod /lib/modules/$(uname -r)/kernel/drivers/net/example.ko falla con errores de símbolos desconocidos, mientras que modprobe example lo carga sin problemas. ¿Por qué?

   • A.insmod carga el módulo en el espacio de usuario, donde no se ven los símbolos del kernel, y modprobe lo carga en el kernel
   • B.modprobe carga una copia firmada del módulo e insmod carga el archivo sin firmar, y los módulos sin firmar fallan la comprobación
   • C.insmod solo funciona con módulos ya listados en /etc/modules-load.d y cualquier otro módulo debe cargarse usando modprobe
   • D.modprobe lee el mapa de dependencias y carga primero los módulos que el controlador necesita, mientras insmod carga solo el archivo dado✓ Respuesta

   insmod es una herramienta mínima: inserta exactamente la ruta de archivo que se le pasa y no resuelve nada, por lo que cualquier símbolo que provea otro módulo se informa como desconocido. modprobe recibe un nombre de módulo, consulta la información de dependencias generada por depmod e inserta los prerrequisitos antes del módulo pedido.

   Ref. QB-NRW57FFuente: modprobe(8) and insmod(8) manual pagesReportar un problema con esta pregunta

10. 10. Se copió el archivo de un controlador del proveedor en /lib/modules/$(uname -r)/extra/, pero modprobe sigue informando de que no encuentra el módulo. ¿Qué comando debe ejecutarse a continuación?

    • A.insmod, para que el módulo quede registrado en el kernel y modprobe pueda verlo en las cargas posteriores
    • B.dracut -f, para que el módulo se añada al sistema de archivos inicial en RAM y modprobe lo encuentre
    • C.modinfo, para que los metadatos del módulo se escriban en el kernel y modprobe resuelva el nombre
    • D.depmod, para que se reconstruya el mapa de dependencias que consulta modprobe e incluya el archivo nuevo✓ Respuesta

    modprobe no recorre el árbol de módulos en tiempo de ejecución; busca el nombre en los archivos de índice que genera depmod, sobre todo modules.dep y su forma binaria. Hasta que se ejecuta depmod para ese kernel, el archivo recién copiado es invisible, por lo que tras colocar un módulo siempre se ejecuta depmod.

    Ref. QB-VK947EFuente: depmod(8) and modules.dep(5)Reportar un problema con esta pregunta

11. 11. Un módulo figura como blacklist ex_drv en /etc/modprobe.d/local.conf, pero tras reiniciar lsmod sigue mostrándolo cargado. ¿Qué lo explica y cómo se corrige?

    • A.La lista negra solo impide la carga por nombre: otro módulo lo arrastró como dependencia, así que use install ex_drv /bin/false✓ Respuesta
    • B.Una entrada blacklist necesita una línea alias equivalente, por lo que hay que añadir un alias del mismo módulo en ese archivo
    • C.Los archivos de /etc/modprobe.d solo los lee insmod, así que la entrada debe trasladarse a /etc/modules-load.d para surtir efecto
    • D.El sistema de archivos inicial en RAM anula por completo las reglas de modprobe, de modo que hay que quitar el módulo del paquete

    Una línea blacklist solo suprime la carga cuando ese nombre de módulo se solicita directamente o coincide con un alias; no impide que se cargue porque otro módulo lo declare como dependencia. Asignar el nombre a un comando que no hace nada con install ex_drv /bin/false, o pasar modprobe.blacklist= en la línea del kernel, lo bloquea en todos los casos.

    Ref. QB-C44XKDFuente: modprobe.d(5), blacklist and install directivesReportar un problema con esta pregunta

12. 12. Un controlador funciona en un servidor, pero nunca aparece en la salida de lsmod y rmmod informa de que no está cargado. ¿Cuál es la explicación más probable?

    • A.El controlador se cargó con insmod en lugar de modprobe, y los módulos cargados así quedan ocultos en /proc/modules
    • B.El controlador está en lista negra, así que el kernel ofrece sus funciones pero no registra el módulo como cargado
    • C.El controlador está compilado dentro de la imagen del kernel y no se carga en caliente, así que no hay módulo que listar✓ Respuesta
    • D.El controlador se carga solo dentro del initramfs, y los módulos cargados allí se descartan tras el switch_root

    Cuando una funcionalidad se selecciona como integrada al compilar el kernel, pasa a formar parte de la propia imagen, por lo que no tiene entrada en /proc/modules ni puede descargarse; solo las funcionalidades construidas como módulos cargables se listan y se quitan. modinfo o el archivo modules.builtin del kernel en uso confirma de cuál de las dos se trata.

    Ref. QB-WKMECFFuente: modinfo(8); Linux kernel Kbuild documentation on built-in versus loadable modulesReportar un problema con esta pregunta

13. 13. El valor de /proc/sys/net/ipv4/ip_forward se cambió con sysctl -w net.ipv4.ip_forward=1 y surtió efecto de inmediato, pero desapareció tras reiniciar. ¿Qué hace persistente ese ajuste?

    • A.Añadir la directiva a /etc/default/grub y regenerar la configuración del gestor de arranque para que el kernel la reciba
    • B.Ejecutar sysctl -p una vez, lo que copia todos los valores actuales dentro de la imagen del kernel para los próximos arranques
    • C.Escribir la directiva en un archivo bajo /etc/sysctl.d/, para que se aplique al arrancar y con sysctl --system después✓ Respuesta
    • D.Editar directamente con un editor el archivo bajo /proc/sys, ya que los archivos editados allí se conservan al reiniciar

    Los archivos bajo /proc/sys son una ventana en vivo a las variables del kernel: una escritura cambia el kernel en marcha y nada más, porque procfs no se almacena en disco. La persistencia viene de la configuración leída al arrancar, es decir los archivos bajo /etc/sysctl.d/ y /etc/sysctl.conf, que sysctl --system vuelve a leer.

    Ref. QB-D4F9SEFuente: sysctl(8) and sysctl.d(5); proc(5) description of /proc/sysReportar un problema con esta pregunta

14. 14. Un equipo quiere un sistema de archivos local cuyo propio diseño permita instantáneas puntuales económicas de un subvolumen y detectar corrupción silenciosa mediante sumas de verificación. ¿Qué tipo lo ofrece?

    • A.ext4, cuyo diario guarda una segunda copia de cada bloque de datos para restaurar un estado anterior cuando se pida
    • B.tmpfs, que mantiene una copia sombra de los datos en memoria y la compara con la copia en disco en cada lectura
    • C.xfs, cuyo asignador basado en extents conserva versiones previas de cada extent para revertir una instantánea
    • D.btrfs, cuyo diseño de copia en escritura escribe bloques nuevos en vez de sobrescribir y verifica datos y metadatos✓ Respuesta

    La copia en escritura implica que un bloque modificado se escribe en otra ubicación mientras el antiguo sigue referenciado, así que una instantánea es solo otra referencia a los bloques existentes y crearla apenas cuesta. Btrfs además guarda sumas de verificación de datos y metadatos, lo que le permite detectar corrupción que el hardware nunca informó. Un diario, en cambio, protege la coherencia de los metadatos tras una caída.

    Ref. QB-XKYRHGFuente: btrfs(5) and btrfs-filesystem(8) documentation, copy-on-write, subvolumes and checksumsReportar un problema con esta pregunta

15. 15. df -h en un servidor muestra un sistema de archivos montado en /run con el tipo tmpfs. ¿Qué es cierto de los datos almacenados allí?

    • A.Se escriben en una partición oculta del disco de arranque y se restauran en /run automáticamente en el siguiente inicio
    • B.Residen en memoria con respaldo de espacio de intercambio y desaparecen al reiniciar, así que nada bajo /run sobrevive✓ Respuesta
    • C.Se guardan en el diario del sistema de archivos raíz y se reproducen en /run cuando la raíz se monta en lectura y escritura
    • D.Son una imagen comprimida extraída del sistema de archivos inicial en RAM que se vuelve a escribir en /boot al apagar

    tmpfs es un pseudosistema de archivos sin dispositivo de bloques detrás: sus páginas se mantienen en la caché de páginas y pueden pasar al espacio de intercambio bajo presión, y todo el sistema de archivos se descarta al desmontarlo o al reiniciar. Esa volatilidad es justo por lo que el estándar de jerarquía sitúa el estado transitorio, como archivos PID y sockets, bajo /run.

    Ref. QB-E4TKXFFuente: tmpfs(5) manual page; Filesystem Hierarchy Standard, /run run-time variable dataReportar un problema con esta pregunta

16. 16. ls -l en /dev produce estas dos líneas: brw-rw---- 1 root disk 8, 0 Sep 1 09:12 sda crw-rw-rw- 1 root root 1, 3 Sep 1 09:12 null ¿Qué indican al administrador el primer carácter y el par de números?

    • A.sda es un dispositivo de bloques y null uno de caracteres, y los números son el mayor y el menor del dispositivo✓ Respuesta
    • B.sda es un dispositivo de respaldo y null uno de caché, y los números son el tamaño de bloque y el total de inodos
    • C.sda es un dispositivo de bus y null uno de consola, y los números son la dirección de bus y la línea de interrupción
    • D.sda es un archivo con búfer y null uno comprimido, y los números son el tamaño del archivo y el conteo de enlaces

    En un listado largo el primer carácter es el tipo de archivo: b marca un dispositivo de bloques al que se accede en bloques de tamaño fijo y c uno de caracteres al que se accede como flujo de bytes. Los nodos de dispositivo no tienen campo de tamaño, así que ls imprime el número mayor, que identifica el controlador, y el menor, que identifica el dispositivo concreto.

    Ref. QB-YKB4QHFuente: Filesystem Hierarchy Standard, /dev device files; ls(1) file types and mknod(2) major and minor numbersReportar un problema con esta pregunta

17. 17. lsblk muestra lo siguiente en un servidor: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 476.9G 0 disk └─nvme0n1p2 259:2 0 475G 0 part / ¿Cómo deben leerse los dos nombres?

    • A.nvme0n1 es la tabla de particiones del primer espacio de nombres y nvme0n1p2 es un segundo disco en el mismo controlador
    • B.nvme0n1 es la vista de bucle invertido de una imagen y nvme0n1p2 son los mismos datos expuestos como bloque crudo
    • C.nvme0n1 es un destino de device mapper y nvme0n1p2 es el disco físico sobre el que se ha superpuesto ese destino
    • D.nvme0n1 es el dispositivo completo y nvme0n1p2 es su segunda partición, como indican el sufijo p y el tipo part✓ Respuesta

    La nomenclatura del kernel distingue el dispositivo de bloques completo de las divisiones que contiene: en NVMe el dispositivo de espacio de nombres recibe una p y un número por cada partición, y en nombres de estilo SCSI o SATA el número se añade directamente, como en sda y sda1. La columna TYPE lo aclara, imprimiendo disk para el dispositivo y part para una partición.

    Ref. QB-F46X4HFuente: lsblk(8); Linux kernel admin-guide documentation on block device and partition namingReportar un problema con esta pregunta

18. 18. Una caja de adquisición de datos aparece como /dev/ttyUSB0 en un arranque y como /dev/ttyUSB1 en el siguiente, según qué adaptador se detecte primero, y un script debe dirigirse siempre a la misma caja. ¿Qué le da un nombre estable?

    • A.Una línea en /etc/fstab que asigne el número de serie del dispositivo a un nombre fijo, leída por el kernel al detectarlo
    • B.Una entrada en /etc/modprobe.d que fije el controlador a un puerto, para que el kernel numere siempre primero ese adaptador
    • C.Una regla en /etc/udev/rules.d que coincida con los atributos propios del dispositivo y le cree un SYMLINK fijo✓ Respuesta
    • D.Una directiva en /etc/sysctl.d que fije el orden de numeración que usa el kernel al enumerar los dispositivos USB

    Los números de dispositivo del kernel se asignan por orden de detección y por tanto no son estables. El gestor de dispositivos recibe un evento por cada dispositivo que aparece y evalúa sus archivos de reglas, así que una regla que coincida con atributos propios de esa unidad, como fabricante, modelo y número de serie, puede crear un enlace simbólico predecible; udevadm info muestra los atributos disponibles.

    Ref. QB-RKURG9Fuente: udev(7) rules files in /etc/udev/rules.d and udevadm(8)Reportar un problema con esta pregunta

19. 19. Una tarjeta de red recién instalada no se puede usar e ip link no muestra ninguna interfaz asociada. lspci -k imprime la entrada de la tarjeta con las líneas Subsystem y Kernel modules, pero sin la línea "Kernel driver in use". ¿Qué indica eso?

    • A.La tarjeta falló su autoprueba de encendido, el firmware deshabilitó la ranura y el sistema operativo no puede reclamarla
    • B.Ningún controlador ha reclamado el dispositivo: el módulo falta, está en lista negra o no viene con el kernel en uso✓ Respuesta
    • C.La interfaz existe pero está administrativamente desactivada, el controlador la liberó y no informa de su nombre
    • D.El bus PCI se quedó sin direcciones, así que el kernel enumeró la tarjeta pero no pudo asignarle ningún recurso

    lspci -k imprime el controlador enlazado a cada dispositivo en la línea "Kernel driver in use", y su ausencia significa que el kernel ve el hardware pero nada se le ha vinculado. Las causas habituales son un módulo no instalado para este kernel, una entrada de lista negra en /etc/modprobe.d o un rechazo de firma con Secure Boot; dmesg revela cuál fue.

    Ref. QB-84PKW8Fuente: lspci(8), the -k option reporting kernel drivers and modules handling each deviceReportar un problema con esta pregunta

20. 20. La instalación de un paquete en un servidor se rechaza con un mensaje de que la arquitectura del paquete no coincide con el sistema. ¿Qué comando identifica la arquitectura que deben compartir el kernel y los paquetes?

    • A.uname -r, que imprime la versión del kernel en ejecución y con ella la arquitectura para la que se compiló
    • B.uname -m, que imprime el nombre de hardware de la máquina del kernel en ejecución, como x86_64 o aarch64✓ Respuesta
    • C.lsblk -f, que imprime la arquitectura registrada en los metadatos del sistema de archivos de la raíz
    • D.dmesg -T, que imprime la arquitectura que el firmware informó al kernel al comenzar este arranque

    uname -m informa del nombre de hardware de la máquina, que es la cadena de arquitectura para la que se compilan los paquetes binarios y los del kernel, y lscpu muestra lo mismo con más detalle. Un paquete construido para otra arquitectura no puede ejecutarse en este kernel, por lo que el gestor de paquetes lo rechaza en lugar de instalarlo.

    Ref. QB-KD9MM3Fuente: uname(1) machine hardware name; lscpu(1); rpm and dpkg package architecture matchingReportar un problema con esta pregunta

Preguntas de práctica redactadas según los objetivos publicados del examen CompTIA Linux+ y la práctica estándar de administración de Linux. CompTIA y Linux+ son marcas de CompTIA, y Linux es una marca registrada de Linus Torvalds; este sitio no está afiliado ni respaldado por CompTIA. El examen real combina preguntas de opción múltiple con preguntas basadas en desempeño que piden ejecutar una tarea en un entorno simulado: eso no puede reproducirse en un formato de cuatro opciones, así que este banco cubre la mitad teórica y conviene practicar en un sistema real en paralelo. CompTIA revisa y numera las versiones de los objetivos periódicamente: confirma los objetivos, el código de examen y los requisitos vigentes con CompTIA antes de examinarte. Sobre la certificación CompTIA Linux+ →