Стоит блоб и bumblebee.

Берём хеллоуворлд, собираем, запускаем. http://www.computer-graphics.se/hello-world-for-cuda.html

optirun ./a.out выдаёт Hello World (правильно), primusrun и просто ./a.out выдают Hello Hello (неправильно, cuda не работает). Аналогичная проблема в блендере: если запускать не через optirun, то возможности выбрать куду в Cycles нету. Раньше работало во всех трёх случаях правильно.

Ещё прикол: через optirun в dmesg-е появляются следующие строчки:

[11148.248717] bbswitch: enabling discrete graphics
[11148.725916] nvidia-nvlink: Nvlink Core is being initialized, major device number 248
[11148.726228] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  396.24  Thu Apr 26 00:10:09 PDT 2018 (using threaded interrupts)
[11149.643660] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  396.24  Wed Apr 25 23:54:18 PDT 2018
[11149.691900] [drm] [nvidia-drm] [GPU ID 0x00000300] Loading driver
[11149.691902] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:03:00.0 on minor 1
[11150.481863] nvidia-modeset: Allocated GPU:0 (GPU-18c192dc-27ac-38fc-9749-67ba1a0a03f8) @ PCI:0000:03:00.0
[11150.482152] nvidia-modeset: Freed GPU:0 (GPU-18c192dc-27ac-38fc-9749-67ba1a0a03f8) @ PCI:0000:03:00.0
[11150.715671] nvidia-modeset: Allocated GPU:0 (GPU-18c192dc-27ac-38fc-9749-67ba1a0a03f8) @ PCI:0000:03:00.0
[11150.715959] nvidia-modeset: Freed GPU:0 (GPU-18c192dc-27ac-38fc-9749-67ba1a0a03f8) @ PCI:0000:03:00.0
[11151.225481] nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 247
[11151.711190] nvidia-uvm: Unloaded the UVM driver in 8 mode
[11151.718699] [drm] [nvidia-drm] [GPU ID 0x00000300] Unloading driver
[11151.723625] nvidia-modeset: Unloading
[11151.733615] nvidia-nvlink: Unregistered the Nvlink Core, major device number 248
[11151.742195] bbswitch: disabling discrete graphics
[11151.754476] pci 0000:03:00.0: Refused to change power state, currently in D0

Я не помню, после чего такая фигня появилась - возможно, из-за того, что я настраивал laptop mode tools, но больше меня смущает то, что я не уверен, что должно быть так, как раньше, а не так, как сейчас. Если раньше работало правильно, то как исправить, а если без bumblebee работать не должно, то почему работало раньше и почему не работает через примус?

Извиняюсь, если скомканно объяснил.

UPD: а, во, ещё secure boot настраивал. Но оно же вроде никак не должно влиять, так ведь?

Использую за основу вот этот туториал. https://wiki.gentoo.org/wiki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot

Вот всё, что я вызываю, и (почти) всё, что мне пишут.

$ sudo mount -o remount,rw /sys/firmware/efi/efivars
$ openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Alpha PK/" -keyout PK.key -out PK.crt -nodes -sha256 -days 36500
Generating a 2048 bit RSA private key
..................................+++
......................................................+++
writing new private key to 'PK.key'
-----
$ cert-to-efi-sig-list -g "$(uuidgen)" PK.crt PK.esl
$ sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth
Timestamp is 2018-6-20 20:29:01
Authentication Payload size 851
Signature of size 1162
Signature at: 40
$ sudo efi-updatevar -f PK.auth PK

$ sudo efi-updatevar -d 0 PK
Can't update variable in User Mode without a key
$ sudo efi-updatevar -d 0 -k PK.key PK
Failed to update PK: Operation not permitted

Ладно первая команда - да, действительно, ключик всё-таки нужен, но вторая-то чего ругается?

Тут есть три варианта: либо кривой биос, либо кривая утилита, либо кривой я. Пока не определился, так что помогите.

Юзаю s2disk для гибернации. Комп выключается, включается, resume возвращает систему на место - и та жёстко тупит. free показывает, что почти всё, что было в RAM до гибернации, сейчас оказалось в свопе. Если до саспенда был запущен браузер, например, то вообще беда - пока вручную своп не почистить, он не отвиснет.

Сейчас при загрузке системы юзается ручной swapoff-swapon, но я так подозреваю, что это грязный костыль, который использовать не следует. Есть ли лучший способ?

Symbol: CONSOLE_LOGLEVEL_DEFAULT [=7]
Type  : integer
Range : [1 15]
Prompt: Default console loglevel (1-15)
  Location:
    -> Kernel hacking
      -> printk and dmesg options
Defined at lib/Kconfig.debug:18

Там же вроде самый низкий приоритет - 8 (KERN_DEBUG), откуда и зачем 15?

