Архив метки: Сборка

Linux 5.1 и Nvidia Drivers 418.56

Обновился на днях до ядра 5.1, но драйвера Nvidia 418.56 не собираются с ядром 5.1, а версия 430.09 не работает, выбрасывает при загрузке граф. режима обратно в консоль, что в 5.0.12, что в 5.1.

Поэтому решил допилить 418.56 для работы с новым ядром. На просторах интернета нашёл такую статью, чел расписывает, как заставить 418.43 работать на 5.1-rc1, практически мой случай.

Перевод на русский 🙂

В файлы nvidia-drm-connector.c nvidia-drm-drv.c nvidia-drm-encoder.c nvidia-drm-gem-nvkms-memory.c в самый верх добавляем строчку #include <linux/version.h>

В файл /kernel/nvidia-drm/nvidia-drm-connector.c, примерно в 203 строчку добавляем:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
int drm_helper_probe_single_connector_modes(struct drm_connector
*connector, uint32_t maxX,
uint32_t maxY);
#endif

В файл kernel/nvidia-drm/nvidia-drm-drv.c, примерно в 37 строчку добавляем:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
void drm_kms_helper_poll_init(struct drm_device *dev);
void drm_kms_helper_poll_fini(struct drm_device *dev);
bool drm_helper_hpd_irq_event(struct drm_device *dev);
void drm_kms_helper_poll_disable(struct drm_device *dev);
#endif

В файл kernel/nvidia-drm/nvidia-drm-encoder.c, примерно в 33 строчку добавляем:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
void drm_kms_helper_hotplug_event(struct drm_device *dev);
#endif

и в строчку 161:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
int drm_helper_probe_single_connector_modes(struct drm_connector
*connector, uint32_t maxX,
uint32_t maxY);
#endif

В файле kernel/nvidia-drm/nvidia-drm-gem-nvkms-memory.c (примерно 77 строчка) заменяем

static int nv_drm_vma_fault(struct vm_fault *vmf)

на

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
static int nv_drm_vma_fault(struct vm_fault *vmf)
#else
static vm_fault_t nv_drm_vma_fault(struct vm_fault *vmf)
#endif

В файле kernel/nvidia-uvm/uvm8.c (примерно 176 строка) заменяем

static int uvm_vm_fault_sigbus_wrapper(struct vm_fault *vmf)

на

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
static int uvm_vm_fault_sigbus_wrapper(struct vm_fault *vmf)
#else
static vm_fault_t uvm_vm_fault_sigbus_wrapper(struct vm_fault *vmf)
#endif

и (примерно 515 строчка)

static int uvm_vm_fault_wrapper(struct vm_fault *vmf)

на

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
static int uvm_vm_fault_wrapper(struct vm_fault *vmf)
#else
static vm_fault_t uvm_vm_fault_wrapper(struct vm_fault *vmf)
#endif

Вот и всё, модуль должен собраться. И да, по ссылке еще 2 файла были изменены - в kernel/common/inc/nv-list-helpers.h нужно поменять строку

