Instale programas de 64 bits en un sistema operativo de 32 bits con un procesador de 64 bits

8

Soy curioso. ¿Es posible instalar un programa de 64 bits en un sistema operativo de 32 bits con un procesador de 64 bits?

Estoy ejecutando Linux en una frambuesa pi 3 e intento instalar una versión más nueva de MongoDB:

armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian

— Crellee
fuente

1

Considere usar un sistema operativo de 64 bits en su lugar. Raspbian está muy atrasado en los tiempos; Fedora de 64 bits ya está disponible para el RPi3 .

— Michael Hampton

19

¿Es posible instalar un programa de 64 bits en un sistema operativo de 32 bits con un procesador de 64 bits?

En principio sí, pero el procesador y el sistema operativo deben admitirlo.

En ARMv8, un kernel de 32 bits (Aarch32) no puede ejecutar procesos de 64 bits (Aarch64). Esta es una limitación del procesador.

Hay otros procesadores que no tienen esta limitación, por ejemplo, es posible ejecutar procesos x86_64 sobre un núcleo x86_32 en un procesador x86_64, pero pocos núcleos lo admiten, presumiblemente porque es de utilidad limitada (principalmente, guarda un bit de RAM en el kernel haciéndolo de 32 bits). Linux no lo admite, pero Solaris sí.

Puede mantener su sistema operativo de 32 bits existente si ejecuta un núcleo de 64 bits . Un kernel de Linux Aarch64 puede ejecutar procesos Aarch32. Raspbian no admite esto de forma inmediata, por lo que necesitaría mantener un SO de 32 bits y un SO de 64 bits. Puede usar uno como el sistema operativo principal (es decir, el que ejecuta init y los servicios del sistema) y el otro para ejecutar un programa específico usando chroot. Consulte ¿Cómo ejecuto programas de 32 bits en un Debian / Ubuntu de 64 bits? para un enfoque práctico.

Tenga en cuenta que deberá instalar todas las bibliotecas que requiere el programa de 64 bits. Cualquier proceso debe ser de 32 bits o de 64 bits, por lo que no puede utilizar una biblioteca de 32 bits en un ejecutable de 64 bits.

A menos que tenga buenas razones para mantener un sistema de 32 bits, si necesita ejecutar un archivo ejecutable de 64 bits, sería más fácil instalar un sistema de 64 bits.

Tenga en cuenta que lo único que pueden hacer los programas de 64 bits, pero los programas de 32 bits no pueden abordar más de aproximadamente 3 GB de memoria virtual, que es de utilidad limitada en un sistema con 1 GB de RAM. Puede obtener beneficios de rendimiento de los registros adicionales más grandes, pero también perderá el rendimiento de los accesos de memoria adicionales.

— Gilles 'SO- deja de ser malvado'
fuente

3

@Wildcard En pocas palabras, en cualquier momento dado, el procesador está en modo de 32 bits ("estado de ejecución de Aarch32") y esperando instrucciones de Aarch32, o en modo de 64 bits esperando instrucciones de Aarch64. La única forma de cambiar de modo es cambiar entre proceso y núcleo (o núcleo e hipervisor, o hipervisor y monitor). Cambiar a un modo de privilegios más bajos no puede cambiar de 32 bits a 64 bits, y cambiar a un modo de privilegios más altos siempre restaura el modo anterior. Por lo tanto, es imposible hacer arreglos para que un código de 32 bits se ejecute con un privilegio mayor que el código de 64 bits.

— Gilles 'SO- deja de ser malvado'

2

@Wildcard (cont.) Presumiblemente, la razón de esta restricción es que hay bastante estado de procesador específico de Aarch64 y que el código Aarch32 no puede acceder. Por ejemplo, un núcleo Aarch32 no podría guardar los registros de un proceso Aarch64.

— Gilles 'SO- deja de ser malvado'

2

