Не может создать “Привет Мировой” модуль (и NVIDIA и VirtualBox)

Выражение $'search add $1 \015', и в целом заключение в кавычки $'string' a bash функции (вероятно, также других оболочек), таким образом, это работает из командной строки, где Вы, вероятно, используете bash.

Это наверняка не работает на sh, это в человечности указывает на dash.

Таким образом, простое решение состоит в том, чтобы вызвать Ваш сценарий с bash ./test.sh.

6
27.02.2019, 12:52
4 ответа

РЕШЕННЫЙ!

Простой как это: /root/.bashrc имел эту внутреннюю часть:

 export GREP_OPTIONS='--color=always'

Измененный это на:

 export GREP_OPTIONS='--color=never'

... и перезапущенный корневая оболочка (конечно; не опускайте этот шаг). Все начало работать снова. И модули ядра NVIDIA и VirtualBox создаются из первой попытки. Я так счастлив!:-)

С другой стороны, хотя, я немного разочарован инструментами сборки ядра. Они должны знать лучше и передача --color=never везде они используют grep; или скорее сохраните старое значение GREP_OPTIONS, переопределите его в течение времени жизни процесса здания, затем восстановите его.

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

Очень теплое благодаря людям, которые были со мной и пытались помочь.

(Все кредиты идут сюда: http://forums.gentoo.org/viewtopic-p-4156366.html#4156366)

6
27.01.2020, 20:25
  • 1
    по случаю нахождения решения. Я думал бы, что это квалифицирует как ошибка в инструментах сборки ядра, поскольку она действительно не должна повреждаться просто, потому что кому-то нравится вывод цвета от grep! –  StarNamer 28.07.2012, 22:28
  • 2
    Хорошая находка. Срыв и раздражающий, также. Я думаю, что это - вид вещи, которая никогда не тестируется, тем не менее, потому что большинство людей, которые хотят цвет ouput использование --colour=auto так, чтобы коды ESC не загрязняли вывод, когда он передается по каналу или перенаправляется. В нескольких случаях Вы могли бы хотеть цветной переданный по каналу вывод (например, при передаче по каналу к less -r) можно указать --colour на командной строке. –  cas 29.07.2012, 02:13
  • 3
    Только обеспокойтесь здесь, я не получил идеи вообще, кто должен я показывать эту страницу, так, чтобы команда инструментов сборки ядра Linux заметила и возможно делала с этим что-то. –  dimitarvp 29.07.2012, 16:26
  • 4
    @dimitko, необходимо попробовать ядро Bugzilla. –  vonbrand 24.03.2014, 04:03

Вы попытались произвести чистку и переустановить dkms?

Вы могли использовать apt-get purge dkms и это также произведет чистку всех пакетов, которые зависят от него, таким образом, необходимо будет переустановить их впоследствии.

Если Вы не хотите подчиненных пакетов, очищенных также, Вы могли бы использовать dpkg:

dpkg --purge --force-depends dkms

переустановите с обычным: apt-get install dkms

FWIW, у меня есть две машины здесь (работающий debian sid) с ядром linux-image-3.2.0-3-amd64 и nvidia-kernel-dkms 302.17-3 и связанные установленные пакеты. dkms модуль скомпилирован без проблемы. Третья машина (мой основной рабочий стол) все еще выполняет nvidia-kernel-dkms 295.53-1, главным образом потому что я не хочу должным быть выходить из системы.

BTW, Вы упомянули, что произвели чистку и переустановили различные пакеты Nvidia со способностью. Существует несколько пакетов Nvidia, которые не имеют Nvidia на имя пакета. Вот решение, которое я предложил для содержания/несодержания Nvidia pkgs (я обычно только хочу обновить Nvidia pkgs, когда я согласный / в состоянии выйти из своего тока X сессий... и после нескольких неприятных неожиданностей с новыми версиями Nvidia, мне нравится тестировать их на моем наименьшее - важная машина сначала):

(примечание: Вам будет нужен мой dlocate пакет, установленный для выполнения этого),

$ cat /usr/local/sbin/hold-nvidia.sh 
#! /bin/bash

PKGS=$(dlocate -l nvidia cuda vdpau | awk '/^[hi]i/ {print $2}' | sed -e 's/:.*//')

echo dpkg-hold $PKGS
dpkg-hold $PKGS

Существует почти идентичный для несодержания пакетов (выполнения dpkg-unhold вместо dpkg-hold), и это было бы тривиально, чтобы заставить его работать dpkg --purge или apt-get purge вместо этого.

2
27.01.2020, 20:25
  • 1
    . Не пытался произвести чистку самого dkms все же - я собираюсь делать это после того, как я сделан, работая в течение дня. Я получил другой вопрос для Вас, хотя - Вы читали мои редактирования при попытке создать "привет мировой" модуль? Часть, где никакой .ko файл никогда не создается? Вы надел какую-либо идею, как я должен исправить это? (modpost в linux-kbuild-3.2 пакет btw.) –  dimitarvp 26.07.2012, 02:14
  • 2
    извините, отчасти перескочил через него в tl; вид доктора :). Я действительно замечал сейчас в ОБНОВЛЕНИИ № 1, что у Вас есть несколько нестандартных каталогов в Вашем ПУТИ... там шанс существует конфликтующий двоичный файл/сценарий в одном из тех директоров? Вы попытались установить "стандартный" ПУТЬ (просто обычные системные директора) прежде, чем создать dkms модуль? –  cas 26.07.2012, 02:24
  • 3
    Вы могли быть правы. Я получил RVM, и это печально известно для переопределения важных вещей в среде. Только что законченный мой 18-часовой фриланс "рабочий день", собираясь катастрофический отказ теперь, но оба Ваших предложения попробуют, первая вещь, когда я встану.Спасибо. –  dimitarvp 26.07.2012, 05:38
  • 4
    К сожалению, никакая радость. Удаленный RVM от моего .bashrc файлы (и корень и обычный пользователь), перезапустил консоль, затем очищенную dkms (который естественно произвел чистку nvidia-kernel-dkms и virtualbox-dkms). Затем я сделал apt-get clean (даже при том, что debsubs не сообщил о проблемах), затем я действительно переустанавливал их. Ничто не изменилось. Мы можем попытаться решить проблему в Обновлении № 4 btw? (Я полагаю, что это - корень проблемы.) Я получил крошечное "привет мировой" модуль, и даже это не создало .ko файл. Вы получили какую-либо идею об этом? –  dimitarvp 26.07.2012, 14:52
  • 5
    извините, проигнорируйте это. я считал его неправильно. делание из экспериментальных причин проблема. возвращение фиксирует его. –  cas 27.07.2012, 01:16