static inline int list_is_first(const struct list_head *list,

на

static inline int nv_list_is_first(const struct list_head *list,

и файл kernel/nvidia-uvm/uvm8_range_tree.c, нужно поменять строку

if (list_is_first(&node->list, &tree->head))

на

if (nv_list_is_first(&node->list, &tree->head))

Но, это всё нужно делать для драйвера версии 418.43. Я лично это всё поменял, как было написано, компилятор начал ругаться на файл kernel/nvidia-uvm/uvm8_range_tree.c

error: implicit declaration of function ‘nv_list_is_first’; did you mean ‘list_is_first’? [-Werror=implicit-function-declaration]
if (nv_list_is_first(&node->list, &tree->head))
^~~~~~~~~~~~~~~~
list_is_first

Ну я и добавил в самый верх этого файла

#include "../common/inc/nv-list-helpers.h"

и всё прекрасно собралось. Но! После всего этого, я опять полез на сайт того чела и дальше вижу в Recent Post такое - фикс для драйвера версии 418.56. И там английским по белому написано, что для данной версии трогать файлы uvm8_range_tree.c и nv-list-helpers.h на предмет замен строк вообще не нужно. Такие дела 🙂

 

Linux и RTL8811CU

Приехал ко мне из Китая вот такой USB-адаптер на чипе RTL8811CU. Так как я заранее посмотрел, что драйвера для него под Linux есть, плюс умело заборол проблемы с предыдущим чипом от Realtek, больших проблем с его подключением не ждал.

Скачал дровишки отсюда https://github.com/whitebatman2/rtl8821CU, начал компилять, первый раз make ругнулся на файл rtl8821CU/os_dep/linux/rtw_android.c

ошибка: в макрос «access_ok» передано 3 аргументов, но используется только 2
if (!access_ok(VERIFY_READ, priv_cmd.buf, priv_cmd.total_len)) {
^
/home/alex/rtl8821CU/os_dep/linux/rtw_android.c:629:7: ошибка: «access_ok» не описан (первое использование в этой функции)
if (!access_ok(VERIFY_READ, priv_cmd.buf, priv_cmd.total_len)) {
^~~~~

Поэтому я её просто закомментил, раз access_ok не описан. И да, в С коммент строки - //, а не #.

Следующая ошибка была в файле rtl8821CU/os_dep/linux/ioctl_cfg80211.c

ошибка: implicit declaration of function «get_monotonic_boottime»; did you mean «getboottime»? [-Werror=implicit-function-declaration]
get_monotonic_boottime(&ts);
^~~~~~
getboottime

Здесь сам компилятор подсказывает, что get_monotonic_boottime нужно заменить на getboottime.

На этом всё, дальше компиляция проходит без проблем, модуль собрался и работает с ядром 5.0.11

Установка Wi-FI адаптера Mercusys MW300UM на чипе RTL8192EU

Предыстория — после 9 лет работы полетела встроенная сетевая карта на материнской плате. Печально. Нужно покупать новую и всё такое. Тут я вспомнил, что где-то у меня припасена сетевая карта, которую я покупал ещё 10 лет назад. Начал рыться в закромах, и вот она. Сдул с неё многолетнюю пыль, прочитал название — Dlink DFE-520.

Ок, попробуем. Воткнул, включил поддержку в ядре, карточка завелась. Но есть две не совсем приятные вещи — 1 — карта после выхода из сна не подхватывается, какие-то проблемы или с модулем или с самой картой. Ну и скорость. После гигабитной карты чувствуется задержка даже при переключении дорожек в плеере.

Поэтому посетила мысль — а не купить ли Wi-FI адаптер? Открыл свой любимый магазин электроники, начал выбирать. Выбор пал на Mercusys MW300UM, невысокая цена (гигабитная сетевая карта от DEXP стоит столько же, но почитав о чипе, который на ней стоит, перехотел брать), скорость в 300 Мб/с, и высокая мощность передатчика, плюс беспроводное соединение. Почитал про чип — RTL8192EU, в линуксе должен работать, даже судя по комментариям к адаптеру. Отправился в магазин, нашёл адаптер (осталось 2 коробочки), жадно схватил одну и метнулся на кассу. Заплатив бабло и получив чек (кстати, гарантия 3 года), на второй передаче понёсся домой.

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

Итак, воткнув адаптер в комп, запустил lsusb, дабы глянуть, что же известно про этот адаптер. А собственно всего ничего, lsusb выдал вот это:

Bus 002 Device 005: ID 2c4e:0100

Ну ок, мы пойдём другим путём — полезем в гугль. Итак, гугл сообщает, что есть несколько вариантов — собрать модуль из ядра, либо скачать с гитхаба, собрать и присовокупить к ядру.

Конечно, проще собрать модуль самого ядра. Полез в ядро, подключил модуль RTL8XXXU и RTL8XXXU_UNTESTED. Собрал ядро, перезагрузился. Ничего. Модуль не загрузился. Сделал это вручную — всё равно тишина, устройство wlan0 не появилось. Dmesg конечно сыпет сообщениями, что типа устройство подключено, производитель такой-то и всё прочее, но это как-то не помогает обеспечить работу устройства.

Ну ладно, хорошо. Соберём и поставим сторонний модуль. На выбор есть 4 (на самом деле больше):

https://github.com/Mange/rtl8192eu-linux-driver
https://github.com/masterzorag/RTL8192EU-linux
https://github.com/jeremyb31/rtl8192eu-linux-driver
https://github.com/ZeeRooo/RTL8192EU

В общем общем после всех плясок выяснилось одно — в коде модуля нет нашего идентификатора устройства (2c4e:0100), поэтому, даже когда модуль загружался, он не работал с адаптером. Что нужно сделать, чтобы всё было прекрасно? Добавить строчку в исходники. Покажу на примере ядра — в моём случае это 5.0.3 и модуля, который я взял с https://github.com/ZeeRooo/RTL8192EU. И да, в некоторых репозиториях, например jeremyb31 и Mange есть возможность поставить модуль через DKMS, что актуально для пользователей Debian-подобных дистрибутивов.

Но хочу сказать сразу, после добавления в ядро идентификатора, устройство wlan0 появилось, ближайшие сети нашлись, но вот подключиться не получилось. В dmesg сыпались ошибки "rtl8192eu_rx_iqk_path_b: Path B RX IQK failed!" и невозможности аутентификации. Там же была почта, на которую просили написать про работу модуля, что я собственно и сделал, ждём ответа (если он вообще будет).

Итак, модуль ядра. Открываем файл (уже в каталоге с ядром, например /usr/src/linux) drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c и ищем в самом конце такие строчки, (должно быть заглавие #ifdef CONFIG_RTL8192E):

{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0107, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops},

0x2357, 0x0107 — это и есть идентификатор устройства. Добавляем туда такую строчку

{USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0100, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops},

0x2c4e, 0x0100 — это мы взяли из вывода lsusb.

Сохраняем файл, не забываем включить модуль rtl8xxxu и rtl8xxxu_untested и собираем ядро, теперь адаптер будет автоматом подхватываться ядром.

Сейчас соберём сторонний модуль ядра. Я бы рекомендовал качать с https://github.com/ZeeRooo/RTL8192EU, т. к. судя по логам он активно поддерживается.

$ git clone https://github.com/ZeeRooo/RTL8192EU.git

$ cd RTL8192EU

Редактируем файл os_dep/linux/usb_intf.c, в нём так же ищем строчки типа {USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0107, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops}, под заглавием #ifdef CONFIG_RTL8192E, только здесь они практически в самом начале файла.

Добавляем туда нашу строку:

{USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0100, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops},

Ну и дальше

$ make

# make install

Модуль будет называться 8192eu.

После установки модуля, для его загрузки нужно выполнить modprobe 8192eu, или вытащить и вставить адаптер.

И да, если используется сторонний модуль, ядерный модуль (rtl8xxxu) должен быть выгружен и наоборот.

Пока адаптер работает нормально, не глючит, дальше видно будет. Будем посмотреть, будут ли допиливать поддержку в ядре.

Переехал на Nouveau и проблемы с Kmail

Наконец-то избавился от nvidia-drivers. Причин было несколько, например не работал  фреймбуфер при переключении в констоль по Ctrl+Alt+Fn и не работала гибернация, т.е. suspend2ram. С nouveau всё прекрасно работает, за исключением Kmail, он крашится через несколько секунд после запуска. Как пишут на bugs.gentoo.org, нужно задать $CFLAGS и $CXXFLAGS опцию"-fno-delete-null-pointer-checks" и пересобрать пакет QtWebEngine. В данный момент электронный болван гудит, аки пылесос, пересобирая его. Будем посмотреть, поможет или нет.

Debian Stretch и новое ядро на Cubietruck

Сидел как-то я, обновлял Debian на Cubietruck и вдруг в голову пришла мысль - а когда следующая версия? Наверное, в следующем году должна выйти. Полез в Википедию, удовлетворить своё любопытство. Как оказалось, уже полгода, как вышла.

Начал искать статьи про обновление до Debian Stretch, вдруг какие-нибудь подводные камни вылезут, все таки не rolling-release, как, например, Gentoo.

Нашёл эту статью. В принципе, ничего не изменилось, ничего сложного.

Обновился, но вот вылезла такая проблема - не запускался Apache, MySQL, TOR, и еще какой-то сервис. При запуске Apache выдавал такую ошибку:

systemd: apache2.service: Control process exited, code=exited status=226

Failed at step NAMESPACE spawning /usr/sbin/httpd: Bad file descriptor
Aug 27 22:48:39 cubie2 systemd: apache2.service: Main process exited, code=exited, status=226/NAMESPACE

На Cubieforums нашёл тему, у человека была такая же проблема, только не было решения.

А решение относительно простое - нужно обновить ядро. Начнём с того, что изначально на Cubietruck был установлен Cubian. Но постепенно я переехал на Debian Jessie, т.к. Cubian перестал обновляться. И при обновлении с Cubian/Wheeze до Jessie так же пришлось обновлять ядро, про это я уже писал.

Инструкция ниже, это смесь из нескольких статей с linux-sunxi.org - Mainline Kernel Howto, Display, и инструкции Miklós Aurél Rónai - Compiling mainline kernel for CubieBoard2 and CubieTruck ну и немного моих знаний 😉

Мой Cubietruck используется исключительно как домашний сервер, поэтому мультимедийные опции в ядре мне не нужны. По поводу загрузки - система начинает загружаться с SD карты, дальше загрузка идёт с HDD. Так же через USB подключён внешний жёсткий диск.

Я сначала опишу процесс сборки ядра и загрузчика, а уже потом будет подготовка SD карты для работы.

Всё делается на Cubietruck'e через SSH. Создаём директорию src для удобства работы и переходим в неё:

mkdir src && cd src

Прежде всего, установим U-boot:

wget ftp://ftp.denx.de/pub/u-boot/u-boot-2017.11.tar.bz2
bzip2 -d u-boot-2017.11.tar.bz2
tar xf u-boot-2017.11.tar
cd u-boot-2017.05
make Cubietruck_defconfig
make

Пока с u-boot всё. Переходим обратно в директорию src, скачиваем исходники ядра и распаковываем их:

wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.68.tar.xz
xz -d linux-4.9.68.tar.xz
tar xf linux-4.9.68.tar

Устанавливаем пакеты для сборки ядра:

apt install gcc build-essentials swig libpython-dev libfdt-dev gcc-6-plugin-dev libncurses5-dev

Переходим с каталог linux-4.9.68 и конфигурируем ядро перед сборкой:

cd linux-4.9.68
make ARCH=arm sunxi_defconfig

Обязательно нужно поставить ARCH=arm перед menuconfig, иначе пропадут все специфичные для arm опции (следовательно, ядро не загрузится). Если забыли - нужно снова выполнить make ARCH=arm sunxi_defconfig

make ARCH=arm menuconfig

Ядро нужно обязательно сконфигурировать, по умолчанию в этой конфигурации нет поддержки NFS-сервера, устройств хранения USB, фреймбуфера, Bluetooth, Wi-FI, PPPoE, поддержки мыши, батареи и т.д. В общем много чего отключено по умолчанию.

Так же нет поддержки NAND - обязательно включите, если система загружается с NAND, а не с SD карты Device Drivers > Memory Technology Device (MTD) support > NAND Device Support > Support for NAND on Allwinner SoCs (*). Обязательно должен быть в ядре, а не собран модулем.

NFS сервер:

File Systems > Network File Systems > NFS Server Support (Собираем как модуль (М) или он будет прямо в ядре (*), кому как больше нравится)

Выходим обратно в File Systems, здесь ещё нужно активировать файловые системы, с которыми будет работать Cubietruck. По умолчанию включены лишь Ext4 с поддержкой Ext2 и FAT. Если будут подключаться диски/флешки с другими файловыми системами, их нужно включить здесь.

Работа с USB накопителями:

Device Drivers > SCSI device support > SCSI disk support (*)

Выходим обратно в Device Drivers > USB Support > USB Mass Storage Support (M) - можно собрать и модулем.

Выше можно включить OTG:

OTG Support.

Если не нужна поддержка звука и мультимедии:

Снять галочки с Sound Card Support и Multimedia Support.

Включение Framebuffer в консоли:

Device Drivers > Graphics support > Frame buffer Devices > Simple framebuffer support и в этом же меню включить Support for frame buffer devices > Enable firmware EDID.

В общем всё, настройка закончена, если кому нужно что-то еще подключить\отключить - всё в ваших руках, ничего сложного здесь нет.

Сохраняем конфиг. файл и выходим из menuconfig

Собираем ядро, dts, модули ядра и устанавливаем их:

# make zImage dtbs modules modules_install

Сборка на Cubietruck с таким конфигом займёт около 3-х часов.

После сборки ядра нужно подготовить SD карту к работе с новым ядром.

Если хотите очистить SD карту, сохранив таблицу разделов:

dd if=/dev/zero of=/dev/mmcblk0 bs=1k count=1023 seek=1

Если хотите очистить SD карту вместе с таблицой разделов:

dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=1

Лично я выбрал первый вариант. Далее, создаём таблицу разделов на SD карте, первый раздел будет смещён на 1МБ от "начала" SD карты (в это место будет записан загрузчик) и размером 16Мб, а второй займёт всё оставшееся место на карте.

blockdev --rereadpt /dev/mmcblk0
cat <<EOT | sfdisk /dev/mmcblk0
1M,16M,c
,,L
EOT

Создаём файловые системы:

mkfs.vfat /dev/mmcblk0p1
mkfs.ext4 /dev/mmcblk0p2

Теперь нужно установить загрузчик (u-boot). Возвращаемся обратно  в директорию u-boot-2017.11:

cd ../u-boot-2017.11

Записываем ранее скомпилированный загрузчик на SD карту:

dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8

Монтируем загрузочный раздел SD карты и копируем туда dtb файл и образ ядра:

mkdir /mnt/bootprt
mount /dev/mmcblk0p1 /mnt/bootprt
cp linux-4.9.68/arch/arm/boot/zImage /mnt/bootprt
cp linux-4.9.68/arch/arm/boot/dts/sun7i-a20-cubietruck.dtb /mnt/bootprt

Переходим в примонтированный загрузочный раздел и создаём файл boot.cmd со следующим содержимым:

fatload mmc 0 0x46000000 zImage
fatload mmc 0 0x49000000 sun7i-a20-cubietruck.dtb
setenv bootargs console=tty0 hdmi.audio=EDID:0 disp.screen0_output_mode=EDID:1920x1080p60 root=/dev/sda2 rootwait panic=10 ${extra}
bootz 0x46000000 - 0x49000000

Поменять здесь можно опцию root - в данный момент она указывает, что корневой раздел находится на /dev/sda2. Опция disp.screen0_output_mode устанавливает разрешение фреймбуфера.

И последняя команда, которая создаёт файл boot.scr:

mkimage -C none -A arm -T script -d boot.cmd boot.scr

Всё, можно перезагружать систему.

Так же можно скачать готовые скомпилированные ядра и модули отсюда. Они для десктопа, с поддержкой всякого - собиралось такое ядро на Cubietruck около 12 часов.

Правда у меня они так и не завелись, возможно я что-то не так делал. Грешу на файл boot.cmd и образ ядра - uImage, а не zImage. Для загрузки uImage ипользуется команда bootm, а я не помню, менял я её или нет 🙂 Попробую ещё на новых версиях, как их выложат.

Сборка dev-qt/qtwebkit-5.6.0 и создание swap файла

Третьего дня зашел на сайт Calculate Linux и узнал, что месяц назад начался переезд на KDE/Plasma5. Судя по каментам, всё работает более-менее стабильно, поэтому нужно было переезжать, тем более переезд был принудительный, KDE 4 перестал поддерживаться сообществом и всё такое.

И вот, система обновляется, всё нормально, пока дело не доходит до сборки dev-qt/qtwebkit-5.6.0

Выдаёт такую ошибку:

make[2]: Entering directory '/var/calculate/tmp/portage/dev-qt/qtwebkit-5.6.0/work/qtwebkit-opensource-src-5.6.0/Source/JavaScriptCore'
ruby /var/calculate/tmp/portage/dev-qt/qtwebkit-5.6.0/work/qtwebkit-opensource-src-5.6.0/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb llint/LowLevelInterpreter.asm LLIntDesiredOffsets.h
/usr/lib64/ruby/2.0.0/rubygems.rb:15:in `require': cannot load such file -- rubygems/compatibility (LoadError)
from /usr/lib64/ruby/2.0.0/rubygems.rb:15:in `<top (required)>'
from <internal:gem_prelude>:1:in `require'
from <internal:gem_prelude>:1:in `<compiled>'
Makefile.LLIntOffsetsExtractor:426: recipe for target 'LLIntDesiredOffsets.h' failed
make[2]: *** [LLIntDesiredOffsets.h] Error 1

Засоветовали пересобрать dev-lang/ruby и dev-ruby/rubygems - не помогло. Далее я обратил внимание, что установлено 2 версии ruby - 2.0 и 2.1.7. Переключение профиля  ruby20 на ruby21 через eselect ruby set ruby21 помогло решить проблему.

Но на этом проблемы не закончились. Дальше при сборке выдаёт такое:

x86_64-pc-linux-gnu-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
Makefile.WebCore.Target:151688: recipe for target '.obj/inspector/InspectorAllInOne.o' failed
make[2]: *** [.obj/inspector/InspectorAllInOne.o] Error 4
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/var/calculate/tmp/portage/dev-qt/qtwebkit-5.6.0/work/qtwebkit-opensource-src-5.6.0/Source/WebCore'
Makefile.WebCore:68: recipe for target 'sub-Target-pri-make_first-ordered' failed
make[1]: *** [sub-Target-pri-make_first-ordered] Error 2
make[1]: Leaving directory '/var/calculate/tmp/portage/dev-qt/qtwebkit-5.6.0/work/qtwebkit-opensource-src-5.6.0/Source/WebCore'
Makefile:178: recipe for target 'sub-Source-WebCore-WebCore-pro-make_first-ordered' failed
make: *** [sub-Source-WebCore-WebCore-pro-make_first-ordered] Error 2

Полез на багтрекер Gentoo - пишут, что скорее всего просто закончилась память.

Действительно, dmesg подтверждает:

[27324.991323] Out of memory: Kill process 6800 (cc1plus) score 125 or sacrifice child
[27324.991337] Killed process 6800 (cc1plus) total-vm:1123472kB, anon-rss:1051444kB, file-rss:0kB

Пришлось подключать дополнительно swap-файл, т.к. раздел для него на жёстком диске я просто не создавал, оперативной памяти в 8Гб всегда хватало.

Создаём файл:

sudo dd if=/dev/zero of=/swapfile bs=1G count=6

Заместо G можно подставить M и K, соответственно мегабайт и килобайт.

Значение count умножаются на значение bs, я создал файл размером в 6 гигабайт.

Создаем swap в файле:

mkswap /swapfile

Включаем его:

swapon /swapfile

После подключения swap'a сборка завершилась успешно.

Более подробно про создание, подключение и настройки своппинга написано здесь.

Разбираемся с Gentoo и MAKEOPTS=”-j${core} +1″

Восстанавливаю похеренный пост. Значится так, задался я вопросом оптимизации. Начал читать всякое, что еще можно в Gentoo подкрутить, чтобы система работала быстрее. И нашел один пост, автор (участник Gentoo Linux ARM Development, наверное что-то да соображает) пишет, что сборка по формуле j={core} + 1 чуть медленнее, чем просто j={core}.

Посмотрев на его результаты, решил проверить все на своем калькуляторе с 6-ти ядерным AMD Phenom II X6 1055T. Я выделил только результаты со значением j от 5 до 7, ибо понятно, что при значениях меньше 5 и больше 7 будет сильная регрессия. И потом, просто для интереса, добавил опции --load-average=6 и --jobs=6, а также переключил процессор в режим perfomance командой "cpupower frequency-set -g performance".

Сборка происходит в оперативной памяти, emerge собирает с опциями "-q1OB".

Опция -q уменьшает объем сообщений emerge, опция -B создает бинарый пакет, но не устанавливает его, -O устанавливает пакет без его зависимостей, -1 не заносит пакет в world файл.

Итак, приступим. Первый кандидат на тест - Firefox 40.0.2

Стандартные значения, процессор переключен в режим ondemand

job 5 = 19m27.126s
job 6 = 17m0.438s
job 7 = 17m17.294s

Процессор переключен в режим perfomance

job 5 = 18m44.965s
job 6 = 16m25.896s
job 7 = 16m39.971s

Добавлена опция --jobs=6

job 5 = 18m46.808s
job 6 = 16m26.300s
job 7 = 16m42.490s

Добавлена опция --load-average=6

job 5 = 21m6.846s
job 6 = 18m24.210s
job 7 = 19m10.559s

Потом последовал пакет Kdelibs 4.14.8, опции те же самые.

Процессор переключен в режим ondemand

job 5 = 9m18.974s
job 6 = 8m8.003s
job 7 = 8m20.969s

Процессор переключен в режим perfomance

job 5 = 8m51.200s
job 6 = 7m50.196s
job 7 = 7m58.345s

Добавлена опция --jobs=6

job 5 = 8m53.102s
job 6 = 7m50.039s
job 7 = 7m58.541s

Добавлена опция --load-average=6

job 5 = 9m3.678s
job 6 = 8m37.215s
job 7 = 8m52.021s

И на последок - сборка @system.

Вот что собиралось

>>> Emerging (1 of 44) sys-apps/man-pages-4.00::gentoo
>>> Emerging (2 of 44) sys-apps/util-linux-2.25.2-r2::gentoo
>>> Emerging (3 of 44) sys-apps/grep-2.21-r1::gentoo
>>> Emerging (4 of 44) sys-apps/kbd-1.15.5-r1::gentoo
>>> Emerging (5 of 44) sys-apps/busybox-1.23.1-r1::gentoo
>>> Emerging (6 of 44) virtual/service-manager-0::gentoo
>>> Emerging (7 of 44) sys-devel/binutils-2.24-r3::gentoo
>>> Emerging (8 of 44) virtual/man-0-r1::gentoo
>>> Emerging (9 of 44) sys-apps/net-tools-1.60_p20130513023548::gentoo
>>> Emerging (10 of 44) virtual/shadow-0::gentoo
>>> Emerging (11 of 44) virtual/modutils-0-r1::calculate
>>> Emerging (12 of 44) sys-apps/gawk-4.0.2::gentoo
>>> Emerging (13 of 44) app-arch/xz-utils-5.0.8::gentoo
>>> Emerging (14 of 44) sys-apps/sed-4.2.1-r1::gentoo
>>> Emerging (15 of 44) sys-process/psmisc-22.21-r2::gentoo
>>> Emerging (16 of 44) sys-fs/e2fsprogs-1.42.13::gentoo
>>> Emerging (17 of 44) sys-apps/file-5.22::gentoo
>>> Emerging (18 of 44) app-arch/bzip2-1.0.6-r6::gentoo
>>> Emerging (19 of 44) app-arch/tar-1.27.1-r2::gentoo
>>> Emerging (20 of 44) virtual/package-manager-0::gentoo
>>> Emerging (21 of 44) net-misc/rsync-3.1.1::gentoo
>>> Emerging (22 of 44) sys-apps/openrc-0.17::gentoo
>>> Emerging (23 of 44) virtual/editor-0::gentoo
>>> Emerging (24 of 44) sys-apps/coreutils-8.23::gentoo
>>> Emerging (25 of 44) sys-devel/make-4.1-r1::gentoo
>>> Emerging (26 of 44) sys-process/procps-3.3.9-r2::gentoo
>>> Emerging (27 of 44) sys-apps/iproute2-3.19.0::gentoo
>>> Emerging (28 of 44) virtual/ssh-0::gentoo
>>> Emerging (29 of 44) virtual/dev-manager-0::gentoo
>>> Emerging (30 of 44) sys-apps/findutils-4.4.2-r1::gentoo
>>> Emerging (31 of 44) virtual/os-headers-0::gentoo
>>> Emerging (32 of 44) app-arch/gzip-1.6::gentoo
>>> Emerging (33 of 44) net-misc/wget-1.16::gentoo
>>> Emerging (34 of 44) sys-apps/which-2.20-r1::gentoo
>>> Emerging (35 of 44) net-misc/iputils-20121221-r1::gentoo
>>> Emerging (36 of 44) virtual/pager-0::gentoo
>>> Emerging (37 of 44) sys-apps/diffutils-3.3::gentoo
>>> Emerging (38 of 44) sys-apps/baselayout-2.2::gentoo
>>> Emerging (39 of 44) sys-apps/less-478::gentoo
>>> Emerging (40 of 44) app-shells/bash-4.3_p39::gentoo
>>> Emerging (41 of 44) sys-devel/patch-2.7.5::gentoo
>>> Emerging (42 of 44) virtual/libc-0::gentoo
>>> Emerging (43 of 44) sys-devel/gnuconfig-20150308::gentoo
>>> Emerging (44 of 44) sys-devel/gcc-4.8.4::gentoo

Процессор переключен в режим ondemand

-j5 = 48m32.519s
-j6 = 46m2.547s
-j7 = 46m39.452s

Процессор переключен в режим perfomance

-j5 = 28m55.455s
-j6 = 28m27.521s
-j7 = 29m15.811s

Добавлена опция --jobs=6

-j5 = 29m13.803s
-j6 = 27m6.803s
-j7 = 27m18.675s

Добавлена опция --load-average=6

-j5 = 37m52.365s
-j6 = 35m25.080s
-j7 = 35m47.117s

Как видно, при значении опции j={core} компиляция проходит чуть быстрее. И еще в скрипте сборки в оперативной памяти (которым всегда пользуюсь, ссылка в начале поста) я добавил переключение процессора в режим perfomance в начале сборки и возврат в режим ondemand после её окончания ибо это дает дополнительный прирост скорости.

 

Chromium и GCC 4.6.1

Решил от нечего делать установить Хромого. Начал ставить версию 13.0.782.32 - не собирается, насколько понял, из-за того, что не поддерживается GCC 4.6.х для сборки. Вроде как патч уже есть, поэтому начал тянуть с SVN. Было свободно в корне 2,5 гига (да, у меня отделен только /home и /boot), так эта сволочь все захапала под свои сорцы, пришлось все удалять из distfiles, все равно df -h показывает, что свободно 0%. Но все равно, Хромиум собирается, глядишь, соберется.

UPD: Собрался, сучечка. И даже работает. Сейчас перекидываю /usr/portage на другой диск, на котором места побольше. Надо было давно это  сделать, ибо проблема со свободным местом появилась месяца 2 назад. Лень, чо тут скажешь.

Стырено с Gentoo.

Wi-Fi, установка Gentoo и прочее

Давненько не писал сюда, хотя поводов хватало - всякое было с моей любимой генточкой. сейчас, пока сижу на больничном, можно и написать всякое, ибо делать совсем нечего.
Итак, 1-ое - на ноуте переехал с freeBSD на Gentoo. вроде все нормально, кроме одного - при входе в админку сайта, после ввода логина\пароля, апач просто напросто сегфолтится и залогинится не получается. На ноуте я был авторизован, поэтому в админку мог попасть спокойно, все работало, за исключения логина.
Потом удачно навернулся блок питания на ноуте, поэтому пришлось забрать блок питания со старого бука, пока пользуюсь им, соответственно поэтому сайт в ауте.
при переезде была одна особенность -  ядро на установочном диске Gentoo было старое, 2.6.18 или 19, и вот, после chroot'a и обновления coreutils до 8.8, перестали собираться программы, ругался touch, что не может создать файл. Сначала нашел на форуме такое решение - вытягивание и пересборка из исходников около 30 системных утилит. Поискал дальше - оказалось, что можно всего-то откатить coreutils на предыдущую версию - 8.5. После этого обновил ядро и coreutils - все нормально работает.
Теперь решил заняться Wi-Fi'ем на ноуте. Теперь его стали часто дергать в другую комнату, а у него появилась еще одна болячка - при выдергивании шнура он отключается. Причем, когда втыкаешь шнур обратно - загорается индикатор зарядки батареи. Ну а при каждом отключении, нужно заного настраивать подключение к Wi-Fi-сети. Скрипт /etc/init.d/net.wlan0 требует wpa_supplicant. Ставим его (причем сеть без шифрования). В /etc/wpa_supplicant/wpa_supplicant.conf достаточно добавить

network={
ssid="essid_name"
key_mgmt=NONE
}

а остальные параметры должны быть прописаны в /etc/conf.d/net.
И еще, чтобы не перезаписывался /etc/resolv.conf (без клиента dhcp) нужно в /etc/conf.d/net добавить такое
dns_servers_wlan0=("ip адрес DNS")
Вот как-то так.

Обновление Python и сборка cracklib

Originally published at Gentoo & FreeBSD. You can comment here or there.

Давеча обновился Python до версии 2.7, ну и

emerge –depclean

радостно затер версию 2.6. Правда после того, как он затер эту версию питона, удаление других программ сразу же отвалилось, ибо емердж полностью завязан на питон. Ну делать нечего, вызвал

eselect python list.

Там есть на выбор питон версий 2.7 и 3.1. Выбираем 2.7, 3.1 пока не рекомендуется для использования. Поэтому рисковать не охота :) И удалять его не охота. Пусть будет в общем :)

ну и все, делаем

eselect python set python2.7

Потом я решил запустить revdep-rebuild, ну и на cracklib все остановилось. Вот ссылка на баг в багзилле генты. Почитал обсуждение и вспомнил, что я-то python-updater запускал, но перед тем, как переключиться на новый профиль питона. Запустил, все нормально собралось. У чувака наверно такая же проблема, о чем я ему и написал.