@crellee, Gilles: No es necesario mirar sistemas operativos exóticos para encontrar ejemplos de núcleos de 32 bits con tierras de usuario de 64 bits. Los núcleos extremadamente populares Mac OS X 10.4 "Tiger", 10.5 "Leopard" y 10.6 "Snow Leopard" se enviaron en la configuración K32 para casi todas las Mac, excepto para algunas máquinas de servidor que pudieron arrancar K64 de Snow Leopard , pero todas eran capaces de ejecutar procesos de usuario de 64 bits (con progresivamente menos restricciones).

— Iwillnotexist Idonotexist

3

@Serge: lo que describe es cierto para 286 -> 386: puede usar un tamaño de operando de 32 bits en modo real de 16 bits con prefijos, donde el tamaño de operando predeterminado es 16. Pero Intel ni siquiera desarrolló x86-64; ese era AMD (que es por eso que a veces todavía se llama AMD64). Y no, no puede usar el tamaño de operando de 64 bits en modo de 32 bits, en absoluto. Los prefijos REX reutilizan los códigos de operación de un byte inc/ decregistro ( 0x40 .. 0x4F). En modo largo (modo de 64 bits), el tamaño de operando predeterminado es 32, pero el tamaño de dirección predeterminado es 64.

— Peter Cordes

2

@Wildcard: IDK si el espacio de usuario de kernel en modo compatible / modo largo era una consideración de diseño en absoluto. Para guardar el estado de registro de enteros para los conmutadores de contexto, Solaris (y OS X) aún debe estar en modo largo para acceder a r8-r15 y las mitades superiores de rax-rsi. IDK si xsave/ xrstoren modo compat puede guardar el estado vectorial completo, tampoco. Por lo tanto, ciertamente no está bien soportado o explícitamente atendido. Probablemente los puntos de entrada del kernel se ejecutan en modo de 64 bits (largo) y cambian al modo de 32 bits (compat) antes de saltar al resto del kernel. (El cambio de modo x86 solo toma un far jmpy no afecta las reglas.)

— Peter Cordes

5

En algunas arquitecturas, sí. Pero no en ARM o x86.

Puede usar QEMU para emular un sistema de 64 bits, pero no quiere hacerlo.

— Ignacio Vazquez-Abrams
fuente

¿Sería un desastre utilizar un emulador como QEMU para instalar y ejecutar una base de datos mongo?

— Crellee

Sería muy, muy lento. Y no vale la pena, ya que el RPi3 solo tiene 1GB de RAM. Considere crear un paquete de 32 bits en su lugar.

— Ignacio Vazquez-Abrams

2

Puede ejecutar un programa de 64 bits sobre un núcleo de 32 bits en x86 si el núcleo lo admite. Linux no, pero Solaris sí. En el brazo no es posible.

— Gilles 'SO- deja de ser malvado'

@ IgnacioVazquez-Abrams Prueba esto. Es lento, pero no catastróficamente. La razón principal es que qemu emula la CPU solo en el espacio del usuario, las llamadas al kernel (es decir, los tiempos de espera io) permanecen igual. En los sistemas hogareños, me gusta usar binarios de arm o mips para algunas herramientas, solo por diversión :-) O, a veces, si no hay una carga de CPU muy grande, algunas herramientas críticas para la seguridad, pero no intensivas en CPU podrían usar algunas arquitectura exótica, para disminuir la probabilidad de ataques de desbordamiento de búfer.

— peterh - Restablece a Mónica el

4

Actualice solo su kernel a uno de 64 bits, para que pueda ejecutar binarios de 64 bits. Esencialmente, ejecutará toda su distribución en modo de compatibilidad de 32 bits, y su único mongodb de 64 bits será su modo normal.

Pero no merece su precio. Es mejor cambiar su mongodb a 32 bits. Sin embargo, en este caso hay una limitación, que su base de datos no puede ser más grande que 2GB, ya que mapea directamente todo en la memoria virtual. Si su base de datos es más grande, solo queda la actualización del núcleo. (¡Gracias @duskwuff la extensión!)

Por cierto, si su base de datos no quiere una carga muy grande, o puede usar alguna solución de almacenamiento en caché antes (por ejemplo: otra, pero mongo de 32 bits), entonces una emulación de CPU podría funcionar. Para eso, comience a buscar en Google "qemu qemu-system-x86_64". Aunque tal solución probablemente tendría una necesidad de trabajo inviable y podría considerarse extraña en un entorno productivo.

