Anteriormente, en varias cajas con Ubuntu 16.04 ejecutándose, he estado usando
sudo systemctl isolate multi-user.target
para ingresar a CLI desde el modo gráfico.objetivo. O he estado usando
sudo systemctl set-default multi-user.target
para permitir que el proceso de arranque se detenga permanentemente en modo multiusuario. Puedo recordar que funcionó hace aproximadamente medio año, pero cuando lo probé hoy, no funcionó en ninguno de los dos sistemas 16.04 completamente actualizados que tenía disponibles hasta la fecha.
Todo lo que me saluda es un cursor parpadeante que no responde. Sin embargo, afortunadamente, es posible cambiar TTY a través de CTRL+ ALT+ F2para poder volver al modo gráfico.objetivo.
Estoy tratando de averiguar si se trata de un error reciente o si introduje algún software conflictivo. No estoy seguro de qué buscar ni dónde buscarlo.
Ambas cajas están usando la versión del kernel.
4.4.0-134-generic #160-Ubuntu SMP Wed Aug 15 14:58:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
¡Me alegraría mucho recibir orientación o confirmación de error!
Respuesta1
¡Acabo de tener el mismo problema! Se solucionó usando el comando:
systemctl enable getty@tty2
Obliga a la máquina a utilizar tty2 de forma predeterminada en el arranque.
Espero que esto te ayude tanto como me ayudó a mí.
Respuesta2
Mary Jane, mi experiencia confirma la tuya. Tengo media docena de sistemas en mi red que fueron configurados de forma predeterminada en modo multiusuario y han continuado funcionando según lo previsto durante más de dos años, todavía lo están y parecen no verse comprometidos por los ciclos regulares de apt-get-upd-upg. . Sin embargo, después de realizar instalaciones limpias de Xubuntu 16.04.6 en dos máquinas nuevas, aparece la siguiente respuesta de error:
systemctl habilitar multiusuario.objetivo
Los archivos de la unidad no tienen configuración de instalación (WantedBy, RequiredBy, También, configuración de Alias en la sección [Instalar] y DefaultInstance para unidades de plantilla). Esto significa que no deben habilitarse mediante systemctl. Las posibles razones para tener este tipo de unidades son: 1) Una unidad puede habilitarse estáticamente mediante un enlace simbólico desde el directorio .wants/ o .requires/ de otra unidad. 2) El propósito de una unidad puede ser actuar como ayuda para alguna otra unidad que dependa de ella. 3) Una unidad puede iniciarse cuando sea necesario mediante activación (socket, ruta, temporizador, D-Bus, udev, llamada systemctl con script, ...). 4) En el caso de unidades de plantilla, la unidad debe habilitarse con algún nombre de instancia especificado.
Luego probé una instalación completamente nueva en otro sistema, y esta vez pareció aceptar 'systemctl enable multi-user.target --force'. Sin embargo, cuando reinicié, había bloqueado completamente la partición (es decir, reinicio completo, seguido de una pantalla en blanco). Me he dado cuenta de que casi no ha habido publicaciones de personas que hayan encontrado este problema y no puedo encontrar soluciones.
Hablando subjetivamente, solo para que conste, cuando Ubuntu decidió obligar a su comunidad de usuarios a aceptar systemd, y más tarde, 'snapd', dejé de usar cualquier nueva versión de ubuntu posterior a la 16.04. Fue solo recientemente, mientras consideraba pasar a 18.04, que decidí reevaluar 16.04.6 y la versión más reciente de 18.04. Estoy muy cerca de abandonar Ubuntu por completo. Esta situación particular puede haber sido la gota que colmó el vaso para mí.