Есть один ГП, Wacom Bamboo Pen что-то там. Он передаёт на мою машину какую-то информацию о давлении пера. Информация эта доходит до системы в общем (проверено hexdump-ом /dev/input/eventX, инфа 100), но почему-то не доходит до блендера и гимпа. Очевидно, где-то в этой цепочке передачи событий от устройств ввода до приложений есть слабое звено, но я даже не представляю, где.

Как это проверить и исправить?

Господа, прошу подсобить. Решил собрать-таки ядро с ручным конфигом, собрал, запустил - вроде работает. Запускаю lsblk, а тут вот такая ерунда:

$ lsblk -o name,uuid
NAME           UUID
sda            
├─sda1         
├─sda2         
│ └─cboot      
└─sda3         
  └─clvm       
    ├─lvm-swap 
    ├─lvm-root 
    └─lvm-home 
sr0  

Вот конфиг: https://pastebin.com/B5SNmymj

Пример магии:

~/tools # USE="static" emerge --root=$PWD coreutils -a
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] virtual/libintl-0-r2 to /home/theta/tools/ ABI_X86="32 (64) (-x32)" 
[ebuild   R    ] sys-apps/attr-2.4.47-r2  USE="static-libs*" 
[ebuild   R    ] sys-apps/acl-2.2.52-r1  USE="static-libs*" 
[ebuild  N     ] sys-apps/coreutils-8.29 to /home/theta/tools/ USE="acl nls static xattr -caps -gmp -hostname -kill -multicall (-selinux) {-test} -vanilla" 

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by sys-apps/coreutils-8.29::gentoo[static,acl]
# required by @system
# required by @world (argument)
>=sys-apps/acl-2.2.52-r1 static-libs
# required by sys-apps/coreutils-8.29::gentoo[static,xattr]
# required by @system
# required by @world (argument)
>=sys-apps/attr-2.4.47-r2 static-libs

Would you like to add these changes to your config files? [Yes/No]

Я бы понял и оценил, если бы он половину системы запихал на новый рут и компилил там как душе угодно, включая пусть даже glibc, но почему он трогает пакеты вне префикса?

Предыстория: хочу собрать initramfs и напихать туда статически слинкованных утилиток. Мержить в системный корень и копировать оттуда не хочу, уж больно грязно получается, да и перекомпилировать обратно потом надо, ибо сидеть со статикой не комильфо.

Сразу скажу, что у чувака винда, а у меня гента, и мы работаем в стандартном питоновском интерактивном шелле. Питон третий, хотя во втором у меня такой же результат.

Возьмём, к примеру, такой код:

>>> from tkinter import *
>>> w=Tk()
>>> btn=Button(w,text="penis")
>>> def penis(v):
...   print("Penis!")
... 
>>> btn.bind("<Button-1>",penis)
'140268791533128penis'
>>> btn.pack()

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

Читал stackoverflow, но там чешут репы и то соглашаются и говорят, что у них так же, то говорят, что так бывает только в некоем IDLE, которого у меня нету и никогда не стояло.

Почему так происходит? Можно списать на разницу в какой-нибудь оконной библиотеке, лежащей под ткинтером и разнящейся на винде и лине, или это у кого-то из нас кривые руки?

Появилась у меня хотелка такая: убрать подчистую подгрузку модулей и включить всё в бинарник ядра. А ещё чтобы драйвер пропиетарный от нвидии был, а главное - чтобы с bumblebee работал, т.к. люто удобная штука этот ваш бамблби.

Как зашить блоб в ядро, я примерно представляю, т.к. там в конфигах даже строчка была для блобов, но не представляю, во-первых, что именно вшивать (просто nvidia.ko или ещё что?), а во-вторых, сможет ли разжевать такой конфиг бамблби, т.к. он вроде как на загрузке-разгрузке модулей и построен, а у меня с пониманием устройства графической подсистемы линуксов примерно как у второклассника с квантовой физикой.

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

Пытаюсь загрузить первое самостоятельно сконфигурированное ядро.

Итак, в грубовском конфиге есть строчки:

echo 'Loading kernel...'
kernel /bzImage

Если что, это же самое ядро в qemu (без ovmf, легаси) прекрасно грузится и выдаёт замечательный kernel panic, которого я и ждал.

_____

Решение: вырубить nvidiafb. Как говорил Святой Линус, «Nvidia, f%ck you!»

Есть один ноут с дохлым ЖД: система дважды слетела за один месяц - диагноз очевиден. Можно, конечно, разломать и кидаться болванками в стену, но хочется как-то использовать ещё хотя бы полгодика без серьёзных осложнений. Возникла мысль прилепить туда какой-нибудь software raid: две зеркальные копии данных, когда слетает сектор на одной из копий - ремапить и восстанавливать из оставшейся.

Кто-нибудь такую штуку реализовывал или хотя бы пытался реализовывать? Это практически осуществимо? Если да, то как именно?

