LINUX.ORG.RU

Не работает Virtual Box

 ,


0

1

У меня с некоторых пор в Gentoo не стартует Virtual Box. Выдает вот такую ошибку:

VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen("/usr/lib64/virtualbox/VBoxRT.so",) failed: <NULL>

VirtualBox: Tip! It may help to reinstall VirtualBox.
Что самое удивительное, на работе стоит такая же Gentoo с такими же USE-флагами, в ней все в порядке. Пробовал как переустанавливать, так и переименовывать каталоги с настройками (~/.VirtualBox и ~/Virtualbox Templates), не помогает. Вот мой emerge --info. Вы не могли бы мне помочь разобраться, в чем может быть причина?

★★★★★

Ответ на: комментарий от Pinkbyte

Вряд ли. Я опасаюсь изменять права у системных файлов. Кроме того, я его полностью сносил недавно и заново компилил с нуля. Но это не помогло. Я не понимаю, как на работе работает, а дома нет, хотя одинаковые конфигурации, и я дома ничего не изменял.

Rinaldus ★★★★★ ()
Ответ на: комментарий от anonymous

На текущий момент да: 4.15.12. Конфиги разные, естественно. Потому что железо разное.

Rinaldus ★★★★★ ()

Собирал или бинарный ставил?

А вообще проверь диск на ошибки. В инете у одного из-за этого такая проблема была.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от Rinaldus

Посмотрите от чего эта библиотека зависит и есть ли все необходимые зависимости в системе.

andreyu ★★★★★ ()
Ответ на: комментарий от Kron4ek
	linux-vdso.so.1 (0x00007ffcaedbb000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f1f09990000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f1f09778000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1f09558000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f1f09350000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f1f09148000)
	libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f1f08de0000)
	libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007f1f08b68000)
	libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f1f088f8000)
	libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f1f084b8000)
	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libstdc++.so.6 (0x00007f1f080b0000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 (0x00007f1f07e98000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f1f07ad0000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1f0a0a0000)
	libicuuc.so.60 => /usr/lib64/libicuuc.so.60 (0x00007f1f07718000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f1f073c8000)
	libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f1f07178000)
	liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f1f06f68000)
	libicudata.so.60 => /usr/lib64/libicudata.so.60 (0x00007f1f053b8000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f1f051a0000)
Rinaldus ★★★★★ ()
Ответ на: комментарий от sehellion

Получилось! У меня /usr принадлежал каком-то левым 999:kdm. И /usr/lib64 тоже принадлежал 999/kdm. Я исправил на root:root и все заработало. Только я не могу понять, кто поменял права на системные каталоги, когда это было сделано и почему? Я лично не делал этого. По всей видимости, это сделал какой-то кривой ебилд. P.S. /etc /sbin /lib /lib64 /var принадлежа сейчас тем же 999:kdm

Rinaldus ★★★★★ ()
Последнее исправление: Rinaldus (всего исправлений: 1)
Ответ на: комментарий от Rinaldus

принадлежал каком-то левым

А rkhunter и chkrootkit не гонял? Прогони для спокойствия души.

SergeySVold ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.