Невозможно открыть виртуальную консоль 7 (Permission Denied) при попытке запустить X на Gentoo
Другая мысль - перезагрузиться с помощью загрузочного диска, получить root shell, смонтировать все разделы и затем выполнить cp -r старых данных в новое место, затем выполнить синхронизацию и размонтировать все разделы и перезагрузиться. BTW, вы также можете изменить таблицу /etc/fstab, чтобы сделать все так, как вам нужно на смонтированном корневом разделе (а не в загрузочном /etc/fstab).
После этого перезагрузитесь, и все будет хорошо.
startxотлично работает в моей системе (Fedora ). Однако на одной устаревшей странице Gentoo Wiki упоминается другой способ запуска :
startx /usr/bin/i3 -- vt1
1— это номер «терминала», на котором вы вошли в систему. Если вы не находитесь на клемме 1, измените команду соответствующим образом.
По-видимому, это исправило ошибку Permission deniedи позволило X запуститься.
Я не понимаю, зачем startxэто нужно передавать явно. Я не понимаю, как Gentoo может делать здесь что-то отличное от Fedora. Ну что ж. По крайней мере, это должно остановить startx/ Xorgот попыток открыть tty7. Это был определенно не современный способ делать что-то, и он не работал на вас.
Cannot open virtual console (Permission denied) также может быть вызвано проблемой разрешения на /dev/ttyX.
Например, на моем openSUSE MicroOS перед входом в систему:
$ ls -l /dev/tty1
crw--w---- 1 root tty /dev/tty1
, но после входа в систему:
$ ls -l /dev/tty1
c--xr-xr-T 1 $USER tty /dev/tty1
Утилита loginменяет владельца телетайпа, чтобы вы могли вводить текст. Однако в этом случае также меняются права доступа и чтение -и запись больше не разрешены! Таким образом, startxпоказывает ошибку отказа в доступе, потому что он не может записывать на устройство.
Обходной путь
Изменить разрешение телетайпа перед startx. В моем.zprofile:
# Auto-start Xorg when logging in on TTY1
check_tty() {
local temp=$(tty)
echo ${temp:5}
}
if [ $(check_tty) = "tty1" ]; then
chmod 1600 /dev/tty1 # Notice the permission change before startx
exec startx
fi
Возможная причина
Мне не удалось найти точную причину проблемы. Это может быть связано с systemd-logind, так как у меня такая же проблема с владением, как этот отчет и этот , когда startxтерпит неудачу.
Я также исследовал PAM и udev, но, похоже, ничего не меняет режим /dev/ttyна 1155, хотя это и происходит на практике!