En su lugar, usaría mongo de 32 bits si es suficiente para mi base de datos, o un núcleo de 64 bits si no lo es.

— peterh - Restablece a Monica
fuente

Tiene sentido, pero ¿cómo cambiarías tu mongodb a 32 bits?

— Crellee

@crellee apt-get install mongodb:i386o algo similar?

— peterh - Restablece a Monica el

eso devolverá un error 'No se puede localizar el paquete mongodb: i386'

— crellee

1

Ejecutar un MongoDB de 32 bits es una mala idea. La base de datos está mapeada en memoria, por lo que ejecutarla en un sistema de 32 bits lo limita a <2 GB de datos.

— duskwuff -inactive-

Sí, y está limitado a la versión 2.4.14, que tiene muchas limitaciones.

— Crellee

3

Yo diría que no es imposible, pero realmente difícil de manejar. Dado que un sistema operativo de 32 bits suele estar empaquetado (y acepta) solo binarios y bibliotecas de 32 bits, necesitará modificar mucho el sistema para que funcione con los de 64 bits.

El principal problema que enfrentaría con un RPI3 es la falta de núcleo de 64 bits (al menos con raspbian).

Larga historia corta: use binarios de 32 bits y estará bien.

EDITAR:

Si desea utilizar un núcleo de 64 bits, deberá instalar una distribución que admita la arquitectura ARM64. Debería echar un vistazo a ArchLinux ARM ( aquí ), pero no es totalmente compatible.

La información que está buscando se encuentra en la parte inferior de la pestaña de instalación.

También puede echar un vistazo a un puerto oficial de Debian , sin embargo, todavía hay grandes problemas con el puerto RPI3, por lo que depende de usted decidir si vale la pena.

El problema es que la CPU se inicia (por el núcleo) en modo de 32 bits, por lo que parece una máquina vieja de 32 bits. Los registros e instrucciones de 64 bits no están disponibles.

— Johan Myréen

1

Correcto, por eso necesitarías un núcleo de 64 bits (que Thomas mencionó).

— Stephen Kitt

Gracias por la buena explicación. Entonces, ¿la solución para mí sería instalar otro sistema operativo en mi RPI3?

— Crellee

Acabo de actualizar mi respuesta.

@ Thomas, algunas distribuciones admiten la operación combinada de 32/64 bits, comenzando con la variante de 32 bits. Debian es un ejemplo, al menos en x86: puede instalar la i386variante, y eso incluye un núcleo de 64 bits, que también permite la instalación de bibliotecas y binarios de 64 bits. Sin embargo, el soporte ARM en Debian no permite esto en los sistemas ARM (pero puede instalarlo combinado arm64y armhf, si comienza con arm64).

— Stephen Kitt

1

He usado un núcleo de 64 bits con un sistema de 32 bits durante bastante tiempo (ese es el requisito previo mínimo para ejecutar ejecutables de 64 bits de forma nativa, además de todas las bibliotecas de 64 bits necesarias). Yo no lo recomendaría. Lo que finalmente me hizo actualizar a un sistema de 64 bits al por mayor fue la constatación de que los encabezados ALSA, particularmente con respecto a las llamadas Midi ioctl, no eran independientes del tamaño, lo que significa que las cosas compiladas en modo de 32 bits no interactuarían bien con el núcleo de 64 bits.

Por supuesto, esto puede considerarse un error que vale la pena corregir, pero el ritmo del desarrollo de ALSA está casi congelado y no podía esperar unos años para que se solucione el soporte de plataforma mixta (y de una manera no binaria compatible para no mezclado ejecutables) cuando el interés en plataformas mixtas está disminuyendo rápidamente de todos modos.

Para algunas aplicaciones, las cosas funcionan en modo mixto (sorprendentemente mucho en realidad), pero si está haciendo más que la parte básica de la interfaz con el núcleo, incluso a través de bibliotecas externas, es demasiado optimista.