Сейчас у меня он включён при загрузке системы, выключается на fn, включается снова после саспенда. Нужно это поведение инвертировать (т.е. по дефолту выключен после саспенда или включения, включается на fn), ещё лучше - запоминать состояние тачпада между саспендами. Как это сделать?

Тачпад вроде дженерик, никаких дровей от синаптика не стоит. Fn не ловится xev-ом, так что костылей особо не наворотить.

Вот вся инфа, которую догадался предоставить.

# zcat /proc/config.gz | grep HIBER
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y

# zcat /proc/config.gz | grep SUSP
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_SUSPEND_SKIP_SYNC is not set
# CONFIG_BT_HCIBTUSB_AUTOSUSPEND is not set

# cat /proc/cmdline
BOOT_IMAGE=/kernel-genkernel-x86_64-4.16.2-gentoo root=/dev/mapper/lvm-root ro crypt_root=UUID=74f4955f-b422-4abe-8bcf-8329919222aa dolvm real_root=UUID=bbd59fba-ed35-4289-86a1-5c16106f2317 real_resume=UUID=a6401d1c-1769-45b0-b582-8b16e238f6bf

# lsblk -o name,type,mountpoint
NAME           TYPE  MOUNTPOINT
sda            disk 
├─sda1         part  /boot/efi
├─sda2         part 
│ └─cboot      crypt /boot
└─sda3         part 
  └─root       crypt
    ├─lvm-swap lvm   [SWAP]
    ├─lvm-root lvm   /
    └─lvm-home lvm   /home
sr0            rom 

Ядро собирал генкернелом. Как видно, своп располагается в довольно труднодоступном месте.

Что я понял из процесса загрузки: сначала грубом грузится ядро, чё-то там своё делает, потом передаёт руль initramfs, который просит у меня пароль от рута, разблокирует его и получает-таки доступ к заветному свопу, на который s2disk в прошлый раз уложил (кстати, вроде бы вполне успешно) систему спать.

Судя по всему, initramfs свою функцию выполняет, т.к. после ввода пароля я замечаю в летящем вверх логе что-то про real_resume, обнаруженный на /dev/dm-1, а ещё убеждаюсь, что initramfs успел записать этот самый /dev/dm-1 в /sys/power/resume (в чём я убеждаюсь чуть позже, после провала resume):

# cat /sys/power/resume
253:1
# file /dev/dm-1
/dev/dm-1: block special (253/1) 

Я точно не знаю, что здесь не так и почему лыжи не едут, но у меня есть несколько гипотез:

1) «253:1» - не совсем тот формат, который нужен в новых модных ядрах линя (у меня 4.16.2, если что)

2) запись в /sys/power/resume происходит невовремя (например, когда примонтирован настоящий рут, или, наоборот, не примонтирован)

3) просто кривые конфиги ядра

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

Я ещё слышал, что существуют разные виды саспенда, типа TuxOnIce и swsusp, нифига не понял, чем они отличаются, и пришёл к выводу, что у меня swsusp, исходя из структуры каталогов на /sys. Если это не так, то я вообще не в ту сторону думаю, тогда проясните мне ситуацию.

Под жестоким выключением подразумевается зажатие кнопки питания.

Делаю так нечасто, но почему-то в примерно в третьей части случаев ноутбук после этого отказывается грузиться. Переустановка systemd-boot помогает, но я всё равно не понимаю, почему в таких случаях страдает именно он, а остальная система на первый взгляд остаётся нетронутой.

$ glxinfo
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig

$ /usr/sbin/lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)

Xorg.0.log: https://pastebin.com/f31qU17g

make.conf: https://pastebin.com/XcmZWhbw

Интересные места из лога:

[    29.652] (II) Loading sub module "glamoregl"
[    29.652] (II) LoadModule: "glamoregl"
[    29.652] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
[    29.652] (II) Module glamoregl: vendor="X.Org Foundation"
[    29.652]    compiled for 1.19.6, module version = 1.0.0
[    29.652]    ABI class: X.Org ANSI C Emulation, version 0.4
[    29.652] (II) glamor: OpenGL accelerated X.org driver based.
[    29.654] (II) glamor: EGL version 1.4 (DRI2):
[    29.654] EGL_MESA_drm_image required.
[    29.654] (EE) modeset(G0): glamor initialization failed

[    29.728] (II) AIGLX: Screen 0 is not DRI2 capable
[    29.728] (EE) AIGLX: reverting to software rendering
[    29.728] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
[    29.728] (EE) GLX: could not load software renderer
[    29.728] (II) GLX: no usable GL providers found for screen 0 