Я работаю Debian Хрипящий (32-разрядный) с драйверами NVIDIA. Я также недавно попробовал версию DKMS 320.17, но вернулся 'Чиновнику' сборка NVIDIA (295.59), не потому что ей не удалось установить, но потому что она не включает nvidia-settings программа и я должны сбросить сверхсканирование на моем телевидении с высокой четкостью (дополнительный монитор).

Однако Вы не должны должны быть связываться /usr/bin/gcc к gcc-4.6 для выполнения более старой версии. Я просто выполнился CC=gcc-4.6 прежде, чем выполнить 'Официальные' 295,59 установок после того, как я произвел чистку всего материала Nvidia это apt-get установил.

Хрипящий все еще версия тестирования, таким образом, возможно, что Вы поразили ошибку, которая не была правильно протестирована в 64-разрядной сборке. Как я сказал, мое 32-разрядное обновление не показало проблемы кроме недостающей функциональности. Вы могли бы хотеть посмотреть на вход отчета об ошибках, если Вы уверены, что все в порядке в Вашей системе.

Моя рекомендация состояла бы в том, чтобы вернуться к 295,59 'Официальным' версиям (или использование Вашей ссылки или определение CC для использования правильной версии gcc) и затем ожидать обновления nvidia-kernel-dkms модуля (или до Хрипящий выпуск как стабильный).

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

0
27.01.2020, 20:25
  • 1
    я пытался понизить. Печально абсолютно та же проблема появилась. Я забыл включать это в исходное сообщение, извините об этом. Но после чистки всего, что склонный - установлено (и я действительно зарегистрировал это и затем правильно удалил ее), и вышел, Кв. - получают установку (с 295,59 версиями), я поразил точно ту же проблему. Это - почему я сказал "очевидно, что что-то повредилось", столь же неясный, как это звучит. –  dimitarvp 20.07.2012, 22:24
  • 2
    я на самом деле загрузил файл NVIDIA-Linux-x86-295.59.run с веб-сайта NVIDIA (существует, вероятно, версия Amd64), и создал его тот путь. Это - то, что я предположил, что Вы подразумевали под 'официальной' версией. Я также прошел все установленные пакеты с nvidia на имя (использование aptitude) и очищенный все для предотвращения проблем. Я также выполняю ядро 3.2.0-3, так не думайте, что снижение ядра помогло бы. –  StarNamer 21.07.2012, 03:26
  • 3
    Ну, это было бы моим последним средством, для ярмарки. Я очень не хочу повторно выполнить такие процедуры каждый раз, когда я получаю обновление ядра. Это - то, для чего DKMS. Так или иначе я полагаю, что мой случай является некоторой неопределенной проблемой компоновщика, которая я надеялся, что этот сайт может помочь с. :-( –  dimitarvp 21.07.2012, 13:35
[112591] Это нехорошо: [12285] Готов поспорить, что по крайней мере в нескольких из этих каталогов у вас были [12286]$PATH[113431] ed[113122] впереди [12287]/bin[12288] и [12289]/sbin[12290] - особенно в [12291]ruby[12292] - у вас были общие скрипты обертки оболочки оболочки для окрашивания вывода. Возможно у вас даже была похожая конфигурация в [12293]/etc/skel[12294]- в этом случае даже [12295]/bin/env -i grep[12296]не смог бы спасти вас от себя.[12297]- вот почему люди компилируют в [12298]chroot.[12299]P.S. Я так критичен только потому, что пару лет назад мне пришлось выучить тот же самый урок точно так же. Вам, наверное, не понадобилось бы [12300] = никогда [12301], если бы ваш [12302] $PATH[12303] был чистым. Кроме того, вы можете просто использовать [12304]-цвет=авто[12305]-в этом случае терминальные выходные данные используются только в том случае, если [12306]grep[113451]'s[113452]stdout[12307]- другими словами - не в [12308]|pipe[12309]-[12310]gcc. [12311]Или, что еще лучше, вместо установки негибкой оболочки [12312] под псевдонимом [12313] с:[12314]Вы можете воспользоваться настройкой [12315]grep[113601][113602]$ENV[12316]:[12317]
1
27.01.2020, 20:25

Теги

Похожие вопросы