Slackware, VirtualBox, VT-x is not available (VERR_VMX_NO_VMX).

Вот она, знаменитая ванилька, которую вечно портят тупые ментейнеры.

Подсмотри как в дебиане собрали с какими патчами и напиши свой слакбилд. Универсальный рецепт для слаки. Пригодится опыт в любом случае, еще много раз на такое нарвешься.

Из Debian вообще-то Virtualbox как раз выкинули. И теперь действительно - его не портят ментейнеры

Да, теперь каждый сам себе мамкин ментейнер. И вместо работы будешь его неделю заводить. Тру-красноглаз-вей.

Может надо еще ядро пересобрать. Ванилька же, энжой.

Где именно? В репах его нет, можно только скачать бинарник с оффсайта.

Старшие, ноутбучные core2 duo , продаются по барахолкам от 800 до 2000 рублей.

Откуда брался VirtualBox? У меня установлен уже собранный из slackonly, всё работает.

[ Status           ] [ Repository               ] [ Package                                  ]   
   installed           slackonly                    virtualbox-extension-pack-4.3.24-x86_64-1_slack   
   installed           slackonly                    virtualbox-kernel-4.3.24_3.10.17-x86_64-1_slack  
   installed           slackonly                    virtualbox-4.3.24-x86_64-1_slack

Может быть VB с каким-то ещё софтом конфликтует? Что ещё установлено в системе?

А там их так просто заменить? Был уверен, что в ноуты их впаивают.

С высокой вероятностью Socket P. У меня дешевый ноут, там такой сокет. Можно почистить от пыли и заодно убедится что сокет в наличии.

Где именно? В репах его нет

В старых релизах смотри. Как он у тебя работал то в дебиане? Ты качал что ли бинарник? И та же версия не пашет в слаке? Щначит копай в сторону ядра.

В свойствах vm c "VT-x" галку сними.

1. Какой именно процессор, есть ли поддержка VT-x?
2. https://zachzimm.com/blog/?p=162 Но снять галку в интерфейсе в свойствах ВМ проще.

Кажется, нашёл суть проблемы.

Из описания шлякбилда:

On x86_64, this by default builds without software virtualization. This means you need hardware virtualization in order to run 32bit guests on 64bit hosts. To enable software virtualization, pass SOFTWARE_VIRTUALIZATION=yes to the script. Note that this will require a compiler that can generate 32bit code, and thus will not build on a stock x86_64 system. This switch has no effect on x86 systems.

Причём эта переменная ещё и не работает, там на амд64-системах захардкожена другая переменная - sw_virt. Сейчас проверим.

Да, пересборка помогла. Странно всё это. Зачем надо было выключать эту опцию.

Эта вкладка нерабочая.

Зачем надо было выключать эту опцию

Это шлака, сынок. Здесь чудеса, тут леший бродит...

Зачем надо было выключать эту опцию

Если в двух словах, slackbuilds.org поддерживает стоковые конфигурации Slackware, а вариант с мультилибом таковым не является. На стоковой x64 иначе настроенный слакбилд просто не соберется.

Но никто не запрещает дополнительные возможности выносить под управление флагов, что и было сделано.

Собственно, в описании слакбилда тоже прямо написано, зачем:
Note that this will require a compiler that can generate 32bit code, and thus will not build on a stock x86_64 system.

Да, с мультилибом я уже намаялся. Каждый второй СлакБилд без бубна не собирается.

с мультилибом я уже намаялся. Каждый второй СлакБилд без бубна не собирается

Гипербола? Нет большого смысла собирать в 32 бита всё подряд, а не только то, что в системе какому-то closed souse софту нужно.

Возможно, я в последнее время собирал в основном системные библиотеки вроде jack или celt, которые настойчиво пытаются линковаться с /usr/lib64.

jack или celt, которые настойчиво пытаются линковаться с /usr/lib64

Это после подготовки сборочной среды при помощи dev32.sh?

# . /etc/profile.d/32dev.sh

Был уверен, что в ноуты их впаивают.

Не в таких старых. «два ядра@два гига» не впаивали точно, а вот современные i{357} — могут и впаять.

Насколько я понял, этот скрипт нужен для сборки 32-битных пакетов, а у меня ситуация немного другая: мне эти 32-битные пакеты мешают собирать нативные. Проблема, в принципе, решается просто - правкой одной переменной в скрипте, но приходится каждый раз править руками.

Значит, я неправильно понял проблему по описанию. Ведь если на x86_64 кто-то настойчиво линкуется к /usr/lib64 (что норма для 64-битных) и это неправильно, то речь скорее всего про 32-разрядные сборки и необходимость /usr/lib вместо /usr/lib64.

Иногда собираемое ожидает увидеть в /usr/lib библиотеки, соответствующие разрядности системы — тут приходится править правила сборки. Но наличие/отсутствие мультилиба на это не влияет, просто разработчик не предусмотрел вариант разделения библиотек на /usr/lib64 и /usr/lib вместо какого-то другого, используемого в его системе, в Makefile-ах пути /usr/lib захардкожены, что и является источником проблемы на Slackware64 и любых других дистрибутивах, имеющих аналогичную схему разделения библиотек разной разрядности.

Судя по тому, что сами создатели Слакбилдс пишут, это типовая проблема на мультилибе:

If you are using multilib packages from somewhere and also have some 32bit packages installed, then you might run into problems with the build process trying to link 32bit libraries instead of 64bit libraries. If this occurs, it can probably be solved by placing the following line:

LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \

after the lines for CFLAGS and CXXFLAGS passed to the configure script. In other words, make it look something like this:

CFLAGS="$SLKCFLAGS" \
  CXXFLAGS="$SLKCFLAGS" \
  LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
  ./configure \

Beyond that, you are on your own. This is an unsupported setup.