На самом деле есть ещё чип от нвидии, но я не добавлял ни нуво, ни блоб в VIDEO_CARDS. Ручное добавление glamore в USE, как советуют тута, не приводит ни к каким пересборкам. Копипастинг xorg-овского конфига из той же секции тоже не шибко помогает - я так подозреваю, что обе операции проделываются автоматически при отсутствии в конфигах.

Как это вообще фиксить?

В целом оконный менеджер запускается, браузер работает, даже mpv видосики проигрывает, но невозможность покрутить glxgears ощущается примерно как шило в заднице.

(если честно, я понятия не имею, что такое GLX, AIGLX, glamore и как это всё работает и связывается друг с другом, я просто хочу покрутить шестерёнки в glxgears и успокоиться, почему ничего не работает, мне страшно, тут какие-то ошибки, помогите, пожалуйста)

Второй день бьюсь над этой задачей. Данных по сборке кросс-компилятора, который работает под линуксом и собирает виндовые бинарники, предостаточно, и даже вполне подробный туториал в доках mingw-w64 есть, но вот адаптировать его под сборку тулчейна именно для винды у меня не получается.

Вот примерный список команд для сборки, которые я взял из туториала по сборке кросс-компилятора (https://pastebin.com/9rtrrkmw), немного изменив:

export WD=$HOME/mingw-build
export TGT=i686-w64-mingw32

cd ~/binutils/tmp
../configure --prefix=$WD --with-sysroot=$WD --host=$TGT --disable-multilib --disable-nls
make && make install

cd ~/mingw/mingw-w64-headers/tmp
../configure --prefix=$WD/$TGT --host=$TGT
make install

ln -s $WD/{$TGT,mingw}

(здесь копируем исходники gmp, mpc и mpfr в ~/gcc)

cd ~/gcc/tmp
../configure --prefix=$WD --with-sysroot=$WD --host=$TGT --disable-multilib --disable-nls --enable-languages=c,c++
make all-gcc && make install-gcc

cd ~/mingw/mingw-w64-crt
../configure --prefix=$WD/$TGT --with-sysroot=$WD --host=$TGT
make && make install

cd ~/gcc/tmp
make

Ошибка вылетает на последнем make:

checking how to run the C preprocessor... /lib/cpp
configure: error: in `/home/alpha/work/tmp/gcc-7.2.0/bin/i686-w64-mingw32/libgcc':
configure: error: C preprocessor "/lib/cpp" fails sanity check

Почему /lib/cpp, а не что-то более подходящее? Не тот тулчейн? Или я этот умудрился запороть? Или я вообще не в ту сторону копаю? Тапками не бейтесь, вручную мало что собираю, а уж gcc тем более. Чисто из интереса решил попробовать.

Исходники последние (gcc 7.2.0, binutils 2.1.19, mingw-w64 5.0.3 ЕМНИП), кросс тоже последний из арчевского репозитория.

Решил заценить SFML. Беру вот отсюда код, компилю, запускаю. Слышу, как что-то внутри ноута едва слышно пищит. Пугаюсь, ограничиваю FPS или просто включаю VSync - ничего не пищит. Переключаюсь с интела на нвидию - ничего не пищит, даже если ничего не ограничивать.

Вопрос: что это может быть?

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

Поискав, я обнаружил статейку на хабре, в которой говорится, что можно очень легко и беззаботно настроить смену раскладки в режиме редактирования... забиндив её на Ctrl-^. На вопросы, а как же переставить её на человеческое сочетание типа Alt+Shift, в комментах стыдливо помалкивают или говорят что-то вроде «вим хороший, иксы плохие».

Может, есть какое-то альтернативное решение, или настройка вима под себя и в самом деле пропадает через час использования?

Пример:

$ sudo dd if=/dev/zero of=/dev/mmcblk0 bs=4M status=progress

При чтении с устройства в /dev/null или stdout, кстати, проблема не возникает.

У кого-нибудь такая проблема возникала, или это я такой уникальный? Решение вообще существует? А то как я погуглил, так создаётся впечатление, что так и должно быть.

В прошлый раз меня отсюда погнали ссаными тряпками, т.к. я не предоставил логов, поэтому утру слёзки и повторю попытку уже с ними.

Ставлю дрова, запускаю nvidia-xconfig, перезапускаюсь, получаю черный экран с курсором. Вот всё, что смог вытащить из виртуальной консоли.

xorg.conf: https://pastebin.com/UizMu3xs

лог xorg: https://pastebin.com/RKUxQQ7R

запуск иксов врукопашку (это же так делается, да? после запуска переключает в пресловутый черный экран с курсором, отчётливо видно место с ^C, на котором я переключился обратно в tty и прекратил это безобразие): https://i.imgur.com/2V5IYPk.jpg

$ lspci
...
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)
...
03:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
$ uname -r
4.13.11-1-ARCH

Интеловские модули блеклистил, nvidia в initramfs пихал, какую-то ерунду из арчевики в опции ядра пихал - всё без толку. Шо делать?