Автор Тема: Ещё несколько вопросов по выбору ПО  (Прочитано 15707 раз)

Оффлайн Иван Светлов

  • Завсегдатай
  • *
  • Сообщений: 56
Цитировать
А зачем у Вас установлен kernel-modules-virtualbox?
Когда устанавливал Альт, он предложил поставить виртуализацию. Я поставил (иногда вложенные виртуалки делаю). Может быть поэтому установлен. На данной ВМ Virtualbox'ом не пользовался.

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Эта строка очевидна
Цитировать
(EE) open /dev/dri/card0: No such file or directory

А эта не совсем
Цитировать
(EE) Unable to find a valid framebuffer device
Она появляется когда отсутствует файл фреймбуфера /dev/fb0

2. На какие дистрибутивы Альт распространяется проблема?

На HD Graphics 5500 (Broadwell GT2) не распространяется, в alt-p9-xfce-sysv-20191212-x86_64 не проявляется, но может быть вызвана искусственно выключением kms.
Что гарантированно приведёт сбою
# grep 'EE' Xorg.0.log.nomodeset
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    27.139] (EE) open /dev/dri/card0: No such file or directory
[    27.139] (EE) open /dev/dri/card0: No such file or directory
[    27.150] (EE) Unable to find a valid framebuffer device
[    27.151] (EE) open /dev/fb0: No such file or directory
[    27.151] (EE) Screen 0 deleted because of no matching config section.
[    27.151] (EE) Screen 0 deleted because of no matching config section.
[    27.407] (EE) AIGLX: reverting to software rendering

в попытке использовать VESA
# grep -i vesa Xorg.0.log.nomodeset
[    26.969] (==) Matched vesa as autoconfigured driver 2
[    27.128] (II) LoadModule: "vesa"
[    27.129] (II) Loading /usr/lib/X11/modules/drivers/vesa_drv.so
[    27.136] (II) Module vesa: vendor="X.Org Foundation"
[    27.136] (II) VESA: driver for VESA chipsets: vesa
...
[    27.272] (**) VESA(0): *Built-in mode "1366x768"
[    27.272] (**) VESA(0): Display dimensions: (340, 190) mm
[    27.272] (**) VESA(0): DPI set to (102, 102)
[    27.272] (**) VESA(0): Using "Shadow Framebuffer"
[    27.283] (II) VESA(0): initializing int10
[    27.283] (II) VESA(0): Primary V_BIOS segment is: 0xc000
[    27.284] (II) VESA(0): VESA BIOS detected
[    27.284] (II) VESA(0): VESA VBE Version 3.0
[    27.284] (II) VESA(0): VESA VBE Total Mem: 32704 kB
[    27.284] (II) VESA(0): VESA VBE OEM: Intel(R) HSW Mobile/Desktop Graphics Chipset Accelerated VGA BIOS
[    27.284] (II) VESA(0): VESA VBE OEM Software Rev: 0.0
[    27.284] (II) VESA(0): virtual address = 0xb518d000, VGAbase = 0xb517d000
[    27.294] (II) VESA(0): Setting up VESA Mode 0x17F (1366x768)
[    27.381] (==) VESA(0): Default visual is TrueColor
[    27.398] (==) VESA(0): Backing store enabled
[    27.398] (==) VESA(0): DPMS enabled

Оффлайн Иван Светлов

  • Завсегдатай
  • *
  • Сообщений: 56
Цитировать
удалить kernel-modules-staging
Не удаётся. Делал apt-get remove kernel-modules-staging* через sudo и от имени root'а.
« Последнее редактирование: 31.12.2019 10:44:50 от Иван Светлов »

Оффлайн Иван Светлов

  • Завсегдатай
  • *
  • Сообщений: 56
Speccyfighter, у меня вылезало сообщение "cannot run in framebuffer mode. please specify busids for all framebuffer devices"
Что в итоге всё это значит (не конкретное сообщение про framebuffer, а проблема с загрузкой в целом)?

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Пользователь становится владельцем фреймбуфера
# ll /dev/fb0
crw------- 1 user video 29, 0 дек 31 09:03 /dev/fb0

при открытой X-сессии (tty8; DISPLAY=:0) и ещё не открытой сессии tty*
# who
user     tty8         2019-12-31 09:03 (:0)
root     pts/1        2019-12-31 09:04 (localhost)

root     pts/1 - это root-сессия в X-терминале:
# ll /dev/pts/1
crw------- 1 root tty 136, 1 дек 31 09:04 /dev/pts/1

Поэтому /dev/fb0 обязан быть.

Права на фреймбуфер, в альтах, по крайней мере на sysv, делегируются в
/etc/security/console.perms.d/50-default.perms
В альтах они сконфигурированы неверно и исправлять это альты отказываются и не будут.
(При неверно сконфигурированых правах в альтах, монопольный захват фреймбуфера. После того как пользователь становтся владельцем фреймбуфера, возможно получение доступа к фреймбуферу через группу, но делегирования прав доступа через группу, в альтах нет. По причине неверной конфигурации сделанной альтами, - доступ через группу возможен, при отсутствии конфигурации доступа по группе. И делегирование прав в альтах невозможно. По причине того, что альты на это поклали болт.)

Т.е. фреймбуфер необходим и файл устройства должен быть в наличии
# grep fb /var/log/Xorg.0.log
"Default Screen Section" for depth/fbbpp 24/32
[  1055.335] (II) Loading sub module "fb"
[  1055.335] (II) LoadModule: "fb"
[  1055.335] (II) Loading /usr/lib64/X11/modules/libfb.so
[  1055.341] (II) Module fb: vendor="X.Org Foundation"

А у вас лог, говорит альтам: "Сам испёк, сам и кушай":
[    53.666] (EE) Unable to find a valid framebuffer device
Невозможно найти устройство фреймбуфера
(/dev/fb0)
« Последнее редактирование: 31.12.2019 12:28:24 от Speccyfighter »

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 5 183
  • antohami@
Не удаётся. Делал apt-get remove kernel-modules-staging* через sudo и от имени root'а.

Удалите только для последнего ядра, введя его полное название.

Оффлайн K0T

  • Завсегдатай
  • *
  • Сообщений: 215
  • Simply 7.0.5
    • Email
Цитата: Иван Светлов
Делал apt-get remove kernel-modules-staging* через sudo и от имени root'а.

а тут разница между sudo и su роли не играет?

Оффлайн Иван Светлов

  • Завсегдатай
  • *
  • Сообщений: 56
Цитировать
Думаю, имеет смысл удалить kernel-modules-staging и установить  kernel-modules-virtualbox-addition-guest-std-def  kernel-modules-virtualbox-addition-std-def  kernel-modules-virtualbox-addition-video-std-def. Предварительно, выполнив update-kernel. А после установки модулей make-initrd. После чего пробовать грузиться с последним ядром.
Проделал всё это на виртуалке. Всё что падало при старте, упало снова.

Оффлайн Koi

  • alt linux team
  • ***
  • Сообщений: 1 893
  • валар дохаэрис
    • Канал на youtube
Зачем от руки делать если есть скрипт.
Удаление старых версий ядра

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Зачем от руки делать если есть скрипт.
Удаление старых версий ядра

:-) Например такой скрипт удалит все старые ядра, включая и те, которые скомпиллированы без wdat_wdt. Что на некоторых архитектурах, на которых таблица WDAT обращается к RTC SRAM, приведёт к исчезновению /dev/rtc* и соответственно к отказу установки времени BIOS. Возможны и какие-то другие регрессии. Это как пример того, что удалять старые ядра нужно вдумчиво.